[CMake] building static binaries

Michael Hertling mhertling at online.de
Thu Nov 11 09:21:17 EST 2010

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?



> @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 <mhertling at 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
>>> 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

More information about the CMake mailing list