The mac linker is unique in how it searches for libraries. The
linker will *always* pick the shared library over the static one if
it finds a shared one first or at the same time. Also the order it
searches the library path list is different than on other *nix systems.
By default the linker searches the paths in a depth first search.
Take the following example:
/usr/lib/libmylib.so
/home/user/libmylib.so
-L/home/user -lmylib
This will pick /home/user/libmylib.so
Now if you had this:
/usr/lib/libmylib.so
/home/user/libmylib.a
-L/home/user -lmylib
This will pick up /usr/lib/libmylib.so, not /home/user/libmylib.a.
This is because the linker looks through all the paths for a .so,
then it looks through all the paths for a .a.
You can fix this by adding a flag: -search_paths_first
Doing a man on ld produces this:
-search_paths_first
By default when the -dynamic flag is in effect,
the -lx and
-weak-lx options first search for a file of
the form
`libx.dylib' in each directory in the library search
path, then
a file of the form `libx.a' is searched for in
the library
search paths. This option changes it so that in
each path
`libx.dylib' is searched for then `libx.a' before the
next path
in the library search path is searched.
I mentioned this on the mailing list a while back, and I was told
that this flag was going to be added by default. I don't know if
that ever happened or what version it made it in.
Also, note that if you have a .a and .dylib in the same path it will
always pick the .dylib file. No magic flags for that, I'm afraid.
James
On Dec 13, 2007, at 1:58 PM, Steven Van Ingelgem wrote:
Hi,
I was talking to Miguel about the recent FindwxWidgets changes because
they didn't work out on for static libraries on a Mac.
Summarizing the issue is that CMake makes the (wrong) assumption that
what you want to add are shared libraries (at least on a Mac).
Let me explain in more detail what happens:
The outcome of the Find-file is:
wxWidgets_LIBRARIES: -arch ppc;-arch i386;;-framework
QuickTime;-framework IOKit;-framework Carbon;-framework
Cocoa;-framework
System;;/usr/lib/libwx_macu_adv-2.9.a;/usr/lib/
libwx_macu_core-2.9.a;/usr/lib/libwx_base_carbonu_net-2.9.a;/usr/
lib/libwx_base_carbonu-2.9.a;/usr/lib/libwx_base_carbonu_xml-2.9.a;-
framework
WebKit;-lwxregexu-2.9;-lwxexpat-2.9;-lwxtiff-2.9;-lwxjpeg-2.9;-
lwxpng-2.9;-lwxzlib-2.9;-lpthread;-liconv
As you might notice it's a mix of static and dynamic libraries.
Then I add them with the command
TARGET_LINK_LIBRARIES(...)
Then when I want to link them on a Linux it adds -Wl,-Bstatic -l...
where ... is the NAME of the library, not the path that was passed in.
Example: -Wl,-Bstatic -lwx_macu_core-2.9 -
lwx_base_carbonu_net-2.9 ... etc ...
Now on a Mac (XCode 2.5, GCC 4.0.1) this -Wl flag doesn't exist, but
the library list STILL includes "-lwx_macu_core-2.9
-lwx_base_carbonu_net-2.9", so the directory where it needs to look
for the static libraries is lost.
My proposal is to change the behaviour of CMake to add the static
libraries as they are given on the command line... The user knows
best! For example if I would have a static library in
/home/steven/test/libtest.a, and one in /usr/lib/libtest.a with BOTH
the same name, and BOTH static, but I add the
/home/steven/test/libtest.a, then CMake will end up using the
/usr/lib/libtest.a... Even though I said to use the one in "home".
I hope I made myself completely clear here... And I hope I'm not going
completely nuts here or is this really a bug in CMake?
Steven, out.
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
