Looking For Static

Here is a curious problem: static linking standard C++ libraries into an executable binary. It is something that I have figured out how to do with a manually constructed link command. But I would really like to know if it’s possible to ask an autotools-based build environment to do the same thing. This is an interesting circumstance since a Linux developer does not usually need to be bothered with such matters; the build tools (autotools, in this case) just make the right build decisions depending on the host system. The build process for many software packages causes the software to ‘nest’ into the host system. Flash Player is different and I have a need to force this particular build decision.

Is there a setting in autoconf/automake and friends to ask the toolset to static link libstdc++? My searches on this matter have been fruitless, though some have alleged that there are projects out there that need to do this. Alternatively, I might be willing to evaluate other build systems (I often hear that SCons and CMake are leading contenders in this field) if they can fulfill this requirement, in addition to some other requirements (all quite reasonable):

  • automatically keep track of dependencies
  • manage multiple build targets
  • create multiple build configurations in separate directories, working from the same source tree

PS: To re-iterate a running theme on this blog, Adobe is not open sourcing the Player at this time. So please do not propose that as a possible solution to this quandary.

19 Responses to Looking For Static

  1. Albert Chin says:

    How about asking on the autoconf mailing list?I don’t think autoconf “knows” about static v. shared linkage. How do you envision “asking” the autotools system to link a static libstdc++? Maybe with -all-static, libtool should know how to do this but I don’t know if it does. The libtool list might know or simply link with the libtool on your system, adding -all-static.

  2. Elder says:

    I’m not sure it is what you’re looking for, but is this link related to it?http://sourceware.org/autobook/autobook/autobook_85.htmlIt is about the –enable-static option for configure.And this other link about the -static option for libtool?http://sources.redhat.com/autobook/autobook/autobook_173.html

  3. Sam Morris says:

    Linking libstdc++ statically has some recipes you may find useful.

  4. Ilya says:

    It’s obvious that what you’re trying to do is to avoid the libstdc++ dependency cause the version of g++ which people tend to have varies.I suggest you take a look at apbuild ( http://autopackage.org/aptools.html ) which provides the apgcc wrapper. This wrapper can flex many dependencies which you binary has. In particular, it has the APBUILD_STATIC option.For my Firefox extension’s (native) XPCOM object, I use:APBUILD_STATIC_LIBGCC=1 CC=apgcc CXX=apgccBy using (ap)gcc for building C++ code, I’m avoiding the explicit dependency on libstdc++ altogether. However, when Firefox runs, it will link to libstdc++ itself and thus I’d be happily using the C++ implementation which Firefox itself uses. Firefox is a much heavier user of C++ that me, so there’s more chances I’ll bring havoc into Firefox by insisting on my own prefered libstdc++ version than Firefox’s preferred one hurting my component.For more info, see:http://www.mozdev.org/source/browse/moztraybiff/source/Makefile?rev=1.24&content-type=text/x-cvsweb-markup&only_with_tag=v1-2-2(yeah, I’m not using autotools, but it doesn’t matter)

  5. Check out teTeX and pdfTeX; it does this, but it wasn’t easy.

  6. Luke says:

    configure can take a –enable-static command line to build static libs, I don’t know whether this will force the command to build the app statically.I’m also wondering if you post a blog entry (or reply to me) on how a commercial application can be distributed for Linux, i.e. how to manage the licence requirements and which linking method should be used. You’re obviously using static linking, but I thought that went against the LGPL and that you should actually link via shared libs.

  7. danny says:

    When you are linking the libraries, remember where possible to use shared libraries. Whenever the APIs of the library you are using have a stable API (which most do), link dynamically so if there is some security issue in the lib, when we update the library, Flash will be fixed too. This has led to big problems in the past with statically linked programs.

  8. Mike Kelly says:

    Hmm, with automake, you can define a few variables in your Makefile.am, like AM_LDFLAGS and AM_CXXFLAGS. Those will make sure that those flags are always appended to any other of those flags passed to the build system (e.g. through your environment).Also, I think there are some macros for enabling static building, but I can’t find them at the moment.

  9. Max Lybbert says:

    You may consider Boost Build ( http://www.boost.org/tools/build/v1/build_system.htm ). It’s designed by C++ programmers and meant to handle these kinds of problems.

  10. Auz says:

    I have run into a similar issue except with 64bit binary statically linked. I tried the -static and that did not seem to create a true static binary so I added +compat and things seemed to be a bit more koshur but i dunno what you are using to develop on so I don’t know if this will be any help. I also tried things like -lstdc++ and -Wl and -Bstatic etc with mixed results. I would also consider looking over the way that Qt from trolltech is built since I believe it also statically links libc++ for the same reasons. Blah good luck can’t wait for the new version!!

  11. ken says:

    just remember, if you ship a static compiled against a lgpl library as you are talking about, you must also distribute a dynamically linked binary as well

  12. r says:

    since you are using gentoo as a dev os.I would think it would be easiest to create an overay, and use all the facilities portage offers.Adding -static to CXXFLAGS or something might also work.since the player is closed source .. you shouldn’t be bothered by how dirty this solution is I figure…

  13. Jon S. says:

    I agree with one of the above commenters. Gentoo does offer a lot of flexibility and so much can be done with Portage, e.g. slots and various use flags, … so on. I use Gentoo every day and I have come across ebuilds that use a “static” flag. You might want to read those ebuilds and then see if they do what you are looking for, if so, you can create your own ebuild in the overlay and that would be your “script” (Some people talked about making a script). You can put anything in the compile section you want.You can also do multi-target building and chost building. There is the multilib tools in multilib.eclass (read that for more info) designed to work with, for example: AMD64 compiled as 64bit but has 32bit emulation installed. Binutils and GCC has some interesting useflags that may be what you want to look at? I guess you know most of this already though. Maybe this helps and maybe it doesn’t. I hope it does though.Oh, The Gentoo devs are friendly and they are on IRC. You can find most of them here:irc://irc.freenode.net/gentoo-dev-helpThey should be able to explain everything I touched on and better and help you out a lot. 😉 I know they can set you up with what you need to use Gentoo to it’s fullest.Cheers.

  14. Bloody says:

    @kenlidstdc++ is a special case; it can be linked statically without restrictions. See the license FAQ about that but the gist of it is that the source code of libstdc++ is distributed under GPL but with the run-time exception which means that the library can be used in proprietary applications without restrictions.Why not the LGPL? Here’s the quote from the FAQ to answer that:”The LGPL requires that users be able to replace the LGPL code with a modified version; this is trivial if the library in question is a C shared library. But there’s no way to make that work with C++, where much of the library consists of inline functions and templates, which are expanded inside the code that uses the library. So to allow people to replace the library code, someone using the library would have to distribute their own source, rendering the LGPL equivalent to the GPL.”

  15. Ronald Hummelink says:

    Since many people don’t really know this, i will make a note of it:There is a small but important issue involving statically linked gnu libc and the NSS libraries (amongst user and hostname lookups are done through these libnss_*.so libs)Even a statically linked libc will go through /etc/nsswitch.conf and use (dlopen() or something) the libraries on the target machine, since these libraries are NOT part of libc.aIf the static linked version of libc is from a different (incompatible) version then the target machine libnss files you are very very likely to segfault IF you do host/user/etc lookups.(I personally had issues with 3ware’s monitor daemon because it was static vs libc, and the Linuxfromscratch.org project has been bitten in the past by the same issue as well)I’m guessing here you want to link libc statically to broaden the distributions you can run the executable on, which are frequently running older (and incompatible NSS wise) versions of gnu libc then Gentoo.If this is the case it may well be a better solution to use a build machine with the lowerst version of libc you intent to support and link dynamically. Libc’s backwards compatibily is a lot better then its support for static linked tricks.Cheers

  16. Carey Evans says:

    If it’s too hard to get libstdc++ reliably statically linked, you might have more success statically compiling your own copy of STLport. This has an even less restrictive license than libstdc++, too.

  17. Moritz Barsnick says:

    If license issues with static linking become too much of a concern, you might want to spend a little cash and use a C++ compiler which comes with its own (statically linkable) C++ library, such as the Intel C++ Compiler. It uses libcxa instead of libstdc++ (flag “-cxxlib-icc”), and gladly links it statically with the flag “-static-libcxa”.

  18. Segin says:

    Why do you care about using autotools? You’re producing a binary-only product. You houldn’t have to worry about discrepancies in the end-user’s enviroment. If it doesn’t work for them, you can always take the route of every single other proprietary software vendor and tell the few users for who it doesn’t work to go get fucked.Or is this a little slip-up that you guys are going to release the source?Meh, I am just messing with your heads. But still, if you’re going with Autotools becuase you fear binary incompatability across distributions, don’t worry about it. Most of this is random FUD from glibc/gcc/bintuils devs right after they’ve just nosed a line or two. Hell, you can have a program link against libc5 and have it also link against libraries that are in turn linked against libc6, and they still work. Only thing to remember is to symlink the /lib/ld-linux.so.2 to /lib/ld-linux.so.1 (which I was told by a number of people would fail, which they were dead wrong)

  19. James Potts says:

    Something you might want to consider (if it’s even possible – I’m not sure), in addition to providing a statically linked version of the player for, say, Debian/Red Hat/Fedora/Mandriva, is providing a version of the player as an object library – compiled, if possible, to be independent of any particular libstdc++ implementation, and with the minimum amount of source code provided to perform “final” linking into an actual netscape plugin/mozilla extension.Ideally the following portions of source code would be provided: video backend, audio backend, input backend (the parts that connect directly to the OS, not the parts that connect directly to the flash API – for example, in the audio portion, what would need to be released is the code that takes the already-mixed sound output and sends it to ALSA), and any other necessary code portions which need to be built against libc, etc.What should not be provided: any part of the source code which exposes the flash API directly, or which exposes any of the internals of how flash works (unless you just want to provide such code).This would allow the people behind various distros to rebuild the necessary parts of the player to suit their configurations (i.e. build it against libc5/6, build for a newer or older version of alsa (or, if necessary (bsd, maybe?), against OSS), build specifically with selinux in mind, etc), which could save you a lot of headaches in the future (especially if you provided no official support for any plugin binary built from this).Please note: I am not requesting the open-sourcing of the flash player. While I think that this would be a Good Thing, I don’t see that you’re amenable to the idea, and am pretty sure that, because of the marketing model behind flash, you probably never will be. Thus the solution I propose – it keeps the flash/swf format closed, while providing the means to get the flash player working on as many different platforms as possible.Here’s hoping this helps.–JP