From mboxrd@z Thu Jan  1 00:00:00 1970
From: espie@quatramaran.ens.fr
To: rth@cygnus.com
Cc: egcs@egcs.cygnus.com
Subject: Re: ISO C violation (really -- style & string pasting)
Date: Wed, 31 Mar 1999 23:46:00 -0000
Message-ID: <19990325231046.13760.qmail@quatramaran.ens.fr>
References: <36F9848A.9F566D1A@interix.com> <19990325142948.E27147@cygnus.com>
X-SW-Source: 1999-03n/msg00836.html
Message-ID: <19990331234600.mykj2lELQmazqBxwUqeGvXZHfnF6CTNLqSHFn5nIcc0@z>

In article < 19990325142948.E27147@cygnus.com > you write:
>No.  Just create a GLOBAL_OFFSET_TABLE_SYMBOL define to use
>within i386.{h,c,md} instead of the current string literal.
>You can then override this for coff or whatever as needed.

>Probably no one's noticed this before because coff doesn't
>use pic on any currently supported platform.

Same problem occurs with a.out, and I do happen to have an i386
a.out platform that does support pic (yep, it's a hack... an old binutils
that got hacked to get pic support for i386... we're looking to upgrading
OpenBSD to newer tools post-2.5).

Part of the problem is that you can't change gcc without changing
the linker as well... the other part of the problem is that this can
snowball: this _GLOBAL_OFFSET_TABLE_ is also present in sparc code,
and I believe this particular spelling was picked in order to be
plug-compatible with the native SunOS 4 linker...  

I'm not really sure there's a way to fix that without breaking compatibility
at one point or another... stuff that we got source to is no big deal (like 
the linker), getting people to upgrade all their tools may just be harder,
getting vendors to distribute newer dynamic libraries might be next to
impossible.