Hello, I'm trying to compile a Linux hello world executable on macOS. The first step is simple: clang -c -target x86_64-linux-gnu -c -o hello.o hello.c But linking results in an error: ld.lld --sysroot=/linuxroot/ -o hello -m elf_x86_64 \ -dynamic-linker /lib64/ld-linux-x86-64.so.2 \ /lib/crt1.o \ /usr/lib/x86_64-linux-gnu/crti.o ../hello.o \ /usr/lib/x86_64-linux-gnu/libc.so \ /usr/lib/x86_64-linux-gnu/crtn.o ld.lld: error: cannot open /lib/crt1.o: No such file or directory ld.lld: error: cannot open /usr/lib/x86_64-linux-gnu/crti.o: No such file or directory /linuxroot/ contains all the necessary files copied from a Linux machine: /linuxroot/lib/crt1.o, /linuxroot/usr/lib/x86_64-linux-gnu/crti.o, etc It works if I use a full path for each file (-dynamic-linker /linuxroot/lib64/ld-linux-x86-64.so.2 ...), but the resulting binary doesn't work on Linux, because it's dynamically linked to /linuxroot/... which is missing on the Linux box. file hi hi: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /linuxroot/lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped The only way I can make it work is to have actual /usr/lib/x86_64-linux-gnu/crti.o etc on my macOS box, which --sysroot is supposed to help avoid. I'm sure I'm missing something simple here. I've been following the docs, but couldn't figure it out on my own. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200514/0606f3bc/attachment.html>
On Thu, May 14, 2020 at 11:04 AM Ivan Medoedov via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hello, > > I'm trying to compile a Linux hello world executable on macOS. > > The first step is simple: > > clang -c -target x86_64-linux-gnu -c -o hello.o hello.c > > But linking results in an error: > > ld.lld --sysroot=/linuxroot/ -o hello -m elf_x86_64 \ > -dynamic-linker /lib64/ld-linux-x86-64.so.2 \ > /lib/crt1.o \ > /usr/lib/x86_64-linux-gnu/crti.o ../hello.o \ > /usr/lib/x86_64-linux-gnu/libc.so \ > /usr/lib/x86_64-linux-gnu/crtn.o > > ld.lld: error: cannot open /lib/crt1.o: No such file or directory > ld.lld: error: cannot open /usr/lib/x86_64-linux-gnu/crti.o: No such file > or directory >--sysroot affects some library search paths, but it doesn't affect paths directly given to the linker. In the above command line, you are directly specifying object file and so file paths without -l, so the linker looks at the only given locations. This is an expected behavior. I think, unlike some other linkers, --sysroot option isn't very useful for lld, because lld doesn't have a notion of built-in default search paths. You always have to specify library search paths by -L option to lld. So why don't you specify library directories with -L, like this? $ ld.lld -o hello -m elf_x86-64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -L /linuxroot/usr/lib -lc /linuxroot/usr/lib/x86_64-linux-gnu/crtn.o> /linuxroot/ contains all the necessary files copied from a Linux machine: > /linuxroot/lib/crt1.o, /linuxroot/usr/lib/x86_64-linux-gnu/crti.o, etc > > It works if I use a full path for each file (-dynamic-linker > /linuxroot/lib64/ld-linux-x86-64.so.2 ...), but the resulting binary > doesn't work on Linux, because it's dynamically linked to /linuxroot/... > which is missing on the Linux box. > > file hi > hi: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically > linked, interpreter /linuxroot/lib64/ld-linux-x86-64.so.2, for GNU/Linux > 3.2.0, not stripped > > The only way I can make it work is to have actual > /usr/lib/x86_64-linux-gnu/crti.o etc on my macOS box, which --sysroot is > supposed to help avoid. > > I'm sure I'm missing something simple here. I've been following the docs, > but couldn't figure it out on my own. > > Thanks! > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200514/6bbd7de1/attachment.html>
On 2020-05-14, Rui Ueyama via llvm-dev wrote:>On Thu, May 14, 2020 at 11:04 AM Ivan Medoedov via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> Hello, >> >> I'm trying to compile a Linux hello world executable on macOS. >> >> The first step is simple: >> >> clang -c -target x86_64-linux-gnu -c -o hello.o hello.c >> >> But linking results in an error: >> >> ld.lld --sysroot=/linuxroot/ -o hello -m elf_x86_64 \ >> -dynamic-linker /lib64/ld-linux-x86-64.so.2 \ >> /lib/crt1.o \ >> /usr/lib/x86_64-linux-gnu/crti.o ../hello.o \ >> /usr/lib/x86_64-linux-gnu/libc.so \ >> /usr/lib/x86_64-linux-gnu/crtn.o >> >> ld.lld: error: cannot open /lib/crt1.o: No such file or directory >> ld.lld: error: cannot open /usr/lib/x86_64-linux-gnu/crti.o: No such file >> or directory >>You misunderstand GNU ld's --sysroot rule, which is applicable in these two cases: * when a path begins with "=" or "$SYSROOT" * https://www.sourceware.org/binutils/docs/ld/File-Commands.html "In case a sysroot prefix is configured, and the filename starts with the ‘/’ character, and the script being processed was located inside the sysroot prefix, the filename will be looked for in the sysroot prefix." For your case, you need a linker script located under /linuxroot/, which INPUT or GROUP an absolute path.>--sysroot affects some library search paths, but it doesn't affect paths >directly given to the linker. In the above command line, you are directly >specifying object file and so file paths without -l, so the linker looks at >the only given locations. This is an expected behavior. > >I think, unlike some other linkers, --sysroot option isn't very useful for >lld, because lld doesn't have a notion of built-in default search paths. >You always have to specify library search paths by -L option to lld. So why >don't you specify library directories with -L, like this? > >$ ld.lld -o hello -m elf_x86-64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 >-L /linuxroot/usr/lib -lc /linuxroot/usr/lib/x86_64-linux-gnu/crtn.o > > >> /linuxroot/ contains all the necessary files copied from a Linux machine: >> /linuxroot/lib/crt1.o, /linuxroot/usr/lib/x86_64-linux-gnu/crti.o, etc >> >> It works if I use a full path for each file (-dynamic-linker >> /linuxroot/lib64/ld-linux-x86-64.so.2 ...), but the resulting binary >> doesn't work on Linux, because it's dynamically linked to /linuxroot/... >> which is missing on the Linux box. >> >> file hi >> hi: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically >> linked, interpreter /linuxroot/lib64/ld-linux-x86-64.so.2, for GNU/Linux >> 3.2.0, not stripped >> >> The only way I can make it work is to have actual >> /usr/lib/x86_64-linux-gnu/crti.o etc on my macOS box, which --sysroot is >> supposed to help avoid. >> >> I'm sure I'm missing something simple here. I've been following the docs, >> but couldn't figure it out on my own. >> >> Thanks! >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>_______________________________________________ >LLVM Developers mailing list >llvm-dev at lists.llvm.org >https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Possibly Parallel Threads
- ld.lld ignoring --sysroot
- ld.lld fails with "undefined symbol: _fopen" on macOS, while working as expected on Linux
- ld.lld fails with "undefined symbol: _fopen" on macOS, while working as expected on Linux
- [LLVMdev] Changes to Debian's linker object files breaks building LLVM [crti.o, crt1.o, crtn.o]
- [LLVMdev] Changes to Debian's linker object files breaks building LLVM [crti.o, crt1.o, crtn.o]