Re: [PATCH] tests: skip with-pic test when no "real" pic flag is used.
On 2012-09-19 23:02, Roumen Petrov wrote: > Peter Rosin wrote: >> On 2012-09-19 21:43, Roumen Petrov wrote: >>> Peter Rosin wrote: * tests/with-pic.at: Windows uses "-DDLL_EXPORT -DPIC" as the pic "flag", but never applies it to static libraries. Cater for this and skip if no "real" pic flag is in use. >>> I'm not sure that this test is suitable for mingw host. >>> >>> Signed-off-by: Peter Rosin --- tests/with-pic.at | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) Ok to push? >>> No as libtool should define -DPIC and for mingw host "pic" flag is >>> -DDLL_EXPORT >> The test skips on MinGW with the patch, w/o the patch it >> fails. You are first saying that the test is not suitable >> for MinGW (implying that a skip is in order), and then you >> don't like the patch (implying that a fail is good news). >> You don't make any sense. >> >> So, what do you mean? > On woe libtool define -DDLL_EXPORT as pic flag . So the value is > pic_flag=" -DDLL_EXPORT -DPIC" > On some "other" platform "PIC default". I don't have asses to > those platforms and I could guess that the value is pic_flag="-DPIC", > i.e. only wit defines. Ah, now the objection makes sense. Thanks for spelling it out! > If I understand patched code properly, skip the test if pic_flag > contain only defines. This mean that "other" platform will be skipped > too. Correct. > What about to skip test only if DLL_EXPORT is in pic_flag ? Since the patch has already been pushed and it is only a test that may be skipped on some "other" platforms, I'm going to wait for a bit until someone can confirm if this change has in fact caused skips where the test used to pass. So, not rushing this one... Anyway, the change is simple if needed: -real_pic=false +no_dlls=: case " $pic_flag " in -[*" "[^" "-]* | *" "-[^D]*]) real_pic=: ;; +"* -DDLL_EXPORT *") no_dlls=false ;; esac -AT_CHECK([$real_pic || exit 77]) +AT_CHECK([$no_dlls || exit 77]) Cheers, Peter
Re: [PATCH] tests: skip with-pic test when no "real" pic flag is used.
Peter Rosin wrote: On 2012-09-19 21:43, Roumen Petrov wrote: Peter Rosin wrote: * tests/with-pic.at: Windows uses "-DDLL_EXPORT -DPIC" as the pic "flag", but never applies it to static libraries. Cater for this and skip if no "real" pic flag is in use. I'm not sure that this test is suitable for mingw host. Signed-off-by: Peter Rosin --- tests/with-pic.at | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) Ok to push? No as libtool should define -DPIC and for mingw host "pic" flag is -DDLL_EXPORT The test skips on MinGW with the patch, w/o the patch it fails. You are first saying that the test is not suitable for MinGW (implying that a skip is in order), and then you don't like the patch (implying that a fail is good news). You don't make any sense. So, what do you mean? On woe libtool define -DDLL_EXPORT as pic flag . So the value is pic_flag=" -DDLL_EXPORT -DPIC" On some "other" platform "PIC default". I don't have asses to those platforms and I could guess that the value is pic_flag="-DPIC", i.e. only wit defines. If I understand patched code properly, skip the test if pic_flag contain only defines. This mean that "other" platform will be skipped too. What about to skip test only if DLL_EXPORT is in pic_flag ? Cheers, Peter Roumen
Re: [PATCH] tests: don't feed -no-undefined to the linker during, configure.
Peter Rosin wrote: On 2012-09-19 21:25, Roumen Petrov wrote: Peter Rosin wrote: * tests/deplibs-mingw.at: Restore LDFLAGS for the configure run so that the linker does not see -no-undefined. Makes the test pass instead of skip on MinGW. Signed-off-by: Peter Rosin --- tests/deplibs-mingw.at |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Ok to push? No idea. It pass to me with git code , cross build, tested in emulated environment. It's strange that you get a pass, if you have mingw. Note that the test is a bit weird in that it passes instead of skips on $host_os != mingw*, so are you sure you even get into the inner configure with your setup? Because if you do, your compiler must accept -no-undefined and that seems unlikely to me. Anyway, in my non-cross, non-emulated setup, the test skips on line 79: LT_AT_CONFIGURE([|| exit 77], ["$abs_top_srcdir"/configure]) where configure bombs out with the compiler not being able to create executables (due to gcc not understanding -no-undefined). I see my regular test are based on 3.4.5, sometime with 4.4 . I just tested with 4.6 and configure "bombs". So with oldest version gcc just warn as config.log show .. configure:3695: i386-mingw32msvc-gcc --version >&5 i386-mingw32msvc-gcc (GCC) 3.4.5 (mingw special) .. configure:3726: checking whether the C compiler works configure:3748: i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -L/opt/mingw/lib -no-undefined conftest.c >&5 i386-mingw32msvc-gcc: unrecognized option `-no-undefined' configure:3752: $? = 0 configure:3800: result: yes .. So, the patch upgrades this completely bogus skip to a pass on real MinGW. With newer gcc versions only. Probably behavior is changed in 4.5. So patch is required. Cheers, Peter Roumen
Re: [PATCH] tests: feed -no-undefined when linking libtool libraries
On 2012-09-19 21:32, Roumen Petrov wrote: > Peter Rosin wrote: >> On 2012-09-19 09:31, Peter Rosin wrote: >>> * tests/runpath-in-lalib.at: Make sure shared libraries are created >>> on Windows by passing -no-undefined. Otherwise libb.la fails to record >>> a dependency on liba.la, and the final link of the program then fails >>> with undefined symbols. >>> >>> Signed-off-by: Peter Rosin >>> --- >>> tests/runpath-in-lalib.at |1 + >>> 1 files changed, 1 insertions(+), 0 deletions(-) >>> >>> Ok to push? > No idea . Test pass to me with current repository code, cross build , run in > emulated . You haven't finished reading the thread. The problem was deeper and the regression has been identified as an accidentally inverted test. Adding -no-undefined was not the correct answer (I hinted at that suspicion in my original message), but if your setup works with git master, then your setup does not behave as the real MinGW behaves when trying to link with undefined symbols. Cheers, Peter
Re: [PATCH] tests: skip with-pic test when no "real" pic flag is used.
On 2012-09-19 21:43, Roumen Petrov wrote: > Peter Rosin wrote: >> * tests/with-pic.at: Windows uses "-DDLL_EXPORT -DPIC" as the pic >> "flag", but never applies it to static libraries. Cater for this >> and skip if no "real" pic flag is in use. > I'm not sure that this test is suitable for mingw host. > > >> Signed-off-by: Peter Rosin >> --- >> tests/with-pic.at | 11 ++- >> 1 files changed, 10 insertions(+), 1 deletions(-) >> >> Ok to push? > No as libtool should define -DPIC and for mingw host "pic" flag is > -DDLL_EXPORT The test skips on MinGW with the patch, w/o the patch it fails. You are first saying that the test is not suitable for MinGW (implying that a skip is in order), and then you don't like the patch (implying that a fail is good news). You don't make any sense. So, what do you mean? Cheers, Peter
Re: [PATCH] tests: don't feed -no-undefined to the linker during, configure.
On 2012-09-19 21:25, Roumen Petrov wrote: > Peter Rosin wrote: >> * tests/deplibs-mingw.at: Restore LDFLAGS for the configure run so that >> the linker does not see -no-undefined. Makes the test pass instead of >> skip on MinGW. >> >> Signed-off-by: Peter Rosin >> --- >> tests/deplibs-mingw.at |3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> Ok to push? > No idea. It pass to me with git code , cross build, tested in emulated > environment. It's strange that you get a pass, if you have mingw. Note that the test is a bit weird in that it passes instead of skips on $host_os != mingw*, so are you sure you even get into the inner configure with your setup? Because if you do, your compiler must accept -no-undefined and that seems unlikely to me. Anyway, in my non-cross, non-emulated setup, the test skips on line 79: LT_AT_CONFIGURE([|| exit 77], ["$abs_top_srcdir"/configure]) where configure bombs out with the compiler not being able to create executables (due to gcc not understanding -no-undefined). So, the patch upgrades this completely bogus skip to a pass on real MinGW. Cheers, Peter
Re: [PATCH] tests: skip with-pic test when no "real" pic flag is used.
Peter Rosin wrote: * tests/with-pic.at: Windows uses "-DDLL_EXPORT -DPIC" as the pic "flag", but never applies it to static libraries. Cater for this and skip if no "real" pic flag is in use. I'm not sure that this test is suitable for mingw host. Signed-off-by: Peter Rosin --- tests/with-pic.at | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) Ok to push? No as libtool should define -DPIC and for mingw host "pic" flag is -DDLL_EXPORT Roumen
Re: [PATCH] tests: feed -no-undefined when linking libtool libraries
Peter Rosin wrote: On 2012-09-19 09:31, Peter Rosin wrote: * tests/runpath-in-lalib.at: Make sure shared libraries are created on Windows by passing -no-undefined. Otherwise libb.la fails to record a dependency on liba.la, and the final link of the program then fails with undefined symbols. Signed-off-by: Peter Rosin --- tests/runpath-in-lalib.at |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Ok to push? No idea . Test pass to me with current repository code, cross build , run in emulated . Roumen
Re: [PATCH] tests: don't feed -no-undefined to the linker during, configure.
Peter Rosin wrote: * tests/deplibs-mingw.at: Restore LDFLAGS for the configure run so that the linker does not see -no-undefined. Makes the test pass instead of skip on MinGW. Signed-off-by: Peter Rosin --- tests/deplibs-mingw.at |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Ok to push? No idea. It pass to me with git code , cross build, tested in emulated environment. Roumen
Re: [PATCH] tests: feed -no-undefined when linking libtool libraries
On 2012-09-19 16:20, Gary V. Vaughan wrote: > Hi Peter, > > My bad, I'm embarrassed to say. I started to write a script to make the > appropriate changes, but ended up doing it manually rather than adding > more and more corner cases to the throwaway script... a poor choice in > hindsight :-( It's easy to be wise after the fact... If you do redo it, may I suggest breaking up the patch in smaller pieces for bisectability? > On 19 ก.ย. 2012, at 19:27, Peter Rosin wrote: >> On 2012-09-19 11:26, Peter Rosin wrote: >>> On 2012-09-19 09:31, Peter Rosin wrote: * tests/runpath-in-lalib.at: Make sure shared libraries are created on Windows by passing -no-undefined. Otherwise libb.la fails to record a dependency on liba.la, and the final link of the program then fails with undefined symbols. Signed-off-by: Peter Rosin --- tests/runpath-in-lalib.at |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Ok to push? Or maybe the failure is deeper than this? Should libb.la record a dependency on liba.la even if libb.la is static only? >>> >>> I likely is deeper, it seems this is a regression since 2.4.2. >> >> I have bisected this regression to 962aa919f51cdf8e2cee4fb2d1d9bafa34d50887 >> syntax-check: fix violations and implement >> sc_prohibit_test_const_follows_var. >> >> I looked through that insanely huge patch and it was not fun. I did >> manage to find a couple of problems: >> >> -if test "$pic_mode" = no && test "$deplibs_check_method" != pass_all; >> then >> +if test yes = "$pic_mode" && test pass_all != "$deplibs_check_method"; >> then >> >> -if test "$prev" = dlprefiles; then >> +if test dlfiles = "$prev"; then >> >> -if test "x`$SED 1q $export_symbols`" != xEXPORTS; then >> +if test EXPORTS = "`$SED 1q $export_symbols`"; then >> >> -if test "x[$]$2" = xyes; then >> +if test yes != "[$]$2"; then >> >> However, my eyes must have glazed over because it is not enough to fix those >> bugs. > > I guess my whole brain glazed over while I was checking and rechecking > before pushing, so I'm not surprised. > >> Comparing to master, I notice that: >> >> * The export_symbols change has a fixup in >> b804ffabee2ce373d9bac6ae2b235ec68e0b55e8 >> fixup: restore EXPORTS test >> * The "x[$]$2" change has a fixup in >> 11869b9c9eb8bcc8cb6a615141f522a447377324 >> m4: fix logic error leading to -fno-rtti being added wrongly. >> >> I have removed a long rant on my opinion of the offending patch, it >> would do no good anyway... > > Thanks for finding it, and sparing me from the additional shame. > >> Bottom line: More eyes needed on that patch! >> >> Ok to push the below? > > I think it will be safer to revert the broken patch, and then > write a script to reapply those changes automatically as I > should have done originally, and only then to merge the result > back to head. If you hold off for a few days, I'll do that as > penance for my sins when I get back to my computer. I'm not sure a revert of such a big patch is possible after 50-odd more patches? But I was thinking revert too after reading it for a while... Who knows what else hides in there? > But please hold on to your test case to verify that I've made > a better job of things on the do over. That's easy, on Cygwin: make check-local TESTSUITEFLAGS="-k Runpath" is supposed to PASS (not FAIL) and make check-local TESTSUITEFLAGS="-k relpaths" is supposed to XFAIL (not XPASS) (mentioning it here so that I don't forget myself) Meanwhile, I found another one by diffing the --debug output from building libb.la in runpath-in-lalib.at with/without the offender: - if test "$deplibs_check_method" != pass_all; then + if test pass_all = "$deplibs_check_method"; then A fixup of this change actually makes the above tests behave on Cygwin/MinGW. So, in case it proves too hard to revert and redo, the below is my current fixup-patch. Cheers, Peter >From 072c4beb6564c39099d4c691620e2fac5f32f7ed Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Wed, 19 Sep 2012 16:38:34 +0200 Subject: [PATCH] fixup: restore stomped tests Commit v2.4.2-120-g962aa91 syntax-check: fix violations and implement sc_prohibit_test_const_follows_var inadvertenty stomped some comparisons. * build-aux/ltmain.m4sh (func_mode_compile): Reverse test when checking if non-PIC is attempted in shared libraries. (func_mode_link): Check for dlprefiles, not dlfiles. (func_mode_link): Reverse test so that dependencies are checked when pass_all is not in effect. --- build-aux/ltmain.m4sh |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh index 14f3c37..0b8defa 100644 --- a/build-aux/ltmain.m4sh +++ b/build-aux/ltmain.m4sh @@ -1350,7 +1350,7 @@ func_mode_compile () pic_mode=default ;; esac -if test yes = "$pic_mode" && test pass_all != "$deplibs_check_method"; then +
Re: [PATCH] tests: feed -no-undefined when linking libtool libraries
Hi Peter, My bad, I'm embarrassed to say. I started to write a script to make the appropriate changes, but ended up doing it manually rather than adding more and more corner cases to the throwaway script... a poor choice in hindsight :-( On 19 ก.ย. 2012, at 19:27, Peter Rosin wrote: > On 2012-09-19 11:26, Peter Rosin wrote: >> On 2012-09-19 09:31, Peter Rosin wrote: >>> * tests/runpath-in-lalib.at: Make sure shared libraries are created >>> on Windows by passing -no-undefined. Otherwise libb.la fails to record >>> a dependency on liba.la, and the final link of the program then fails >>> with undefined symbols. >>> >>> Signed-off-by: Peter Rosin >>> --- >>> tests/runpath-in-lalib.at |1 + >>> 1 files changed, 1 insertions(+), 0 deletions(-) >>> >>> Ok to push? >>> Or maybe the failure is deeper than this? Should libb.la record a >>> dependency on liba.la even if libb.la is static only? >> >> I likely is deeper, it seems this is a regression since 2.4.2. > > I have bisected this regression to 962aa919f51cdf8e2cee4fb2d1d9bafa34d50887 > syntax-check: fix violations and implement sc_prohibit_test_const_follows_var. > > I looked through that insanely huge patch and it was not fun. I did > manage to find a couple of problems: > > -if test "$pic_mode" = no && test "$deplibs_check_method" != pass_all; > then > +if test yes = "$pic_mode" && test pass_all != "$deplibs_check_method"; > then > > -if test "$prev" = dlprefiles; then > +if test dlfiles = "$prev"; then > > -if test "x`$SED 1q $export_symbols`" != xEXPORTS; then > +if test EXPORTS = "`$SED 1q $export_symbols`"; then > > -if test "x[$]$2" = xyes; then > +if test yes != "[$]$2"; then > > However, my eyes must have glazed over because it is not enough to fix those > bugs. I guess my whole brain glazed over while I was checking and rechecking before pushing, so I'm not surprised. > Comparing to master, I notice that: > > * The export_symbols change has a fixup in > b804ffabee2ce373d9bac6ae2b235ec68e0b55e8 > fixup: restore EXPORTS test > * The "x[$]$2" change has a fixup in > 11869b9c9eb8bcc8cb6a615141f522a447377324 > m4: fix logic error leading to -fno-rtti being added wrongly. > > I have removed a long rant on my opinion of the offending patch, it > would do no good anyway... Thanks for finding it, and sparing me from the additional shame. > Bottom line: More eyes needed on that patch! > > Ok to push the below? I think it will be safer to revert the broken patch, and then write a script to reapply those changes automatically as I should have done originally, and only then to merge the result back to head. If you hold off for a few days, I'll do that as penance for my sins when I get back to my computer. But please hold on to your test case to verify that I've made a better job of things on the do over. > Cheers, > Peter Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [PATCH] tests: feed -no-undefined when linking libtool libraries
On 2012-09-19 11:26, Peter Rosin wrote: > On 2012-09-19 09:31, Peter Rosin wrote: >> * tests/runpath-in-lalib.at: Make sure shared libraries are created >> on Windows by passing -no-undefined. Otherwise libb.la fails to record >> a dependency on liba.la, and the final link of the program then fails >> with undefined symbols. >> >> Signed-off-by: Peter Rosin >> --- >> tests/runpath-in-lalib.at |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> Ok to push? >> Or maybe the failure is deeper than this? Should libb.la record a >> dependency on liba.la even if libb.la is static only? >> >> The relevant difference in libb.la with this patch is this (I have >> elided changes to dlopen and library_names which are empty when >> no shared library is built): >> >> @@ -17,7 +17,7 @@ >> inherited_linker_flags='' >> >> # Libraries that this one depends upon. >> -dependency_libs=' >> -R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar ' >> +dependency_libs=' >> -R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar >> /home/peda/libtool/git/cygwin/tests/testsuite.dir/047/liba.la' >> >> # Names of additional weak libraries provided by this library >> weak_library_names='' > > I likely is deeper, it seems this is a regression since 2.4.2. I have bisected this regression to 962aa919f51cdf8e2cee4fb2d1d9bafa34d50887 syntax-check: fix violations and implement sc_prohibit_test_const_follows_var. I looked through that insanely huge patch and it was not fun. I did manage to find a couple of problems: -if test "$pic_mode" = no && test "$deplibs_check_method" != pass_all; then +if test yes = "$pic_mode" && test pass_all != "$deplibs_check_method"; then - if test "$prev" = dlprefiles; then + if test dlfiles = "$prev"; then - if test "x`$SED 1q $export_symbols`" != xEXPORTS; then + if test EXPORTS = "`$SED 1q $export_symbols`"; then -if test "x[$]$2" = xyes; then +if test yes != "[$]$2"; then However, my eyes must have glazed over because it is not enough to fix those bugs. Comparing to master, I notice that: * The export_symbols change has a fixup in b804ffabee2ce373d9bac6ae2b235ec68e0b55e8 fixup: restore EXPORTS test * The "x[$]$2" change has a fixup in 11869b9c9eb8bcc8cb6a615141f522a447377324 m4: fix logic error leading to -fno-rtti being added wrongly. I have removed a long rant on my opinion of the offending patch, it would do no good anyway... Bottom line: More eyes needed on that patch! Ok to push the below? Cheers, Peter >From 79d4c09db4317f2f96ba7cbbfc06a8a9da0ff984 Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Wed, 19 Sep 2012 14:23:26 +0200 Subject: [PATCH] fixup: restore stomped tests Commit v2.4.2-120-g962aa91 syntax-check: fix violations and implement sc_prohibit_test_const_follows_var inadvertedly stomped some comparisons. * build-aux/ltmain.m4sh (func_mode_compile): Reverse test when checking if non-PIC is attempted in shared libraries. (func_mode_link): Check for dlprefiles, not dlfiles. --- build-aux/ltmain.m4sh |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh index 14f3c37..69722ef 100644 --- a/build-aux/ltmain.m4sh +++ b/build-aux/ltmain.m4sh @@ -1350,7 +1350,7 @@ func_mode_compile () pic_mode=default ;; esac -if test yes = "$pic_mode" && test pass_all != "$deplibs_check_method"; then +if test no = "$pic_mode" && test pass_all != "$deplibs_check_method"; then # non-PIC code in shared libraries is not supported pic_mode=default fi @@ -5151,7 +5151,7 @@ func_mode_link () fi # CHECK ME: I think I busted this. -Ossama - if test dlfiles = "$prev"; then + if test dlprefiles = "$prev"; then # Preload the old-style object. func_append dlprefiles " $pic_object" prev=
Re: [PATCH] tests: skip with-pic test when no "real" pic flag is used.
On 2012-09-19 11:20, Gary V. Vaughan wrote: > Hi Peter, > > On 19 ก.ย. 2012, at 15:56, Peter Rosin wrote: > >> * tests/with-pic.at: Windows uses "-DDLL_EXPORT -DPIC" as the pic >> "flag", but never applies it to static libraries. Cater for this >> and skip if no "real" pic flag is in use. >> [[...]] >> >> Ok to push? > > Yes, with nit below addressed. Thanks! > >> I tried to eliminate the loop using variants of this: >> >> real_pic=false >> case " $pic_flag " in >> *" "[^-]* | *" "-[^D]*) real_pic=: ;; >> esac >> AT_CHECK([$real_pic || exit 77]) >> >> ...but I never got that to work in the test. It worked in an >> interactive bash though. Strange. > > M4 will strip one level of square brackets as it generates the testsuite > script. Normally we just put an extra level of quoting around regexps/globs > to account for that: > > [*" "[^-]* | *" "-[^D]*]) real_pic=: ;; Doh! Face-palm. It's been a while... I needed an extra space to not see " " as a real pic flag. This is what I pushed: Cheers, Peter diff --git a/tests/with-pic.at b/tests/with-pic.at index cee5e32..915acf5 100644 --- a/tests/with-pic.at +++ b/tests/with-pic.at @@ -24,7 +24,11 @@ AT_SETUP([test --with-pic]) eval `$LIBTOOL --config | $EGREP '^(pic_flag|FGREP)='` -AT_CHECK([test -n "$pic_flag" || exit 77]) +real_pic=false +case " $pic_flag " in +[*" "[^" "-]* | *" "-[^D]*]) real_pic=: ;; +esac +AT_CHECK([$real_pic || exit 77]) AT_CHECK([test . != "$at_srcdir" || exit 77]) CONFIGURE=$abs_top_srcdir/tests/demo/configure
Re: [PATCH] tests: feed -no-undefined when linking libtool libraries
On 2012-09-19 09:31, Peter Rosin wrote: > * tests/runpath-in-lalib.at: Make sure shared libraries are created > on Windows by passing -no-undefined. Otherwise libb.la fails to record > a dependency on liba.la, and the final link of the program then fails > with undefined symbols. > > Signed-off-by: Peter Rosin > --- > tests/runpath-in-lalib.at |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > Ok to push? > Or maybe the failure is deeper than this? Should libb.la record a > dependency on liba.la even if libb.la is static only? > > The relevant difference in libb.la with this patch is this (I have > elided changes to dlopen and library_names which are empty when > no shared library is built): > > @@ -17,7 +17,7 @@ > inherited_linker_flags='' > > # Libraries that this one depends upon. > -dependency_libs=' > -R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar ' > +dependency_libs=' > -R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar > /home/peda/libtool/git/cygwin/tests/testsuite.dir/047/liba.la' > > # Names of additional weak libraries provided by this library > weak_library_names='' I likely is deeper, it seems this is a regression since 2.4.2. Cheers, Peter
Re: [PATCH] tests: skip with-pic test when no "real" pic flag is used.
Hi Peter, On 19 ก.ย. 2012, at 15:56, Peter Rosin wrote: > * tests/with-pic.at: Windows uses "-DDLL_EXPORT -DPIC" as the pic > "flag", but never applies it to static libraries. Cater for this > and skip if no "real" pic flag is in use. > [[...]] > > Ok to push? Yes, with nit below addressed. Thanks! > I tried to eliminate the loop using variants of this: > > real_pic=false > case " $pic_flag " in > *" "[^-]* | *" "-[^D]*) real_pic=: ;; > esac > AT_CHECK([$real_pic || exit 77]) > > ...but I never got that to work in the test. It worked in an > interactive bash though. Strange. M4 will strip one level of square brackets as it generates the testsuite script. Normally we just put an extra level of quoting around regexps/globs to account for that: [*" "[^-]* | *" "-[^D]*]) real_pic=: ;; (untested -- still on vacation ;-) Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
[PATCH] tests: skip with-pic test when no "real" pic flag is used.
* tests/with-pic.at: Windows uses "-DDLL_EXPORT -DPIC" as the pic "flag", but never applies it to static libraries. Cater for this and skip if no "real" pic flag is in use. Signed-off-by: Peter Rosin --- tests/with-pic.at | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) Ok to push? I tried to eliminate the loop using variants of this: real_pic=false case " $pic_flag " in *" "[^-]* | *" "-[^D]*) real_pic=: ;; esac AT_CHECK([$real_pic || exit 77]) ...but I never got that to work in the test. It worked in an interactive bash though. Strange. Cheers, Peter diff --git a/tests/with-pic.at b/tests/with-pic.at index cee5e32..e4f52c2 100644 --- a/tests/with-pic.at +++ b/tests/with-pic.at @@ -24,7 +24,16 @@ AT_SETUP([test --with-pic]) eval `$LIBTOOL --config | $EGREP '^(pic_flag|FGREP)='` -AT_CHECK([test -n "$pic_flag" || exit 77]) +# skip if there is no "real" pic flag (-D defines don't count) +set x $pic_flag +shift +for pf; do + case $1 in +-D*) shift ;; +*) break ;; + esac +done +AT_CHECK([test $# -ne 0 || exit 77]) AT_CHECK([test . != "$at_srcdir" || exit 77]) CONFIGURE=$abs_top_srcdir/tests/demo/configure -- 1.7.9
[PATCH] tests: feed -no-undefined when linking libtool libraries
* tests/runpath-in-lalib.at: Make sure shared libraries are created on Windows by passing -no-undefined. Otherwise libb.la fails to record a dependency on liba.la, and the final link of the program then fails with undefined symbols. Signed-off-by: Peter Rosin --- tests/runpath-in-lalib.at |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Ok to push? Or maybe the failure is deeper than this? Should libb.la record a dependency on liba.la even if libb.la is static only? The relevant difference in libb.la with this patch is this (I have elided changes to dlopen and library_names which are empty when no shared library is built): @@ -17,7 +17,7 @@ inherited_linker_flags='' # Libraries that this one depends upon. -dependency_libs=' -R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar ' +dependency_libs=' -R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar /home/peda/libtool/git/cygwin/tests/testsuite.dir/047/liba.la' # Names of additional weak libraries provided by this library weak_library_names='' Cheers, Peter diff --git a/tests/runpath-in-lalib.at b/tests/runpath-in-lalib.at index bdd1279..7c433d3 100644 --- a/tests/runpath-in-lalib.at +++ b/tests/runpath-in-lalib.at @@ -41,6 +41,7 @@ instdir=`pwd`/inst libdir=$instdir/lib bindir=$instdir/bin addrunpath=`pwd`/foobar +LDFLAGS="$LDFLAGS -no-undefined" mkdir $instdir $libdir $bindir -- 1.7.9
