This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bug report: objc classes linked in wrong order
- To: nicola at brainstorm dot co dot uk
- Subject: Re: Bug report: objc classes linked in wrong order
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 15 May 2000 13:50:41 -0600
- cc: hjl at lucon dot org, egcs at egcs dot cygnus dot com, ovidiu at cup dot hp dot com
- Reply-To: law at cygnus dot com
In message <Pine.LNX.4.10.10005151138270.1862-100000@lin9.brainstorm.co.uk>yo
u write:
> A good idea would simply be not to link in the NXConstantString
> implementation in the shared libobjc. I know people who like this idea a
> lot. My opinion is that this would not allow people to run objective-C
> code without linking to GNUstep or another library providing an
> implementation of NXConstantString - and we don't want to scare newcomers,
I think this would be a major mistake.
Having worked with shared libraries under Unix for about 10 years now
across a variety of platforms I've learned that providing different
routines in the shared vs archive libraries is one of the biggest
mistakes you can make. It leads to nothing but problems for developers
and users. It's simply a losing proposition.
> so my proposal is to use the following patch to libobjc/init.c:
Is the root of the problem related to the order in which ctors are
fired? If so, it might be possible to use constructor priorities to
arrange for the libobjc version to have the lowest priority. [ Maybe,
I'm not intimately familiar with the ctor/dtor priority code either.
From a design standpoint I'd prefer to avoid the kind of interface you
have proposed, it just seems like a bad design to have to expose that
kind of internal detail about the library's implementation to another
library.
jeff