This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: R_PPC_LOCAL24PC c++ linking problems with current binutils
On Mon, Jul 19, 1999 at 07:49:24PM -0400, Ian Lance Taylor wrote:
> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Tue, 20 Jul 1999 00:07:53 +0200
>
> Compiling with c++ -o mmaptest.so -fPIC -shared mmaptest.cc gives:
> mmaptest.o: In function `__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned int, int &)':
> mmaptest.o(.__default_alloc_template<true, 0>::gnu.linkonce.t._S_chunk_alloc(unsigned int, int &)+0x234): undefined reference to `__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned int, int &)'
> mmaptest.o(.__default_alloc_template<true, 0>::gnu.linkonce.t._S_chunk_alloc(unsigned int, int &)+0x2a8): undefined reference to `__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned int, int &)'
> collect2: ld returned 1 exit status
>
> /* It makes no sense to point a local relocation
> at a symbol not in this object. */
> if (h != NULL
> && (h->root.type == bfd_link_hash_defined
> || h->root.type == bfd_link_hash_defweak)
> && sec->output_section == NULL)
>
> I think the last is the wrong test. sec->output_section will be NULL
> for a linkonce section which is being discarded. More appropriate
> would be a test whether ELF_LINK_HASH_DEF_REGULAR is set in
> h->elf_link_hash_flags.
A brief experiment showed that sec->output_section == NULL for the
symbols in question, and (h->elf_link_hash_flags &
ELF_LINK_HASH_DEF_REGULAR) == 0. So that doesn't quite seem to be the
problem.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/