This is the mail archive of the
mailing list for the GCC project.
Re: Results for 3.4-bi 20021213 (experimental) testsuite on
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: nathan at codesourcery dot com (Nathan Sidwell)
- Cc: zack at codesourcery dot com, gcc-testresults at gcc dot gnu dot org
- Date: Sun, 15 Dec 2002 18:09:21 -0500 (EST)
- Subject: Re: Results for 3.4-bi 20021213 (experimental) testsuite on
> This test of a weak function address is in the gthr-*.h headers,
We haven't enabled thread support under hpux11 because of problems
like this. gthr-simple.h doesn't have any weak tests. Under hpux10,
the 32-bit port used multilib configuration.
> (see __gthread_active_p), so I figured it was ok. The gcc docs do not
> give a formal description of what supporting weak symbols means. I went
> with the elf specs which (IIRC) are
> * a weak definition is overridden by a non-weak definition
> * an unresolved weak declaration is resolved to zero.
If that's the case, then the hpux dynamic loader should set the address
in the function descriptor to zero. Can you point me to the elf specs
to which you referred?
> That might well work, but IMHO the hpux is not supporting weak. I, of
> course, don't feel strongly about this, but would like to clarify
> what weak support means before trying to work around this problem.
I'm also pragmatic about the matter and must defer to the ELF experts
when it comes what weak support means. The testing for unresolved
weak symbols is a very nice feature but it looks like there is quite
a bit to fix before it will work on hppa64-hpux. I'm not sure what
the odds are of getting HP to fix their linker and possibly the
dynamic loader, but I suspect they aren't great unless the request
comes from someone with a service contract.
J. David Anglin firstname.lastname@example.org
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)