Well, as far as I know you can take the .a-file with linking to the full path... I don't know why CMake doesn't keep the parameters I give them? Probably if I add the libraries to the linking variables, it would take them, but that's not the point :S... If I pass CMake a full static path, I expect CMake to keep it like that.
For example: If I had: /home/user/libwx.a /home/user/libwx.so I could easily link to the static one by supplying: -l/home/user/libwx.a, and it would take the static one, not the dynamic. That's how I always worked before. So it really is possible to link statically even with same name dynamic libraries in the directory... I just don't know why CMake doesn't keep it the way I tell the program to. On 12/13/07, James Bigler <[EMAIL PROTECTED]> wrote: > 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
