On Fri, Feb 10, 2006, Doug Summers wrote:
> >Ah, ok. Then our GNU binutils is broken on RHEL4/amd64. I guess this
> >platform uses a C run-time object which is either in a location GNU
> >binutils doesn't know about by default or the file is named differently
> >(perhaps with some "64" in the filename, etc). Perhaps GNU binutils just
> >thought (during its own build-time) that the platform is RHEL4/ix86.
> >
> >As quick and dirty workaround you can just remove the OpenPKG "binutils"
> >package and rebuild the "gcc" package with option "with_binutils=no". On
> >a modern Linux box this usually has no drawbacks in the functionality
> >AFAIK as the vendor already uses GNU binutils itself.
> [...]
>
> Actually it's not binutils fault, it's glibc's fault. My last compile
> try was with "with_binutils no", but it made no difference.
You have to also uninstall OpenPKG's "binutils". Else the Autoconf
magic in OpenPKG's "gcc" still feels happy to use the GNU binutils from
OpenPKG, I think.
> /usr/lib64/crt1.o exists, but /usr/lib/crt1.o doesn't. Unfortunately the
> 32-bit glibc-devel RPM isn't installed by default nor is it available
> via RHN & up2date. I have access to it internally at work and the
> compile just finished with no errors.
Yes, you're right, it's then actually an issue with glibc's installation
path fiddling. But I still think GNU binutils should be smart enough to
determine that the crt1.o on RHEL4/amd64 stays under /usr/lib64 instead
of /usr/lib...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List openpkg-users@openpkg.org
