On Friday 02 April 2010 18:39:36 Denys Vlasenko wrote: > On Tuesday 30 March 2010 02:09, Rob Landley wrote: > > > 1.16.1 has been released today. > > > > I rebuilt the set of statically linked more or less defconfig busybox > > binaries for various targets and uploaded them Morris, see > > http://busybox.net/downloads/binaries/1.16.1 > > > > By the way, if you need statically linked strace for the same set of > > targets (sometimes useful, it's come up here on this list a couple > > times), you can find that (and dropbear) at > > http://impactlinux.com/fwl/downloads/binaries > > Hi Rob, > > Wonderful job! This is so much further along than my crude > cross-compiler. You have fifteen architectures covered. > I had only two. > > > I downloaded cross-compiler-i686 and cross-compiler-x86_64 > and I can build static executables using either > after I made symlinks > /usr/x86_64-unknown-linux -> > /whereever/I/untarred/cross-compiler-x86_64/x86_64-unknown-linux > > I have a few questions. > > When I run "strace -oLOG -f x86_64-gcc --static t.c" > I see that it still tries to use your configured target path, > /home/landley/temp/firmware/build/cross-compiler-x86_64. > Can this be prevented? (I can send you LOG if you need it).
Lemme guess, this is when calling out to the linker? (I can deal with everything else via ccwrap, but this one I'd have to patch out.) Back in 2006, I sat down and tried to clean out the horrible path logic from GCC. Just remove everything it shouldn't be doing, and add one clean set of "this lives here, that lives there" parsing. When my patch passed 10,000 lines of stuff it was removing, with no end in sight, I gave up and went with a wrapper. http://landley.net/notes-2006.html#15-11-2006 The gcc path logic is _evil_. They assemble a big long array of every possible place the files they're looking for _might_ be, taken from stuff the ./configure infrastructure writes into the header files, and from querying environment variables at runtime, and from stuff written in their own scripting language, and from paths derived from where it finds other things at runtime, and even a few paths literally hardwired into the C code. They do this for system includes, compiler includes, system libraries, compiler libraries, and executables they shell out for. The worst part is that they never remove anything from this list, just add more to it. (Which is the last thing you want to do when cross compiling, the big failure for cross compiling is finding the _wrong_ stuff by accident.) When the stuff they've been doing proves intractably horrible, they just add another layer on top, inserting more random locations at the beginning of these arrays, and then fall back to check all the historical craziness. Their current fresh coat of paint over dry rot is called "sysroot", and just like the previous _five_ reboot attempts I found in the code they're _sure_ this will fix everything. You know how it works? The code still contains hardwired absolute paths into the user's home directory it was built in, but then they string match for them and do a search and replace at runtime. The approach I took was to write a wrapper (ccwrap.c, based on the old uClibc wrapper from back before buildroot) which parses the command line and rewrites it starting with --nostdinc --nostdlib. That way, gcc can hallucinate any strange paths it likes, it's just explicitly told NEVER TO USE THEM, and instead only check the locations that ccwrap feeds it on the command line. Alas, what this _doesn't_ fix is the exec shellouts to find the assembler and linker and strip and such. (All the file from binutils.) You'd think it would check the $PATH, and eventually it does fall back to checking the $PATH. (And yes, ccwrap adjusts the $PATH so what it's looking for is right at the start.) But first it checks a few random hardwired locations determined at compile time, and since I started using ccwrap I stopped patching gcc's path logic, which is what I'd have to do to make it not do that. > And second, dynamic linking ("x86_64-gcc t.c") also works, > but of course resulting binary needs some files to be in /lib, > in simplest case /lib/ld-uClibc.so.0 and /lib/libc.so.0: You can feed the -L option to qemu to override that, which sometimes works. ("Set the ELF interpreter prefix.") Depends on qemu version and what exactly you try to do. (Last time I checked it, it worked for the program you ran but not new programs that program spawned.) You can also compile things with a different hardwired dynamic linker path, using the somewhat esoteric command line option: -Wl,--dynamic-linker,/path/to/new/ld-uClibc.so But the dynamic linker is always at a hardwired absolute path, that's just the way it works. It's like #!/bin/bash needing the /bin/ on the front. (Yeah, in that case you can uuse "env", but you still need an absolute path to env.) Laptop battery dying, answer the rest in a bit... Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
