NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/hp/14127

Text File | 1992-12-16 | 3.6 KB | 87 lines

Newsgroups: comp.sys.hp
Path: sparky!uunet!news.mentorg.com!dracula!gcagle
From: [e-mail] (Greg Cagle)
Subject: Re: ld(1) question
Message-ID: <[e-mail]>
Sender: gcagle@dracula (Greg Cagle)
Date: Wed, 16 Dec 1992 15:13:32 GMT
Distribution: usa
Reply-To: [e-mail]
References:  <[e-mail]>
Nntp-Posting-Host: dracula.mentorg.com
Organization: Mentor Graphics
Keywords:
Followup-To: [e-mail]
Lines: 70

In article <[e-mail]>, [e-mail] (Randall Atkinson) writes:
>  In trying to get GNU groff 1.06 compiled for my HP, using GCC both
>as a C and C++ compiler and with standard HP libraries rather than
>libg++, I run into the following error message:
>
>ld: R_DATA_ONE_SYMBOL fixup in file env.o for code unsat symbol
>"abort" - use P' fixup
>

From the FAQ:

1)  What's a P-FIXUP error?

   Several questions on comp.sys.hp lately have involved the Gnu C compiler
and the linker message below :

        gcc  test_h.o -o test_h ../libg++.a -lm
ld: R_DATA_ONE_SYMBOL fixup in file ../libg++.a(streambuf.o) for code unsat
symbol "abort" - use P' fixup
collect: /bin/ld returned 1 exit status

   This is caused by the code generator emitting assembly code in a data
subspace to initialize a function pointer, equivalent to :

    .word    foo

where (in this case) foo() is an extern, and shared libraries are referenced
by the executable being built (usually libc.sl).

   The linker is being helpful by pointing out a fatal error waiting
to happen, as function pointers are different in the presence of shared
libraries.  A different fixup is needed to generate the kind of procedure
label that can be called.  This is explained under "Procedure Labels" in
Chapter 7 of "Programming on HP-UX" (Part # B2355-90026 E0892) and at the
end of "Expressions" in Chapter 1 of the Assembly Language Reference Manual
(Part # 92432-90001 E0191).

   There are two ways to fix this :
    1) Change the code generation to the equivalent of :
        .word P%foo
    or
    2) Link the program using the "-a archive" linker option.  The
    easiest way to do this is via the LDOPTS environment variable :
        setenv LDOPTS "-a archive"
         - or -
        LDOPTS="-a archive"; export LDOPTS

   The first fixes the problem directly, generating an R_DATA_PLABEL fixup
which is unambiguous whether shared libraries are present or not.  The
second puts you back in time to the situation before shared libraries were
added to HP-UX.  Without shared libraries HP-UX drew no distinction between
code addresses and procedure labels - an ambiguity that the P% fixup syntax
resolves.

   The reason the linker can't just fix this situation is that there are
cases where code addresses are implicitly or explicitly desired, cases that
are part of the motivation for having an assembler to begin with.
Unfortunately, in this case a message designed to be helpful to an errant
assembly programmer is instead a symptom of an out-of-date code generator,
and is too low-level to help the people seeing it.  The other alternative
(letting the program segmentation violate at runtime with no warning) would
be more likely to result in the user blaming the Gnu code generator instead
of HP's linker, but otherwise very little more satisfying.

--
---------------------------------------------------------------------------
Greg Cagle                                      Mentor Graphics Corporation
[e-mail]                         Platform Technology Division
[phone]                                  Member of the Cultural Elite
---------------------------------------------------------------------------