Es schrieb "H . J . Lu": > > On Wed, Oct 31, 2001 at 08:18:28PM +0100, Guido Draheim wrote: > > > > please be a bit more specific, what cross compiler do you use? > > Otherwise, 2.95.x crosscompiling does work smoothly for a lot of > > Does 2.95.x even use libtool?
yupp, but I was amazed to see it calls itself "libtool-1.2f", uiiiih..... > > > platforms under my hands, but I did not check 3.0.x so far. What > > version is that "libtool in gcc 3.x". I guess it is not the fault > > of libtool as seen in cvs, but feel free to patch your own > > libtool over there - may be use the postconfigured patch-macros > > as seen in the ac-archive as a guideline. cheers, guido > > > > You will see the problem when you have libfoo.la in /usr/lib and pass -lfoo > to libtool for cross compiling. Just tell me what sys_lib_search_path_spec > is used for and do a.k.a. "system specific library search path" - like the -nostdinc for gcc would be "/usr/include /usr/local/include", and for "ld" you have std-L path of "/lib /usr/lib /usr/local/lib" - the path that is searched even without any "-L". > > # cd cpu-vendor-os > # find -name libtool | xargs grep sys_lib_search_path_spec= > > in your gcc 3.x build directory. We have been lucky in gcc so far since > there is no libfoo.la in /lib, /usr/lib or /usr/local/lib yet. I am not gcc-pro, sorry, IIRC, the native compiler will create first a native-gcc (native-to-native) that will then be used to compile the crosscompiler. For the intermediate native-gcc, it is correct to have the locals sys_lib_search_path to be the native one, probably being the unix way - the crosscompiler however should not use it. A simple find/grep might give you answers for the intermediate-just-for-build gcc. If the created gcc has it, it is a bug. `crossplatform-gcc -print-search-dirs` should not yield the locals syslibpath but the lib-paths where the crosstarget's libraries are supposed to be put up for symbol resolution, e.g. /usr/$crosstarget/lib A libtool (outside of gcc in this respect) should detect a crosscompiler and not use the natives syslibpath either, instead it could ask the gcc via "-print-search-dirs" .. but that does really depend on the $crosstarget how the crosstarget sys_lib_search_path is detected. Hmm, I just checked the sources of libtool - and it seems you are absolutly correct - there is nothing that will try to detect crosscompiling automatically and kill the native's libpath, possibly filling it with the one being returned by the cross-compiler. That's surely no problem if the build-os and target-os have a different library-format (which is the case for me) so that none of the syslibs can get linked - which I guess was the common case for decades. And indeed, I have problems to imagine a case where that happens to end up with finding actual libs being out to resolve symbols with a lib being not available in the target system. If you can report a setup where that actually is the case, then libtool will have an urgent need to change the behaviour. anyway, forgive my early reply - I think you are correct, libtool does not handle the crosscompiling case in itself. The question comes about whether there is a need to actually do it - can you report any specific problem or did ye just ask out of noticing the fact.... YMHS, guido > > H.J. > ---- > > Es schrieb "H . J . Lu": > > > > > > Does libtool really support cross compile? Libtool should never, ever set > > > > > > sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib" > > > > > > when generating binaries for the cross target. The current libtool in gcc > > > 3.x does it wrong. I am enclosing a patch for ltconfig here. I don't know > > > how to fix libtool. > > > > > > H.J. > > > --- > > > --- ltconfig.cross Sat May 19 00:19:10 2001 > > > +++ ltconfig Mon Oct 29 15:02:29 2001 > > > @@ -2123,6 +2123,12 @@ case $ltmain in > > > ;; > > > esac > > > > > > + if test $host != $build; then > > > + # Don't even think about setting sys_lib_search_path_spec for cross > > > + # compiling. > > > + sys_lib_search_path_spec= > > > + fi > > > + > > > if test -z "$tagname"; then > > > trap "$rm \"$ofile\"; exit 1" 1 2 15 > > > echo "creating $ofile" > > > > > > _______________________________________________ > > > Libtool mailing list > > > [EMAIL PROTECTED] > > > http://mail.gnu.org/mailman/listinfo/libtool > > > > -- guido Edel sei der Mensch, hilfreich und gut > > GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode) > > _______________________________________________ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool -- guido Edel sei der Mensch, hilfreich und gut GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode) _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
