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 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: 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: 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
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 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
Perhaps the issue is caused by this in the GCC spec file?
*lib:
%{!symbolic: %{pthreads|pthread:-lpthread}
%{pthreads|pthread|fprofile-generate*:} %{p|pg:-ldl} -lc}
If that is true, then the problem should go away if pthreads are not
requested.
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
lib/gcc/i386-pc-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 Thu, 26 Jul 2012, Fabian Groffen wrote: Libtool apparently figures out what libs to link to by watching what the compiler does. It applies duplicate elimination on the result of that (don't know why) causing -lgcc_s -lc -lgcc_s to be turned into -lc -lgcc_s. As result, the library aborts on Solaris when it throws an exception because -lc comes before -lgcc_s. On Sparc, the result is -lgcc_s -lc, probably because both were double. I'm not sure this can be properly fixed by making sure -lgcc_s -lc remains, since GCC purposely emits the same library multiple times, so I decided to just disable the duplicate elimination for Solaris. Unfortunately, this fix is not working for me (not fixing issue I already encountered). I do see libtool's exceptions test pass (for a 32-bit build) , but it does not work for my own C++ application as a 64-bit build. It seems that GCC itself is causing the harm (or is just plain not working). With no specific request for any of these libraries, this is the list of libraries that GCC 4.7.1 is passing to collect2 while building my C++ test application: -lstdc++ -lm -lc -lgomp -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc I tried running collect2 manually with different permutations but was unable to find one which gets C++ exceptions working. The Sun/Oracle compiler has never had a problem with C++ exceptions. 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
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
---
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, 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] 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 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.
me conversion fails
+* Native MinGW File Name Conversion:: 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
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
---
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
+
+ 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
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 2/6] maint: consolidate Introductions of README and README.alpha.
uilds and passes the test suite (`gmake check'), please send + a short note to the libtool mailing list 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 5/6] maint: improve README's `Obtaining the Latest Sources'.
/gnu/libtool + + To reduce load on the main server, please use one of the mirrors + listed 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 4/6] maint: reformat README `The Test Suites' for consistency.
the old testsuite only, do it like this: - gmake check TESTSUITEFLAGS=-V +gmake check TESTSUITEFLAGS=-V If you want to run the new 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, . + 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] maint: ship .xz, not .lzma
On Tue, 14 Sep 2010, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Tue, Sep 14, 2010 at 05:02:42PM CEST: 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. This is fairly grave criticism, esp. the second part. Can you please be more specific as to other examples you consider politics and lacking proper technical analysis? This is the only example I am talking about at the moment. Bob -- 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: [PATCH 0/2] sysroot patches followup
On Sat, 14 Aug 2010, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Thu, Aug 12, 2010 at 11:28:31PM CEST: Thanks. So far, with a merge of sysroot to master, I see one regression on AIX with runtimelinking (configure LDFLAGS=-Wl,-brtl) and a different one on Solaris, The Solaris issue is shown below and is actually an old unrelated bug that Bob reported previously and I had forgotten about again: lt_dlerror might return NULL when it shouldn't, and that upsets Solaris printf %s, understandably. I think that the associated test should be enhanced such that it always fails if the error string is null. The test should not be relying on an implementation aspect of an OS library in order for a failure to occur. If the failure is reported on more targets, then the bug is more likely to be fixed. Some C library printfs output a string like "(null)" if a null pointer is passed while others result in a core dump. Bob Cheers, Ralf 81. lalib-syntax.at:24: testing syntax of .la files ... [...] ++ for file in ./missing-closing-quote.la ./wrong-quotes.la ./no-dlname.la ./nonexistent-dlname.la ++ lt_exe=./main ++ test -f ./main ++ lt_exe=./main ++ set +x ../../libtool/tests/lalib-syntax.at:128: if "$lt_exe" $file; then :; else lt_status=$?;test $lt_status != 1 && test "X$host" != "X$build" && test -x "$lt_exe" && exit 77; exit $lt_status; fi ++ ./main ./missing-closing-quote.la ++ lt_status=139 ++ test 139 '!=' 1 ++ test Xsparc-sun-solaris2.10 '!=' Xsparc-sun-solaris2.10 ++ exit 139 stderr: /home/rwild/lt/build-sparc-sun-solaris2.10/tests/testsuite.dir/at-groups/81/test-source: line 179: 11043 Segmentation Fault (core dumped) "$lt_exe" $file stdout: ../../libtool/tests/lalib-syntax.at:128: exit code was 139, expected 1 81. lalib-syntax.at:24: FAILED (lalib-syntax.at:128) -- 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 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: 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: 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 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: 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: 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: [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/
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: 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
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/
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: [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: 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: 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: 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.
automake: $automake_version
# autoconf: $autoconf_version
#
-# Report bugs to .
+# Report bugs to <@PACKAGE_BUGREPORT@>.
+# GNU @PACKAGE@ home page: <@PACKAGE_URL@>.
+# General help using GNU software: <http://www.gnu.org/gethelp/>.
PROGRAM=libtool
packa...@package@
diff --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 .
+# 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:
I'm really confused now. Is there any specific formulation, sentence,
or something in the manual that my change made worse in any way? If you
think so, can you please point it out precisely, including a suggestion
on how to improve it? Your comment seems very general, and while I can
guess that in general, the transformation from third to second person
singular can be problematic, I fail to see why this should be the case
in this patch.
It seems to me that the term 'you' is first person in the context of
the person doing the reading.
In all autotools manuals, use of "you" is already abundant.
I can't help that.
The problem with trying to be sexually agnostic is that the english
language was never designed for it. Until very recent times, it was
accepted that 'he' also meant 'she' unless specifically mentioned
otherwise. ('she' becomes subordinate to 'he' due to the biblical
story of how woman was created from Adam's rib). The result becomes
clumsy text.
Bob
--
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.
c
+++ b/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: [PATCH] Enable runtime cwrapper debugging; add tests
Charles, Within the bounds of technical recommendations/comments made already (by Ralf and perhaps others), I recommend that you commit your log-jammed Cygwin patches according to the 72 hour rule. Otherwise it is unlikely that there will be any forward progress. If anything becomes broken for some other platform, it is certain to be fixed. Development libtool has not been released for quite a long time now (since September 2008) and will need to undergo regression testing on a wide variety of platforms prior to release. Bob On Sun, 14 Feb 2010, Charles Wilson wrote: Charles Wilson wrote: Charles Wilson wrote: Charles Wilson wrote: Ralf Wildenhues wrote: * Charles Wilson wrote on Mon, Jun 22, 2009 at 03:50:42AM CEST: * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [ltwrapper_debugprintf]: Renamed to... I think functions should still be put in (parens) in the ChangeLog entry, not in [brackets], according to GCS. [... other review comments ...] Okay, here's a followon patch to "Enable runtime cwrapper debugging; add tests" http://lists.gnu.org/archive/html/libtool-patches/2009-12/msg00014.html The first patch, in addition to addressing various points raised in this thread, obsoletes the "extra" mingw fix: http://lists.gnu.org/archive/html/libtool-patches/2009-12/msg00017.html Assuming these two patches are approved, I'll squash them together into a single commit (and update the commit history) before pushing. I just figured it was easier to review, by presenting the response to the review comments separately. ping... ping, again. -- Chuck -- 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: OTOH, pre-standard C++ compilers are definitely a concern for testing. I usually do pre-release testing on a couple of systems that have fairly old and non-standard C++ compilers (no namespaces etc). I don't want to see errors stemming from this. I have not encountered such a limited C++ compiler for at least 12 years, including on archaic systems. 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
#include
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: libtool, llvm-gcc, failing C++ exceptions
On Sat, 9 Jan 2010, Ralf Wildenhues wrote:
[ moving from libtool@ ]
* Bob Friesenhahn wrote on Tue, Jan 05, 2010 at 05:11:56PM CET:
Using 'llvm-gcc' (GCC frontend to llvm compiler) I find that C++
exceptions do not work (are not caught) in the built programs.
[ and suspect libtool as culprit ]
We can only find out better if we have small examples to look at.
Here is a proposed patch to try exception handling in libraries and
modules. Tested with g++ on GNU/Linux; it will certainly need fixes
for other systems, and Libtool may as well.
I'd appreciate a look over it for any obvious glitches, before I commit
it.
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.
Bob
Thanks,
Ralf
Testsuite exposure for C++ exception handling.
* tests/exceptions.at (C++ exception handling): New file, new
test.
* Makefile.am (TESTSUITE_AT): Update.
Report by Bob Friesenhahn.
diff --git a/Makefile.am b/Makefile.am
index 31b4275..e9f8566 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -496,6 +496,7 @@ TESTSUITE_AT= tests/testsuite.at \
tests/recursive.at \
tests/template.at \
tests/ctor.at \
+ tests/exceptions.at \
tests/early-libtool.at \
tests/no-executables.at \
tests/deplibs-ident.at \
diff --git a/tests/exceptions.at b/tests/exceptions.at
new file mode 100644
index 000..d551cb8
--- /dev/null
+++ b/tests/exceptions.at
@@ -0,0 +1,231 @@
+# exception.at -- test C++ exception handling with libtool -*- Autotest -*-
+#
+# Copyright (C) 2010 Free Software Foundation, Inc.
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING. If not, a copy
+# can be downloaded from http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+AT_SETUP([C++ exception handling])
+AT_KEYWORDS([libtool])
+AT_KEYWORDS([libltdl])
+: ${LTDLINCL="-I$abs_top_srcdir/libltdl"}
+: ${LIBLTDL="$abs_builddir/../libltdl/libltdlc.la"}
+CPPFLAGS="$LTDLINCL $CPPFLAGS"
+
+AT_DATA([module.h],
+[[class modexc { };
+extern "C" int modfoo () throw (modexc);
+]])
+
+AT_DATA([module.cpp],
+[[#include
+#include "module.h"
+
+int modbar (void) throw (modexc)
+{
+ throw modexc ();
+}
+
+extern "C"
+int modfoo (void) throw (modexc)
+{
+ try {
+modbar ();
+ }
+ catch (modexc) {
+std::cerr << "caught inside module\n";
+throw modexc ();
+ }
+ return 0;
+}
+]])
+
+AT_DATA([lib.h],
+[[class libexc { };
+int libfoo () throw (libexc);
+]])
+
+AT_DATA([lib.cpp],
+[[#include
+#include "lib.h"
+
+int libbar (void) throw (libexc)
+{
+ throw libexc ();
+}
+
+int libfoo (void) throw (libexc)
+{
+ try {
+libbar ();
+ }
+ catch (libexc) {
+std::cerr << "caught inside lib\n";
+throw libexc ();
+ }
+ return 0;
+}
+]])
+
+AT_DATA([main.cpp],
+[[#include
+#include
+#include
+#include "lib.h"
+#include "module.h"
+
+class exc { };
+
+int foo (void) throw (exc)
+{
+ throw exc ();
+ return 0;
+}
+
+int exceptions_in_prog (void)
+{
+ std::cerr << "exceptions_in_prog\n";
+ try {
+foo ();
+ }
+ catch (exc) {
+ std::cerr << "caught\n";
+return 0;
+ }
+ return 1;
+}
+
+int exceptions_in_lib (void)
+{
+ std::cerr << "exceptions_in_lib\n";
+ try {
+libfoo ();
+ }
+ catch (libexc) {
+ std::cerr << "caught\n";
+return 0;
+ }
+ return 1;
+}
+
+int exceptions_in_module (void)
+{
+ std::cerr << "exceptions_in_module\n";
+
+ if (lt_dlinit ())
+{
+ std::cerr << "init error: " << lt_dlerror () << '\n';
+ return 1;
+}
+
+ // Some systems need RTLD_GLOBAL for exceptions to work in modules.
+ lt_dladvise advise;
+ if (lt_dladvise_init (&advise) || lt_dladvise_global (&advise))
+{
+ std::cerr << &q
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: 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: 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: The thread safety thing can be ignored as libltdl isn't thread safe and needs to be mutexed anyway. Care to test this patch? 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(). An alternative approach would be to store loader-specific errors in loader-specific storage and iterate through the loaders in order to obtain their error messages. With this patch, how will the accumulated error strings be reported to the API user? Some of the error reports will be useless and so it may not be useful to combine them since a useless report would have the same significance as an important one. The origin (id of the reporting loader) would be useful to record. If the origin was part of the string (or the string is owned by the loader) then that would serve to keep them distinct. Unfortunately, lt_dladderror() is publically exposed so it is difficult to change its arguments even though it is not documented. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] Enable runtime cwrapper debugging; add tests
On Mon, 14 Dec 2009, Charles Wilson wrote: Two related lines of inquiry: 1) Under *normal* development rules -- e.g not a pre-release bug-fix-only phase, nor a not-quite-pre-release code slush like (I think) we're in right now, for 2.2.8 -- surely you aren't suggesting that EVERY contribution must be validated on EVERY platform, prior to push? These were tested on cyg/ming and linux, so in general, during /normal/ development, that should be sufficient contra reveiwer comments, right? The bar seems to be raised quite high now in libtool development so that only those who practice the art regularly are able to satisfy all the requirements. It seems to me that if the patch works on several platforms, and there is no reason to believe that any issues with other platforms can't be reasonably fixed, that the patch should be accepted. 100% coverage on all platforms is not a reasonable requirement for a patch. 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: Coverage for libltdl/slist.c and fallout
On Sun, 6 Dec 2009, Ralf Wildenhues wrote: More generally, I am really convinced that libltdl quality is the way it is only because authors never really cared to ensure their code really does what it was supposed to do. If we continue to treat testing and coverage as an afterthought, there is little reason to believe that is going to change. So yes, I pretty much think that all code that isn't exercised by the testsuite but could be, does not belong in the tree. There is no doubt that testing is important. It seems most important (to me) that externally-exposed interfaces should be validated before there is intense focus on test coverage of internal 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. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Preloading without .la
On Wed, 2 Dec 2009, Pierre Ossman wrote: I upgraded to libtool 2 the other day and was hit by this bug again. Has there been any work on fixing this rather large hole in the preload functionality? Did someone say 'hole'? Can you please summarize the issue again to refresh our memory? Any solution needs to be fully secure, even if the underlying OS is not as secure as it should be. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Coverage for libltdl/slist.c and fallout
On Mon, 30 Nov 2009, Gary V. Vaughan wrote: IIRC, it was trying to build libltdl with some old C++ compiler (maybe Solaris 7 or so, but I don't recall clearly) which complained about the use of NULL which drove me to using '0' in slist.c. I googled for NULL vs 0, and it seems there it has become a religious issue. The definition of NULL in system headers has been inconsistent and sometimes the definition of NULL is not so friendly for C++. However, both C and C++ will consistently accept 0 both to initialize and compare with a pointer value. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Fix bindir and dlopen tests for C++ compilers (CC=g++).
On Mon, 30 Nov 2009, Ralf Wildenhues wrote: Well, the cast only looks random as long as we don't know a good rationale for it, I guess. I should mention that there is a very good reason why strrchr() should return 'const char *'. The reason is that the input string is 'const char *' and since the returned string points into the input string, it would be wrong for it to not also be 'const char *' Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Fix bindir and dlopen tests for C++ compilers (CC=g++).
On Mon, 30 Nov 2009, Ralf Wildenhues wrote: I don't see a warning to that end, my system declares strrchr as #include char *strrchr(const char *s, int c); Solaris 10 manual pages says that this prototype is used for C: char *strrchr(const char *s, int c); and this one is used for ISO C++: const char *strrchr(const char *s, int c); Since the C++ one is more restrictive (and is also more correct), it may be useful to try to correct the code rather than just add a cast. 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: 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: libtool, OS X, and GNU ranlib
On Thu, 1 Oct 2009, Tim Rice wrote: Warn on darwin if install will overwrite /usr/bin/libtool * configure.ac: Add warning. I would wonder why /usr/bin/libtool is writable by a user. Or why one would build software as root. I can't remember the last time I had to build a package as root. The problem occurs when someone does ./configure --prefix=/usr make sudo make install Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool, OS X, and GNU ranlib
On Thu, 1 Oct 2009, Peter O'Gorman wrote: On 10/01/2009 05:04 PM, Bob Friesenhahn wrote: Excuse this top-post. I continue to believe that this "user error" should be explictly prevented (by a hard configure error) and that very few people will notice a warning message while configure is running. Hmm, well, ok, I could make it an error, but allow overriding for people who "know what they are doing", maybe by setting a cache var, e.g. ./configure --prefix=/usr lt_cv_darwin_override=yes ? and mention the possibility of using the override in the error message. This seems like a lot of complexity to me. First off, someone who "knows what they are doing" won't overwrite a necessary build tool. Secondly, the person who really knows what they are doing could 'rm' the file. If the Darwin-provided libtool exists, then configure should error out if the settings would destroy it, but if it doesn't, or if it is already GNU libtool, then configure should not complain. Of course, it is possible to identify similar situations on other systems. For example, someone could specify a prefix of /usr/ccs on Solaris and overwrite the Sun provided linker. It is much more common for someone to provide a prefix of /usr since that is what they are used to under Linux. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool, OS X, and GNU ranlib
Excuse this top-post. I continue to believe that this "user error" should be explictly prevented (by a hard configure error) and that very few people will notice a warning message while configure is running. Bob On Thu, 1 Oct 2009, Peter O'Gorman wrote: On 09/10/2009 02:04 PM, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Thu, Sep 10, 2009 at 08:21:32PM CEST: On Thu, 10 Sep 2009, Ralf Wildenhues wrote: IMHO, people installing to /usr need to know what they are doing. s/need to/should/g Yes. Enabling --program-prefix=g with --prefix=/usr would be quite a surprise for everyone else who is otherwise familiar with GCS, so I'd prefer not to go that way. Right. I think that it is better for libtool to error out during configuration if it detects that the user would be destroying the Apple version. Yes. Be sure to not error out in the case that the smart user is cross compiling for another system from Darwin, or intends to DESTDIR-install to a staging area, or similar use case that *they* might know to be sensible but *we* may not. A warning is of course prudent. But just to drive the point home again: this issue is not a bug in Libtool, it is a user error. We do not need to fix it. 2009-10-01 Peter O'Gorman Warn on darwin if install will overwrite /usr/bin/libtool * configure.ac: Add warning. ok? Peter -- Peter O'Gorman http://pogma.com -- 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 Wed, 23 Sep 2009, Ralf Wildenhues wrote: The most important question is whether it is correct, not only for Linux. That's what I'm not yet certain about. Something tells me that it is not correct for Windows. Under Windows I see a lack of versioning and libtool adds a simple number like name-7.dll to the name. Not all OSs support library versioning, so in that case applications would continue using the older library and freshly compiled applications would use the newer library. 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
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" 2>conftest.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" 2>out/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" 2>conftest.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\"" 2>conftest.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] [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: [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] 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: 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/
