Wgcc status report
Hey again! Wgcc status report ;o) (this is rc4 with libtool patch from today): PASS: cdemo-static.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-static.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: depdemo-static.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-static.test PASS: mdemo-make.test PASS: mdemo-exec.test PASS: mdemo-inst.test PASS: mdemo-unst.test PASS: cdemo-conf.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-conf.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: deplibs.test PASS: depdemo-conf.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-conf.test PASS: mdemo-make.test PASS: mdemo-exec.test PASS: mdemo-inst.test PASS: mdemo-unst.test PASS: dryrun.test PASS: demo-nofast.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: demo-pic.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-nopic.test PASS: demo-make.test PASS: demo-exec.test PASS: depdemo-nofast.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: cdemo-shared.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-shared.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test SKIP: hardcode.test FAIL: build-relink.test PASS: noinst-link.test PASS: demo-unst.test PASS: depdemo-shared.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test FAIL: build-relink2.test PASS: depdemo-unst.test PASS: mdemo-shared.test PASS: mdemo-make.test PASS: mdemo-exec.test PASS: mdemo-inst.test PASS: mdemo-unst.test PASS: assign.test PASS: link.test PASS: link-2.test PASS: nomode.test PASS: quote.test PASS: sh.test PASS: suffix.test PASS: pdemo-conf.test PASS: pdemo-make.test PASS: pdemo-exec.test PASS: pdemo-inst.test PASS: mdemo-conf.test PASS: mdemo-make.test PASS: mdemo2-conf.test PASS: mdemo2-make.test FAIL: mdemo2-exec.test PASS: duplicate_members.test PASS: link-order.test PASS: tagdemo-static.test PASS: tagdemo-make.test PASS: tagdemo-exec.test PASS: tagdemo-conf.test PASS: tagdemo-make.test PASS: tagdemo-exec.test PASS: tagdemo-shared.test PASS: tagdemo-make.test PASS: tagdemo-exec.test 3 of 102 tests failed (1 tests were not run) Please report to bug-libtool@gnu.org This looks *very* cool ;o) For the tests failed: hardcode will never work, thats clear (fails with gcc too). The other three, i really have no idea there. Mdemo2 fails only half, as far as i've seen the static version executes OK. I think the error is, that libltld allways tries to dlopen the static library, not the shared one, but i can't figure it out (i hate dlpreopening ;o)) (and i can't read my own changed code anymore... *argl* ;o)) I also tested gcc, to see if my changes influenced it somehow. Only hardcode.test failed, and thats ok (it does without my patch too) ;o). I now changed the hardcode.test to skip on all interix platforms for now. Cheers, Markus libtool-1.5.22-wgcc-2.x-26-09-2006.patch Description: libtool-1.5.22-wgcc-2.x-26-09-2006.patch ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Wgcc status report
Hello Markus, I would prefer if you did not send messages to the libtool list twice, did not send messages including large patches to the libtool list (that's what the libtool-patches list is for), and I would also personally prefer if your announcement frequency were more that of an, err, announcement. Users interested in every next step can still read your interix-wgcc-developer and/or the libtool-patches list. * Duft Markus wrote on Tue, Sep 26, 2006 at 09:44:10AM CEST: > FAIL: build-relink.test > FAIL: build-relink2.test > FAIL: mdemo2-exec.test > This looks *very* cool ;o) For the tests failed: hardcode will never > work, thats clear (fails with gcc too). Wrong. The hardcode test tests that the settings in libtool.m4 conform to expected behavior. The settings are false, thus the failure. > I now changed the hardcode.test to skip on all interix platforms for > now. So you paper over the issue. > The other three, i really have > no idea there. Mdemo2 fails only half, as far as i've seen the static > version executes OK. I think the error is, that libltld allways tries to > dlopen the static library, not the shared one, but i can't figure it out > (i hate dlpreopening ;o)) (and i can't read my own changed code > anymore... *argl* ;o)) > > I also tested gcc, to see if my changes influenced it somehow. Only > hardcode.test failed, and thats ok (it does without my patch too) ;o). If you desire to get your changes into GNU Libtool, you should strive to - keep system-specific changes out of ltmain.sh, and out of all the tests as much as is sanely possible. Remember the tests should also demonstrate what users are expected to do, so work hard to keep the number of preprocessor conditionals down to a minimum; and to - not break any other system with your patches; that is a show-stopper. Using `uname' in ltmain.sh is wrong, that breaks for cross-compilation. Some of the comments in the patch you posted are wrong (they are copy and pasted from elsewhere, but do not match the pasted code). I would like to encourage you to port your patch to CVS Libtool, as it has a better testsuite. In case that is too much work for you, you may anyway want to try its testsuite with ./tests/testsuite LIBTOOL=/path/to/1.5.22/build/libtool -k libtool \ -k stresstest Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Dlpreopen on windows
Hello Markus, * Duft Markus wrote on Mon, Sep 25, 2006 at 05:18:21PM CEST: > > Libtool generates a symbol table on the fly which it then compiles and > links in, correct? > That symbols table contains both .text and .data symbols. There is no > problem with .text symbols so far ;o) > As i saw the nmS file uses a one letter prefix to identify the type > of symbol. My mdemo.nmS for exmaple has three types: > > T.text i think, so all functions > B.bss (??) i think, initialized data > C.data (??) uninitialized data? The types are derived from how `nm' on unices shows the ELF sections: "B" The symbol is in the uninitialized data section (known as BSS). "C" The symbol is common. Common symbols are uninitialized data. When linking, multiple common symbols may appear with the same name. If the symbol is defined anywhere, the common symbols are treated as undefined references. "D" The symbol is in the initialized data section. "T" The symbol is in the text (code) section. We should probably change the mdemo test to not only test common symbols (they are the least important), but to test initialized (to null and to non-null) symbols. Oh well, the stresstest in HEAD is useful for that. > P.S.: the windows compiler does not define data symbols in object files > if they are not referenced at least once in that object file. So the > libtool mdemo/foo(1|2).c nothing variable is missing in the objects > unless i initialize them with something (0 in my case...). Hmm. Is there a command line option to make it emit the common symbol? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Hardcoding paths.
Hi again!
With wgcc (again ;o)) i now tell libtool, that hardcoding is
"unsupported". Configure tells this too now, so everything seems to be
ok. But when i run hardcode.test:
= Searching for hardcoded library directories in each program
.libs was not hardcoded in `hc-direct', as libtool expected
.libs was not hardcoded in `hc-libflag', which fooled libtool
.libs was not hardcoded in `hc-libpath', as libtool expected
.libs was not hardcoded in `hc-minusL', as libtool expected
FAIL: hardcode.test
Err... When hardcoding is unsupported, why the ... Does libtool expect
hardcoded paths? Libtool looks like this:
hardcode_action=unsupported
hardcode_into_libs=yes
hardcode_libdir_flag_spec="\${wl}-rpath,\$libdir"
hardcode_libdir_flag_spec_ld=""
hardcode_libdir_separator=""
hardcode_direct=no
hardcode_minus_L=no
hardcode_shlibpath_var=no
hardcode_automatic=no
I know i will set hardcode_into_libs to no in the future, but i don't
think this is the reason, or could this be?
Cheers, markus
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Hardcoding paths.
* Duft Markus wrote on Tue, Sep 26, 2006 at 12:08:52PM CEST:
>
> = Searching for hardcoded library directories in each program
> .libs was not hardcoded in `hc-direct', as libtool expected
> .libs was not hardcoded in `hc-libflag', which fooled libtool
> .libs was not hardcoded in `hc-libpath', as libtool expected
> .libs was not hardcoded in `hc-minusL', as libtool expected
> FAIL: hardcode.test
>
> Err... When hardcoding is unsupported, why the ... Does libtool expect
> hardcoded paths? Libtool looks like this:
>
> hardcode_action=unsupported
> hardcode_into_libs=yes
As you rightly note, hardcode_into_libs should be set to no.
> hardcode_libdir_flag_spec="\${wl}-rpath,\$libdir"
Well, I assume wgcc just throws away `-Wl,-rpath', right?
So this setting is not honest: it's not really possible to hardcode
paths into outputs on w32. But fixing this requires other fixes in
ltmain before that, see this thread for more details:
http://lists.gnu.org/archive/html/libtool-patches/2006-09/msg00010.html
> hardcode_libdir_flag_spec_ld=""
> hardcode_libdir_separator=""
> hardcode_direct=no
> hardcode_minus_L=no
> hardcode_shlibpath_var=no
> hardcode_automatic=no
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
