On Sun, Jan 21 2018, Peter Hessler <phess...@openbsd.org> wrote: > On 2018 Jan 21 (Sun) at 21:45:53 +0100 (+0100), Jeremie Courreges-Anglas > wrote: > :On Sun, Jan 21 2018, Brian Callahan <bcal...@devio.us> wrote: > :> On 01/21/18 08:13, Peter Hessler wrote: > :>> On 2018 Jan 21 (Sun) at 02:06:52 -0500 (-0500), Brian Callahan wrote: > :>> :Finally, it looks like libffi needs libc++abi on arm for at least some > :>> :functions, as > :>> :experienced with lang/snobol4, its configure script didn't pick up > libffi and > :>> :instead > :>> :complained about this: > :>> :/usr/local/lib/libffi.so.1.2: undefined reference to > `__aeabi_unwind_cpp_pr0' > :>> :/usr/local/lib/libffi.so.1.2: undefined reference to > `__aeabi_unwind_cpp_pr1' > :>> :Those functions are in libc++abi. > :>> : > :>> > :>> Did you mean to include a patch to libffi.pc to address these issues? > :>> > :>> > :> > :> Ugh. No more 2am diffs more me. > :> > :> We just want this to be for arm, of course, to avoid breaking all gcc > :> archs. Attached diff deals. > : > :I think it would be better to link libffi against -lc++abi, inter-libs deps > :would be enough and would ensure that consumers don't need to use > :pkg-config. static builds would still need the pkg-config goo, but we > :don't have static archs any more. Do we have such ports? > : > > iirc, lld doesn't do inter-lib deps so we would still need pkg-config > help. while this isn't a problem *yet*, I'd like to avoid it being a > problem in the (hopefully near) future.
lld's behavior is a bit more convoluted: say your program links against libfoo, and libfoo in turn links against libbar. As long as your program only uses symbols from libfoo, you're fine. If the program also use symbols from libbar, you must tell lld to link your program against libfoo *and* libbar*. This is not the case here, linking libffi against libc++abi should be enough. If a port uses libffi and also needs functions from libc++abi/libunwind, it should specify so. * There's probably a more formal, better wording for the difference in behavior between our old ld(1) and lld. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
