From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geoff Keating To: Franz.Sirl-kernel@lauterbach.com Cc: binutils@sourceware.cygnus.com, drow@false.org Subject: Re: R_PPC_LOCAL24PC c++ linking problems with current binutils Date: Mon, 19 Jul 1999 19:30:00 -0000 Message-id: <199907200217.MAA09776@geoffk.wattle.id.au> References: <99072000221900.00843@ns1102.munich.netsurf.de> X-SW-Source: 1999-q3/msg00270.html > From: Franz Sirl > Date: Tue, 20 Jul 1999 00:07:53 +0200 > Cc: drow@false.org, geoffk@ozemail.com.au > > Hi, > > linking this little program currently fails on Linux/PPC, glibc-2.1: > > mmaptest.cc: > #include > class FileFd > { > public: > int iFd; > unsigned long Flags; > string FileName; > > > FileFd(int Fd,bool) : iFd(Fd), Flags(0) {}; > virtual ~FileFd(); > }; > > > Compiling with c++ -o mmaptest.so -fPIC -shared mmaptest.cc gives: > mmaptest.o: In function `__default_alloc_template::_S_chunk_alloc(unsigned int, int &)': > mmaptest.o(.__default_alloc_template::gnu.linkonce.t._S_chunk_alloc(unsigned int, int &)+0x234): undefined reference to `__default_alloc_template::_S_chunk_alloc(unsigned int, int &)' > mmaptest.o(.__default_alloc_template::gnu.linkonce.t._S_chunk_alloc(unsigned int, int &)+0x2a8): undefined reference to `__default_alloc_template::_S_chunk_alloc(unsigned int, int &)' > collect2: ld returned 1 exit status OK, I see it. The problem is that the following is happening: 1. g++ is defining the symbol '__default_alloc_template::_S_chunk_alloc(unsigned int, int &)' (in demangled form, which I'll just call `...' from now on :-) weak in a linkonce section. 2. In libstdc++.so, the symbol is not defined weak. 3. In the same linkonce section, there is 'bl ...@local'. The @local is because it's a recursive call. 4. ld finds the strong definition, in the shared object. 5. The symbol is not therefore defined locally, and linking fails. I assume ld is correct in emitting the linkonce section even though it will actually be using the shared object symbol. I may be wrong. Certainly it doesn't seem to make much sense to do this. Other fixes would be: (i) define the libstdc++ symbol weak, and/or (ii) don't use @local on weak symbols and/or (iii) make @local relocs point to the symbol defined in this object whether or not there is a stronger definition elsewhere. (ii) implies that it is not legal to have a weak nested procedure (at present the register used for the static chain conflicts with registers clobbered in the PLT), but I'm not sure this makes sense anyway. (iii) might be hard. It means we have to keep track of multiple symbol definitions in ld. It is probably also the correct solution :-(. Note that it is not valid to just ignore the @local, because calling through the PLT is allowed to trash certain registers and @local is not. -- Geoffrey Keating