This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Tue, 2004-11-09 at 06:09, Robert P. J. Day wrote: > > i haven't had a chance to test run the executables yet, but in both > cases, i got executables as output that "file" told me were SH > binaries. so at least that part worked (the static binary being, > naturally, massively larger than the dynamic). > I meant mv instead of cp. Try it. You probably won't like the fireworks display you're liable to get. If you copy, the relocated binaries will still have the original files to find and use. What you're doing by copying is approximately equivalent to setting symlinks in /usr that refer back to your original PREFIX. Dunno 'bout you, but I'd call that cheating :-) <no offense> But we're talking about building cross-compilers here -- the ultimate purpose is to move cross-compiled executables (and/or dynamic libs) to foreign machines of the target hw/os type. If you need to build -shared executables, you're really in trouble when you transport that executable to a foreign machine where your build & PREFIX paths are unknown. You _might_ get away with statically linked executables, if you can make the link phases work. BTDT. You'll hit a brick wall _somewhere_, sadly. If there's an easier solution, I'm all ears. chroot jail (built to standard /usr, /usr/lib, /lib paths) still sounds like the course of action with the most promise to me. Peace, --Jim-- ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |