Re: Why Gnome RPMS need to work with RH 5.2
- From: Eric Kidd <eric kidd pobox com>
- To: gnome-list gnome org
- Subject: Re: Why Gnome RPMS need to work with RH 5.2
- Date: Tue, 6 Apr 1999 18:18:52 -0400
On Tue, Apr 06, 1999 at 03:52:04PM -0600, Dean Elhard wrote:
> My experience with this is not that the libraries are incompatible, but
> that some of the headers configured on a system using egcs have
> configuration defines which are specific to egcs, and will cause
> subsequent compiles using those headers with gcc to fail.
I've just received verification on the egcs list that there are serious
compatibility issues with the gcc 2.7 and egcs runtime libraries. This
typically causes problems when you compile a shared library with egcs and
then link a gcc-compiled application against it. If you start seeing errors
about __register_frame_info, you've found this problem.
The workaround seems to involve linking certain pieces of the egcs runtime
into glibc 2.1 and crossing your fingers. :-( Getting this right seems to
be very tricky. If you're not careful, you'll break the binary
compatibility of certain sonames on your system. Being linked against glibc
2.0 instead of 2.1 somehow makes everything worse. I'm still trying to
understand the details, and will post a better explanation when and if I
figure things out.
The Gnome RPMS currently on the FTP site break binary compatibility of
several sonames. This means that things can be expected to go wrong unless
you recompile every application that was linked against them. Yes, the
purpose of sonames is to prevent this.
#include <binary_compatibility_flame.h>
Cheers,
Eric
> What this boils down to is that the binraies should interoperate, but
> if you try to do a source compile using gcc when certail libraries
> have been configured using egcs, it won;t work.
>
> An example is the glib libraries where the config header installed
> with the library contains the line:
> #define VA_COPY __va_copy
> which is not defines in gcc 2.7.2.x
>
> Some of this is just a question of being careful to only include
> config-dependent items in public headers which are tied to correct
> calling of the public interface. I haven't looked at the case I
> mentioned to see if the interface is actually dependent on this
> define, but I would guess that It isn't.
>
> =============\ http://members.home.net/dean-elhard /=================
> Dean Elhard \_____ dean_elhard@viasoft.com ____/ I'm a telepath...
> (NOT speaking for) \ dean-elhard@home.com / Work It out...
> Viasoft Inc. \______________________/ Bester - Babylon 5
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]