bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shlibpath.at may need -no-undefined


From: Roumen Petrov
Subject: Re: shlibpath.at may need -no-undefined
Date: Mon, 27 Jul 2009 01:08:36 +0300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090624 SeaMonkey/1.1.17

Ralf Wildenhues wrote:
Hello Roumen,

* Roumen Petrov wrote on Fri, Jul 24, 2009 at 03:26:47PM CEST:
It seems to me that test shlibpath.at require -no-undefined flag to
generated shared libraries on windows platforms, i.e. something as
"LDFLAGS="$LDFLAGS -no-undefined" at begining.

As the currently test don't work in cross-environment ( replated to
PATH variable) I could not propose a patch.

I really appreciate you reporting bugs and sending patches (along with
all other people who do so, and who constantly receive less attention on
this list than they deserve  :-/ ), but can you please get into the
habit of never writing "it doesn't work" without any proof?  I mean, if
you've already tried it out, then it should be easy for you to copy and
paste the failing command and the error message, no?  That would save me
quite a bit of time; even if you don't analyze the error at all.  In
fact, copy-n-paste of the message is often more important than the error
analysis done.  Thanks.

Anyway, this test definitely needs -no-undefined.  When I add that,
however, the test fails like this under native MinGW:

++ eval test -n '"$PATH"'
+++ test -n 
'/home/ralf/lt/build/tests:/home/ralf/lt/libtool/tests:/home/ralf/local/bin:/home/ralf/lt/build:/home/ralf/lt/libtool:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Programme/ATI
 Technologies/ATI Control 
Panel:/C/Qt/2009.02/qt/bin:/C/msysgit/msysgit/bin:/C/msysgit/msysgit/mingw/bin'
++ sep=:
++ eval 'PATH=$addpath$sep$PATH'
+++ 
PATH=/home/ralf/lt/build/tests/testsuite.dir/29/moved/bin:/home/ralf/lt/build/tests:/home/ralf/lt/libtool/tests:/home/ralf/local/bin:/home/ralf/lt/build:/home/ralf/lt/libtool:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Programme/ATI
 Technologies/ATI Control 
Panel:/C/Qt/2009.02/qt/bin:/C/msysgit/msysgit/bin:/C/msysgit/msysgit/mingw/bin
++ export PATH

[SNIP]

../../libtool/tests/shlibpath.at:67: if "$lt_exe" ; then :; else lt_status=$?;     test $lt_status != 0 &&         test 
"X$host" != "X$build" && test -x "$lt_exe" && exit 77;     exit $lt_status; fi

[SNIP]


along with popup windows noting that the "a" symbol wasn't found in the
library.

AFAICS this is due to the wrapper executable adding paths for us.

Yes . The wrapper executable executable set PATH variable to ...\\testsuite.dir\\29\\sub\\lib;...\testsuite.dir\\29\\sub\\bin; + OLD_PATH . OLD_PATH list "...\\moved\\bin" but directory is in the list after ...\\sub\\bin so loader found "wrong_lib" first.

Charles Wilson patch "[PATCH] Enable runtime cwrapper debugging; add tests" from 22.06.2009 (GMT) show this well ./m.exe --lt-debug :
(lt_update_lib_path) modifying 'PATH' by prepending ''
(lt_update_exe_path) modifying 'PATH' by prepending '...\testsuite.dir\29\sub\lib;...\sub\bin;' (lt_setenv) setting 'PATH' to '...\testsuite.dir\29\sub\lib;...\testsuite.dir\29\sub\bin;C:\windows\system32;C:\windows....'
(main) lt_argv_zero : .../testsuite.dir/29/.libs/m.exe
(main) newargz[0]   : .../testsuite.dir/29/.libs/m.exe
XXXX: Call from 0x7ef9c609 to unimplemented function liba-0.dll.a, aborting

In cross-environment test script change PATH in build environment and its value is not propagated to the emulated environment. So this break the test in emulated env.


Same issue for "static.at".


I think we need to change the test to only try out an installed program,
but I'm not quite sure yet.
I'm not sure how to make the test run smoothly in a cross compile setup
(but pursuing that further should come after going through the pending
cross compile patches).

Other tests pass (lt_dlopen.at skipped it is fine as test require system that allows undefined symbols, darwin is out of scope).


Cheers,
Ralf






reply via email to

[Prev in Thread] Current Thread [Next in Thread]