On 11/03/2010 10:36 PM, Szilárd Páll wrote: > Hi, > > First of all, I'd be grateful for a reply to the 2nd of my question. > Can anyone confirm that LINK_SEARCH_END_STATIC on Linux + gcc is > buggy?
Indeed, I can confirm that enabling the LINK_SEARCH_END_STATIC target property without further measures results in "cannot find -lgcc_s" on my Linux with GCC. Additionally including "-static" in the LINK_FLAGS succeeds, but prevents linking against shared libraries at all, and I doubt if this is the intention of the LINK_SEARCH_END_STATIC property. Perhaps an issue with GCC? Regards, Michael > @Michael: Thanks for the link, I've actually seen that thread, but I > was quite disappointed by the conclusions so I asked with the hope > that the opinion of the developers has shifted. > > I have only one thing to add to the static/shared library finding > business. Although I understand that the Win community is large enough > to invalidate certain CMake feature requests that do not favor this > OS, but IMHO in this case it would be fairly straightforward to > implement this feature for at least a dozen *NIX OS-es. In particular, > I like the suggestion that Philip Lowman suggested > (http://www.mail-archive.com/cmake@cmake.org/msg21354.html). > > -- > Szilárd > > > > On Wed, Nov 3, 2010 at 5:57 PM, Michael Hertling <mhertl...@online.de> wrote: >> On 11/02/2010 10:54 PM, Szilárd Páll wrote: >>> Hi, >>> >>> I've been trying to implement a feature which would enable building >>> static binaries with cmake, but I've got completely stuck, I hope >>> someone can hint me what's the best way to do this. >>> >>> What I've done is a 2 stage solution for making static binaries: >>> >>> 1) Telling cmake to prefer picking up ".a"-s when searching for >>> libraries (CMAKE_FIND_LIBRARY_SUFFIXES). >>> >>> This works fine, but referring to file extensions/endings might not be >>> general enough. Making it less platform-dependent would require >>> rewriting the way external libraries are treated: instead of adding >>> them with full path we'd need to add -Lpath -llibname separately. Any >>> other ways for doing this? >>> >>> >>> 2) Telling cmake to use static system libraries. >>> >>> This should work with the target property LINK_SEARCH_END_STATIC which >>> essentially should result in a the system libs linked in statically >>> whenever possible (depending on the platform). Well, it seems that >>> even in fairly straightforward situations (Linux + gcc) I get the a >>> linker error: /usr/bin/ld: cannot find -lgcc_s. >>> >>> Obviously, libgcc_s.a is not available, but by looking at the verbose >>> output, the implicit gcc linker call contains the "-Wl,-Bstatic" >>> argument. This AFAIK is not correct, or more precisely not enough to >>> just tell ld to link statically, gcc also has to know about it >>> (through the "-static" argument). Can anyone confirm this? >>> >>> >>> I'd be grateful for tips on how to fix the issue with 2), but I'm open >>> for other portable (and preferably elegant) solutions. >> >> FYI: See [1], and in particular [2] and [3]. >> >> Regards, >> >> Michael >> >> [1] http://www.mail-archive.com/cmake@cmake.org/msg21106.html >> [2] http://www.mail-archive.com/cmake@cmake.org/msg21317.html >> [3] http://www.mail-archive.com/cmake@cmake.org/msg21416.html _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
