Re: DESTDIR install on hppa-hpux
Hello Michael, * Michael Haubenwallner wrote on Wed, May 27, 2009 at 12:16:59AM CEST: now I've managed to get 'make install DESTDIR=...' working on hppa-hpux10 and hppa-hpux11 with libtool. Cool. 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. 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. 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 -- hppa 10.20 32 * gcc-3.0.1 hppa 10.20 32 * HP C Compiler A.10.32.30 (with CXX=false) hppa 11.11 32 * gcc-3.3.4 hppa 11.11 32 * HP C Compiler PHCO_27774 + HP ANSI C++ A.03.52 hppa 11.11 64HP C Compiler PHCO_27774 + HP ANSI C++ A.03.52 ia64 11.23 32gcc-4.2.4 ia64 11.23 32HP aC++/ANSI C A.06.10 (both cc/aCC) ia64 11.23 64gcc-4.2.4 ia64 11.23 64HP aC++/ANSI C A.06.10 (both cc/aCC hppa 11.31 32 * gcc-4.3.1 hppa 11.31 32 * HP C Compiler PHCO_27774 + HP ANSI C++ A.03.85 hppa 11.31 64HP C Compiler PHCO_27774 + HP ANSI C++ A.03.85 What does this table mean? That for each of the combinations, the libtool testsuite was run, and there were no failures? I haven't looked at the patch in detail yet. Thanks! Ralf
Re: purpose of the c wrapper
On Tue, 2 Jun 2009, Bob Friesenhahn wrote: On Tue, 2 Jun 2009, Vincent Torri wrote: So, the first line is the link of my real binary (evil_suite.exe), then the compilation of the c wrapper is done and is failing. If I run make install, evil_suite.exe is not installed. This is expected behavior since the Makefile uses the wrapper binary as the target and libtool takes care of building the files in .libs as a sort of side-effect (please ignore the man behind the curtain). If you put any file at all in place of the wrapper (e.g. 'touch evil_suite.exe') then it seems likely that make install would work. I don't know enough about Windows CE to know if a wrapper executable can be made to work at all. Imho, the wrapper will never work (as i can't execute Windows CE code when i'm cross-compiling) and hence is useless for that platform. How can it be disabled when using cegcc / mingw32ce ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
Hello Vincent, Bob, Bob already noted that the primary reason for any kind of wrapper, be that a shell script or a compiled C program, for uninstalled programs is so that uninstalled shared libraries are found when these programs are executed. Another reason is that, on some platforms, programs may need to be relinked upon installation, and in that case, the wrapper provides the necessary information to libtool to allow it to do the relinking at 'make install' time. (This is for disabled or impossible fast-install mode only.) Whether a shell or a C wrapper is generated is currently a hardcoded mess in the ltmain.m4sh script. MinGW and Cygwin hosts will have a C wrapper, so that the generated file will have an .exe extension, so that it will satisfy the 'make' rule for the program. (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.) 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. But anyway, I don't see how the current git code generates C wrappers for wince. Can you post a small example Makefile.am that causes this, and then post the failing 'libtool --mode=link' command, rerun it manually with --debug added (you can stuff it in LIBTOOLFLAGS) and post all output of that? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
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. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
