Re: DESTDIR install on hppa-hpux
* Michael Haubenwallner wrote on Thu, Jun 04, 2009 at 01:35:11PM CEST: On Wed, 2009-06-03 at 20:54 +0200, Ralf Wildenhues wrote: The most important part of the fix is already suggested in comments around 'hardcode_minus_L=yes', as the encoded library path is used as fallback location for a specific library when runpath lookup fails. As this isn't really 'hardcoding' in libtool's sense, hardcode_minus_L can safely be set to 'no' IMO, opening the door for DESTDIR support. Hmm. This does open a small security issue, no? Imagine the following setup: user joe compiles some package, then uses 'sudo make install' to install it in a system location. First issue: the path to the compilation location is revealed in the installed libraries and programs which have dependencies to newly-installed libraries. Second, if those deplibs are removed for whatever reason, then the runtime linker will search in joe's build tree for the shared libraries. This may not be likely to happen, but it's something to think about. I've thought about this too, but how would the link command have to look like to avoid this issue? I don't know. That's precisely the reason we haven't gone this way before. Another minor one was that there is no need to pass +b $install_libdir, as the linker ignores subsequent +b values. Erm, libtool has code to merge multiple run path values (and to let ltmain know that this needs to be done). Weren't semantics on HP-UX that way that, if +b was not used, then the linked path with -L is searched too? That would be bad then. This is done anyway using $hardcode_libdir_flag_spec. Leaving +b $install_libdir in $archive_cmds would ignore the subsequent collected +b $libdir. Oh. So I guess this would be an independent fix anyway? arch HP-UX bits * compiler -- What does this table mean? That for each of the combinations, the libtool testsuite was run, Exactly. and there were no failures? Well, there weren't _no_ failures, but the same failures compared to vanilla git/master, except for the 12 tests changing from SKIP or XFAIL to PASS (see above). Cool. Thank you. Cheers, Ralf
Re: DESTDIR install on hppa-hpux
On Wed, 2009-06-03 at 20:54 +0200, Ralf Wildenhues wrote: With this patch, 10 tests (demo-nofast.test to depdemo-unst.test) change from SKIP to PASS, and both Simple DESTDIR install and DESTDIR with in-package deplibs (destdir.at) change from expected failure to ok, for the 32bit hppa environments marked with * below. No other tests do change their result. The most important part of the fix is already suggested in comments around 'hardcode_minus_L=yes', as the encoded library path is used as fallback location for a specific library when runpath lookup fails. As this isn't really 'hardcoding' in libtool's sense, hardcode_minus_L can safely be set to 'no' IMO, opening the door for DESTDIR support. Hmm. This does open a small security issue, no? Imagine the following setup: user joe compiles some package, then uses 'sudo make install' to install it in a system location. First issue: the path to the compilation location is revealed in the installed libraries and programs which have dependencies to newly-installed libraries. Second, if those deplibs are removed for whatever reason, then the runtime linker will search in joe's build tree for the shared libraries. This may not be likely to happen, but it's something to think about. I've thought about this too, but how would the link command have to look like to avoid this issue? This does require to use 'chatr' in demo-hardcode.test to not get false positives when testing for hardcoded path (more comments inside). That seems like an acceptable compromise. Another minor one was that there is no need to pass +b $install_libdir, as the linker ignores subsequent +b values. Erm, libtool has code to merge multiple run path values (and to let ltmain know that this needs to be done). Weren't semantics on HP-UX that way that, if +b was not used, then the linked path with -L is searched too? That would be bad then. This is done anyway using $hardcode_libdir_flag_spec. Leaving +b $install_libdir in $archive_cmds would ignore the subsequent collected +b $libdir. The patch has been tested in these HP-UX environments (as well as on linux and aix, without any test result changes there): arch HP-UX bits * compiler -- What does this table mean? That for each of the combinations, the libtool testsuite was run, Exactly. and there were no failures? Well, there weren't _no_ failures, but the same failures compared to vanilla git/master, except for the 12 tests changing from SKIP or XFAIL to PASS (see above). Thank you! /haubi/
Re: purpose of the c wrapper
Ralf Wildenhues wrote:
Hello Vincent, Bob,
[SNIP]
But anyway, I don't see how the current git code generates C wrappers
for wince.
The host is usually xxx-mingw32ce and will match patterns like
{*-}*-mingw*, i.e. it will generate wrappers as for mingw32.
But the C-wrapper-code of current (my repository close is about one
month old) libtool don't include error.h :
.
#ifndef __MINGW32CE__
# include errno.h
#endif
.
[SNIP]
Roumen
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
Hello Vincent, * Vincent Torri wrote on Wed, Jun 03, 2009 at 09:32:50PM CEST: Does there exist a simulator for wince? Even if not now, can there exist one at some point? In that case, we should strive to not make things harder for that setup. there is a simulator for Windows CE that can be run on linux. But it is a pain to setup and to use, and i never succeeded in using it for graphic programs (which is the purpose of the libraries I'm porting). Hmm. But libtool aims to be usable not just for you. Oh well, I guess we've been there before, but no other user has shown up yet. The file link_output.txt is the result of the command : /bin/bash ../../libtool --tag=CC --debug --mode=link arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import -L/home/torri/local/wince/lib -Wl,-s -o test_evil.exe test_evil.o ../../src/lib/libevil.la link_output.txt 21 My version of libtool : 2.2.6 Well, we've been through this before, too. You and I have put in fixes for this bit after 2.2.6 was released, the relevant one seems to be in 4e7334c7c28e51d3943339f6f3617985c03e3f79. Try current git or a nightly snapshot, it will set $wrappers_required to no, which is not the case in the log you have showed: + wrappers_required=yes + case $host in + test yes '!=' yes + test yes = no + test -n '' + test -n '' + compile_var= + finalize_var= Then everything should work just fine. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: d3dx9.lib is not managed by ld, but libd3dx9.a is
Vincent Torri wrote: Hey, I'm writing a dll using D3D and autotools stuff (MSYS / MinGW). I pass -ld3dx9 and i have added everything so that the dll is built. If I add from the DirectX SDK d3dx9.lib in /mingw/lib, i have the usual warning message from linker / libtool: *** Warning: linker path does not have real file for library -ld3dx9. blah blah blah and only the static lib is built. If I rename d3dx9.lib to libd3dx9.a, then the DLL is built. I don't understand why because, according to the doc of ld for win32: http://sourceware.org/binutils/docs/ld/WIN32.html if I pass -ld3dx9, then d3dx9.lib should be used. What is the reason of the failure ? thank you Vincent Torri I'm not sure that libtool has to deal with library '.lib' suffix. From the suffix is not clear type of library file - static or import library. GNU compiler(mingw) use suffix '.a' for static library and '.dll.a' for import libraries. If a xx.lib file is found in search path libtool has to process file and to find its type(static/import). This impact performance. Also support for MSVC import libraries isn't perfect and linker will fail to link if a library export variables. Note in this case GNU linker succeed to link directly shared(DLL) library. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
Hey, * Vincent Torri wrote on Wed, Jun 03, 2009 at 09:32:50PM CEST: Does there exist a simulator for wince? Even if not now, can there exist one at some point? In that case, we should strive to not make things harder for that setup. there is a simulator for Windows CE that can be run on linux. But it is a pain to setup and to use, and i never succeeded in using it for graphic programs (which is the purpose of the libraries I'm porting). Hmm. But libtool aims to be usable not just for you. Oh well, I guess we've been there before, but no other user has shown up yet. well, the emulator is not really usable on linux, and it emulates only some versions of Windows CE, not all. The file link_output.txt is the result of the command : /bin/bash ../../libtool --tag=CC --debug --mode=link arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import -L/home/torri/local/wince/lib -Wl,-s -o test_evil.exe test_evil.o ../../src/lib/libevil.la link_output.txt 21 My version of libtool : 2.2.6 Well, we've been through this before, too. You and I have put in fixes for this bit after 2.2.6 was released, the relevant one seems to be in 4e7334c7c28e51d3943339f6f3617985c03e3f79. Try current git or a nightly snapshot, it will set $wrappers_required to no, I have just tried with the latest git of libtool. And I have exactly the same problem, $wrappers_required is set to 'yes'. I think that I know why. wrappers_required is set to 'no' only if cegcc is used. I should be a bit more precise: The cegcc framework provide 2 sets of cross compilation toolchain: a) 'cegcc', which provides a POSIX emulation (a kind of cygwin for win ce) b) 'mingw32ce', which provides a native compilation toolchain in ltmain.m4sh, only cegcc is mentioned. mingw32ce should also be mentioned. Here is below a patch, which fixes the problem. Note that I have to put the test before *cygwin* | *mingw* because otherwise, mingw32ce will fall into that case (which was actually the case) Vincent Torri diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 5609304..778666b 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -7411,15 +7411,15 @@ EOF wrappers_required=yes case $host in + *cegcc* | *mingw32ce* ) +# Disable wrappers for cegcc and mingw32ce, we are cross compiling anyway. +wrappers_required=no +;; *cygwin* | *mingw* ) if test $build_libtool_libs != yes; then wrappers_required=no fi ;; - *cegcc*) -# Disable wrappers for cegcc, we are cross compiling anyway. -wrappers_required=no -;; *) if test $need_relink = no || test $build_libtool_libs != yes; then wrappers_required=no ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
On Thu, 4 Jun 2009, Roumen Petrov wrote:
Ralf Wildenhues wrote:
Hello Vincent, Bob,
[SNIP]
But anyway, I don't see how the current git code generates C wrappers
for wince.
The host is usually xxx-mingw32ce and will match patterns like {*-}*-mingw*,
i.e. it will generate wrappers as for mingw32.
i have just sent a mail with a patch for that.
But the C-wrapper-code of current (my repository close is about one month
old) libtool don't include error.h :
.
#ifndef __MINGW32CE__
# include errno.h
#endif
and if the patch os accepted, you can remove the 3 #ifndef __MINGW32CE__
that are in the wrapper for cygwin / mingw
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
Hi Charles, * Charles Wilson wrote on Thu, Jun 04, 2009 at 04:20:12AM CEST: Ralf Wildenhues wrote: (On most w32 systems, a script without an .exe extension would match such a rule as well, but that's not the case for example on GNU/Linux - w32 cross compiles and with some weird Cygwin mount options.) ...such as the default (only) mount mode under the upcoming cygwin-1.7 release. Ugh. Thanks for the heads-up! I didn't know (or forgot again) Cygwin was going to go that way. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
