kicad-developers team mailing list archive
Mailing list archive
Re: Re: libstdc++
--- In kicad-devel@xxxxxxxxxxxxxxx, Dick Hollenbeck <dick@...> wrote:
There are two suggestions below to address this problem:
One thing we can explore it to statically link libstdc++ to each of our
programs, just libstdc++, not libc.
The wx libraries will be built on the host, so I think they can continue
to be dynamically linked into the host system's libstdc++.
Actually the *recommended* way to use libstd++ is as a static lib (said by the gcc people themselves!). Of course most (all?) the distro distribute it as a dso because otherwise you add about 2MB to each executable :P
The conflict issues because the stdc++ ABI is depending on the compiler version (only the major one, usually). But not everyone has gcc4, there are still a lot of gcc3 around. Also most of the STL is actually generated from templates so the issues are bigger.
IMHO there are only two ways to handle this:
- Force source compilation and hope for some package mantainers to keep the binaries updated
- Build binaries for the most 'available' distro... i.e. a debian one and a centos/rh one (of course the debian one will work on ubuntu and *usually* the rh one works for the other distro around too).
Debian is usually the difficult one because it patches about everything (libc and PAM included! the pam files for debian are NOT compatible with these from any other system...)
As an aside I remember one version of oracle 8i which could be installed only on *one specific version* of RHE: the installer didn't even start otherwise (that was because oracle needed to patch libc itself to expose some private symbol!).
Commercial FPGA folks handle this by simply distributing the
libstdc++.so with their apps.
You add a third option, compile for the everyone.
But I insist that my two options are still valid, and wonder if
statically linking in libstdc++ will add 2 MB, since this is a "link
only what's needed" form of link.