Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Den 2010-09-24 19:37 skrev Ralf Wildenhues: Hi Peter, * Peter Rosin wrote on Fri, Sep 24, 2010 at 11:30:07AM CEST: Den 2010-09-24 06:20 skrev Ralf Wildenhues: The part about this patch which I'm unsure about is this: Does the testsuite otherwise cover well enough the fact that users may name their modules with or without leading 'lib' prefix (and with .la or .dll or .so suffix or so)? IOW, I'd like to be sure we're not hiding anything here. But that is not a problem with *this* patch. That's one of those gigantic tasks that Chuck mentions from time to time. This is not like the low max_cmd_len test. In both cases the libtool script is rigged to simulate weird conditions, but the need_lib_prefix test is rigging something that never happens on platforms that never create a lib prefix. You should also not confuse this prefix with the name of the .la file, the .la files are always allowed to have a lib prefix, this is about the real libraries. Ah, ok. We have plenty of tests that create -modules named module.la without the prefix, for example dlloader-api.la. I'm not sure what you mean by users naming their modules with various suffixes, as they must be named .la? No, they don't. On GNU/Linux, you ought to be able to, say, lt_dlopen(foo.so, ...) if you like. There are users of libltdl that do this. Of course, that requires the users to be aware of the system-specific naming issues, but ideally, some way like this should work on other systems, too. Ah, you meant the *real* module and how it is named when (ab)using it. I was thinking about the name when creating the module. I don't know if we have any tests that try to open the real module, bypassing the .la file. I get the feeling that I'm saying things that you already know, so I'm probably missing something. What? I don't think you are, apart from the above. And yes, I think (part of) the log entry from the initial test addition probably deserves to be a comment in the test, so we don't have to look it up again. Probably a good idea. I'll add some words before pushing anything, but I'd like this settled before doing anything further with the patch. In light of your response, and if my response above doesn't invalidate your reasoning, the patch is ok with me, with that comment added. Excellent, pushed with this comment in need_lib_prefix.at: # Originally written to simulate a failure visible on systems # which need a library prefix like 'lib', such as BeOS. Currently # the prefix is hardcoded as 'lib', so systems that require a # different prefix skips the test. Cheers, Peter
Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Hi Ralf, Den 2010-09-24 06:20 skrev Ralf Wildenhues: Hello Peter, * Peter Rosin wrote on Fri, Sep 17, 2010 at 08:44:43AM CEST: need_lib_prefix.at currently fails with MSVC. I think the test is there to ensure that weird systems continue to work even if the testsuite is running on a normal system. weird in this case are systems with need_lib_prefix set to unknown and normal are those with it set to no. However, there are even weirder systems where need_lib_prefix should perhaps be set to never (i.e. MSVC) but that currently simply sets it to no. never would perhaps be more appropriate since preopen doesn't work right if libs have a lib prefix. I think OS/2 is affected in the same way as MSVC, but I have no means to test that. The below patch makes the need_lib_prefix.at test skip for the even weirder systems, i.e. those where libname_spec does not prefix library names with lib. Ok to push? You may want to compare this patch with thread http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00174.html which instead makes the test pass for the even weirder systems, but I don't think that is really desired. Why should the code be changed to accommodate a contrived test case? Because this would never happen in the wild, right? The part about this patch which I'm unsure about is this: Does the testsuite otherwise cover well enough the fact that users may name their modules with or without leading 'lib' prefix (and with .la or .dll or .so suffix or so)? IOW, I'd like to be sure we're not hiding anything here. But that is not a problem with *this* patch. That's one of those gigantic tasks that Chuck mentions from time to time. This is not like the low max_cmd_len test. In both cases the libtool script is rigged to simulate weird conditions, but the need_lib_prefix test is rigging something that never happens on platforms that never create a lib prefix. You should also not confuse this prefix with the name of the .la file, the .la files are always allowed to have a lib prefix, this is about the real libraries. We have plenty of tests that create -modules named module.la without the prefix, for example dlloader-api.la. I'm not sure what you mean by users naming their modules with various suffixes, as they must be named .la? I get the feeling that I'm saying things that you already know, so I'm probably missing something. What? And yes, I think (part of) the log entry from the initial test addition probably deserves to be a comment in the test, so we don't have to look it up again. Probably a good idea. I'll add some words before pushing anything, but I'd like this settled before doing anything further with the patch. Cheers, Peter
Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Hi Peter, * Peter Rosin wrote on Fri, Sep 24, 2010 at 11:30:07AM CEST: Den 2010-09-24 06:20 skrev Ralf Wildenhues: The part about this patch which I'm unsure about is this: Does the testsuite otherwise cover well enough the fact that users may name their modules with or without leading 'lib' prefix (and with .la or .dll or .so suffix or so)? IOW, I'd like to be sure we're not hiding anything here. But that is not a problem with *this* patch. That's one of those gigantic tasks that Chuck mentions from time to time. This is not like the low max_cmd_len test. In both cases the libtool script is rigged to simulate weird conditions, but the need_lib_prefix test is rigging something that never happens on platforms that never create a lib prefix. You should also not confuse this prefix with the name of the .la file, the .la files are always allowed to have a lib prefix, this is about the real libraries. Ah, ok. We have plenty of tests that create -modules named module.la without the prefix, for example dlloader-api.la. I'm not sure what you mean by users naming their modules with various suffixes, as they must be named .la? No, they don't. On GNU/Linux, you ought to be able to, say, lt_dlopen(foo.so, ...) if you like. There are users of libltdl that do this. Of course, that requires the users to be aware of the system-specific naming issues, but ideally, some way like this should work on other systems, too. I get the feeling that I'm saying things that you already know, so I'm probably missing something. What? I don't think you are, apart from the above. And yes, I think (part of) the log entry from the initial test addition probably deserves to be a comment in the test, so we don't have to look it up again. Probably a good idea. I'll add some words before pushing anything, but I'd like this settled before doing anything further with the patch. In light of your response, and if my response above doesn't invalidate your reasoning, the patch is ok with me, with that comment added. Thanks, Ralf
Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Hello Peter, * Peter Rosin wrote on Fri, Sep 17, 2010 at 08:44:43AM CEST: need_lib_prefix.at currently fails with MSVC. I think the test is there to ensure that weird systems continue to work even if the testsuite is running on a normal system. weird in this case are systems with need_lib_prefix set to unknown and normal are those with it set to no. However, there are even weirder systems where need_lib_prefix should perhaps be set to never (i.e. MSVC) but that currently simply sets it to no. never would perhaps be more appropriate since preopen doesn't work right if libs have a lib prefix. I think OS/2 is affected in the same way as MSVC, but I have no means to test that. The below patch makes the need_lib_prefix.at test skip for the even weirder systems, i.e. those where libname_spec does not prefix library names with lib. Ok to push? You may want to compare this patch with thread http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00174.html which instead makes the test pass for the even weirder systems, but I don't think that is really desired. Why should the code be changed to accommodate a contrived test case? Because this would never happen in the wild, right? The part about this patch which I'm unsure about is this: Does the testsuite otherwise cover well enough the fact that users may name their modules with or without leading 'lib' prefix (and with .la or .dll or .so suffix or so)? IOW, I'd like to be sure we're not hiding anything here. And yes, I think (part of) the log entry from the initial test addition probably deserves to be a comment in the test, so we don't have to look it up again. Subject: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries. * tests/need_lib_prefix.at [MSVC, OS/2]: Skip this test on systems that do not have libraries prefixed with lib. Thanks, Ralf
Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Peter Rosin wrote:
Den 2010-09-18 00:04 skrev Roumen Petrov:
Hi Peter,
Peter Rosin wrote:
Hi!
need_lib_prefix.at currently fails with MSVC.
Hmm probably test fail as shared library is build without -no-undefined flag.
Did libtool MSC allow creation of shared libraries without -no-undefined ?
On windows platforms (msc, gcc(mingw*)) may be the test require some PATH
magics.
(as example like func_fix_path from static.at test)
You are barking up the wrong tree, since:
1. The test passes on MinGW and Cygwin with gcc, if wouldn't do that if
-no-undefined was the cause of the fail.
2. The patch in the old quoted message makes the test pass on MSVC, which
it wouldn't do if -no-undefined was the cause of the fail.
PATH magic is not relevant if -no-undefined is not passed, since everything
should be static in that case (no dlls created).
But the libtool command contain -rpath so the test build shared and
static libraries .
1) linux native build:
$ cd .../testsuite.dir/086
$ strace -f ./main 21 | grep foo
open(/.libs/tls/i686/libfoo1.so, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/.libs/tls/libfoo1.so, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/.libs/i686/libfoo1.so, O_RDONLY) = -1 ENOENT (No such file
or directory)
open(/.libs/libfoo1.so, O_RDONLY) = 3
open(/.libs/libfoo2.so, O_RDONLY) = 3
write(1, libfoo1: 2\nlibfoo2: 3\n, 22libfoo1: 2
libfoo2: 3
$ ls .../testsuite.dir/086/.libs/
foo1.la@ foo1.lai foo1.o foo2.o libfoo1.a libfoo1.so* libfoo2.a
libfoo2.la@ libfoo2.lai libfoo2.so* lt-main* main* mainS.o
Result test pass. Both static and shared libraries are created. The
executable load shared.
2) In cross-build env. verbose more:
libtool: link: ( cd .libs rm -f foo1.la ln -s ../foo1.la
foo1.la )
/X/need_lib_prefix.at:165: $LIBTOOL --mode=link $CC -module
-avoid-version $CFLAGS $LDFLAGS -o libfoo2.la foo2.lo -rpath $instdir/lib
stderr:
libtool: link: warning: undefined symbols not allowed in
i386-pc-mingw32msvc shared libraries
$ ls .libs/
foo1.la@ foo1.lai foo1.o foo2.o libfoo1.a libfoo2.a libfoo2.la@
libfoo2.lai lt-main.c main.exe* main.exeS.o main_ltshwrapper
Result the test pass. Shared libraries are not created.
I'm not convinced that test is correct for windows platforms.
3) In cross-build env. and test patched with -no-undefined :
$ ls .libs/
foo1.la@ foo1.o libfoo1.a libfoo1.dll.a libfoo2.dll*
libfoo2.la@ lt-main.c main.exeS.o
foo1.lai foo2.o libfoo1.dll* libfoo2.a libfoo2.dll.a
libfoo2.lai main.exe* main_ltshwrapper
Result test skipped = failed.
3.1)
$ cd .../testsuite.dir/086/.libs/
$ ./main.exe
libfoo2: 3
function `f' not found: Procedure not found
error during preloading.
$ strace -f ./main.exe 21 | grep foo
[pid 353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755,
st_size=809650, ...}) = 0
[pid 353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755,
st_size=809650, ...}) = 0
[pid 353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755,
st_size=809650, ...}) = 0
[pid 353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755,
st_size=809650, ...}) = 0
[pid 353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755,
st_size=809650, ...}) = 0
[pid 338] open(/086/.libs/libfoo1.dll,
O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 78
[pid 353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755,
st_size=809650, ...}) = 0
[pid 353] open(/086/.libs/libfoo1.dll, O_RDONLY) = 9
[pid 353] open(/opt/wine/1.3.1/lib/wine/libfoo1.dll.so, O_RDONLY) =
-1 ENOENT (No such file or directory)
[pid 353] open(/opt/wine/1.3.1/lib/wine/libfoo1.dll.so,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755,
st_size=809656, ...}) = 0
[pid 353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755,
st_size=809656, ...}) = 0
[pid 353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755,
st_size=809656, ...}) = 0
[pid 353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755,
st_size=809656, ...}) = 0
[pid 353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755,
st_size=809656, ...}) = 0
[pid 338] open(/086/.libs/libfoo2.dll,
O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 79
[pid 353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755,
st_size=809656, ...}) = 0
[pid 353] open(/086/.libs/libfoo2.dll, O_RDONLY) = 9
[pid 353] open(/opt/wine/1.3.1/lib/wine/libfoo2.dll.so, O_RDONLY) =
-1 ENOENT (No such file or directory)
[pid 353] open(/opt/wine/1.3.1/lib/wine/libfoo2.dll.so,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755,
st_size=809650, ...}) = 0
[pid 353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755,
st_size=809650, ...}) = 0
[pid 353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755,
Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Den 2010-09-18 00:04 skrev Roumen Petrov: Hi Peter, Peter Rosin wrote: Hi! need_lib_prefix.at currently fails with MSVC. Hmm probably test fail as shared library is build without -no-undefined flag. Did libtool MSC allow creation of shared libraries without -no-undefined ? On windows platforms (msc, gcc(mingw*)) may be the test require some PATH magics. (as example like func_fix_path from static.at test) You are barking up the wrong tree, since: 1. The test passes on MinGW and Cygwin with gcc, if wouldn't do that if -no-undefined was the cause of the fail. 2. The patch in the old quoted message makes the test pass on MSVC, which it wouldn't do if -no-undefined was the cause of the fail. PATH magic is not relevant if -no-undefined is not passed, since everything should be static in that case (no dlls created). Cheers, Peter
[PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Hi! need_lib_prefix.at currently fails with MSVC. I think the test is there to ensure that weird systems continue to work even if the testsuite is running on a normal system. weird in this case are systems with need_lib_prefix set to unknown and normal are those with it set to no. However, there are even weirder systems where need_lib_prefix should perhaps be set to never (i.e. MSVC) but that currently simply sets it to no. never would perhaps be more appropriate since preopen doesn't work right if libs have a lib prefix. I think OS/2 is affected in the same way as MSVC, but I have no means to test that. The below patch makes the need_lib_prefix.at test skip for the even weirder systems, i.e. those where libname_spec does not prefix library names with lib. Ok to push? You may want to compare this patch with thread http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00174.html which instead makes the test pass for the even weirder systems, but I don't think that is really desired. Why should the code be changed to accommodate a contrived test case? Because this would never happen in the wild, right? Oh, and one more thing, there's no rush for this one. Cheers, Peter From d23b133decabf20349e7b2a13aec5b1ce070b03c Mon Sep 17 00:00:00 2001 From: Peter Rosin p...@lysator.liu.se Date: Thu, 16 Sep 2010 23:17:28 +0200 Subject: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries. * tests/need_lib_prefix.at [MSVC, OS/2]: Skip this test on systems that do not have libraries prefixed with lib. Signed-off-by: Peter Rosin p...@lysator.liu.se --- ChangeLog|6 ++ tests/need_lib_prefix.at |7 +++ 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 37f6c84..1f86926 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2010-09-16 Peter Rosin p...@lysator.liu.se + + Skip need_lib_prefix.at on systems without lib prefix on libraries. + * tests/need_lib_prefix.at [MSVC, OS/2]: Skip this test on + systems that do not have libraries prefixed with lib. + 2010-09-16 Ralf Wildenhues ralf.wildenh...@gmx.de tests: avoid localization failure due to unstable compiler messages. diff --git a/tests/need_lib_prefix.at b/tests/need_lib_prefix.at index f6cfcfb..bed24b6 100644 --- a/tests/need_lib_prefix.at +++ b/tests/need_lib_prefix.at @@ -148,6 +148,13 @@ esac], [], [ignore]) CPPFLAGS=$LTDLINCL $CPPFLAGS LDFLAGS=$LDFLAGS +# Skip this test when libraries are not normally prefixed with lib. +# E.g., for MSVC and OS/2. +eval `$LIBTOOL --config | $EGREP '^(libname_spec)='` +name= +eval libname=\$libname_spec\ +AT_CHECK([test $libname = lib || exit 77]) + # Create our own libtool, forcing need_lib_prefix setting sed 's,^\(need_lib_prefix\)=.*$,\1=unknown,' $LIBTOOL ./libtool LIBTOOL=$SHELL ./libtool -- 1.7.1
Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Hi Peter, Peter Rosin wrote: Hi! need_lib_prefix.at currently fails with MSVC. Hmm probably test fail as shared library is build without -no-undefined flag. Did libtool MSC allow creation of shared libraries without -no-undefined ? On windows platforms (msc, gcc(mingw*)) may be the test require some PATH magics. (as example like func_fix_path from static.at test) I think the test is there to ensure that weird systems continue to work even if the testsuite is running on a normal system. weird in this case are systems with need_lib_prefix set to unknown and normal are those with it set to no. However, there are even weirder systems where need_lib_prefix should perhaps be set to never (i.e. MSVC) but that currently simply sets it to no. never would perhaps be more appropriate since preopen doesn't work right if libs have a lib prefix. I think OS/2 is affected in the same way as MSVC, but I have no means to test that. The below patch makes the need_lib_prefix.at test skip for the even weirder systems, i.e. those where libname_spec does not prefix library names with lib. The test use libtool -module flag and thus libtool won't complain if library is created without lib prefix. Ok to push? No if -no-undefined and PATH magic resolve failure in this test. [SNIP] Roumen
