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] |
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.
No, no, that's not a problem at all; crosstool removes the absolute paths from the shared library references. No need to build static.
so it depends on the proper setting of LD_LIBRARY_PATH, then?
It depends on the default ld.so search path, and on you to copy the .so*'s from /opt/crosstool/$TARGET/$TOOLCOMBO/$TARGET/lib to /lib on the target system when you set it up. Alternately, it depends on /etc/ld.so.conf having that lib directory added.
LD_LIBRARY_PATH should be used sparingly. I use it only when I'm still testing something I don't want to expose the whole system to, or in a wrapper shell script for a broken third-party binary. - Dan
-- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
------ 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] |