On 17/05/15 17:41, Justin Cormack wrote:
There is another problem - unlike the __aeabi_* symbols and the
__sync_ ones, these do not seem to be standard, so Linux on arm does
not supply them as far as I can see. So programs linked against
rump+linux libc rather than rump_netbsd libc are going to have issues
if they need these symbols - we havent run into the issue as nothing
has actually needed them yet.

I'm not 100% sure what "these" refers to, but at any rate, in case __symbols are used internally (i.e. _NOT_ via the toolchain), they should be used via an internal alias instead of via the toolchain alias.

... which is not to say I'm denying a problem exists, just saying that if one exists, fixing it requires rototilling code to conform to what the code already should be conforming to.

Reply via email to