kicad-developers team mailing list archive

["Lorenzo" <lomarcan@...>]

--- In kicad-devel@xxxxxxxxxxxxxxx, Dick Hollenbeck <dick@...> wrote:

> 
> There are two suggestions below to address this problem:
> 
> 
> 1)
> 
> 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 itas 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 thebinaries updated
- Build binaries for the most 'available' distro... i.e. a debian one and acentos/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 thesefrom 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!).