间接依赖Mac OS X的链接问题

Question

we have some linking problems with indirect dependencies. Guessing from what I read on the web it may be because of two-level namespace usage. This happens when we link against a boost library, boost_filesystem to be precise, which itself depends on boost_system. The linker doesn't resolve the dependency between boost_filesystem and boost_system. Can someone give me some hints how this can be resolved? Adding boost_system manually to the dependencies feels ugly and besides, it works fine on other platforms.

Answer 1

Some versions of the static link editor ld on Mac do not resolve indirect dependencies via the -L option and instead simply look them up via the install_name that is baked into the direct dependency. Running otool -L on boost_filesysten will show you where ld is looking for boost_system.

You can either change the install_name with install_name_tool or you can use the

-dylib_file install_name:file_name

option to ld which is just a way of telling ld that whenever it comes across an install_name path matching the part of the argument before the colon then it should actually get that library from the path after the colon.

I think that newer versions of ld now do respect -L for indirect dependencies on Mac but I'm not sure. I've only used 10.4 which had an ld that ignored -L for indirect dependencies and I used -dylib_file to get rid of a lot of phantom explicit dependencies that other people had put in to get round the very problem you describe!

Answer 2

If boost_filesystem is using symbols from boost_system (and your application isn't), and is itself linking directly against boost_system to resolve them, it should just work. The flat vs. two-level namespace problems generally rear their head when you expect symbols provided by a dependency of a library you're linking against to be available within your app.

If boost_filesystem isn't linking against boost_system (otool -L will tell you), then you've got little option—short of relinking it—except to add a manual dependency upon boost_system.

Am I right in thinking boost doesn't use GNU libtool (it handles inter-library dependencies in the correct platform-specific way for you)? If it does, that might be an easy workaround.