<div dir="ltr"><div><br></div>Since I'm working in a single threaded environment I created a stub which always returned true. I'm stuck with the atomic dependencies from tensorflow even though it's a single core target.<div><br></div><div>The project now builds successfully, although I'm back at the run time error now! Definitely getting closer though,</div><div><br></div><div>Thanks for the help.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 7, 2018 at 2:20 PM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 7 Aug 2018, at 14:10, Pete Blacker <<a href="mailto:pete.blacker@gmail.com">pete.blacker@gmail.com</a>> wrote:<br>
> <br>
> atomic.c now compiles without warning but it's failing to link with a lot of undefined reference to `__atomic_is_lock_free' errors. This is definitely progress!<br>
> <br>
> Is this simply a case of adding another source file from the llvm builtins?<br>
<br>
</span>This one is harder.  These are all meant to be compiler-provided builtins that tell the system whether it can do atomic operations of a particular size or whether it needs to do a library call (or, in the case of the stuff in atomic.c, use a lock).<br>
<br>
You might be able to get away with providing a stub definition of __atomic_is_lock_free that always returns false.  This should then cause the library functions to use a mutex.  You will need a compiler that can at least provide a simple compare and swap to implement a spinlock though… (or you’ll need to add a new locking implementation in atomic.c that uses some assembly for your target).<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
<br>
<br>
</font></span></blockquote></div><br></div>