I'm a C++ programmer that is porting from Windows to the Linux world. So far things are great. I've recently tried to use the -static option with gcc to generate binaries that are more portable, and so far it works. The only problem is that in FC5 the static libs are being removed (libjpeg-devel - see ticket # 145971). I understand that Shared libraries save space and this is good for software that is bundled with the OS, but for third party vendors, static would be a more ideal solution. I own my own company with one product available for Windows (currently it's my bread and butter). I don't have the resources available (just me) to release a Linux based solution for every major distro out there such as the Wine project does (fyi : I've contributed to that project - a few lines). The size of these libraries is not that much, my system only has 30MBs of static libs, compared to the 3GB disc image size. I tried to move a binary built on FC5 to a FC4 system and of course it didn't work (openssl version mismatch). So by removing static libs Fedora will be hurting the little guys (like me). I also know that some functions (like dlopen()) currently do not work in static mode, but some of my apps don't need this functionality. I've written my own DNS client, so the gethostaddr() etc functions I don't need. Does anyone know if it would be possible to use most libraries as static and maybe just use the shared version of dl, or glibc?
I can see Linux (possibly Fedora) taking on Windows head-to-head some day, but without static libs Fedora would be crippling our options and force some of us to other options.
If you would like to check out my "free" projects, goto http://digiforce.sourceforge.net and http://javaforce.sourceforge.net. Anyways, Thanks for listening.
On Thu, 2005-12-15 at 23:48 +0000, Peter Jr. Quiring wrote:
I'm a C++ programmer that is porting from Windows to the Linux world. So far things are great. I've recently tried to use the -static option with gcc to generate binaries that are more portable, and so far it works. The only problem is that in FC5 the static libs are being removed (libjpeg-devel
- see ticket # 145971). I understand that Shared libraries save space and
this is good for software that is bundled with the OS, but for third party vendors, static would be a more ideal solution. I own my own company with one product available for Windows (currently it's my bread and butter). I don't have the resources available (just me) to release a Linux based solution for every major distro out there such as the Wine project does (fyi : I've contributed to that project - a few lines). The size of these libraries is not that much, my system only has 30MBs of static libs, compared to the 3GB disc image size. I tried to move a binary built on FC5 to a FC4 system and of course it didn't work (openssl version mismatch). So by removing static libs Fedora will be hurting the little guys (like me). I also know that some functions (like dlopen()) currently do not work in static mode, but some of my apps don't need this functionality. I've written my own DNS client, so the gethostaddr() etc functions I don't need. Does anyone know if it would be possible to use most libraries as static and maybe just use the shared version of dl, or glibc?
I don't know much about C++ compiling, but from a company standpoint, why can't you publish your software in source form, then do some builds for your targetted supported OSs, such as Fedora. If it is in source form, and uses dynamic linking, then folks that want your software in other distributions can rebuild it themselves? Better yet, pair up with a Fedora Extras maintainer so that your source gets built by the maintainer and pushed into Extras for all to use. Upstream doe source, distros compile it.
On Thursday 15 December 2005 18:48, Peter Jr. Quiring wrote:
I can see Linux (possibly Fedora) taking on Windows head-to-head some day, but without static libs Fedora would be crippling our options and force some of us to other options.
There has been much discussion about this over the years but eventually it always comes down to the fact that shared libraries are the way the Unix world has been going.
There are two reasonable things you can do:
1) Get over it. Then you will have to compile and (should) package separately for different platforms (RHEL, Fedora, SuSE, Debian, ...)
2) Package the shared libraries. You still should package for the different platforms (which then leaves the questions on why you don't just compile for them specifically). Then, write a wrapper shell script and either uses LD_LIBRARY_PATH or LD_PRELOAD (depends on if you already loaded libs to be loaded or not) and then executes the real binary...
Of course if you do 2, then you'll get lots of people that will complain the packaging... If you're serious, I can only recommend that you do it like everyone else does...
Peter.
On Thu, Dec 15, 2005 at 11:48:26PM +0000, Peter Jr. Quiring wrote:
I tried to move a binary built on FC5 to a FC4 system and of course it didn't work (openssl version mismatch). So by removing static libs Fedora will be hurting the little guys (like me). I also know that some
openssl is a problem area certainly.
functions (like dlopen()) currently do not work in static mode, but some of my apps don't need this functionality. I've written my own DNS client, so the gethostaddr() etc functions I don't need. Does anyone know if it would be possible to use most libraries as static and maybe just use the shared version of dl, or glibc?
To be honest Fedora is aimed at being cutting edge rather than being the proprietary high stability oriented platform. What you say is I think quite fair in terms of C++. For C the LSB has it mostly licked, for C++ the changing C++ ABI has been problematic.
Usually btw the way to get good compatibility is to build on old. Old to new is generally very good (you might need to also ship copies of 'legacy' library versions for things like openssl) but glibc and the like work well and handle versioning. New to old is always trickier.
Alan
On Thu, 2005-12-15 at 19:25 -0500, Alan Cox wrote:
On Thu, Dec 15, 2005 at 11:48:26PM +0000, Peter Jr. Quiring wrote:
I tried to move a binary built on FC5 to a FC4 system and of course it didn't work (openssl version mismatch). So by removing static libs Fedora will be hurting the little guys (like me). I also know that some
openssl is a problem area certainly.
functions (like dlopen()) currently do not work in static mode, but some of my apps don't need this functionality. I've written my own DNS client, so the gethostaddr() etc functions I don't need. Does anyone know if it would be possible to use most libraries as static and maybe just use the shared version of dl, or glibc?
To be honest Fedora is aimed at being cutting edge rather than being the proprietary high stability oriented platform. What you say is I think quite fair in terms of C++. For C the LSB has it mostly licked, for C++ the changing C++ ABI has been problematic.
Both the compiler ABI and the libstdc++ ABI. The former is understandable, but there's no excuse for the latter.
Shared libraries using GNU C++ on ELF systems are a path to madness, and they'll stay that way until the libstdc++ people start practicing basic software maintenance skills, or glibc's ld.so gets support for DT_1_GROUP.
Once upon a time, Peter Jr. Quiring pquiring@hotmail.com said:
I understand that Shared libraries save space and this is good for software that is bundled with the OS, but for third party vendors, static would be a more ideal solution.
They don't just save space on the disk; they save RAM (as shared libraries can be shared between processes).
I tried to move a binary built on FC5 to a FC4 system and of course it didn't work (openssl version mismatch).
Another benefit of shared libraries is that a security or bugfix update to the library only requires a new library; all programs using the shared library get the fix. Any programs that used static linking will have to be rebuilt. OpenSSL has had several such security updates for example.
Also, according to the terms of the LGPL (which for example glibc is licensed under), if link your program statically to an LGPL library, you need to include the object and/or source code of your program in any distribution (or an offer for the object and/or source) so that it could be relinked against the LGPLed library.
On Thu, 2005-12-15 at 23:48 +0000, Peter Jr. Quiring wrote:
I'm a C++ programmer that is porting from Windows to the Linux world. So far things are great. I've recently tried to use the -static option with gcc to generate binaries that are more portable, and so far it works.
the problem is that due to a bunch of technicalities, -static binaries are LESS portable in linux, not more portable.
http://people.redhat.com/drepper/no_static_linking.html
However there is a middle ground; static link only the lib(s) that are a real portability problem, eg libstdc++, but not the rest. (at which point you need to be careful wrt the LGPL already but I don't know the exact details of the libstdc++ license, it may well have an exception for this).
Linking openssl static sounds like a nightmare from a security update pov.... it's better to avoid it anyway in non-core-OS software due to the very unstable ABI.
btw the way to only link libstdc++ static is this: -Wl,-static -lstdc++ -Wl,-dynamic
On Fri, Dec 16, 2005 at 09:11:22AM +0100, Arjan van de Ven wrote:
On Thu, 2005-12-15 at 23:48 +0000, Peter Jr. Quiring wrote:
I'm a C++ programmer that is porting from Windows to the Linux world. So far things are great. I've recently tried to use the -static option with gcc to generate binaries that are more portable, and so far it works.
the problem is that due to a bunch of technicalities, -static binaries are LESS portable in linux, not more portable.
http://people.redhat.com/drepper/no_static_linking.html
However there is a middle ground; static link only the lib(s) that are a real portability problem, eg libstdc++, but not the rest. (at which point you need to be careful wrt the LGPL already but I don't know the exact details of the libstdc++ license, it may well have an exception for this).
Linking openssl static sounds like a nightmare from a security update pov.... it's better to avoid it anyway in non-core-OS software due to the very unstable ABI.
btw the way to only link libstdc++ static is this: -Wl,-static -lstdc++ -Wl,-dynamic
-Wl,-Bstatic -lstdc++ -Wl,-Bdynamic actually (and always make sure the command line ends in -Bdynamic state, as that's what will be used for the implicitly added libraries (-lc, -lgcc_s (sometimes), -lpthread (sometimes)).
I should note that libstdc++ is not bad ABI-wise recently, GCC 3.4, 4.0 (and the upcoming 4.1) are all (backwards) binary compatible. So if you build against GCC 3.4 (e.g. FC3 or RHEL4), it will work on FC3/FC4/FC5/RHEL4/(likely RHEL5) libstdc++/C++ ABI wise as well as any other distro that ships with GCC 3.4/4.0/4.1. Of course other libraries like openssl might be a problem.
Jakub
It really depends on what the software is intended to. For system softwares dynamic linking is unavoidable, but for numerical software, where the security/bugfixes/nss/glibc arguments don't hold having statically linked binaries may be of help. I have static binaries that work since 6 or more years and it is very convenient to just run them on any new linux.
I still agree that linking statically in general and especially with openssl isn't a good choice.
-- Pat
On Fri, 2005-12-16 at 10:33 +0100, Patrice Dumas wrote:
It really depends on what the software is intended to. For system softwares dynamic linking is unavoidable, but for numerical software, where the security/bugfixes/nss/glibc arguments don't hold having statically linked binaries may be of help. I have static binaries that work since 6 or more years and it is very convenient to just run them on any new linux.
but as long as you didn't use "evil" libraries, you'd be able to run them on any new linux when they were dynamic linked as well.
Regarding dynamic-vs-static, I was wondering what effects does it have when an app is linked either way. Does anyone know exactly?
Also, what about pie-vs-nonpie?
thanks,
On Fri, 2005-12-16 at 15:22 +0100, Pozsar Balazs wrote:
On Fri, Dec 16, 2005 at 02:47:24PM +0100, Pozsar Balazs wrote:
Regarding dynamic-vs-static, I was wondering what effects does it have when an app is linked either way. Does anyone know exactly?
Err... I meant what effect _on execution speed_ does it have?
A statically linked application by itself with a lot of memory might execute a bit faster. However, if all apps were statically linked then all library code would be duplicated in each application leading to general system slowdown due to more swapping and worse cache behaviour.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a scrappy voodoo Green Beret possessed of the uncanny powers of an insect. She's a vivacious paranoid traffic cop with a birthmark shaped like Liberty's torch. They fight crime!
Alexander Larsson wrote:
On Fri, 2005-12-16 at 15:22 +0100, Pozsar Balazs wrote:
On Fri, Dec 16, 2005 at 02:47:24PM +0100, Pozsar Balazs wrote:
Regarding dynamic-vs-static, I was wondering what effects does it have when an app is linked either way. Does anyone know exactly?
Err... I meant what effect _on execution speed_ does it have?
A statically linked application by itself with a lot of memory might execute a bit faster. However, if all apps were statically linked then all library code would be duplicated in each application leading to general system slowdown due to more swapping and worse cache behaviour.
Exactly. This is particularly true of a desktop environment with gnome applications which generally share a lot of dynamic libraries. The hotter cache results in much faster startup times and response time for gnome apps.
On Fri, 2005-12-16 at 15:22 +0100, Pozsar Balazs wrote:
On Fri, Dec 16, 2005 at 02:47:24PM +0100, Pozsar Balazs wrote:
Regarding dynamic-vs-static, I was wondering what effects does it have when an app is linked either way. Does anyone know exactly?
Err... I meant what effect _on execution speed_ does it have?
on x86 you pay a small overhead (single digit percents nowadays), on x64 it's mostly free.... in the single use case in the multiple-use case there is actually an advantage due to more efficient use of L1/L2 cache