-----BEGIN PGP SIGNED MESSAGE-----
Hi again, world.
Looks like I found a clue to my reported problems:
|=> Hello World,
|=> I'm trying to compile gcc (2.7.2.2, 2.7.2.3) on a DEC Alpha
|=> running DU4.0c in order to later use gas with some assembler
|=> programs.
|=>
|=> Following problem, when building stage1:
|=> configuring> ./configure --prefix=/vol/local
|=> This appears to be a alpha-dec-osf4.0 system.
|=> Using `./config/alpha/alpha.c' to output insns.
|=> Using `./config/alpha/alpha.md' as machine description file.
|=> Using `./config/alpha/osf2.h' as target machine macro file.
|=> Using `./config/alpha/xm-alpha.h' as host machine macro file.
|=> Merged alpha/x-alpha.
|=> Merged c++ fragment(s).
|=> Created `./Makefile'.
|=> Merged alpha/x-alpha.
|=> Created `cp/Makefile'.
|=> Links are now set up to build a native compiler for alpha-dec-osf4.0.
|=> making> make LANGUAGES=c
|=> ...skipping until error appears...
|=> if [ -f libgcc2.ready ] ; then \
|=> true; \
|=> else \
|=> touch libgcc2.ready; \
|=> fi
|=> ./xgcc -B./ -DIN_GCC -g -I./include enquire.o -o enquire
|=> inst emulated pid=31003 <ld> va=0x14000f088 pc=0x120046e08 inst=0x282b0000
|=> collect2: ld returned 1 exit status
|=> /lib/libc.a(ldr_atexit.o)(.lita+0x38): undefined reference to `_DYNAMIC_LINK'
|=> /lib/libc.a(find_rtfunc.o)(.lita+0x90): undefined reference to `_gpinfo'
|=> /lib/libc.a(find_rtfunc.o)(.lita+0xa8): undefined reference to `_fpdata_size'
|=> /lib/libc.a(find_rtfunc.o)(.lita+0xb8): undefined reference to `_DYNAMIC_LINK'
|=> /lib/libc.a(ldr_load.o)(.lita+0xa8): undefined reference to `_DYNAMIC_LINK'
|=> make: *** [enquire] Error 1
|=> making>
|=>
|=> Looks like the problem is with the /lib/libc.a, but where are
|=> these functions/arrays defined ?
This seems to belong to the GNU ld. When I deleted that program
and reinstalled gcc I did not get the problem anymore. GNU as
seems to work properly now.
|=>
|=> BTW, what does the "inst emulated pid=31003 <ld> va=0x14000f088
|=> pc=0x120046e08 inst=0x282b0000" line mean, which appears with
|=> most loading/linking routines on some of our machines but not on
|=> others ? (This does NOT affect the negative result of the
|=> compilation, though.) Also the flags -D_OSF_SOURCE, -D__GNUC__
|=> and -D_POSIX_SOURCE which I added some times, one or the other,
|=> to the Makefile don't change the result.
This may be related to the new GNU cc 2.8.0. It disappeared with 2.7.2.3
|=>
|=> P.S. Does anyone experience problems with the bourne shell the
|=> way that it does not find local directories (e.g ./dir is found,
|=> dir is not...)? Looks like a problem with my personal
|=> environment, since it works OK as root.
|=>
Well, as I said, my personal environment: I defined an
environment variable CDPATH to export it to different sub-csh's,
but newer Bourne sh's also define this variable, but in bourne
shell syntax, i.e. I defined
setenv CDPATH '(/my/path/one /my/path/two ...)'
and sh interpreted the pathname as being "(my/path/one /my/path/two ...)"
instead of my/path/one:/my/path/two:...
P.S.: When reinstalling GNU ld after gcc runs, I run into trouble
again. Where does gcc look for its loader/assembler, since GNU ld
is definitely NOT the first ld it may find in the standard path ?
Tschüß,
Dieter
_____________________________*__________________________________
/ * dieter.meinert_at_aip.de \
\ Dieter Meinert (- **
http://www.obs.aip.de/~dieter/ \
\__________________A______*__*___________________________________/
(public pgp key from
http://www.obs.aip.de/~dieter/)
-----BEGIN PGP SIGNATURE-----
Version: 2.6
iQCVAgUBNQ6YrfYksnFoaQ6JAQH6IgQApP4VIi8aZMRRRd+hnZpD4tGkXoZseDlF
eRRXkPhFDOymb4Glq4PYF+aOSiNpWgNGicoiQ6Hxky05Kmk61a3zpMZOOo7m84y5
mYBPwZ+t6qOBe0b8sERyQ+IZ9EqcVPcpeEPU898yNEEE+PC6L2yWmg7Y4whPqpgk
EdWm7UAxhMY=
=S7mQ
-----END PGP SIGNATURE-----
Received on Tue Mar 17 1998 - 16:37:51 NZST