LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (http://www.linuxquestions.org/questions/linux-software-2/)
-   -   gcc toolchain works but dynamically linked executables won't run (without help) (http://www.linuxquestions.org/questions/linux-software-2/gcc-toolchain-works-but-dynamically-linked-executables-wont-run-without-help-4175447709/)

prushik 01-29-2013 11:07 AM

gcc toolchain works but dynamically linked executables won't run (without help)
 
I built a working cross compilation toolchain with binutils, gcc, and musl-libc based on modified lfs book instructions. I compiled busybox with it and all went well, but I linked it statically. I compiled a few other important programs and linked them statically as well. now I have enough cross compiled sw to chroot into.
However, I want to now executables which will be dynamically linked. so I gave it a shot using normal cross compilation methods and it made an executable, but after moving the executable to the target fs, i can't run it normally.
However, in musl-libc, the c library acts as the dynamic loader, so i symlinked ld.so to libc.so and now I can run executables by typing "/lib/ld.so <exe name>".
This is all fine and good, but wont work for bigger executables which need to run other dynamically linked executables.
objdump shows executables are linked only to libgcc_s.so.1 and libc.so
What should I do?

business_kid 01-30-2013 06:54 AM

Quote:

based on modified lfs book instructions.
There, I think is your problem. We really don't know what you've done. Are they elf executables? There's paths hardcoded into gcc somewhere. I would go very close to the clfs book instructions, because headscratching has gone into every line in there. To sort you out, we would need a link to what you did exactly. What does ldd show?

prushik 01-30-2013 08:24 AM

Quote:

Originally Posted by business_kid (Post 4880630)
There, I think is your problem. We really don't know what you've done. Are they elf executables? There's paths hardcoded into gcc somewhere. I would go very close to the clfs book instructions, because headscratching has gone into every line in there. To sort you out, we would need a link to what you did exactly. What does ldd show?

Well actually, in reality, what I did was more like this: http://www.ifp.illinois.edu/~nakazato/tips/xgcc.html
I built minimal binutils and gcc using lfs book instructions to adjust gcc to look for libraries in /tools, then installed kernel headers in /tools/include, then used those newly built binutils and gcc to build musl-libc which I dropped that into /tools, then built binutils and gcc again (with the host compiler) so that they are aware of the new headers and libraries.
/tools is actually bound from /media/lfs/tools.

output of ldd:
My (host) ldd says "invalid elf header" which is expected since the executable is not linked with glibc.
Musl ldd (symlinked to /lib/libc.so) gives this output:
Code:

libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7f0928f81000)
when run with a valid dynamically linked executable

business_kid 01-31-2013 04:05 AM

What you did sounds OK. You have basically replaced glibc with musl-libc on your system.

Unless your host system is also running musl-libc, you must stop cross compiling at that point and compile on musl-libc boxes only, and preferably on the target. Beware also that certain paths are hardcoded at build time into gcc. If you check the gcc pages in the hlfs book, they go adjusting the specs file in gcc and have some interesting tests for what they were trying to do.

prushik 01-31-2013 08:56 PM

Quote:

Originally Posted by business_kid (Post 4881207)
What you did sounds OK. You have basically replaced glibc with musl-libc on your system.

Unless your host system is also running musl-libc, you must stop cross compiling at that point and compile on musl-libc boxes only, and preferably on the target. Beware also that certain paths are hardcoded at build time into gcc. If you check the gcc pages in the hlfs book, they go adjusting the specs file in gcc and have some interesting tests for what they were trying to do.

Well that's what I want to do. but I need to compile GCC and binutils for the target, which works fine, but gcc and binutils executables themselves are dynamically linked and won't run without explicitly calling the loader on the command line. Which will fail if I try to do any compilation because gcc will call subprocesses which are also dynamically linked.
Right?


EDIT: OK, I think I found the problem. When I configured musl, I think I should have added --syslubdir=/tools/lib, so it looks in the wrong place for the dynamic loader

prushik 02-01-2013 10:25 AM

Ok, well that wasn't exactly the problem, but I was on the right track. I got it working, though I am still confused a bit. Essentially, I started over. I built musl-libc for my host system, and installed it at /opt/musl, then used its gcc wrapper script to cross compile binutils, musl and gcc and installed those in the target. now at least my target has a native compiler (I just verified that the executables run, not that the native toolchain is sane).


All times are GMT -5. The time now is 08:18 PM.