This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version


On Wed, 18 May 2005 15:13:41 +0200, Jakub Jelinek wrote:
> Compiler built in presence of dl_iterate_phdr creates binaries and shared
> libraries, that rely on its presence in target glibc, as support code
> for older glibc's is intentionally left out in that case.

Why is that? Is the support code for older glibcs really that large?
 
> BTW, all glibc versions are really only backwards compatible, not forward
> compatible, new symbols are added through symbol versioning all the time.

Yes I know, I don't think this versioning system works very well to be
honest - it has a lot of problems (I think this was discussed on
fedora-devel-list some time ago).

It's possible to work around this using problem using auto-generated
headers with .symver directives in though.

> You can always install into a chroot an older distribution and
> compile/link programs in there if you want one library or binary to work
> with multiple OS releases.

Well, maintaining a separate build box (which is what this chroot thing is
equivalent to) is very painful:

- Old system == old libs that maybe your users no longer have, for
  instance your binary may end up depending on an old libncurses.so.4
  file when 99% of your users actually have libncurses.so.5, so you 
  have to manually upgrade bits of the system which breaks package
  management and you end up with a frankenstein box where you aren't
  sure what's on it. 

  For any complex app with lots of dependencies you need good testing
  to ensure this sort of "accidental dependency" doesn't become a problem.

- No security updates for old systems

- Old system means old compilers and headers that maybe can't compile your
  new code

The biggest problem really is that this sort of thing is a lot of effort
for your average evenings-and-weekends open source hacker who wants to
distribute Linux binaries to his end users. Setting up and maintaining a
dedicated build box or chroot is an awful lot of work for these people,
even if it's do-able by commercial developers.

It's also something Windows and Mac developers don't have to do, and
therefore don't expect (and they don't understand what they did wrong when
the problems inevitably appear).

I'd really love to see a proper debate on the merits of this
backwards-compatible-only policy. It seems many of the things that cause
binaries built on new systems to not work on older ones are just the
toolchain automatically enabling optimisations and new features. That's
fine for people who compile everything themselves or use only RPMs built
for their exact distro version, but it's a problem for developers who
would rather have easy binary portability than these optimisations and
features.

Even just a -frun-on-older switch would be great news for people like me
who distribute Linux binaries.

thanks -mike


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]