Re: Two small libltdl patches.
* Peter O'Gorman wrote on Tue, Aug 26, 2008 at 06:24:11PM CEST: > Ralf Wildenhues wrote: > > I'd like this to fail for me on darwin (more likely to notice it), so I > will probably add: > > > +AT_CHECK([eval "$NM \"\$argz_o\" | $global_symbol_pipe"], > > +[], [stdout], [ignore]) > > +AT_CHECK([grep "^T argz_" stdout], [1]) > > +AT_CHECK([grep "^T _argz_" stdout], [1]) Of course. Good idea. Thanks, Ralf
Re: Two small libltdl patches.
Ralf Wildenhues wrote: > Yes, certainly. I think a NEWS entry would be good, too, as well as > a test so we don't regress again. What do you think of this? You > can squash it into your patch when you commit. Thanks. > > The test doesn't work on many systems (only those that need argz.c, > and only those without leading underscore in symbol names) and skips > resp. doesn't expose a failure elsewhere, but I think that should be > sufficient. I'd like this to fail for me on darwin (more likely to notice it), so I will probably add: > +AT_CHECK([eval "$NM \"\$argz_o\" | $global_symbol_pipe"], > + [], [stdout], [ignore]) > +AT_CHECK([grep "^T argz_" stdout], [1]) +AT_CHECK([grep "^T _argz_" stdout], [1]) > + > +AT_CLEANUP This should be fine, because all global symbols exported from argz.o must be "lt__" prefixed. Will commit with these changes later today. Peter -- Peter O'Gorman http://pogma.com
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Charles Wilson skrev: I also think that -winnt is too broad; and I'd really hate to see the massive uglification of the libtool code -- and thousands of configure.ac's out there -- that would ensue if -mingw* were /officially/ overloaded to also represent the msvc-toolchain case. Thanks a bunch for that. Where specifically is this "massive uglification" in the pr-msvc-support branch? Cheers, Peter
Re: Two small libltdl patches.
Hi Peter, * Peter O'Gorman wrote on Sat, Aug 23, 2008 at 11:59:00PM CEST: > Subject: [PATCH] Allow for extensions other than .a for preloaded modules. > > * libltdl/m4/ltdl.m4 (_LTDL_SETUP): Define LT_LIBEXT. > * libltdl/ltdl.c (lt_dladvise_preload): Use it. > Reported by Ralf Wildenhues. OK, thanks. Does this need a NEWS entry? I'm not sure. Cheers, Ralf
Re: Two small libltdl patches.
Hi Peter, * Peter O'Gorman wrote on Sat, Aug 23, 2008 at 11:59:00PM CEST: > > On systems without argz we were exporting unmangled symbols argz_count > and argz_add from libltdl. Not really a good idea. Rather than mangle > the names, since we do not use either function, they were removed. > Subject: [PATCH] Remove unnecessary global argz functions. > > * libltdl/argz.c (argz_add,argz_count): Remove. * Peter O'Gorman wrote on Mon, Aug 25, 2008 at 04:43:57AM CEST: > > I just went back and re-read the argz threads on bug-libtool. The two > functions were added back in February, the June thread then decided that > libtool could keep its own argz and only have the functions it needs, > while gnulib's could "evolve along glibc's". ACK. > Now that I look at the patch again, I see that I forgot to remove the > functions from argz_.h :) > > So, with the functions also removed from the header, ok? Yes, certainly. I think a NEWS entry would be good, too, as well as a test so we don't regress again. What do you think of this? You can squash it into your patch when you commit. The test doesn't work on many systems (only those that need argz.c, and only those without leading underscore in symbol names) and skips resp. doesn't expose a failure elsewhere, but I think that should be sufficient. Thanks, Ralf * NEWS: Update. * tests/ltdl-api.at: New file. * Makefile.am: Adjust. diff --git a/NEWS b/NEWS index e0d1062..c85f741 100644 --- a/NEWS +++ b/NEWS @@ -21,6 +21,9 @@ New in 2.2.??: 2008-08-??: git version 2.2.5a, Libtool team: - Several testsuite issues have been fixed, thanks to user feedback. + - Fix 2.2 regression that caused argz symbols to be exported from +libltdl unrenamed on systems that do not have working argz. + New in 2.2.4: 2008-05-04: git version 2.2.3a, Libtool team: * New features: diff --git a/Makefile.am b/Makefile.am index 0085c7f..1417e84 100644 --- a/Makefile.am +++ b/Makefile.am @@ -454,6 +454,7 @@ TESTSUITE_AT= tests/testsuite.at \ tests/am-subdir.at \ tests/lt_dlexit.at \ tests/lt_dladvise.at \ + tests/ltdl-api.at \ tests/need_lib_prefix.at \ tests/standalone.at \ tests/subproject.at \ diff --git a/tests/ltdl-api.at b/tests/ltdl-api.at new file mode 100644 index 000..b811ae3 --- /dev/null +++ b/tests/ltdl-api.at @@ -0,0 +1,36 @@ +# ltdl-api.at -- test libltdl API-*- Autotest -*- +# +# Copyright (C) 2008 Free Software Foundation, Inc. +# Written by Ralf Wildenhues, 2008. +# +# This file is part of GNU Libtool. +# +# GNU Libtool is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# GNU Libtool is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with GNU Libtool; see the file COPYING. If not, a copy +# can be downloaded from http://www.gnu.org/licenses/gpl.html, +# or obtained by writing to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + + +AT_SETUP([ltdl API]) +AT_KEYWORDS([libltdl]) + +# Ensure that no symbols from argz are unrenamed. +eval `$LIBTOOL --config | $EGREP '^(NM|global_symbol_pipe|objext)='` +argz_o=$abs_top_builddir/libltdl/argz.$objext +AT_CHECK([test -f "$argz_o" || exit 77]) +AT_CHECK([eval "$NM \"\$argz_o\" | $global_symbol_pipe"], +[], [stdout], [ignore]) +AT_CHECK([grep "^T argz_" stdout], [1]) + +AT_CLEANUP
RE: hppa-hpux DESTDIR support.
> > Duft Markus wrote: > > >>> Patches that do more good than harm are likely to be accepted. > >> That's exactly the point i'm unsure about, if I do more harm than > good > >> or the other way round :) of course, for _me_ I do more good, but > does > >> it harm others that the hardcode test fails now? > > Sorry, don't know how I missed that patch, still, it strikes me as more > of a hack than a solution (and what is with the commented case > statements being added to ltmain.m4sh?). I wrote about that just in the last mail... the commented thing is to add a rpath everytime, so that +s gets added... > > I'm not even sure how much +s is relevant here, you are changing the > hardcode_minus_L to no, surely that is having the largest effect on > your DESTDIR installs, not the +s changes? I - again - tried to follow the path I took through the libtool sources: >From destdir.at: (so I need fast_install=yes) [# DESTDIR installs do not work with relink at install time. AT_XFAIL_IF([eval `$LIBTOOL --config | grep '^fast_install='` case $fast_install in no) :;; *) false;; esac]) >From libtool.m4: (so I need hardcode_action != relink) if test "$_LT_TAGVAR(hardcode_action, $1)" = relink || test "$_LT_TAGVAR(inherit_rpath, $1)" = yes; then # Fast installation is not supported enable_fast_install=no Again from libtool.m4: (so I need either hardcode_direct = no or hardcode_minus_L = no) # We can hardcode non-existent directories. if test "$_LT_TAGVAR(hardcode_direct, $1)" != no && # If the only mechanism to avoid hardcoding is shlibpath_var, we # have to relink, otherwise we might link with an installed library # when we should be linking with a yet-to-be-installed one ## test "$_LT_TAGVAR(hardcode_shlibpath_var, $1)" != no && test "$_LT_TAGVAR(hardcode_minus_L, $1)" != no; then # Linking always hardcodes the temporary library directory. _LT_TAGVAR(hardcode_action, $1)=relink In reality both harcode_direct and hardcode_minus_L are yes on hpux. This prevents DESTDIR from ever working, since hardcode_action=relink, and thus fast_install=no, and thus DESTDIR=not working ... :( This means I need to make one of the two (hardcode_direct or hardcode_minus_L) "no". hardcode_minus_L is true, because the linker hardcodes the -L as the _default_ path to the lib, which means it is taken into account as a last resort. In libtool.m4 there is this comment: # hardcode_minus_L: Not really in the search PATH, # but as the default location of the library. Which makes me believe, that switching hardcode_minus_L is still wrong, but should work for all cases except for when there is no other path encoded anywhere, right? I now changed my patch, and removed all the +s stuff from it, so there are only two hunks left, changing hardcode_minus_L to yes. The classic Testsuite runs through, except demo-hardcode.test again of course, which detects the hardcode_minus_L "wrong" setting. The Autotest-suite has as many FAILED as always :) but now the destdir.at tests succeed. The new patch looks like this: diff -ru -x 'configu*' -x 'config.*' -x 'Make*' -x '*cache*' -x 'aclocal*' -x 'acinclude*' -x '*doc*' -x ltmain.sh libtool-2.2.4.orig/libltdl/m4/libtool.m4 libtool-2.2.4/libltdl/m4/libtool.m4 --- libtool-2.2.4.orig/libltdl/m4/libtool.m42008-08-22 10:07:34 +0200 +++ libtool-2.2.4/libltdl/m4/libtool.m4 2008-08-25 08:23:40 +0200 @@ -4777,7 +4777,8 @@ # hardcode_minus_L: Not really in the search PATH, # but as the default location of the library. - _LT_TAGVAR(hardcode_minus_L, $1)=yes + _LT_TAGVAR(hardcode_minus_L, $1)=no + ;; esac fi @@ -5707,7 +5708,7 @@ *) _LT_TAGVAR(hardcode_direct, $1)=yes _LT_TAGVAR(hardcode_direct_absolute, $1)=yes -_LT_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH, +_LT_TAGVAR(hardcode_minus_L, $1)=no # Not in the search PATH, # but as the default # location of the library. ;; > > This patch is not acceptable as is, sorry. Yeah, I thought so... Suggestions? > > By the way, do you see DESTDIR installs failing for every package on > hppa-hp-hpux systems? I don't really know, since a colleague gave me that problem. We need DESTDIR for portage to work, and obviously even if it would be only some cases, it would be too many of them. The destdir tests in libtool testsuite are skipped by default, since they have no chance to ever work it seems. Cheers, Markus > > Peter > -- > Peter O'Gorman > http://pogma.com
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev: I created a simple dll, exporting one function doing a printf (some random libc function). When building this dll, MSVC8 generated a manifest, but I instead embedded the manifest pointing to an older msvcr80. I.e. Embedded this: version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> instead of what MSVC8 generated, which was this: version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> Then I created an exe using both fopen (some other libc function) and consuming this dll, and in that exe I embedded the generated manifest (i.e. version 8.0.50727.762). Looking at this exe with depends.exe reveals that only one msvcr80.dll is loaded. That might be a bug in depends.exe though. Turns out there's a "policy" involved as well. For all assemblies on my system containing msvcr80.dll (there's currently three) the policy says to redirect older versions to the one the policy is for. I.e. for version 8.0.50727.1433 of the assembly, there's this in the policy file: newVersion="8.0.50727.1433"/> newVersion="8.0.50727.1433"/> That explains why I only saw one of the dlls being loaded. However, why are versions 8.0.50608.1-8.0.50727.41 not being redirected? That's disheartening... So I took the liberty of temporarily renaming the policy files, and I could indeed make depends.exe show something other than the .1433 dll, but I could not make it show two different libc at the same time. With the policy files renamed, I also failed to make depends.exe show two different msvcr80.dll when using LoadLibrary on the dll instead of linking with the import library, so that's something... Cheers, Peter
Re: hppa-hpux DESTDIR support.
Duft Markus wrote: >>> Patches that do more good than harm are likely to be accepted. >> That's exactly the point i'm unsure about, if I do more harm than good >> or the other way round :) of course, for _me_ I do more good, but does >> it harm others that the hardcode test fails now? Sorry, don't know how I missed that patch, still, it strikes me as more of a hack than a solution (and what is with the commented case statements being added to ltmain.m4sh?). I'm not even sure how much +s is relevant here, you are changing the hardcode_minus_L to no, surely that is having the largest effect on your DESTDIR installs, not the +s changes? This patch is not acceptable as is, sorry. By the way, do you see DESTDIR installs failing for every package on hppa-hp-hpux systems? Peter -- Peter O'Gorman http://pogma.com
