> On 13 Mar 2017, at 05:20, Jeffrey Walton <noloader@xxxxxxxxx> wrote: > >>> [QUESTION]: libiconv included in sourcetree was build, but later ignored at link time in favor of system libiconv? >> >> The system linker ld64 [at least at the 85.2.1 version from XCode 3.1.4] will prefer a shared library if it finds one (even if there is a convenience library of the same name first on the link line). >> >> There is a reason for this - to do with the different model for symbol resolution in the Mach-O toolchain (c.f. the ELF ones, for example). This has some advantages (only need to present libraries once) and some gotchas (the shlib will be found over the convenience one). Recent versions of ld64 have more controls over this, but you’d need to use my port of the PPC stuff (since that was dropped from ld64 around XCode 3.2.x). > > Thanks for that Iain. I've always wondered about that behaviour; > especially on iOS where most user programs cannot dynamically link to > libraries. Actually, my reply was too terse - and conflates two things ;-) The different symbol resolution scheme refers to the revisiting of libraries multiple times (rather than needing them placed on the link line multiple times). There’s quite a lot of good developer documentation for Darwin shared libraries and the general processes of resolution at link and runtime. The library path search order aspect is described in “man ld” by -search_paths_first. Note that the default for this option has changed so you might want to check for the specific ld64 version you’re using. so for example (on Darwin10 / OS X 10.6) if we have: shared/ libfoo.dylib conv/ libfoo.a both/ libfoo.dylib libfoo.a then gcc -Lconv -Lshared … -lfoo — will find the shared library gcc -Lconv -Lshared … -Wl,-search_paths_first -lfoo — will find the convenience library gcc -Lboth … -lfoo — will find the shared library regardless of the setting of search_paths_first (if you want to use the convenience library in “both” you have to pass the path “both/libfoo.a” explicitly instead of -lfoo). I.e, there is no ‘per library’ control (no easy equivalent of -Bstatic -Bdynamic). Because /usr/lib and /usr/local/lib are default search paths, then with the default search path ordering for ld64 on say 10.5 - a shared library in /usr/lib will be found by preference to a convenience one in an earlier -L path. So in the specific case mentioned, /usr/lib/libiconv.dylib would be found instead of project/libiconv.a As noted, you can alter that with -search_paths_first, but it applies in a general sense to the link line - not per library (and there’s no way, that I’m aware of, other than specifying the convenience library path, to pick a convenience library in the same directory as a shared one of the same name). Hopefully, that’s a better explanation (noting again that the default for -search_paths_first is dependent on the version of ld64 you’re using). cheers, Iain
