bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/25803] cross compilation of glibc using mips64el-none-linu


From: beatlesnut at mac dot com
Subject: [Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
Date: Tue, 14 Apr 2020 14:28:34 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=25803

--- Comment #7 from beatlesnut at mac dot com ---
Hi

My host is actually an x86_64 Darwin machine. But i'm cross compiling with a
multilib compiler, so that's why the host is being set to
mipsel-none-linux-gnu. 

So an x86_64 host is what you want. 

Essentially trying to build the 32 bit libraries for the 32 bit target
(mipsel-none-linux-gnu) using the mulitlib compiler (mips64el-none-linux-gnu)
with an x86_64 cpu

I can provide the object files, yes.

  Original Message  
From: nickc at redhat dot com
Sent: Tuesday, 14 April 2020 8:16 AM
To: address@hidden
Subject: [Bug binutils/25803] cross compilation of glibc using
mips64el-none-linux-gnu as the host

https://sourceware.org/bugzilla/show_bug.cgi?id=25803

--- Comment #6 from Nick Clifton <nickc at redhat dot com> ---
(In reply to gagan singh sidhu (gagz, broly, w/e u want) from comment #5)

I am sorry, but that is not what I meant by a small, standalone test case.

Would you be able to provide a compressed tarball of the object files and
libraries used on the final link ? Ie these:

> mips64el-none-linux-gnu-gcc -mabi=32 -B/cross/bin/ -shared -static-libgcc
> -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld.so.1 
> -B/Volumes/xtoolshit/bglibc/csu/ 
> -Wl,--version-script=/Volumes/xtoolshit/bglibc/librt.map
> -Wl,-soname=librt.so.1 -Wl,-z,relro -Wl,--hash-style=both 
> -Wl,--enable-new-dtags,-z,nodelete -L/Volumes/xtoolshit/bglibc
> -L/Volumes/xtoolshit/bglibc/math -L/Volumes/xtoolshit/bglibc/elf
> -L/Volumes/xtoolshit/bglibc/dlfcn -L/Volumes/xtoolshit/bglibc/nss
> -L/Volumes/xtoolshit/bglibc/nis -L/Volumes/xtoolshit/bglibc/rt
> -L/Volumes/xtoolshit/bglibc/resolv -L/Volumes/xtoolshit/bglibc/mathvec
> -L/Volumes/xtoolshit/bglibc/support -L/Volumes/xtoolshit/bglibc/crypt
> -L/Volumes/xtoolshit/bglibc/nptl
> -Wl,-rpath-link=/Volumes/xtoolshit/bglibc:/Volumes/xtoolshit/bglibc/math:/
> Volumes/xtoolshit/bglibc/elf:/Volumes/xtoolshit/bglibc/dlfcn:/Volumes/
> xtoolshit/bglibc/nss:/Volumes/xtoolshit/bglibc/nis:/Volumes/xtoolshit/bglibc/
> rt:/Volumes/xtoolshit/bglibc/resolv:/Volumes/xtoolshit/bglibc/mathvec:/
> Volumes/xtoolshit/bglibc/support:/Volumes/xtoolshit/bglibc/crypt:/Volumes/
> xtoolshit/bglibc/nptl -o /Volumes/xtoolshit/bglibc/rt/librt.so -T
> /Volumes/xtoolshit/bglibc/shlib.lds /Volumes/xtoolshit/bglibc/csu/abi-note.o
> -Wl,--whole-archive /Volumes/xtoolshit/bglibc/rt/librt_pic.a
> -Wl,--no-whole-archive /Volumes/xtoolshit/bglibc/nptl/libpthread.so 
> -Wl,--start-group /Volumes/xtoolshit/bglibc/libc.so
> /Volumes/xtoolshit/bglibc/libc_nonshared.a -Wl,--as-needed
> /Volumes/xtoolshit/bglibc/elf/ld.so -Wl,--no-as-needed -Wl,--end-group

It would also really help if you can capture the linker command line itself
(via adding -v to the gcc command line) so that I can be sure that I am testing
the right options.

Are you able to confirm that the problem is restricted to a 32-bit host ?
If so that might pose a problem as I only have immediate access to 64-bit
machines. But I can probably set up a 32-bit guest machine if necessary.

Cheers
Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]