home *** CD-ROM | disk | FTP | other *** search
- From: cdb@hpcuhe.cup.hp.com (Carl Burch)
- Date: Tue, 10 Nov 1992 01:51:45 GMT
- Subject: Re: INFO: GNU products on HP9000s700. Also GCC 2.3.1 on same.
- Message-ID: <31480280@hpcuhe.cup.hp.com>
- Organization: Hewlett Packard, Cupertino
- Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!scd.hp.com!hpscdm!hplextra!hpcss01!hpcuhe!cdb
- Newsgroups: comp.sys.hp
- References: <mathieu.721079639@gdim>
- Lines: 56
-
- > B - Linker problems:
- > 1) fontutils-0.6
- > gcc -O -o limn -L/usr/lib/X11R4 -L/usr/local/lib/X11 -g curve.o display.o fit.o main.o output-bzr.o pxl-outline.o xserver.o version.o .././lib/lib.a .././gf/gf.a .././pk/pk.a .././bzr/bzr.a .././tfm/tfm.a .././widgets/widgets.a .././lib/lib.a -static -L/usr/lib/X11R4 -L/usr/local/lib/X11 -lXaw -lXmu -lXext -lXt -lX11.././lib/dlsym.o -lm
- > ld: R_DATA_ONE_SYMBOL fixup in file .././widgets/widgets.a(Label.o) for code unsat symbol "_XtInherit" - use P' fixup
- > collect: /bin/ld returned 1 exit status
-
- Several questions on comp.sys.hp lately have involved the Gnu C compiler
- and the linker message above :
-
- 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.
-
- Carl Burch
- HP California Language Lab
- ------------------------------------------------------------------------
- I don't get paid to speak for myself, let alone HP.
-