Re: [PATCH] libtool: remove OpenBSD support for non-shared and a.out archs
On Wed, 17 Jan 2024, Roumen Petrov wrote: Hi All Mike Frysinger wrote: On 16 Jan 2024 21:11, Brad Smith wrote: libtool: remove OpenBSD support for non-shared and a.out archs OpenBSD stopped supporting the last non-shared arch 8 years ago and stopped supporting a.out 10.5 years ago. This cannot be reason to drop support. For instance RHEL was release in 2011 and is still supported. This seems like a strong argument, but there are other factors. A strong reason to stop supporting a target/version is if it's existence interferes with maintenance/development and there is no reasonable means available to verify that the support still works. Support which is not periodically tested likely does not work any more. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [PATCH 0/3] Fix typos and update links
On Thu, 23 Nov 2023, Antonin Décimo wrote: As a side question: is libtool still maintained? I also note that the latest version isn't reported on the webpage (2.4.7 instead of 2.4.6). Which web page (e.g. URL, documentation file in libtool git) are you talking about? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [PATCH v2 04/12] ltmain.in: Don't encode RATHS which match default linker paths
On Sat, 16 Apr 2022, Sam James wrote:
From: Richard Purdie
We don't want to add RPATHS which match default linker search paths, they're
a waste of space. This patch filters libtools list of paths to encoode and
removes the ones we don't need.
While cross-compiling some software ("Curl") for a target which
already had an older install present, libtool ended up defeating me.
I wanted to produce my own libcurl and have the apps specifically
linking with it, use the libcurl that I had built. I wanted to leave
the libcurl that came with the system in place for the many other
existing apps which needed it. Unfortunately, the add-on software was
already configured to install and use libraries in "/usr/lib" and the
popular/default "/usr/local/lib" was included in the default linker
path so that would not have worked either.
The libtool I was using (originating from Ubuntu Linux) stripped the
rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable
to embed an rpath in the libcurl I built so that applications linked
with that libcurl would find it.
The end result was that apps linked with the new libcurl tried to use
an older libcurl on the system, and failed to run.
I was unable to circumvent this issue caused by libtool.
It is useful if user-provided options have priority over built-in
optimizations in libtool.
As a user, I strongly suggest that libtool honor user-supplied options
to the configure script and provided to the libtool command line, even
while it optimizes other unneeded options away.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive
On Sun, 21 Nov 2021, Alex Ameen wrote: Overall I think we're on the same page. I understand that `libtool' is ultimately intended to provide cross-platform consistency as a portability wrapper around each platform's various compilers, linkers, and loaders. It is certainly not my intention to promote a specific tool or platform over another. I am glad that our new maintainer is philosophically on the same page and also has excellent skills. I think that (similar to the influence of GNU/FSF philosophies on software development) libtool should help guide application developers to to use the most portable approaches while achieving their own objectives. From this standpoint, libtool (and Autotools in general) are not just 'tools' (like 'ld') but help guide users (developers) so that if they follow guidelines, and what the tools intend to promote, their applications are most likely to be portable and still work well. If the development/porting problem is looked at using Venn diagrams, then there would be a proportion of features/solutions in common amongst modern targets and those should be the features/solutions which are promoted by Autotools. In some cases the description of what is wanted can be at a high enough level that the desired low-level behavior can be accomplished entirely differently on different targets (because of how they work). In Autotools, the above has worked well, although there have been many complaints over the years about libtool behavior regarding explicit dependencies (via ".la" files) whereas leveraging implicit dependencies are usually prefered by distribution maintainers. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive
On Sat, 20 Nov 2021, Alex Ameen wrote: Thanks for the follow up, this gave me a much clearer idea of the underlying issue that you're trying to solve. I really do appreciate you taking the time to help improve `libtool'. You're absolutely right that `libtool' completely bungles the use of `--whole-archive' and `--no-whole-archive' which I see as a high priority issue. In several build systems I've built in the past I have needed to apply manual patches to `libtool' to work around this, and I plan on merging changes to fix this soon ( I'm taking my time to create test cases ). I don't pretend to understand the associated issues, but please take care that libtool does not promote solutions which only work with GNU ld (or linkers designed to perfectly emulate GNU ld) on a limited set of targets. Libtool is a portability solution to encourage development of software which is able to compile and run on many targets, even if the authors of the software have never experienced those targets. Linking static libraries into shared libraries is a complex topic and is a reason why libtool offers the clumsy/inefficient "convenience library" mechanism since it assures that the objects were compiled properly to be used in the library they are linked into. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Organization of ltmain.in into sub-files
On Mon, 18 Oct 2021, Alex Ameen wrote: This sounds great to me, I'd love to lend a hand. I had filled out the form a few weeks ago when I sent in patch for `/usr/bin/file' references, so that might still be sitting in the queue for review. If not, let me know and I can file a new request. The problem is that there are no libtool maintainers to service your requests. :-( This means that you would need to contact the GNU organization to express your interest in becomming a libtool maintainer. There are many pending bug reports with patches to be integrated. Your own work may collide with these patches so they can not be easily applied. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Organization of ltmain.in into sub-files
On Sun, 17 Oct 2021, Alex Ameen wrote: I thought I had seen in some TODO notes that other maintainers had been working on reorganizing `ltmain.in', so I wanted to poke my head in and see if there was an existing branch doing this sort of works, or if this was something that anyone thinks would be useful as a project branch? Right now Your work sounds like an excellent idea. The major problem for the libtool project right now is that (as far as I am aware) there have not been active maintainers for years. It seems like you have the skills required for this task. Becoming an official libtool maintainer would help move the project forward and make it easier to integrate your own ideas. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: when linking on Solaris 64bit shared object using cc, -m64 should be used
On Mon, 9 Jun 2014, Petr Sumbera wrote: Hi, I'm often getting following error: /usr/apr/1.5/build/sparcv9/libtool --silent --mode=link cc -o mod_dtrace.la -rpath /usr/apache2/2.2/libexec/sparcv9 -module -avoid-version mod_dtrace.lo ld: fatal: file .libs/mod_dtrace.o: wrong ELF class: ELFCLASS64 apxs:Error: Command failed with rc=131072 Attached patch fixes the issue. Normally such options should already be included in CFLAGS (or sometimes works better in CC). All of the software needs to be compiled with the same -m64 option. When compiling using the Sun compiler and targeting 64-bits, I configure using something like ./configure 'CC=/opt/SUNWspro/bin/cc -m64' ... Libtool is not multilib capable under Solaris. That is, it does not automatically install a library into an architecture-specific subdirectory or search there either. You might notice that the system does support different directories (e.g. '/lib/32', '/lib/64', '/lib/amd64') and GCC is multilib capable, putting its own 64-bit libraries in an architecture-specific subdirectory. For my own 64-bit compiles under Solaris, I use a different installation prefix in order to make sure that 32-bit and 64-bit libraries/includes are sane. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: when linking on Solaris 64bit shared object using cc, -m64 should be used
On Tue, 10 Jun 2014, Petr Sumbera wrote: And finally I was uncertain with CC=cc -m64. It appeared to me as something what can cause some troubles and should be rather avoided. In my experience, this has worked best for Solaris. Libtool uses CC (or CXX in the case of C++) for linking. Until such time that libtool implements proper multilib support, this seems like the most reliable solution. It would be wrong for libtool to incorporate a partial solution. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: g++ and -nostdlib
On Mon, 11 Nov 2013, Peter Rosin wrote: Quite a lot of effort went into making this work the way it currently does. I realize that, but if it really works or not is a different question :-) Yes, of course. It is obviously primarily working as demonstrated by the massive amount of software linked for years and years using libtool. I.e., as far as I can tell, $LD is not used for linking. $CXX is used, with -nostdlib and some manually detected libs/objects, which end up wrong if different flags (such as -pthread) are used when digging and actually linking. Yes, GCC has known bugs with reporting the libraries which would actually be used based on proposed arguments. It must be the case that GCC maintainers don't consider this to be a bug since GCC has not changed its behavior. Googling a bit more turned up this old quote from Ralf [1] on this subject: BTW, I believe libtool does the -nostdlib stuff because, at least in the past, not using it could cause situations where later libstdc++ would not be found automatically. I think at least for dlopen'ed modules depending on C++ libraries this is still the case (completely untested). That was 8 years ago, even then it appears noone really knew why -nostdlib is used (which is interesting in itself). As far as I am aware, the issue is primarily due to some C++ standard libraries being delivered as static libraries (usually due to C++ exceptions problems) and therefore necessitating being linked to the dependent executable rather than into a shared library (which may then be linked with other shared libraries linked into an executable). This magic is done via information cached in the .la files. Intuiting all the libraries which would be used has been a core tenant of libtool given that it attempts to record all the linkage dependencies in its .la files. So, someone needs to write some test cases that tries to build a library with --static-libgcc and then use that in a program w/o --static-libgcc (and vice versa), as well as doing some dlopen test with C++ modules to try to deduce if the above problem described by Ralf can still be reproduced (but his wording suggest that it might be subtle). And lastly we might need some test that tries to throw C++ exceptions over DLL boundaries, if that isn't already done by tests/exceptions.at... The tests/exceptions.at tests the ability to catch exceptions thrown from a DLL. It is not uncommon for it to fail with GCC for certain targets due to target-specific libtool bugs or GCC compiler bugs. Even with this test, it very difficult to tell if the C++ exceptions framework is really working. In my experience, C++ exceptions are reliably working with proprietary compilers and sometimes failing with GCC. In my opinion, this topic is significant enough that it should be discussed on the general libtool list before any decision to rip out the existing special GCC support and treat GCC similar to other compilers. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: g++ and -nostdlib
On Fri, 8 Nov 2013, Peter Rosin wrote: Hi! There seem to be a longstanding complaint that libtool is using -nostdlib when it links libraries using g++. It interferes with -pthread and I think I have also seen other issues. No one can give a satisfactory explanation why libtool does this, it seems Isn't it because libtool wants to control the order of the linking and assure that all dependencies (including static) are tracked/known and applied at the correct times? It wants to assure that static dependencies are linked into the dependent program rather than into some dependent shared library (and thus causing a problem). It was common (and perhaps still is) for the GNU C++ library to be delivered as a static library for Windows/MinGW because C++ exceptions were not handled properly when thrown by DLLs. Quite a lot of effort went into making this work the way it currently does. First libtool tries to take away all of the libraries which would be added automatically and then it applies the libraries that GCC says it would use at the correct time. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Support 64-bit default GCC on Solaris/x86
On Wed, 9 Oct 2013, Brooks Moses wrote: On 10/31/2011 06:14 AM, Rainer Orth wrote: In version 4.7, GCC will gain a 64-bit default Solaris/x86 configuration, similar to the existing sparcv9-sun-solaris2 configurations. In order for that to work with GNU ld (Sun ld works out of the box), I had to make the following minor patch to libtool.m4. This patch has been tested with a slightly earlier version already included in the gcc repository for Go support. There's an effort underway to upgrade the libtool in gcc to 2.4.2. A gcc bootstrap with 64-bit gld and this patch included completed without regressions. Looks like this is essentially equivalent to the patch from Fabian Groffen that I recently committed: http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=eee4f853019cc246b1d65054771f85ef500098ff The distinction is that you match only x86_64-*-solaris2.1[[0-9]]*, while Fabian's patch matches x86_64-*-solaris*. Is there a need for the more-complex pattern? If so, I can make an amended commit. Fabian's version looks fine to me. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: git-version-gen w/o git
On Fri, 28 Dec 2012, Peter Rosin wrote: Libtool remains regressed and a PITA to work with for me until this is fixed. I'm a bit frustrated since the changes are tiny and non-intrusive, at least in my opinion. I also find the extra dependencies to be frustrating. In my case, I check out and do edits on a real unix system but share the same files (via Samba) for use by Cygwin and MSYS/MinGW. Only one system should need to run git. Besides Windows, the ability to do the minimum on remote, isolated, or resource-limited target systems is useful. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Windows Line Endings
On Tue, 9 Oct 2012, Roumen Petrov wrote: You just point that you lack basic knowledge and experience with libtool test suite . With recent commits you just ask you commit privileges to be revoked due lack of background knowledge Peter, I hop that after 10 years you will reach level of Ralf . Your posting is clearly in violation of RFC 1855 (http://www.ietf.org/rfc/rfc1855.txt). The Internet mail system is based on IETF RFCs so they should be respected. Please be pleasant. At least in public. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Windows Line Endings
On Sat, 6 Oct 2012, Gary V. Vaughan wrote: I actually run a lot of virtual machines on my Mac, including a couple of versions of Mac OS and Linux, and I certainly wouldn't want to squander perfectly good hardware on an OS that I don't use, and wasn't aware of the 180 days trials, so I'll take a look into that next time I have half a day spare. I just forked out $350 for Windows 7 to support free software development. There just did not seem any way around it. The pain is severe. Do they also have similar trials for MSVC? There is free MSVC (Visual Studio Express in Google) available. It is really intended for .net/C# developers, but by following instructions on the net and adding downloadable free SDKs (requires manually editing some configuration files), one can create a Visual Studio capable of building C and C++ code without spending any money. Any idea what the least painful version of Windows for a VM is these days (I'm guessing XP is still the best)? Windows 7 runs very well in VirtualBox. My wife has been running Windows 7 in VirtualBox running on Ubuntu for almost a year now. I wouldn't recommend that anyone start with XP these days since it is 12 years old, patched beyond all repair, and quickly becoming defunct. It is good that you are willing to suffer for the cause. The cmake build system is quickly becoming popular since it works well for Windows and it is a threat to the GNU build system (as we know it). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool quoting error
On Mon, 20 Aug 2012, Peter Rosin wrote: On 2012-08-19 22:18, Peter Rosin wrote: Oops, forgot a couple of backslashes, trying again. Sorry for the noise. Testsuite running, just in case... The patch does not seem to affect the testsuite, so I'll push in a few days. Unless someone speaks up against it of course. The final version (with backslash) looks good to me. No need to wait a few days. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] disable de-duplication of postdeps on Solaris
-solaris2.10/:/usr/ccs/bin/ LIBRARY_PATH=/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/:/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/../../../amd64/:/lib/amd64/:/usr/lib/amd64/:/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/:/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/../../../:/lib/:/usr/lib/ Reading specs from /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/libgomp.spec COLLECT_GCC_OPTIONS='-m64' '-march=opteron' '-v' '-march=native' '-O' '-g' '-g3' '-ggdb' '-Wall' '-Winline' '-Wextra' '-Wno-unknown-pragmas' '-D' '_REENTRANT' '-pthreads' '-o' 'Magick++/tests/exceptions' '-L/usr/local64/lib' '-L/usr/openwin/lib' '-L/usr/lib' '-fopenmp' '-pthreads' '-shared-libgcc' '-pthread' /usr/local/libexec/gcc/i386-pc-solaris2.10/4.7.1/collect2 -V -Y P,/lib/amd64:/usr/lib/amd64 -Qy -o Magick++/tests/exceptions /usr/lib/amd64/crt1.o /usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/crtbegin.o -L/usr/local64/lib -L/usr/openwin/lib -L/usr/lib -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/../../.. -zlazyload Magick++/tests/exceptions.o Magick++/lib/.libs/libGraphicsMagick++.a /home/bfriesen/build/GM-16-static-64bit/magick/.libs/libGraphicsMagick.a -lpthread /usr/local64/lib/liblcms2.so /usr/local64/lib/libtiff.so /usr/local64/lib/libjbig.so /usr/local64/lib/libfreetype.so /usr/local64/lib/libjasper.so /usr/local64/lib/libjpeg.so /usr/local64/lib/libwmflite.so -lXext -lSM -lICE -lX11 -lsocket -lnsl /usr/local64/lib/liblzma! .so -lbz2 -lxml2 -lz /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/libgomp.so -lrt /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/libstdc++.so -R /usr/local64/lib -R /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64 -R /usr/local64/lib -R /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64 -R /usr/openwin/lib -lstdc++ -lm -lc -lgomp -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/crtend.o /usr/lib/amd64/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.1507 ld: warning: file /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/libstdc++.so: attempted multiple inclusion of file ld: warning: file /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/libgomp.so: attempted multiple inclusion of file -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] disable de-duplication of postdeps on Solaris
On Mon, 30 Jul 2012, Fabian Groffen wrote: On 30-07-2012 08:49:17 -0500, Bob Friesenhahn wrote: Libtool link line: /bin/bash ./libtool --tag=CXX --mode=link /usr/local64/bin/c++-64 -march=native -O -g -g3 -ggdb -Wall -Winline -W -Wextra -Wno-unknown-pragmas -D_REENTRANT -pthreads -no-undefined -Wl,-zlazyload -L/usr/local64/lib -R/usr/local64/lib -L/usr/openwin/lib -R/usr/openwin/lib -L/usr/local64/lib -L/usr/lib -o Magick++/tests/exceptions Magick++/tests/exceptions.o Magick++/lib/libGraphicsMagick++.la there's no -lc here libtool: link: /usr/local64/bin/c++-64 -march=native -O -g -g3 -ggdb -Wall -Winline -W -Wextra -Wno-unknown-pragmas -D_REENTRANT -pthreads -Wl,-zlazyload -o Magick++/tests/exceptions Magick++/tests/exceptions.o -L/usr/local64/lib -L/usr/openwin/lib -L/usr/lib Magick++/lib/.libs/libGraphicsMagick++.a /home/bfriesen/build/GM-16-static-64bit/magick/.libs/libGraphicsMagick.a -lpthread /usr/local64/lib/liblcms2.so /usr/local64/lib/libtiff.so -lc /usr/local64/lib/libjbig.so /usr/local64/lib/libfreetype.so /usr/local64/lib/libjasper.so /usr/local64/lib/libjpeg.so /usr/local64/lib/libwmflite.so -lXext -lSM -lICE -lX11 -lsocket -lnsl /usr/local64/lib/liblzma.so -lbz2 -lxml2 -lz /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/libgomp.so -lrt /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/libstdc++.so -lm -fopenmp -pthreads -Wl,-R -Wl,/usr/local64/lib -Wl,-R -Wl,/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64 -Wl,-R -Wl,/usr/local64/lib -Wl,-R -Wl,/usr/local/lib/gcc/i386-! pc-! and there is now so most likely it was in the libGraphicsMagick++.la file, which got it from libtiff's pkg-config perhaps? (just guessing) GraphicsMagick does not use pkg-config. However, I see that -lc is included in the libtiff.la file as a dependency: # Libraries that this one depends upon. dependency_libs=' -R/usr/local64/lib -L/usr/local64/lib /usr/local64/lib/liblzma.la /usr/local64/lib/libjbig.la /usr/local64/lib/libjpeg.la -lz -lm -lc' /usr/local/libexec/gcc/i386-pc-solaris2.10/4.7.1/collect2 -V -Y P,/lib/amd64:/usr/lib/amd64 -Qy -o Magick++/tests/exceptions /usr/lib/amd64/crt1.o /usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/crtbegin.o -L/usr/local64/lib -L/usr/openwin/lib -L/usr/lib -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/../../.. -zlazyload Magick++/tests/exceptions.o Magick++/lib/.libs/libGraphicsMagick++.a /home/bfriesen/build/GM-16-static-64bit/magick/.libs/libGraphicsMagick.a -lpthread /usr/local64/lib/liblcms2.so /usr/local64/lib/libtiff.so /usr/local64/lib/libjbig.so /usr/local64/lib/libfreetype.so /usr/local64/lib/libjasper.so /usr/local64/lib/libjpeg.so /usr/local64/lib/libwmflite.so -lXext -lSM -lICE -lX11 -lsocket -lnsl /usr/local64/lib/libl! zma! .so -lbz2 -lxml2 -lz /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/libgomp.so -lrt /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/libstdc++.so -R /usr/local64/lib -R /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64 -R /usr/local64/lib -R /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64 -R /usr/openwin/lib -lstdc++ -lm -lc -lgomp -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/amd64/crtend.o /usr/lib/amd64/crtn.o -lc was specified, so not much the compiler can do here, IMO. Yesterday I took the link command that libtool was generating and removed -lc from it. GCC still produced -lc in its collect2 invocation. It seems that there are at least two issues. In some cases libtool is putting -lc into the .la files and in some cases (I am suspecting pthreads) GCC injects -lc. I am not seeing -lc listed as a dependency in the other .la files for libraries built for AMD64. A strong clue is that this also appears in libtiff.la: # Linker flags that can not go in dependency_libs. inherited_linker_flags=' -pthreads' I see that libtiff is ingesting and using the AX_PTHREAD macro. As a maintainer of libtiff, I will investigate this. It seems likely to be pulled in through use of OpenGL/GLUT macros. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] disable de-duplication of postdeps on Solaris
On Mon, 30 Jul 2012, Fabian Groffen wrote: I think libtool only injects -lc if it was actually explicitly given, or do you suspect it to do otherwise? I think you are correct. However, once this junk makes it into a libtool .la file then it is preserved by libtool. Your GCC seems to use GNU ld. My GCC build uses Solaris ld and therefore uses the collect2 wrapper, which might cause some change in behavior. My GCC builds (on Solaris 10 and OpenIndiana) do use GNU 'as' from binutils 2.22. In my experience, using GNU ld on Solaris is dangerous. I have been bit by it every time I tried. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] disable de-duplication of postdeps on Solaris
On Thu, 26 Jul 2012, Fabian Groffen wrote: Hi, I tracked down an issue on Solaris/OpenSolaris/OpenIndiana where C++ libraries built by libtool would cause abort/traps when an exception was being thrown. This issue has been causing problems for my C++ library for many years. There is even a libtool test case to replicate it. However, it seems that you may have found the cause and the solution for it (I have not tested to verify). This used to be an issue for x86-64 FreeBSD. I have also observed it with some MinGW installations. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] cwrapper: avoid duplicate strlen calculation.
On Mon, 30 Jan 2012, Peter Rosin wrote:
[Sorry for replying to myself]
I do that often.
* build-aux/ltmain.m4sh (func_emit_cwrapperexe_src:lt_update_exe_path):
Remove duplicate strlen calculation.
Hmmm, I like the following better, so I'm going to push that instead,
in case of silence.
Why wait? Your patch looks fine to apply to me.
Bob
Cheers,
Peter
From 7b945cfdaaad8a87a19fcf837dd4bc04f399b1ab Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Mon, 30 Jan 2012 15:49:05 +0100
Subject: [PATCH] cwrapper: avoid surplus strlen calculations.
* build-aux/ltmain.m4sh (func_emit_cwrapperexe_src:lt_update_exe_path):
Avoid surplus strlen calculations.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
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 922e957..00d063c 100644
--- a/build-aux/ltmain.m4sh
+++ b/build-aux/ltmain.m4sh
@@ -4151,9 +4151,9 @@ lt_update_exe_path (const char *name, const char *value)
char *new_value = lt_extend_str (getenv (name), value, 0);
/* some systems can't cope with a ':'-terminated path #' */
int len = strlen (new_value);
- while (((len = strlen (new_value)) 0) IS_PATH_SEPARATOR
(new_value[len-1]))
+ while ((len 0) IS_PATH_SEPARATOR (new_value[len-1]))
{
- new_value[len-1] = '\0';
+ new_value[--len] = '\0';
}
lt_setenv (name, new_value);
XFREE (new_value);
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.
On Thu, 8 Dec 2011, Gary V. Vaughan wrote:
Instead of doing it this way, I'd almost rather see:
if test ${BASH_VERSION+set} = set; then
Face palm! Absolutely, that is far more sensible. Assuming we decide
to push this patch, I'll do it that way and ditch the host check. Thanks!
Is the value of this variable inheritable by subordinate shells, or is
it an internal shell variable which would never be exported to
subordinate shells?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.
On Thu, 8 Dec 2011, Peter O'Gorman wrote: Any additional forks will slow down the script and should be avoided on all platforms. I definitely agree with that. Besides the Windows problem, it does not seem like fork performance improves linearly from adding processor cores so it is important to minimize forks so that parallel compiles don't hit an bottleneck. Simply removing $(SHELL) from the LIBTOOL variable should fix the bug that this is attempting to fix, without slowing down libtool. Will this approach work ok if the Cygwin/MinGW user is using something like zsh or dash rather than bash? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time.
On Mon, 28 Nov 2011, Peter Rosin wrote: My typical use case is mid-sized at a magnitude or so larger, and even there with a fork rate of approx 10-15 Hz as I'm seeing, it wouldn't be too harsh with a couple of extra forks - a minutes or so on the wall clock time. But it would really add to the pain on some (hypothetical?) large project with thousands of libtool invocations. That's all I'm saying, but *I* am not building any of those... Is Windows fork performance observed to improve linearly as processor cores are added, or does it maintain pretty much a fixed rate? If it does not improve linearly as processor cores are added, then the extra forks will severely impact available performance of parallel builds. I have become used to seeing substantial speedup with 'make -j 4' on a Windows system with four cores. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.
On Wed, 2 Nov 2011, Gary V. Vaughan wrote: Did you consider this existing use while developing the plan to rename this often-shared directory? Yes I did, and it doesn't seem at all onerous to me if I have gone to all the trouble of upgrading libtool and re-bootstrapping my project with it to also amend one line in configure.ac. As it stands, libtoolize will issue an upgrade recommendation, and if you ignore that, nothing will actually break, you will just get duplicate copies of libltdl's build-aux files (compile, config.guess, config.sub, depcomp, install-sh, ltmain.sh and missing) alongside your parent project's files in ltdl/config. Gary, Due to libtool's spotted past, many projects check the 'libtoolized' files (including libltdl) into their project's source control system, including rather crippled systems like CVS. Libtool files then become much more carefully managed than autoconf or automake generated files because libtool was historically more fragile. A change to the libltdl footprint then requires adding/removing/renaming directories. Likewise, it has become common for various OS distributions to patch package's bundled libtool files (which include non-libtool files like config.guess) as part of the procedure to build a package for that OS distribution. Moving the files increases effort and churn since the patches need to be re-generated and re-distributed. If an OS port is completely re-autotooling the packages (as some OS distributions mandate), then more effort is required if non-autotool files in the package now need to be patched to work with the specific libtool version used. If a package does not check generated autotools files into its source repository then each person using the source repository needs to autotool the package, and changing the path makes the package libtool-version sensitive so that only newer (or older) versions will work. It is rather inconvenient for developers to maintain several installed libtool versions in order to successfully autotool packages. I am not saying that the effort is insurmountable but it is perhaps more effort to the world at large than your are imagining. However, what did you think of my plan to adopt a gnulib inspired cruft removal warning and tidy up process (the second paragraph in this post: http://lists.gnu.org/archive/html/libtool-patches/2011-11/msg2.html)? If you don't object, in that vein I'll add code to libtoolize (scheduled for removal in 2013) which copies $pkgdatadir/build-aux contents to the existing ltdl/config you've specified in the parent configure.ac AC_CONFIG_AUX_DIR declaration... My project (and the derived ImageMagick) are among the very few which would be impacted by this proposal since its non-recursive build is including the libltdl bits from Makefile.am like: include ltdl/Makefile.inc This is another case of changing a documented external interface. The impact is surely much smaller than moving the 'config' files. Google shows very few packages using this approach. The deprecation detection logic does not seem fully robust since there is no standard extension for Automake include files and file naming other than *.mk and Makefile.am might be used. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.
On Tue, 1 Nov 2011, Gary V. Vaughan wrote: This next series of changesets is the beginning of modelling the directory and filenaming conventions of Libtool to match what is done by other prominent GNU projects... this means that gnulib scripts will require less tweaking and configuration, so we can use them in the configuration in which they have been most widely tested and debugged. Also, it makes everything look more familiar to anyone coming from another GNU project who is hoping to generate some patches for us... and every little thing we can do to reduce friction in that process is a net win as far as I am concerned. I should not have to remind that GNU libtool is usually embedded to become part of other packages and some have become more intimate with libtool (as documented) in order to improve build times and reduce redundant waste. For packages (such as mine), the libltdl 'config' directory is treated as a well defined public interface which is referenced by (and shared by) exisiting package configure scripts. For example, this is how the configure.ac refers to it in my package: # Directory where autotools helper scripts lives. AC_CONFIG_AUX_DIR([ltdl/config]) Changing from 'config' to 'build-aux' will require existing configure.ac files to change. Did you consider this existing use while developing the plan to rename this often-shared directory? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-28-gadb7abd
On Sun, 23 Oct 2011, Peter O'Gorman wrote: One of these commits broke the daily snapshot. The machine does not yet have autobuild installed. Now that it's a hard bootstrap requirement, I will try to make time to install it. It seems that there is also a problem if gnulib is not installed on the machine because 'make check' ends up using a formally-installed gnulib .m4 file rather than the one in the libtool source tree. I know this because I don't have gnulib installed on my machine and so 'make check' fails. The issue is due to an m4 include path problem. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [SCM] GNU Libtool branch, master, updated. v2.4-58-g789817d
On Mon, 17 Oct 2011, Gary V. Vaughan wrote: case $version_type in + # correct linux to gnu/linux during the next big refactor You're not following the whitespace convention of the surrounding code. Good point. That's what comes of writing an emacs macro to do the edits I suppose. I'll fix and commit, thanks. I think that it is best to include this sort of comment in the libtool TODO file similar to other tasks which are left to do rather than spamming the script with duplicated comments. Certainly no more than one comment near the point of first usage should be warranted if the comment must appear in the script. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Bug 9210: fix to replace Linux with GNU/Linux where needed
On Mon, 5 Sep 2011, Christophe Jarry wrote: Please learn to use git for sending patches; thanks! The new patch is attached. Please tell me if there are still issues with it. This patch looks ok to apply to me. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] libtool -- don't print warnings with --silent
On Mon, 29 Aug 2011, Peter O'Gorman wrote: This turns off warnings for --silent (and turns them on again for --verbose). But I am not sure that --silent was meant to imply no warnings, rather it turns off the verbose compile/link messages. Would a new --no-warnings option be more appropriate? I agree that a new option would be more appropriate. However, it should be a user-provided configuration option (when building the package) and not something which will be hard-coded into Makefiles by developers. The --silent option should have been handled the same so that the person building the software can easily decide if the build should be silent. If developers start producing packages which have 'silent' and 'no-warnings' irreversably baked into the Makefiles, then it will be very difficult to diagnose the case that the sofware does not build or work due to a tool, build options, or platform issue. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: warnings from openSuSE rpmlint
On Mon, 14 Feb 2011, Peter O'Gorman wrote: I would say it is easier to install it with permissions matching its status. What is easier depends on your POV. In the end, what is easier to the customer should prevail because there are more customers than developers. I'll look into this. This passed all tests and make distcheck, I am pretty sure that nothing requires ltmain to be executable, but just in case someone knows better, I'm asking for approval :) Ok? This change sounds fine to me. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Rebuild menus in the manual.
:: MSYS file name conversion idiosyncrasies
+* Cygwin/Windows File Name Conversion:: Using @command{cygpath} to convert
Cygwin file names
+* Unix/Windows File Name Conversion:: Using Wine to convert Unix paths
+* LT_CYGPATH:: Invoking @command{cygpath} from other
environments
+* Cygwin to MinGW Cross:: Other notes concerning MinGW cross
@end menu
@node File Name Conversion Failure
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 1/2] tests: __declspec (dll{ex, im}port) in tests/exceptions.at
On Mon, 20 Sep 2010, Peter Rosin wrote:
Hi!
I have tested this patch on MinGW/gcc and Cygwin/gcc and they are both
ok with the __declspec() notation. On MSVC, the test goes from skip
to fail, as it needs 2/2.
This patch looks good to apply, as does the 2/2 patch to make sure
that lt__PROGRAM__LTX_preloaded_symbols is globally scoped and extern
C.
Bob
Cheers,
Peter
From 52972128c5952da628e033e4509208711906c3a2 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Mon, 20 Sep 2010 09:07:25 +0200
Subject: [PATCH 1/2] tests: __declspec (dll{ex,im}port) in tests/exceptions.at
* tests/exceptions.at (common.h, module.h, lib.h) [w32]: Use
__declspec (dllimport) and __declspec (dllexport) instead of
the less portable __attribute__ ((dllimport)) and
__attribute__ ((dllexport)). Makes the test compile on MSVC.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
ChangeLog |8
tests/exceptions.at | 17 -
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 78d3e48..3c72890 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2010-09-20 Peter Rosin p...@lysator.liu.se
+
+ tests: __declspec (dll{ex,im}port) in tests/exceptions.at
+ * tests/exceptions.at (common.h, module.h, lib.h) [w32]: Use
+ __declspec (dllimport) and __declspec (dllexport) instead of
+ the less portable __attribute__ ((dllimport)) and
+ __attribute__ ((dllexport)). Makes the test compile on MSVC.
+
2010-09-19 Peter Rosin p...@lysator.liu.se
tests: Import items from liba1 for MSVC.
diff --git a/tests/exceptions.at b/tests/exceptions.at
index 235597c..286b2ac 100644
--- a/tests/exceptions.at
+++ b/tests/exceptions.at
@@ -66,9 +66,8 @@ CPPFLAGS=$LTDLINCL $CPPFLAGS
# the regex). However, in this test, none of these situations apply,
# so we don't directly address it. Otherwise, the correct mechanism
# would be to avoid all of those flags, and instead explicitly decorate
-# all symbols with appropriate __attribute__ ((dllexport)) or
-# __attribute__ ((dllimport)) flags when building the DLLs and the
-# clients.
+# all symbols with appropriate __declspec (dllexport) or
+# __declspec (dllimport) flags when building the DLLs and the clients.
#
# For more information, see these two threads:
# http://lists.gnu.org/archive/html/bug-libtool/2010-06/msg00069.html
@@ -84,9 +83,9 @@ AT_DATA([common.h],
#if defined(__CYGWIN__) || defined(_WIN32)
# if defined(DLL_EXPORT) || defined(USING_COMMON_DLL)
# if defined(LIBTOOL_TEST_IN_COMMON)
-# define COMMON_IMPEXP __attribute__ ((dllexport))
+# define COMMON_IMPEXP __declspec (dllexport)
# else
-# define COMMON_IMPEXP __attribute__ ((dllimport))
+# define COMMON_IMPEXP __declspec (dllimport)
# endif
# else
# define COMMON_IMPEXP
@@ -128,9 +127,9 @@ AT_DATA([module.h],
#if defined(__CYGWIN__) || defined(_WIN32)
# if defined(DLL_EXPORT) || defined(USING_MODULE_DLL)
# if defined(LIBTOOL_TEST_IN_MODULE)
-# define MODULE_IMPEXP __attribute__ ((dllexport))
+# define MODULE_IMPEXP __declspec (dllexport)
# else
-# define MODULE_IMPEXP __attribute__ ((dllimport))
+# define MODULE_IMPEXP __declspec (dllimport)
# endif
# else
# define MODULE_IMPEXP
@@ -174,9 +173,9 @@ AT_DATA([lib.h],
#if defined(__CYGWIN__) || defined(_WIN32)
# if defined(DLL_EXPORT) || defined(USING_LIB_DLL)
# if defined(LIBTOOL_TEST_IN_LIB)
-# define LIB_IMPEXP __attribute__ ((dllexport))
+# define LIB_IMPEXP __declspec (dllexport)
# else
-# define LIB_IMPEXP __attribute__ ((dllimport))
+# define LIB_IMPEXP __declspec (dllimport)
# endif
# else
# define LIB_IMPEXP
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 4/6] maint: reformat README `The Test Suites' for consistency.
testsuite only, do it like this: - gmake check-local +gmake check-local The tests of the old test suite run in groups in the various demo subdirectories, so if one of the tests early in a group FAILs, the rest @@ -100,9 +100,8 @@ To run a test group of the old test suite in isolation (say, you think you have fixed a bug, but don't want to rerun the entire suite), you can do it like this: - gmake check TESTS=tests/cdemo-static.test tests/cdemo-static-make.test \ - tests/cdemo-static-exec.test \ - TESTSUITEFLAGS=-V +gmake check TESTSUITEFLAGS=-V TESTS=tests/cdemo-static.test \ +tests/cdemo-static-make.test tests/cdemo-static-exec.test Providing that you have a FAIL from the most recent group from a particular demo directory (like the cdemo-static.test group above), you @@ -118,28 +117,40 @@ the verbose output from all failed tests. In order to enable debug shell tracing, you can set VERBOSE=debug when running the old test suite. +In the long run, Libtool will move to using only the new, Autotest- +driven testsuite. Its usage is documented in: -In the long run, Libtool will move to using only the new, -Autotest-driven testsuite. Its usage is documented in +info Autoconf 'testsuite Invocation' - info Autoconf 'testsuite Invocation' +but simple help may also be obtained through: -but simple help may also be obtained through - - gmake check-local TESTSUITEFLAGS='--help' +gmake check-local TESTSUITEFLAGS='--help' For verbose output, add the flag `-v', for running only a subset of the independent tests, merely specify them by number or by keyword, both of which are displayed with the `--list' flag. For example, the `libtool' keyword is used for the tests that exercise only this script. So it is possible to test an installed script, possibly from a different Libtool -release, with - gmake check-local TESTSUITEFLAGS=-k libtool LIBTOOL=/path/to/libtool +release, with: + +gmake check-local \ +TESTSUITEFLAGS=-k libtool LIBTOOL=/path/to/libtool + +Some tests, like the one exercising max_cmd_len limits, make use of this +to invoke the testsuite recursively on a subset of tests. For these +tests, the variable INNER_TESTSUITEFLAGS may be used. It will be +expanded right after the `-k libtool', without separating whitespace, so +that further limiting of the recursive set of tests is possible. For +example, to run only the template tests within the max_cmd_len, use: + +gmake check-local TESTSUITEFLAGS=-v -x -k max_cmd_len \ + INNER_TESTSUITEFLAGS=',template -v -x' If you wish to report test failures to the libtool list, you need to send the file `tests/testsuite.log' to the bug report mailing list, bug-libt...@gnu.org. + 4. Obtaining the Latest Sources === -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 5/6] maint: improve README's `Obtaining the Latest Sources'.
at: + +http://www.gnu.org/order/ftp.html + +* Alpha quality pre-releases of GNU Libtool, also with detached + signature files are available from: + +ftp://alpha.gnu.org/gnu/libtool + + and some of the mirrors listed at: + +http://www.gnu.org/order/ftp.html + +* Nightly snapshots of the unreleased development trunk of GNU Libtool + are available from: + +http://pogma.com/libtool + + These files do not have signatures, but will allow you to easily + determine whether the most recent development code still exhibits any + bugs you have discovered, without requiring you to install a complete + build environment and the extra tools needed to bootstrap a version + control checkout. + * The master libtool repository is stored in git. If you are a member of the savannah group for GNU Libtool, a writable @@ -195,6 +241,14 @@ send the file `tests/testsuite.log' to the bug report mailing list, - Autoconf 2.59 or later - Automake 1.9.6 or later +* The `bootstrap' script sets up the source directory for you to hack, + though it may take quite some time to run. If you don't intend to + re-run the test suite, you can speed up the `bootstrap' step by an + order of magnitude if you call it like this instead: + +reconfdirs='. libltdl' ./bootstrap + + 5. Version Numbering @@ -250,7 +304,7 @@ things: For more details about version numbers, see: http://www.gnu.org/software/libtool/contribute.html --- +-- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc. Written by Gary V. Vaughan, 2004 -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 2/6] maint: consolidate Introductions of README and README.alpha.
and passes the test suite (`gmake check'), please send + a short note to the libtool mailing list libt...@gnu.org with a + subject line including the string `[PLATFORM]', and containing the + details from the end of `./libtool --help' in the body. + * Otherwise, see `Reporting Bugs' below for how to help us fix any + problems you discover. + +To use Libtool, add the new generic library building commands to your +Makefile, Makefile.in, or Makefile.am. See the documentation for +details. 2. Reporting Bugs -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] maint: ship .xz, not .lzma
On Tue, 14 Sep 2010, Gary V. Vaughan wrote: No objections. I'm curious to know what the history of lzma and xz is that makes this desirable though. I am curious to know if XZ Utils has now achieved a proper stable release or if it will be perpetually in a prototype like state. Its code is quite large and quite obtuse. Also, I remain curious to know why 'lzip' has never been considered as a suitable replacement. Lzip accomplishes the same thing with 10 times less code, and better fits the traditions previously established by gzip and bzip2. Its only limitation is that it requires a C++ compiler. The claim is made that it is not portable because it does not come with a megabyte-sized configure script, but it does not need such a huge configure script because it only uses portable ANSI interfaces, similar to the way gzip only requires ANSI C. This sort of decision-making results in people feeling that GNU software is excessively complex bloatware. Personal politics and status has become more important than proper technical analysis. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Next Libtool Point Release Pending
On Mon, 9 Aug 2010, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Mon, Aug 09, 2010 at 06:52:19PM CEST: That's true, but I think that was because we tried too hard to make the 2.x branch perfect, and spent altogether too much time pumping out more and more 1.5.x releases with patches merged back from an ever diverging code base. As long as we're careful not to do any of this things, then we can avoid repeating history. Do you really want to reopen this can? IMVHO 2.x took so long because it was destabilized *too* *much*. Both of you are correct. 2.x was very destablized for a couple of years and then we became paranoid for a couple more years in order to make up for past excesses. The test suite became a whole lot better in the mean time. We should always keep in mind that libtool is just a 'tool' and eventually it should be feature-rich enough to only require periodic updates for compiler and operating system changes. We are not far from that objective. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Next Libtool Point Release Pending
On Fri, 6 Aug 2010, Gary V. Vaughan wrote: OTOH, since I hope to have more larger changes in the future, I'm not sure we really want another major number bump already. That's only a minor bump, according to major.minor.micro: major bump = substantial rewrite minor bump = new features, new code and new bugs micro bump = regressions and bugs fixed This is the scheme I believe most people recognize, and that suggests to me that 2.4.0 would be the next logical release number? You do make a good point. It is better to advance the minor number (rather than continually increase the micro number) if significant new features have been added. However, the objectives should be met (e.g. really able to build adequately with MSVC) before we bump to 2.4. This should not discourage including 99% of the necessary updates in another 2.2 release. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Next Libtool Point Release Pending
On Sat, 7 Aug 2010, Gary V. Vaughan wrote: Nonetheless I still think that users should have some confidence that releases get more stable as micro increases. Rolling a ton of new code into a micro bump violates that idea. True. Incrementing minor suggests production of a branch and that there may be a later bug-fix release from that branch which would increment micro. There are various implications suggested by the numbering strategy. These implications could result in more maintenance effort. They may also result in OS distribution maintainers not picking up the update since the increment to minor makes the release seem more major than it actually is. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: MSVC: Preloading in ltdl doesn't heed libname_spec.
On Tue, 6 Jul 2010, Ralf Wildenhues wrote: Perhaps things are not all that bad. While 35 of 110 tests fail under Debian Linux, only these two extra are failing under FreeBSD, OS-X, and Solaris: FAIL: tests/mdemo2-make.test FAIL: tests/pdemo-make.test It would probably be even more helpful if you posted verbose test failure output (or excerpts), that would make assigning blame easier, I guess. Yes. And in fact it would be even better if the test suite always produced/retained verbose output for failed tests so that the information is always immediately available on demand. The fact that it does not should be considered to be a bug. I am thinking that the many test failures under Debian Linux are due to it using older tool versions such as Autoconf 2.61. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: verbose test output (was: MSVC: Preloading in ltdl doesn't heed libname_spec.)
On Thu, 8 Jul 2010, Ralf Wildenhues wrote: I am thinking that the many test failures under Debian Linux are due to it using older tool versions such as Autoconf 2.61. Facts, not thinking, please. We cannot read your computer's mind. In this case, the thinking was correct. Many Debian tests are failing due to a demand for Autoconf 2.62 (which Debian stable does not supply). However, as if today, only 6 of 116 tests failed, which is a big improvement from a day ago. Also, as of today, for FreeBSD and OS-X All tests behaved as expected, which is an improvement. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: MSVC: Preloading in ltdl doesn't heed libname_spec.
On Mon, 5 Jul 2010, Peter Rosin wrote: Inspired by the remarkable progress, I'm bringing up this patch again. It would be good if the progress was even more remarkable. Yesterday's libtool was doing quite good with the tests but I am seeing plenty of failures now for all Unixish targets. Even Linux blows failures all over the place. Not to worry, it is likely something simple. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: MSVC: Preloading in ltdl doesn't heed libname_spec.
On Mon, 5 Jul 2010, Bob Friesenhahn wrote: On Mon, 5 Jul 2010, Peter Rosin wrote: Inspired by the remarkable progress, I'm bringing up this patch again. It would be good if the progress was even more remarkable. Yesterday's libtool was doing quite good with the tests but I am seeing plenty of failures now for all Unixish targets. Even Linux blows failures all over the place. Not to worry, it is likely something simple. Perhaps things are not all that bad. While 35 of 110 tests fail under Debian Linux, only these two extra are failing under FreeBSD, OS-X, and Solaris: FAIL: tests/mdemo2-make.test FAIL: tests/pdemo-make.test Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)
On Sat, 3 Jul 2010, Charles Wilson wrote: No one is threatening your committer status. I didn't say they were. But if I *did* misbehave -- well, I could hardly be surprised by the inevitable consequences, could I? Doesn't take a genius to predict those consequences, either. Misbehavior is characterized by intent and subsequent acceptance of responsibility. If someone commits a change which de-stabilizes the software, then they should expect to take responsibility for the clean-up. Likewise, committing a change which will knowingly de-stabilize the software is harmful, unless there is a plan made in advance for how the issue will soon be rectified. Sometimes temporary instability is ok because the end justifies the means. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)
On Sat, 3 Jul 2010, Charles Wilson wrote: That's an...interesting take. I've never assumed that ANY contribution would be acceptable unless it received an actual approval by a maintainer. I mean, really: here's this patch, and no single maintainer has endorsed it without some significant objection -- and I should feel free as a non-maintainer to say well, I disagree, so I'm pushing anyway?? I think that you are attributing to much special status to official maintainers. It should not matter where approval comes from as long as the approval is from a sufficiently qualified person with knowledge of the subject who has done a proper review and/or actual testing. The official maintainers are sometimes not qualified to properly review a patch. That seems like a fast way to lose committer status, IMO. While I am sure that it is possible to lose committer status due to misbehavior, I don't recall this happening in libtool history for any reason other than the person disappeared from the Internet or requested that their committer status be removed. No one is threatening your committer status. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
libtool head fails under Solaris 10 FreeBSD
As a heads-up, yesterday libtool was passing the normal number of tests (usually fails 2) under Solaris 10. With latest changes from today, libtool tests are failing badly: 26 of 53 tests failed (53 tests were not run) Please report to bug-libt...@gnu.org Usually the test suite works perfectly under FreeBSD 8.0 but it is failing 3 tests now: 3 of 96 tests failed (10 tests were not run) Please report to bug-libt...@gnu.org Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool head fails under Solaris 10 FreeBSD
On Wed, 30 Jun 2010, Gary V. Vaughan wrote: I can't reproduce this one. But that might be something to do with the fix I just committed... I am dutifully re-running the tests with your latest patch (d8bdf9339ba7de82f40c49705650506e0cc3f979). Early impressions are that there are far fewer failures than before under Solaris 10 but the stress tests are still running. This one is still new though: 6: enhanced shell option appending FAILED (getopt-m4sh.at:183) I don't have access to FreeBSD 8.0, could you retest, and show verbose logs of the fails if they haven't gone away please? Yes, sir. Will do. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool head fails under Solaris 10 FreeBSD
On Wed, 30 Jun 2010, Gary V. Vaughan wrote: 26 of 53 tests failed (53 tests were not run) Please report to bug-libt...@gnu.org I can't reproduce this one. But that might be something to do with the fix I just committed... Now Solaris 10 produces just 3 unexpected failures, which is one more than normal. The tests/testsuite.log file is attached. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ testsuite.log.gz Description: Binary data
Re: libtool head fails under Solaris 10 FreeBSD
With OS-X Leopard PowerPC: ## - ## ## Test results. ## ## - ## 100 tests behaved as expected. 15 tests were skipped. but with FreeBSD 8.0: 3 of 96 tests failed (10 tests were not run) Please report to bug-libt...@gnu.org I found that the file tests/testsuite.log was from a very old run. So I removed the build tree and did everything from scratch. No tests/testsuite.log file was produced. This similar failure was counted three times: FAIL: tests/depdemo-make.test FAIL: tests/depdemo-make.test FAIL: tests/depdemo-make.test Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)
On Sun, 27 Jun 2010, Ralf Wildenhues wrote: * Charles Wilson wrote on Sun, Jun 27, 2010 at 02:51:21PM CEST: In that case, Ralf's suggested libfile_$(transliterated implib name) is used, because we have the .la file available which allows that shortcut. The only time we need `dlltool --identify' is when dlpreopening a non-libtool implib, where we have no .la file. And the sed-fu is a fallback to THAT fallback. So...can I get a verdict? Is -dlpreopen not-an-la-file supposed to work? I think Pierre's report was about using -dlpreopen file.la at link time, but then not wanting to need the .la file at run time. I think that is desirable. At link edit time, having a .la file is a reasonable thing I think. Probably I have not been paying enough attention to this topic stream and I might be misinterpreting the above. While it is nice to dream about not having the .la files, the module loading can not work completely reliably without it. A program may depend on preopened modules, dynamically loaded modules, and dynamically loaded DLLs which are loaded as dependencies. The .la files contain the dependency chain information. Using them allows a dependency library to be changed without breaking things. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: lt_dlerror changes
On Fri, 18 Jun 2010, Charles Wilson wrote: The final loader called, for /usr/bin/last -- which exists -- is the 'last' loader. In last_open(), it sets LT_ERROR_FILE_NOT_FOUND as a sort of generic error value -- which, strangely, is exactly the OPPOSITE of the problem here. The real problem is there actually IS a file named /usr/bin/last, but because that name does not match exactly last, last_open() reports what it considers a generic error. I seem to be backlogged by the flurry of email, but hopefully you guys will get this figured out. I would be astonished if Windows LoadLibrary() is not willing to load a Windows executable file similar to the way it loads a DLL. If so, this raises security implications that we want to avoid. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: lt_dlerror changes
On Fri, 18 Jun 2010, Charles Wilson wrote: If so, this raises security implications that we want to avoid. I don't think so. Hopefully not. If a binary from an executable program is placed at the path C:\cygwin\bin\last (with no .exe extension) does LoadLibrary() load it? Since we are on the subject, it is good to make sure that Windows really is in good shape security-wise. Windows paranoia about downloaded files might go away if the file extension is missing so it is good to know if it will still attempt to load an exectuable or DLL which has its file extension missing. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Print Libtool project URL in program --help output.
On Tue, 15 Jun 2010, Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Sun, Jun 13, 2010 at 06:16:15PM CEST:
On Sun, 13 Jun 2010, Ralf Wildenhues wrote:
Tested with git Autoconf and 2.62. OK?
This change looks fine to me.
Thanks for the review. I had applied this, but it turns out it wasn't
complete after all. The bootstrap script also tries to extract PACKAGE
and VERSION from configure.ac. This causes, for example, bogus settings
in tests/package.m4 where the package name was 'GNU' and the email
bug-...@... And then, we were not extracting PACKAGE_NAME and
PACKAGE_URL correctly at all. And more fallout.
Any reasons against the patch below to fix this? I'll otherwise push it
soonish.
For what it's worth, this change also looks fine to me. You should be
able to apply this and advance to step #3, which is hopefully a NOP.
Bob
Print Libtool project URL in program --help output.
* configure.ac (AC_INIT): Set PACKAGE argument to `GNU Libtool',
so Autoconf knows this is GNU software. For Autoconf 2.64,
if AC_PACKAGE_URL is not defined, substitute PACKAGE_URL.
[...]
Sorry about that glitch.
Cheers,
Ralf
Fix bootstrap script to cope with changed AC_INIT arguments.
* bootstrap: When extracting PACKAGE and VERSION from AC_INIT
arguments, be sure to remove a 'GNU ' prefix and lowercase the
package name for PACKAGE. Also set PACKAGE_NAME and PACKAGE_URL
appropriately for GNU software. Pass these variables to the
make commands creating tests/package.m4 and other files.
* Makefile.am (edit): Fix substitution of PACKAGE_NAME and
PACKAGE_STRING.
* libltdl/config/announce-gen.m4sh: Use @PACKAGE@ not
@package_str...@.
diff --git a/Makefile.am b/Makefile.am
index 8e00b3e..aa2cd9c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -127,8 +127,8 @@ edit = sed \
-e 's,@PACKAGE\@,$(PACKAGE),g' \
-e 's,@PACKAGE_BUGREPORT\@,$(PACKAGE_BUGREPORT),g' \
-e 's,@PACKAGE_URL\@,$(PACKAGE_URL),g' \
- -e 's,@PACKAGE_NAME\@,$(PACKAGE),g' \
- -e 's,@PACKAGE_STRING\@,$(PACKAGE) $(VERSION),g' \
+ -e 's,@PACKAGE_NAME\@,$(PACKAGE_NAME),g' \
+ -e 's,@PACKAGE_STRING\@,$(PACKAGE_NAME) $(VERSION),g' \
-e 's,@PACKAGE_TARNAME\@,$(PACKAGE),g' \
-e 's,@PACKAGE_VERSION\@,$(VERSION),g' \
-e 's,@SED\@,$(SED),g' \
diff --git a/bootstrap b/bootstrap
index d505c36..81ed4b0 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1,7 +1,8 @@
#! /bin/sh
# bootstrap -- Helps bootstrapping libtool, when checked out from repository.
#
-# Copyright (C) 2003, 2004, 2005, 2006, 2009 Free Software Foundation, Inc,
+# Copyright (C) 2003, 2004, 2005, 2006, 2009, 2010 Free Software
+# Foundation, Inc,
# Mritten by Gary V. Vaughan, 2003
#
# This file is part of GNU Libtool.
@@ -116,9 +117,18 @@ fi
set dummy `$SED -n '
/AC_INIT/{
s/[][,()]/ /g
+ s/ GNU / /
p
}' configure.ac`
shift
+PACKAGE=`echo $2 | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz`
+PACKAGE_NAME=$2
+PACKAGE_URL=
+if grep 'AC_INIT.*GNU' configure.ac /dev/null; then
+ PACKAGE_NAME=GNU $PACKAGE_NAME
+ PACKAGE_URL=http://www.gnu.org/software/$PACKAGE/;
+fi
+VERSION=$3
# Whip up a dirty Makefile:
makes='Makefile.am libltdl/Makefile.inc'
@@ -135,13 +145,15 @@ rm -f $auxdir/ltmain.sh $m4dir/ltversion.m4
$MAKE ./$auxdir/ltmain.sh ./$m4dir/ltversion.m4 \
./libtoolize.in ./tests/defs.in ./tests/package.m4 \
./tests/testsuite ./libltdl/Makefile.am ./doc/notes.txt \
-srcdir=. top_srcdir=. PACKAGE=$2 VERSION=$3 \
-PACKAGE_BUGREPORT=bug...@gnu.org M4SH=$AUTOM4TE --language=m4sh \
+srcdir=. top_srcdir=. PACKAGE=$PACKAGE VERSION=$VERSION \
+PACKAGE_NAME=$PACKAGE_NAME PACKAGE_URL=$PACKAGE_URL \
+PACKAGE_BUGREPORT=bug-$pack...@gnu.org M4SH=$AUTOM4TE --language=m4sh \
AUTOTEST=$AUTOM4TE --language=autotest SED=$SED MAKEINFO=$MAKEINFO \
GREP=$GREP FGREP=$FGREP EGREP=$EGREP LN_S=$LN_S
test -f clcommit.m4sh $MAKE -f Makefile.maint ./commit \
-srcdir=. top_srcdir=. PACKAGE=$2 VERSION=$3 M4SH=$AUTOM4TE -l m4sh \
+srcdir=. top_srcdir=. PACKAGE=$PACKAGE VERSION=$VERSION \
+M4SH=$AUTOM4TE -l m4sh \
SED=$SED GREP=$GREP FGREP=$FGREP EGREP=$EGREP LN_S=$LN_S
rm -f Makefile
diff --git a/libltdl/config/announce-gen.m4sh b/libltdl/config/announce-gen.m4sh
index a528fef..38e6232 100644
--- a/libltdl/config/announce-gen.m4sh
+++ b/libltdl/config/announce-gen.m4sh
@@ -99,7 +99,7 @@ test -d $top_srcdir || top_srcdir='@top_srcdir@'
# Initialisation:
mailnotify_flags=
-package_name=@PACKAGE_NAME@
+package_name=@PACKAGE@
sendmail_to=
valid_release_types='alpha,beta,release-candidate,stable'
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Print Libtool project URL in program --help output.
--git a/libtoolize.m4sh b/libtoolize.m4sh
index 2aa82d4..04db82f 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -65,7 +65,9 @@ AS_INIT[]m4_divert_push([HEADER-COPYRIGHT])dnl
# automake: $automake_version
# autoconf: $autoconf_version
#
-# Report bugs to bug-libt...@gnu.org.
+# Report bugs to @PACKAGE_BUGREPORT@.
+# GNU @PACKAGE@ home page: @PACKAGE_URL@.
+# General help using GNU software: http://www.gnu.org/gethelp/.
: ${TAR=tar}
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Rewrite manual intro to be gender-neutral.
On Sun, 6 Jun 2010, Ralf Wildenhues wrote: This mirrors a similar recent fix to automake.texi. Any technical reasons against this patch? The rest of the manual greps ok. Regardless of Gary's affirmation, I don't think that replacing 'he' with 'you' is suitable. 'He' and 'you' are not at all equivalent terms. If there are two people in a room and one of them is 'you' then the other one may be 'he' or 'she' but is definitely not 'you'. If one is talking about the past, then the gentle reader might still have been in elementary school at the time (or the womb) and so it is not suitable to use the term 'you'. Bob Thanks, Ralf Rewrite manual intro to be gender-neutral. * doc/libtool.texi (Introduction): Use gender-neutral formulation when addressing developers. diff --git a/doc/libtool.texi b/doc/libtool.texi index bbc22f4..051aec3 100644 --- a/doc/libtool.texi +++ b/doc/libtool.texi @@ -230,13 +230,13 @@ Platform quirks @node Introduction @chapter Introduction -In the past, if a source code package developer wanted to take advantage -of the power of shared libraries, he needed to write custom support code -for each platform on which his package ran. He also had to design a -configuration interface so that the package installer could choose what -sort of libraries were built. +In the past, if you were a source code package developer and wanted to +take advantage of the power of shared libraries, you needed to write +custom support code for each platform on which your package ran. You +also had to design a configuration interface so that the package +installer could choose what sort of libraries were built. -GNU Libtool simplifies the developer's job by encapsulating both the +GNU Libtool simplifies your job by encapsulating both the platform-specific dependencies, and the user interface, in a single script. GNU Libtool is designed so that the complete functionality of each host type is available via a generic interface, but nasty quirks -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool versioning
On Tue, 4 May 2010, Ralf Wildenhues wrote:
Looked it up in the net now, e.g.,
http://grammar.quickanddirtytips.com/may-might.aspx, tells me that I
should be using might instead of may only for things that are rather
improbable to happen.
http://www.fortunecity.com/bally/durrus/153/gramch10.html tells me
that may can be used as a more formal form of some meanings of can
or is able to, which I think is applicable here. Remains avoidance of
repetition, which is generally a good thing in flowing text but not
needed so much in technical documentation which is more concerned with
correctness.
I'll apply the patch below soon unless I hear complaints.
As a native english speaker, I don't think that these particular
improvements are improvements. I like the existing text better.
Bob
Thanks,
Ralf
Reword alternate versioning algorithm a bit.
* doc/libtool.texi (Updating version info): Replace some uses of
`may' with `might' or `can' as appropriate.
Suggestion by Tor Lillqvist.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 987b232..ec24a2f 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2947,7 +2947,7 @@ Instead, use the @option{-release} flag (@pxref{Release
numbers}), but be
warned that every release of your package will not be binary compatible
with any other release.
-The following explanation may help to understand the above rules a bit
+The following explanation can help to understand the above rules a bit
better: consider that there are three possible kinds of reactions from
users of your library to changes in a shared library:
@@ -2961,14 +2961,14 @@ is needed. In this case, bump @var{revision} only,
don't touch
@item
Programs using the previous version may use the new version as
-drop-in replacement, but programs using the new version may use APIs not
+drop-in replacement, but programs using the new version can use APIs not
present in the previous one. In other words, a program linking against
-the new version may fail with ``unresolved symbols'' if linking against
+the new version might fail with ``unresolved symbols'' if linking against
the old version at runtime: set @var{revision} to 0, bump @var{current}
and @var{age}.
@item
-Programs may need to be changed, recompiled, relinked in order to use
+Programs might need to be changed, recompiled, relinked in order to use
the new version. Bump @var{current}, set @var{revision} and @var{age}
to 0.
@end enumerate
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 2/4] Fix incompatible struct declarations.
/tests/pdemo/longer_file_name_dlmain.c
@@ -1,6 +1,7 @@
/* dlmain.c -- hello test program that uses simulated dynamic linking
- Copyright (C) 1996-1999, 2004, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1996-1999, 2004, 2006, 2007, 2010 Free Software
+ Foundation, Inc.
This file is part of GNU Libtool.
@@ -27,18 +28,18 @@ or obtained by writing to the Free Software Foundation,
Inc.,
#define lt_preloaded_symbols lt__PROGRAM__LTX_preloaded_symbols
-struct lt_symlist
+typedef struct
{
const char *name;
lt_ptr_t address;
-};
+} lt_dlsymlist;
-extern const struct lt_symlist lt_preloaded_symbols[];
+extern const lt_dlsymlist lt_preloaded_symbols[];
int
main (int argc, char **argv)
{
- const struct lt_symlist *s;
+ const lt_dlsymlist *s;
int (*pfoo)() = 0;
int (*phello)() = 0;
int *pnothing = 0;
--
1.7.0.rc1.161.g90487
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: preloader declaration bug
On Sun, 28 Mar 2010, Ralf Wildenhues wrote:
Working on support for -flto has uncovered an ugly buglet in libltdl.
ltmain declares this symbol as:
extern $lt_dlsym_const lt_dlsymlist
lt_${my_prefix}_LTX_preloaded_symbols[];
but libltdl declares it as:
#define preloaded_symbols LT_CONC3(lt_, LTDLOPEN, _LTX_preloaded_symbols)
#ifdef HAVE_LIBDLLOADER
extern lt_dlsymlist preloaded_symbols;
#endif
(note the missing []) and takes its address to make up for it.
gcc -flto notices this inconsistency between the objects.
This patch fixes it, it passes the testsuite. I'll be pushing it soon.
I don't actually know whether this bug can cause issues on some system.
Nice catch. I had not been aware of the -flto option before.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [patch] sort 'find' output to enable deterministic builds.
On Tue, 16 Mar 2010, Ralf Wildenhues wrote: Yes, that may be it. However, that also means that, while the patch fixes things for you, it doesn't really add value to Libtool in the sense that we cannot guarantee an improvement of some portable kind to users. That's ok per se, but of course not ideal. ;-) As long as build portability does not suffer, I think it is a good thing for builds to be as deterministic as possible. Otherwise it is possible for the built binaries to perform differently from build to build. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Current libtool tests status
On Mon, 22 Feb 2010, Ralf Wildenhues wrote: Hi Bob, thanks for testing. It was only a quick sanity check for reassurance. :-) * Bob Friesenhahn wrote on Mon, Feb 22, 2010 at 01:22:16AM CET: On my systems (and after Charles raft of submissions) this is the current final test status: Solaris 10 == ERROR: 94 tests were run, 6 failed (4 expected failures). 11 tests were skipped. Please send the numbers of the test failures, or, even better, tests/testsuite.log so it can be analyzed easily. I searched diligently for Solaris tests/testsuite.log (out of the 222 currently available for selection) and found it so it is attached. I am pretty sure that the unexpected test failures were already expected under Solaris since the previously reported libltdl issues still exist. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ testsuite.log.gz Description: Binary data
Current libtool tests status
On my systems (and after Charles raft of submissions) this is the current final test status: Solaris 10 == ERROR: 94 tests were run, 6 failed (4 expected failures). 11 tests were skipped. FreeBSD 8 = 92 tests behaved as expected. 13 tests were skipped. OS-X Leopard 91 tests behaved as expected. 14 tests were skipped. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Report proper errors from the loadlibrary loader.
On Sun, 17 Jan 2010, Ralf Wildenhues wrote: I'm not too fond of adding new static storage and manipulation (yet another reason lt_dlopen may not be called concurrently from different threads), or improved functionality without testsuite exposure that we really improved. Further, the documentation I found about GetLastError states W2K as minimum version, so I hope that you checked that this works with older Windows as well. Otherwise, I am fine with the patch. It seems that GraphicsMagick has been using GetLastError() for a very long time. Certainly at least since Y2K. There is no special provision in this part of the code for anything older than Windows XP and Windows 2000. Then again, practically no one cares about Windows versions older than this. It is necessary to collect and store the error as soon as possible since any additional activity might invoke a new system call, which results in an unrelated error being reported by GetLastError(). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool, llvm-gcc, failing C++ exceptions
On Tue, 12 Jan 2010, Ralf Wildenhues wrote: The test is currently skipped if the compiler doesn't like main.cpp (which already exposes this API), so we should be safe there but not test on as many systems as we could. I added that for those kinds of issues, but primarily for the older, pre-standard C++ compilers that don't grok namespaces etc. A missing throw() on virtual what() is a violation of ISO C++98 however. I don't think that pre-standard C++ compilers are much of a concern. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool, llvm-gcc, failing C++ exceptions
On Sun, 10 Jan 2010, Ralf Wildenhues wrote:
My main comment is that it would be useful if the thrown class is
derived from std:exception (or one of its standard derived classes)
in order to flush out any issues which may stem from possible
partial template instantiation in libstdc++ (or pre-compiled
headers) as well as in the test translation unit.
OK, sounds useful. Would that entail more than just something like
this incremental addition?
I think that the virtual what() method needs to be provided or else
you have only a partially implemented class:
class MyException : public std::exception
{
public;
MyException() {}
virtual const char *what() const throw()
{
return My message;
}
};
But this is a better class to test with since it uses more standard
library stuff and is therefore more likely to fail if something is
wrong:
#include exception
#include string
class MyException : public std::exception
{
public;
MyException(std::string str)
: message(str)
{
}
virtual const char *what() const throw()
{
return message.c_str();
}
private:
std::string message;
};
Which can be thrown with
throw MyException(My message);
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Happy New Year
On Wed, 6 Jan 2010, Ralf Wildenhues wrote: I don't care all that much whether we update all copyright entries in Libtool now or not; if the others prefer this, and the script doesn't break --version, sure why not. I don't see much value offered from this sort of churn. Unless there is actual value offered, then it should not be done. More useful value would be to get Chuck Wilson's patches approved so that libtool can work better with Cygwin 1.7, which is already released as current. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Error reporting should be improved
On Wed, 30 Dec 2009, Peter Rosin wrote: There used to be some useless effort to make it thread safe. Apparently that is gone now. Regardless, there is also a potential re-entrancy issue, which could be encountered if a legacy OS interface is supported (re-implemented) via dlopen() or if some other implementation logic (e.g. lazy symbol resolution) uses dlsym(). I can't say that I understand what you are describing, but dlerror need not be reentrant[1], and we do various manipulations of internal state during lt_dlopen etc, so I don't see how any argument about reentrancy can hold. What am I missing this time? What I am saying is that an OS may choose to re-implement its legacy loader interfaces via dlopen() and since we still provide a loader driver for the legacy interface, use of this other loader may scramble the error reports from the dlopen() loader. This patch does of course not address the original issue, it only addresses the issue with dlerror returning a string to the ltdl user that might have a limited life span. The patch does not seem to address that since it does not allocate a buffer to store the error string. What it does address is how to collect multiple error messages. Unfortunately, lt_dladderror() is publically exposed so it is difficult to change its arguments even though it is not documented. This patch does not change lt_dladderror in a way that I classify as significant. Do you disagree? I don't disagree, but I had suggested that it is quite useful to know the origin of the error report. The origin could have been handled via another parameter. I have not found anything in your message that kills the patch, but yet I get the feeling that you do not like it, and I would like to know what you think is wrong with it... It seems to me that these error strings need to be in allocated buffer storage so that they don't point to potentially volatile storage. Also, there needs to be a way to clear out the existing errors when a lt_dlopen*() or lt_dlsym() starts so that the errors only correspond to the last requested operation. The current implementation appears to be a memory leak since nothing is freeing the error string pointer (user_error_strings). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Error reporting should be improved
On Wed, 30 Dec 2009, Peter Rosin wrote: Aha, you have misunderstood the patch, that's why we don't understand each other. The patch does indeed allocate a buffer, that's the whole point of sending the error message to lt_dladderror. The error message is cached indefinitely inside lt_dladderror. In order to not grow that In what line of code is a string buffer allocated? The only buffer allocation I see is a REALLOC to increase the buffer which holds diagnostic pointers. Then the passed pointer is assigned directly to the pointer at errindex without any allocation or string copy. cache, I implemented a comparison so that registering the same user error multiple times results in returning the index of the old error message instead of inventing a new error number each time. Yes. And so it is impossible to decipher meaningless errors from meaningful ones. If the error comes from a loader which should not have worked in the first place, then the user should be able to ignore it. Note that user_error_strings is an array of strings, not one big long string. Yes, it is an array of string pointers. The patch does exactly the first part, but not the second. There is simply no way to know when the user is done with the string, so it has to be kept indefinitely. We could document the lifetime rules, but until then there is no way to know when the message can be freed. The documentation should say that this data is only valid until the next lt_* call, which is currently the case. Yes, that is true. But that is not a new problem, just magnified by increased usage of lt_dladderror. It was essentially unused before since it was only used by a rarely used loader on OS-X. This discussion should completely move to the patches list so I will delete the Cc: to the bugs list. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: ltdl .la file parsing (was: Coverage for libltdl/slist.c and fallout)
On Tue, 8 Dec 2009, Ralf Wildenhues wrote: interfaces. For example, it is already known that the .la file parser is fragile and trivial edits to an .la file will cause the using program to core-dump. The .la file parsing is an external interface so it should get more priority. Good idea. Proposed patch. What other things do you know about that are mishandled? OK to commit? The fix and the tests look quite good and useful to me. I don't currently know of other parsing issues. As long as the application can trust that libltdl will search for .la files in secure locations, then there should not be great concern about corrupted .la files. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Status update: pr-msvc-support branch
On Wed, 25 Nov 2009, Peter Rosin wrote: Today I have tested the pr-msvc-support branch on Linux without noticing any regressions from master in the testsuite. I have used debian testing (squeeze) since that's where I found the required autotools versions. I think that people are quite interested to hear about build performance differences. Can you time execution of the test suite for both HEAD and pr-msvc-support branch and see what execution impact there may be? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Status update: pr-msvc-support branch
On Wed, 25 Nov 2009, Peter Rosin wrote: master again: $ time make -k check *snip* real23m35.390s user12m9.290s sys 10m24.720s This is in a VM on an XP box with some programs started but otherwise doing nothing... These results are good to see since there has been an expressed fear that the MSVC support might make other builds slower. Of course the libtool test suite may not actually be a good test case since it really does not compile/link very much at all. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Improve versioning algorithm description
On Tue, 22 Sep 2009, Ralf Wildenhues wrote:
The current text in the Updating version info node is seen as hard to
understand by some users, IIRC we've had a few reports about this in the
past. Richard made me try to reformulate it now.
What do you think about this additional explanation?
OK to apply (and ok to add you to THANKS, Richard)?
This explanation is very useful. Please apply.
Bob
Improve versioning algorightm documentation.
* doc/libtool.texi (Updating version info): Repeat the
algorithms in different, hopefully simpler terms.
* THANKS: Update.
Report by Richard B. Kreckel and others, several times.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 08a44c4..cb6ec80 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2879,6 +2879,37 @@ Instead, use the @option{-release} flag (@pxref{Release
numbers}), but be
warned that every release of your package will not be binary compatible
with any other release.
+The following explanation may help to understand the above rules a bit
+better: consider that there are three possible kinds of reactions from
+users of your library to changes in a shared library:
+
+...@enumerate 1
+...@item
+Programs using the previous version may use the new version as
+drop-in replacement, and programs using the new version can also work
+with the previous one. In other words, no recompiling nor relinking
+is needed. In this case, bump @var{revision} only, don't touch
+...@var{current} nor @var{age}.
+
+...@item
+Programs using the previous version may use the new version as
+drop-in replacement, but programs using the new version may use APIs not
+present in the previous one. In other words, a program linking against
+the new version may fail with ``unresolved symbols'' if linking against
+the old version at runtime: set @var{revision} to 0, bump @var{current}
+and @var{age}.
+
+...@item
+Programs may need to be changed, recompiled, relinked in order to use
+the new version. Bump @var{current}, set @var{revision} and @var{age}
+to 0.
+...@end enumerate
+
+...@noindent
+In the above description, @emph{programs} using the library in question
+may also be replaced by other libraries using it.
+
+
@node Release numbers
@section Managing release information
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: make commit conflicts in configure files less likely
On Sat, 22 Aug 2009, Ralf Wildenhues wrote:
Now, since most modern shells (except for dash, hello, Debian :-)
implement $LINENO support fairly well, I think there is little reason
to rely on this arcane way of expanding line numbers at configure script
generation time any more. I thus propose this patch to remove them.
OK?
Yes, please. This will be a welcome improvement for me.
Bob
Thanks,
Ralf
2009-08-20 Ralf Wildenhues ralf.wildenh...@gmx.de
Remove __oline__ from macros, for less spurious configure diffs.
* libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK, _LT_COMPILER_OPTION)
(_LT_COMPILER_C_O, LT_PATH_NM): Replace __oline__ instances with
$LINENO.
* NEWS: Update.
diff --git a/NEWS b/NEWS
index be4dc4d..8666196 100644
--- a/NEWS
+++ b/NEWS
@@ -48,6 +48,8 @@ New in 2.2.8 2009-??-??: git version 2.2.7a, Libtool team:
- Link mode works around a parallel build failure on Darwin 9.6.0 due
to the `ar' `flock'ing an archive upon extraction, by protecting the
extraction of convenience archives with a lock.
+ - The Libtool macro files do not contain instances of __oline__ any more,
+easing merges for configure scripts that are added to version control.
* Miscellaneous changes:
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index eebe990..7d4bc31 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1162,7 +1162,7 @@ ia64-*-hpux*)
;;
*-*-irix6*)
# Find out which ABI we are using.
- echo '[#]line __oline__ configure' conftest.$ac_ext
+ echo '[#]line '$LINENO' configure' conftest.$ac_ext
if AC_TRY_EVAL(ac_compile); then
if test $lt_cv_prog_gnu_ld = yes; then
case `/usr/bin/file conftest.$ac_objext` in
@@ -1351,11 +1351,11 @@ AC_CACHE_CHECK([$1], [$2],
-e 's:.*FLAGS}\{0,1\} :$lt_compiler_flag :; t' \
-e 's: [[^ ]]*conftest\.: $lt_compiler_flag:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo \\$as_me:__oline__: $lt_compile\ AS_MESSAGE_LOG_FD)
+ (eval echo \\$as_me:$LINENO: $lt_compile\ AS_MESSAGE_LOG_FD)
(eval $lt_compile 2conftest.err)
ac_status=$?
cat conftest.err AS_MESSAGE_LOG_FD
- echo $as_me:__oline__: \$? = $ac_status AS_MESSAGE_LOG_FD
+ echo $as_me:$LINENO: \$? = $ac_status AS_MESSAGE_LOG_FD
if (exit $ac_status) test -s $ac_outfile; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
@@ -1821,11 +1821,11 @@ AC_CACHE_CHECK([if $compiler supports -c -o
file.$ac_objext],
-e 's:.*FLAGS}\{0,1\} :$lt_compiler_flag :; t' \
-e 's: [[^ ]]*conftest\.: $lt_compiler_flag:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo \\$as_me:__oline__: $lt_compile\ AS_MESSAGE_LOG_FD)
+ (eval echo \\$as_me:$LINENO: $lt_compile\ AS_MESSAGE_LOG_FD)
(eval $lt_compile 2out/conftest.err)
ac_status=$?
cat out/conftest.err AS_MESSAGE_LOG_FD
- echo $as_me:__oline__: \$? = $ac_status AS_MESSAGE_LOG_FD
+ echo $as_me:$LINENO: \$? = $ac_status AS_MESSAGE_LOG_FD
if (exit $ac_status) test -s out/conftest2.$ac_objext
then
# The compiler can only warn and ignore the option if not recognized
@@ -3204,13 +3204,13 @@ _LT_DECL([], [NM], [1], [A BSD- or MS-compatible name
lister])dnl
AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_nm_interface],
[lt_cv_nm_interface=BSD nm
echo int some_variable = 0; conftest.$ac_ext
- (eval echo \\$as_me:__oline__: $ac_compile\ AS_MESSAGE_LOG_FD)
+ (eval echo \\$as_me:$LINENO: $ac_compile\ AS_MESSAGE_LOG_FD)
(eval $ac_compile 2conftest.err)
cat conftest.err AS_MESSAGE_LOG_FD
- (eval echo \\$as_me:__oline__: $NM \\\conftest.$ac_objext
AS_MESSAGE_LOG_FD)
+ (eval echo \\$as_me:$LINENO: $NM \\\conftest.$ac_objext
AS_MESSAGE_LOG_FD)
(eval $NM \conftest.$ac_objext\ 2conftest.err conftest.out)
cat conftest.err AS_MESSAGE_LOG_FD
- (eval echo \\$as_me:__oline__: output\ AS_MESSAGE_LOG_FD)
+ (eval echo \\$as_me:$LINENO: output\ AS_MESSAGE_LOG_FD)
cat conftest.out AS_MESSAGE_LOG_FD
if $GREP 'External.*some_variable' conftest.out /dev/null; then
lt_cv_nm_interface=MS dumpbin
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] [mingw] Improve sys_lib_search_path_spec detection.
On Mon, 29 Jun 2009, Charles Wilson wrote: Charles Wilson wrote: * libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER): Fix handling of dos-style paths when parsing $CC -print-search-dirs output. --- Currently running regression tests on MSYS-1.0.12 + mingw-4.4.0-dw2 (TDM version). OK to push, if no regressions from earlier behavior on mingw? OK to push? This patch seems like it offers considerable improvement. Please push it. It is unfortunate that GCC 3.4.5 is including libraries that some MinGW users definitely don't intend to use. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Fortran libraries on the Blue Gene with mpi
On Wed, 22 Apr 2009, Christian Rössel wrote: Ralf Wildenhues wrote: First, please ensure that you have Autoconf 2.63 and Automake 1.10.2 installed somewhere (below the same --prefix) and found early in $PATH. why do I need to install them below the *same* prefix. Is this a general requirement? What will happen if I use distinct prefixes but put both bindirs into my PATH? Installation under the same prefix is necessary because the installed m4 files from the various packages share a directory and that is where aclocal looks for them. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] Improve compatibility with older automake
On Sun, 29 Mar 2009, Charles Wilson wrote: * libltdl/m4/lt~obsolete.m4: Add AC_DEFUNs for _LT_PREPARE_SED_QUOTE_VARS and _LT_PROG_ECHO_BACKSLASH. Report by Yaakov Selkowitz. aclocal-1.8 and older fail: aclocal: macro `_LT_PREPARE_SED_QUOTE_VARS' required but not defined aclocal: macro `_LT_PROG_ECHO_BACKSLASH' required but not defined autoreconf-2.63: aclocal failed with exit status: 1 Tested by running aclocal-1.8 successfully, but didn't do a full bootstrap. Still, the fix seems obvious...okay to push? Since the fix seems obvious, please do. Bob Chuck --- libltdl/m4/lt~obsolete.m4 |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/libltdl/m4/lt~obsolete.m4 b/libltdl/m4/lt~obsolete.m4 index b60bbd2..5f6a956 100644 --- a/libltdl/m4/lt~obsolete.m4 +++ b/libltdl/m4/lt~obsolete.m4 @@ -92,3 +92,5 @@ m4_ifndef([AC_LIBTOOL_CONFIG], [AC_DEFUN([AC_LIBTOOL_CONFIG])]) m4_ifndef([_LT_AC_FILE_LTDLL_C],[AC_DEFUN([_LT_AC_FILE_LTDLL_C])]) m4_ifndef([_LT_REQUIRED_DARWIN_CHECKS], [AC_DEFUN([_LT_REQUIRED_DARWIN_CHECKS])]) m4_ifndef([_LT_AC_PROG_CXXCPP], [AC_DEFUN([_LT_AC_PROG_CXXCPP])]) +m4_ifndef([_LT_PREPARE_SED_QUOTE_VARS], [AC_DEFUN([_LT_PREPARE_SED_QUOTE_VARS])]) +m4_ifndef([_LT_PROG_ECHO_BACKSLASH], [AC_DEFUN([_LT_PROG_ECHO_BACKSLASH])]) -- 1.6.1.2 -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] Use correct export_dynamic_flag_spec for PE-COFF $hosts
On Sun, 29 Mar 2009, Charles Wilson wrote:
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin*|mingw*|pw32*|cegcc*]:
Define export_dynamic_flag_spec as -Wl,--export-all-symbols, as required
by GNU ld for PE-COFF.
Original patch by Yaakov Selkowitz. As he explained:
On Cygwin, the --export-all-symbols linker flag is required;
--export-dynamic has no effect
(see http://sourceware.org/bugzilla/show_bug.cgi?id=6744).
This patch fixes two problems:
(1) LT_SYS_DLOPEN_SELF returns a false negative;
(2) Using the -export-dynamic libtool flag does not affect the
resulting binary.
Tested in combination with several other cygwin patches, as part of the
recent cygwin official 2.2.7a-N libtool release(s):
http://cygwin.com/ml/cygwin-announce/2009-03/msg00080.html
http://cygwin.com/ml/cygwin-announce/2009-03/msg00081.html
No regressions. Okay to push?
If you are sure that --export-all-symbols will work with older (within
reason) Cygwin and MinGW installs, then this seems ok to push. I do
see support for --export-all-symbols in my archaic MinGW install so
the risk of problems seems low.
Bob
libltdl/m4/libtool.m4 |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 477f6e3..15612c0 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4275,6 +4275,7 @@ _LT_EOF
# _LT_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
# as there is no search path for DLLs.
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+ _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-all-symbols'
_LT_TAGVAR(allow_undefined_flag, $1)=unsupported
_LT_TAGVAR(always_export_symbols, $1)=no
_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
--
1.6.1.2
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] [cygwin] Improve operation with gcc4
On Sun, 29 Mar 2009, Charles Wilson wrote:
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER) [cygwin*]:
Add w32api to sys_lib_search_path_spec without overriding gcc's
own search path.
Original patch by Yaakov Selkowitz. As he explained:
With gcc4 providing shared libs, it should now perfectly legitimate to
add any of these libs to the libtool link command. Right now, though,
libtool can't find these libraries because $sys_lib_search_path_spec is
hard-coded to ignore it, and libtool will refuse to link against any
library it can't find (even though the linker itself can).
Instead, this patch simply adds /usr/lib/w32api to the default
gcc-specific search path. The m4_if() makes sure that w32api is added
only once, as is done with Darwin a few lines later.
Tested in combination with several other cygwin patches, as part of the
recent cygwin official 2.2.7a-N libtool release(s):
http://cygwin.com/ml/cygwin-announce/2009-03/msg00080.html
http://cygwin.com/ml/cygwin-announce/2009-03/msg00081.html
No regressions. Okay to push?
This change seems good to me. Please push it.
I am looking forward to using Cygwin 1.7.
Bob
---
libltdl/m4/libtool.m4 |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 15612c0..63e831e 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2156,7 +2156,8 @@ cygwin* | mingw* | pw32* | cegcc*)
cygwin*)
# Cygwin DLLs use 'cyg' prefix rather than 'lib'
soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} |
$SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
- sys_lib_search_path_spec=/usr/lib /lib/w32api /lib /usr/local/lib
+m4_if([$1], [],[
+ sys_lib_search_path_spec=$sys_lib_search_path_spec /usr/lib/w32api])
;;
mingw* | cegcc*)
# MinGW DLLs use traditional 'lib' prefix
--
1.6.1.2
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Status of the MSYS/MSVC port
On Thu, 29 Jan 2009, Peter Rosin wrote: Den 2009-01-29 11:49 skrev Charles Wilson: What version of mingw-runtime are you using? (I'm not sure which version I have; its from a bundle I put together about a year ago; I can get to the docu for that bundler later today. It's probably mingw-runtime-3.14). Something prior to [1] obviously. 3.1 or 3.2 perhaps, ca 2003 it seems? Maybe we should just ignore this (ancient) problem... My own MinGW install dates from the 2002/2003 time frame. :-) At the time MinGW/MSYS was a simple install. Nowadays it seems to be all jumbled up so I have not tried to cross the hurdle of an update. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: versioning test (was: Small patch for the QNX platform)
On Sat, 24 Jan 2009, Ralf Wildenhues wrote: Here is a testsuite addition to get some exposure to versioning. OK to push (and add Mike to THANKS)? It'd be good if somebody proof-read it so there are no silly typos or thinkos. I read it and did not see any silly typos or thinkos, but then again it is not easy reading. It should be interesting to see where these tests report a failure. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: spaces
On Thu, 22 Jan 2009, Tim Rice wrote: Or maybe it just seems so because those that want a change are those that will speak up. I prefer tabs. If I want the text in the 25th column it's just 3 tab keys and start typing. I don't have to count out pressing the space bar 24 times and then wondering if it really was 24. I find python code really annoying because it is spaces only. Almost anyone will prefer tabs if they are the only ones working on the source code. The problems occur when several/many people are working on shared source code using a variety of editors. Can we agree to make the switch only after 2.2.8 though, I would like to avoid unnecessary churn ATM. I am in favor of instituting a rule that all new code and patch code should use spaces but that existing TABs can continue to exist until those specific regions of code are edited. The formatting situation is not worse than now (we probably already have mixed spaces and tabs) and eventually the code will entirely use spaces. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] Minor cygwin cleanup
On Tue, 20 Jan 2009, Charles Wilson wrote:
libltdl/config/ltmain.m4sh (func_generate_dlsyms): Correct
case pattern for cygwin.
---
Ok to push?
Looks fine to me.
Bob
libltdl/config/ltmain.m4sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 6be529a..760f647 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1987,7 +1987,7 @@ extern \C\ {
eval '$GREP -f $output_objdir/$outputname.exp $nlist
$nlistT'
eval '$MV $nlistT $nlist'
case $host in
- *cygwin | *mingw* | *cegcc* )
+ *cygwin* | *mingw* | *cegcc* )
eval echo EXPORTS ' $output_objdir/$outputname.def'
eval 'cat $nlist $output_objdir/$outputname.def'
;;
--
1.6.0.4
==
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Run tests with low max_cmd_len on MSYS/MSVC
On Wed, 21 Jan 2009, Ralf Wildenhues wrote: We may need to think about speeding up func_to_host_path, e.g., by not forking for arguments that don't need conversion, or by converting several paths with a constant amount of forks. But that can be done separately. There is also the possibility of building a translation cache which is preserved across libtool invokations. The only concern is if the mounts get changed after the cache is generated. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: spaces (was: Provide a means to activate dynamically the debug traces)
On Mon, 19 Jan 2009, Akim Demaille wrote: I have worked for years with the same set up as you, using an much TAB as is possible. But I read someday something that Jim wrote about this topic, in which he was advocating the no-tab approach, and I was convinced. What changed my viewpoint was that (i) Jim is in favor of it, so it's good :) and (ii) because he did point out that it makes it really easier to discuss about code in emails. It is true that I have been disturbed and even annoyed by tab vs. space in some patches that gave the impression of improper indentation. Therefore, for a year or so, I am now using spaces only. It is not necessary to use hard tabs. They are a form of text compression which originated with anchient character terminals and typewriters. Since many/most people have a habit of changing the meaning of TAB to something other than the standard 8 spaces, TAB causes a lot of formatting problems if TAB is used in conjunction with spaces. Text editors have a very hard time agreeing on how to treat TAB and so when TAB is used, the text only appears correct for the person who wrote it. For many years I have had my editor configured to always use spaces. This ensures WYSIWYG for everyone involved. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: set_program_name behavior
On Mon, 19 Jan 2009, Ralf Wildenhues wrote: Well, alias lgdb='libtool --mode=execute gdb' is still shorter than what you suggest, but for reference, here's a patch that does what you want. What do the others think, should libtool be lenient here? I don't have a strong preference (sure don't mind), the requirement for a mode seems to have been present for at least 10 years. 10 years already? the only concern I can think of is if this blocks building the program called 'gdb', but hopefully it's build is already using --mode given the 10 years.. Aside, I am not quite sure whether it is portable (to other systems or debugger versions) to assume that gdb will not be interactive when started with stdin redirected to /dev/null. This may be a valid concern for systems which do not support POSIX pty's or /dev/null (primarily Windows). Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Rebase of the pr-msvc-support branch?
On Fri, 9 Jan 2009, Ralf Wildenhues wrote: Agreed, too; 2.2.8 soon would be good. A couple of small issues need looking at (esp. the aclocal.m4 messup reported by Akim). Any volunteers for the release? so that we can bite the bullet and integrate your branch into mainline. Agreed, too. Them bullets sure taste rather bitter, though. ;-) Those of us who have been targeting Windows for many years have bitten many bitter bullets. There is little doubt that my anticipated lifespan has already been reduced due to intense frustration associated with Windows. It will solve a lot of problems if autotools can be used to build real Windows programs. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Rebase of the pr-msvc-support branch?
Someone needs to cut the next libtool so that we can bite the bullet and integrate your branch into mainline. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [SCM] GNU Libtool branch, master, updated. v2.2.4-45-gc2b8636
On Sun, 7 Sep 2008, Ralf Wildenhues wrote: Why is Automake = 1.10.1 an issue though? It's been around for almost a year... But some distros still have two-year latencies for stable - stable releases. Yes, and some stable users may take another two-years to update to the latest stable release. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [SCM] GNU Libtool branch, master, updated. v2.2.4-45-gc2b8636
On Mon, 8 Sep 2008, Gary V. Vaughan wrote: How does one pull a release? I don't think it is possible. Replace the tarball with a message that says. D'oh! Sorry, this release was stillborn, please get this other one instead The original tarball can be deleted from the official FSF site but it is likely already mirrored to a 1000 places which use various mirror rules. Does FSF recommend 'a', 'b', 'c' notation for fixed releases, or does it recommend adding another decimal place? Actually, I think they recommend 'a' suffix IIRC... This is indeed a rather serious issue so I recommend creating a new release ASAP using the process that the FSF recommends for quick fix re-releases. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Two small libltdl patches.
On Sun, 24 Aug 2008, Charles Wilson wrote: But wasn't there a thread back in June where we explicitly added a bunch of argz functions, so that (a) we would be using the same file as gnulib, and (b) that file would have a complete argz implementation? I recall that it was decided that it was not necessary for the implementation to be identical to gnulib and that the code should not need to be updated unless it is found to be broken. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Linking with '-L /path/to/lib' (note the space!)
On Thu, 21 Aug 2008, Ralf Wildenhues wrote: discover otherwise non-existing bugs somewhere else. Well, libtool *could* also remove the space. I'm just not sure whether it's worth supporting this. Removing the space might simply cause a failure later if it is an actual typo (like your test case). Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 370] Implement lt_dlopening of only preloaded modules.
On Tue, 12 Aug 2008, Ralf Wildenhues wrote: This patch causes a testsuite failure on GNU/Linux. As a step toward stabilization, I would like to propose to revert the above patch. Its acceptance should rely on its test passing on at least more than one of Darwin, MinGW, GNU/Linux, and AIX. (Does it currently pass on any of them?) OK to revert? Or, rather: does anybody have problems with the reversal? Temporarily or permanently? It seems that lt_dladvise_preload() is needed to allow ltdl to be more secure for applications which need it. It should be ok to revert the patch temporarily so that the forthcoming release can be cut. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 370 bis] Implement lt_dlopening of only preloaded modules.
$LDFLAGS -o main main.$OBJEXT $preloaded $modules $LIBLTDL], +[], [ignore], [ignore]) + +# Remove loadable libpreload module, so we know it is the preloaded module +# that is being executed by a successful test invocation: +$LIBTOOL --mode=clean rm libpreload.la + +LT_AT_NOINST_EXEC_CHECK([./main], [$modules], [], [expout], []) + AT_CLEANUP -- 1.5.4.3 == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: argz whitespace
On Tue, 20 May 2008, Eric Blake wrote: Also, would anyone be interested in a patch that renames argz_.h to argz.in.h to match gnulib? Gnulib recently changed to avoid _ in file names where possible, and these days, platforms that don't handle two . in a file name are generally not worth porting to. http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=5155f7d Isn't one of those platforms versions of Microsoft Windows? What qualifies a platform as not being worth porting to? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: argz whitespace
On Tue, 20 May 2008, Eric Blake wrote: According to Eric Blake on 5/20/2008 6:32 AM: | Also, would anyone be interested in a patch that renames argz_.h to | argz.in.h to match gnulib? Gnulib recently changed to avoid _ in file | names where possible, and these days, platforms that don't handle two . in | a file name are generally not worth porting to. | http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=5155f7d Like so. OK to apply? There is a palpable cost to renaming libltdl/argz_.h and the cost should be carefully considered before renaming files. Have you considered the cost? What is the value behind this change and is the value obtained greater than the cumulative cost? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: argz whitespace
On Tue, 20 May 2008, Bob Friesenhahn wrote: There is a palpable cost to renaming libltdl/argz_.h and the cost should be carefully considered before renaming files. Have you considered the cost? What is the value behind this change and is the value obtained greater than the cumulative cost? It comes to mind that perhaps the reason for the cost is not clear. This apparently minor change causes these issues: * Template libltdl source code footprint changes. This means that on a system where installed files are not precisely controlled by a package manager (so the prior version is completely uninstalled), after an upgrade, we are left with stale residue which remains for the rest of time. * Every package using libltdl incorporates a copy of it. These copies are maintained in version control systems. The maintainer of the package needs to notice the change (unlikely since it is unexpected) so that the new name can be added, and the old name removed. Eventually the problem will be noticed, but only after it has caused some harm. Currently packages using libltdl offer to install the packaged version so there is opportunity for even more churn. Now that libtool 2.2 is out the door we need to be conservative about file additions, removals, and renames in libltdl. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: argz whitespace
On Tue, 20 May 2008, Eric Blake wrote: | What qualifies a platform as not being worth porting to? It's somewhat subjective. The gnulib mailing list has come up with an ad-hoc definition of any platform released within the last 3-5 years, and preferably where the vendor has not declared the platform end-of-life, while also supporting older platforms where the vendor is still actively providing support. So, as an example, Solaris 4 and Windows 95 are generally not viable porting targets (their vendors no longer support Clearly these are not suitable rules for libtool. Autoconf and libtool need to be dicated by whether the features they need to execute are present (might require augmentation such as replacement compiler and shell), and not how old the target is, or if its manufacturer still cares about it. I am quite certain that Solaris 2.4 is a solid POSIX-compliant OS which is capable of performing useful tasks today just as it did when it was released. It does not have POSIX threads, but it has most other useful Unix things that we enjoy today. Some Y2K and daylight-savings bugs may be present but this is not necessarily cause to throw the hardware away. To me, a 5 year old system has reached middle age and a 3 year old system is practically new. Ten years is senior citizen and should seek retirement. Regardless, we should not be changing the libtool 2.2.X install footprint for the sake of change. There should be a good reason. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: --with-included-ltdl infers --enable-ltdl-convenience
On Tue, 6 May 2008, Ralf Wildenhues wrote: This patch shuts up the warning about --enable-ltdl-convenience (I suppose the fact that you write --with-included-ltdl in the paragraph is a typo, as you use the correct one in the Subject:). However, it I don't believe that it is a typo since if --with-included-ltdl is supplied, then the configure script also sets --enable-ltdl-convenience to yes and this is inserted into the config.status file as a supplied option so that it is applied later. The --enable-ltdl-convenience option was in development libtool 2.X for almost four years. also exposes the flag to the user (via ./configure --help). I'm not sure whether that is a good idea. What do you think? It is perhaps not a great thing since it is now a secondary (non-dominant) option. In fact, I noticed that --enable-ltdl-convenience is 'yes' even if libltdl is being built as a shared library for formal installation. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [Patch] cwrapper invokes target directly
On Tue, 29 Apr 2008, Charles Wilson wrote: If I can get some feedback on the '*_with_wine.sh' script I could update the patch to also support $build=some_unixy_platform_with_wine and $host=mingw. I have a MinGW cross-compiler hosted off of FreeBSD 7.0. Presumably I can run Wine on it. I know that Linux has special hooks in order to automatically run Windows executables using Wine. Is the Wine execution support dependent on this Linux feature? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libltdl and cygwin 1.7.0
On Wed, 30 Apr 2008, Eric Blake wrote:
Cygwin 1.7.0 will change the size of MAX_PATH in its headers, but the old
cygwin_conv_to_* API silently suffers from buffer overrun if more than 256
bytes occur in the conversion. As a result, cygwin developers wisely
deprecated the old API when adding the new cygwin_path_conv, and compilation
now issues a warning (which in turn cripples -Werror builds):
libltdl/loaders/loadlibrary.c: In function `vm_open':
libltdl/loaders/loadlibrary.c:147: warning: `cygwin_conv_to_full_win32_path' is
deprecated (declared at /usr/include/sys/cygwin.h:52)
make[2]: *** [libltdl/loaders/loadlibrary.lo] Error 1
OK to apply?
This looks good to apply to me except for the minor nit that the
bracing indentation within the HAVE_DECL_CYGWIN_CONV_PATH is wrong
(and should be corrected).
-#if defined(__CYGWIN__)
+#if HAVE_DECL_CYGWIN_CONV_PATH
+ if (cygwin_conv_path (CCP_POSIX_TO_WIN_A, filename, wpath, MAX_PATH))
+{
+ LT__SETERROR (CANNOT_OPEN);
+ return 0;
+ }
+ len = 0;
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
