Bug report: objc classes linked in wrong order

[H . J . Lu]

On Tue, May 09, 2000 at 12:05:15PM -0700, H . J . Lu wrote:
> On Mon, May 08, 2000 at 05:01:06PM +0100, nicola@brainstorm.co.uk wrote:
> > Hi - I have a bug report.
> > 
> > The problem description is as follows:
> > 
> > (*)  [standard behaviour] if I have two libraries implementing the same
> > function, say
> > 
> > void hello (void);
> > 
> > and I link an executable with the two libraries, the `hello` from the
> > first library given on the command line gets used.  This happens with both
> > static and shared library.
> > 
> > (*) if I do the same with an Objective-C class, i.e. I have two libraries
> > implementing the same method of the same class, what happens is:
> > 
> > [standard behaviour] if I link an executable with the two libraries, the
> > method of the class from the first library on the command line gets used
> > when the two libraries are static.
> > 
> > [the problem] The weird thing is when I link dynamically the two libraries
> > in:  then - consistently - the class from the second library on the
> > command line gets used instead of the first as it should have.
> > 
> > I was able to isolate the problem and to create a complete test showing
> > the problem, which I enclose in attach.
> > 
> > Please notice that I am willing to actively help to fix the bug - only I
> > am not a linker/compiler expert, so I'm pretty stuck and don't know what
> > to look at.  But it is quite important to me that the bug gets fixed.
> > 
> > --
> > 
> > I am using binutils-2.9.1.0.23 and almost everything which comes with
> > RedHat 6.1.  I have the bug with both the old and the latest CVS egcs
> > compiler.
> > 
> > Thank you for any help.
> 
> It is a very interesting problem. I know very little about Objective-C.
> From the asm output, I have an impression that the Objective-C class
> implemenation is registered via the .ctors section. When you link with
> 
> # cc -I./ -L/user/hjl/bugs/objc/shared/bug.report/install -o test-shared test.o -ltest1 -ltest2 -lobjc -lpthread
> 
> "-ltest1 -ltest2 -lobjc -lpthread -lgcc -lc -lgcc" is passed to the
> linker. The dynamic linker in glibc 2.1 will process the .ctors section
> in the reverse order. That is
> 
> 11951:  calling init: /lib/libc.so.6
> 11951:  calling init: /lib/libpthread.so.0
> 11951:  calling init: ./install/libtest2.so.0
> 11951:  calling init: ./install/libtest1.so.0
> 
> As the result, the implemenation in libtest2 gets register first. For
> the static link, libtest2.a is not even used at all. I don't know for
> sure what the right answer for it is.
> 
> BTW, it may have an impact when libgcc.so is introduced. It will be
> interesting to see the order of calling init if it will make a
> difference.
> 
> 
> H.J.

I forget to include the testcase.

H.J.