Re: ia64-hp-hpux* linker

[Cary Coutant <ccoutant at google dot com>]

This looks like Gnu ld and nm are not equipped to recognize the
special section SHN_ANSI_COMMON that HP-UX uses. This distinguishes
the symbol from an old K&R-style common symbol -- which would cause
the linker to load an archive member to satisfy an undef, while an
ANSI Common symbol is treated as an ordinary undef as far as archive
searching goes.

To my knowledge, the gnu linker has never been fully supported on
HP-UX, and you may find other problems beyond this.

-cary


On Fri, Apr 24, 2009 at 9:29 AM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> Denis Scherbakov wrote:
>>> ? It's really odd that this symbol would end up in the abs section. ?I don't
>>> know anything about hpux, but could the hidden visibility somehow mean that in
>>> file2, shTest is effectively a COMMON symbol (and then, that there's maybe
>>> some kind of problem with COMMON handling additionally)? ?What does "nm
>>> file1.o" look like when you compile with --save-temps? ?Does
>>> "-fno-zero-initialized-in-bss" help any?
>>
>> Dave, thanks for asking.
>>
>> -fno-zero-initialized-in-bss does not help. Here are the outputs:
>>
>> ================================================
>> $ nm file.o
>> 00000000 T func
>> ? ? ? ? ?U puts
>> 00000002 A varTest
>> ================================================
>
> ?Ok, it's coming out as an ABS symbol from the word go.
>
>> ================================================
>> $ cat file.s
>
>> ? ? ? .hidden varTest#
>> ? ? ? .common varTest#,2,2
>
> ?But it should be common.
>
>> ? ? ?9: 00000002 ? ? 2 OBJECT ?GLOBAL HIDDEN ANSI_COM varTest
>
> ?And readelf disagrees, thinking (IMO correctly) that it is in the common
> section. ?That's peculiar, and I think it may give you something to start
> digging into: why does nm get it wrong? ?Find that out and you'll probably
> find out why the rest of BFD thinks it's an *ABS* rather than COMMON symbol.
>
> ? ?cheers,
> ? ? ?DaveK
>
>