Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive

2021-11-21 Thread Bob Friesenhahn

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

2021-11-21 Thread Bob Friesenhahn

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

2021-10-18 Thread Bob Friesenhahn

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

2021-10-18 Thread Bob Friesenhahn

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

2014-06-10 Thread Bob Friesenhahn

On Mon, 9 Jun 2014, Petr Sumbera wrote:


Hi,

I'm often getting following error:

/usr/apr/1.5/build/sparcv9/libtool --silent --mode=link cc -o mod_dtrace.la
-rpath /usr/apache2/2.2/libexec/sparcv9 -module -avoid-version
mod_dtrace.lo
ld: fatal: file .libs/mod_dtrace.o: wrong ELF class: ELFCLASS64
apxs:Error: Command failed with rc=131072

Attached patch fixes the issue.


Normally such options should already be included in CFLAGS (or 
sometimes works better in CC).  All of the software needs to be 
compiled with the same -m64 option.


When compiling using the Sun compiler and targeting 64-bits, I 
configure using something like


  ./configure 'CC=/opt/SUNWspro/bin/cc -m64' ...

Libtool is not multilib capable under Solaris.  That is, it does not 
automatically install a library into an architecture-specific 
subdirectory or search there either.  You might notice that the system 
does support different directories (e.g. '/lib/32', '/lib/64', 
'/lib/amd64') and GCC is multilib capable, putting its own 64-bit 
libraries in an architecture-specific subdirectory.


For my own 64-bit compiles under Solaris, I use a different 
installation prefix in order to make sure that 32-bit and 64-bit 
libraries/includes are sane.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: when linking on Solaris 64bit shared object using cc, -m64 should be used

2014-06-10 Thread Bob Friesenhahn

On Tue, 10 Jun 2014, Petr Sumbera wrote:

And finally I was uncertain with CC=cc -m64. It appeared to me as something 
what can cause some troubles and should be rather avoided.


In my experience, this has worked best for Solaris.  Libtool uses CC 
(or CXX in the case of C++) for linking.


Until such time that libtool implements proper multilib support, this 
seems like the most reliable solution.


It would be wrong for libtool to incorporate a partial solution.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: g++ and -nostdlib

2013-11-11 Thread Bob Friesenhahn

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

2013-11-08 Thread Bob Friesenhahn

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

2013-10-09 Thread Bob Friesenhahn

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

2012-12-27 Thread Bob Friesenhahn

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

2012-10-09 Thread Bob Friesenhahn

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

2012-10-05 Thread Bob Friesenhahn

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

2012-08-20 Thread Bob Friesenhahn

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

2012-07-30 Thread Bob Friesenhahn
-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

2012-07-30 Thread Bob Friesenhahn

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

2012-07-30 Thread Bob Friesenhahn

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

2012-07-26 Thread Bob Friesenhahn

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.

2012-01-30 Thread Bob Friesenhahn

On Mon, 30 Jan 2012, Peter Rosin wrote:


[Sorry for replying to myself]


I do that often.


* build-aux/ltmain.m4sh (func_emit_cwrapperexe_src:lt_update_exe_path):
Remove duplicate strlen calculation.


Hmmm, I like the following better, so I'm going to push that instead,
in case of silence.


Why wait?  Your patch looks fine to apply to me.

Bob



Cheers,
Peter


From 7b945cfdaaad8a87a19fcf837dd4bc04f399b1ab Mon Sep 17 00:00:00 2001

From: Peter Rosin p...@lysator.liu.se
Date: Mon, 30 Jan 2012 15:49:05 +0100
Subject: [PATCH] cwrapper: avoid surplus strlen calculations.

* build-aux/ltmain.m4sh (func_emit_cwrapperexe_src:lt_update_exe_path):
Avoid surplus strlen calculations.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
build-aux/ltmain.m4sh |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh
index 922e957..00d063c 100644
--- a/build-aux/ltmain.m4sh
+++ b/build-aux/ltmain.m4sh
@@ -4151,9 +4151,9 @@ lt_update_exe_path (const char *name, const char *value)
  char *new_value = lt_extend_str (getenv (name), value, 0);
  /* some systems can't cope with a ':'-terminated path #' */
  int len = strlen (new_value);
-  while (((len = strlen (new_value))  0)  IS_PATH_SEPARATOR 
(new_value[len-1]))
+  while ((len  0)  IS_PATH_SEPARATOR (new_value[len-1]))
{
-  new_value[len-1] = '\0';
+  new_value[--len] = '\0';
}
  lt_setenv (name, new_value);
  XFREE (new_value);



--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

2011-12-08 Thread Bob Friesenhahn

On Thu, 8 Dec 2011, Gary V. Vaughan wrote:


Instead of doing it this way, I'd almost rather see:

if test ${BASH_VERSION+set} = set; then


Face palm!  Absolutely, that is far more sensible.  Assuming we decide
to push this patch, I'll do it that way and ditch the host check.  Thanks!


Is the value of this variable inheritable by subordinate shells, or is 
it an internal shell variable which would never be exported to 
subordinate shells?


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

2011-12-08 Thread Bob Friesenhahn

On Thu, 8 Dec 2011, Peter O'Gorman wrote:


Any additional forks will slow down the script and should be avoided on all 
platforms.


I definitely agree with that.  Besides the Windows problem, it does 
not seem like fork performance improves linearly from adding processor 
cores so it is important to minimize forks so that parallel compiles 
don't hit an bottleneck.


Simply removing $(SHELL) from the LIBTOOL variable should fix the bug that 
this is attempting to fix, without slowing down libtool.


Will this approach work ok if the Cygwin/MinGW user is using something 
like zsh or dash rather than bash?


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time.

2011-11-28 Thread Bob Friesenhahn

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'.

2011-11-02 Thread Bob Friesenhahn

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'.

2011-11-01 Thread Bob Friesenhahn

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

2011-10-23 Thread Bob Friesenhahn

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

2011-10-17 Thread Bob Friesenhahn

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

2011-09-05 Thread Bob Friesenhahn

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

2011-09-01 Thread Bob Friesenhahn

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

2011-02-14 Thread Bob Friesenhahn

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.

2010-11-14 Thread Bob Friesenhahn
::  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

2010-09-20 Thread Bob Friesenhahn

On Mon, 20 Sep 2010, Peter Rosin wrote:


Hi!

I have tested this patch on MinGW/gcc and Cygwin/gcc and they are both
ok with the __declspec() notation.  On MSVC, the test goes from skip
to fail, as it needs 2/2.


This patch looks good to apply, as does the 2/2 patch to make sure 
that lt__PROGRAM__LTX_preloaded_symbols is globally scoped and extern 
C.


Bob



Cheers,
Peter


From 52972128c5952da628e033e4509208711906c3a2 Mon Sep 17 00:00:00 2001

From: Peter Rosin p...@lysator.liu.se
Date: Mon, 20 Sep 2010 09:07:25 +0200
Subject: [PATCH 1/2] tests: __declspec (dll{ex,im}port) in tests/exceptions.at

* tests/exceptions.at (common.h, module.h, lib.h) [w32]: Use
__declspec (dllimport) and __declspec (dllexport) instead of
the less portable __attribute__ ((dllimport)) and
__attribute__ ((dllexport)).  Makes the test compile on MSVC.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
ChangeLog   |8 
tests/exceptions.at |   17 -
2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 78d3e48..3c72890 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2010-09-20  Peter Rosin  p...@lysator.liu.se
+
+   tests: __declspec (dll{ex,im}port) in tests/exceptions.at
+   * tests/exceptions.at (common.h, module.h, lib.h) [w32]: Use
+   __declspec (dllimport) and __declspec (dllexport) instead of
+   the less portable __attribute__ ((dllimport)) and
+   __attribute__ ((dllexport)).  Makes the test compile on MSVC.
+
2010-09-19  Peter Rosin  p...@lysator.liu.se

tests: Import items from liba1 for MSVC.
diff --git a/tests/exceptions.at b/tests/exceptions.at
index 235597c..286b2ac 100644
--- a/tests/exceptions.at
+++ b/tests/exceptions.at
@@ -66,9 +66,8 @@ CPPFLAGS=$LTDLINCL $CPPFLAGS
# the regex).  However, in this test, none of these situations apply,
# so we don't directly address it.  Otherwise, the correct mechanism
# would be to avoid all of those flags, and instead explicitly decorate
-# all symbols with appropriate __attribute__ ((dllexport)) or
-# __attribute__ ((dllimport)) flags when building the DLLs and the
-# clients.
+# all symbols with appropriate __declspec (dllexport) or
+# __declspec (dllimport) flags when building the DLLs and the clients.
#
# For more information, see these two threads:
#   http://lists.gnu.org/archive/html/bug-libtool/2010-06/msg00069.html
@@ -84,9 +83,9 @@ AT_DATA([common.h],
#if defined(__CYGWIN__) || defined(_WIN32)
# if defined(DLL_EXPORT) || defined(USING_COMMON_DLL)
#  if defined(LIBTOOL_TEST_IN_COMMON)
-#   define COMMON_IMPEXP __attribute__ ((dllexport))
+#   define COMMON_IMPEXP __declspec (dllexport)
#  else
-#   define COMMON_IMPEXP __attribute__ ((dllimport))
+#   define COMMON_IMPEXP __declspec (dllimport)
#  endif
# else
#  define COMMON_IMPEXP
@@ -128,9 +127,9 @@ AT_DATA([module.h],
#if defined(__CYGWIN__) || defined(_WIN32)
# if defined(DLL_EXPORT) || defined(USING_MODULE_DLL)
#  if defined(LIBTOOL_TEST_IN_MODULE)
-#   define MODULE_IMPEXP __attribute__ ((dllexport))
+#   define MODULE_IMPEXP __declspec (dllexport)
#  else
-#   define MODULE_IMPEXP __attribute__ ((dllimport))
+#   define MODULE_IMPEXP __declspec (dllimport)
#  endif
# else
#  define MODULE_IMPEXP
@@ -174,9 +173,9 @@ AT_DATA([lib.h],
#if defined(__CYGWIN__) || defined(_WIN32)
# if defined(DLL_EXPORT) || defined(USING_LIB_DLL)
#  if defined(LIBTOOL_TEST_IN_LIB)
-#   define LIB_IMPEXP __attribute__ ((dllexport))
+#   define LIB_IMPEXP __declspec (dllexport)
#  else
-#   define LIB_IMPEXP __attribute__ ((dllimport))
+#   define LIB_IMPEXP __declspec (dllimport)
#  endif
# else
#  define LIB_IMPEXP



--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: [PATCH 4/6] maint: reformat README `The Test Suites' for consistency.

2010-09-18 Thread Bob Friesenhahn
 testsuite only, do it like this:

-  gmake check-local
+gmake check-local

The tests of the old test suite run in groups in the various demo
subdirectories, so if one of the tests early in a group FAILs, the rest
@@ -100,9 +100,8 @@ To run a test group of the old test suite in isolation 
(say, you think
you have fixed a bug, but don't want to rerun the entire suite), you can
do it like this:

-  gmake check TESTS=tests/cdemo-static.test tests/cdemo-static-make.test \
- tests/cdemo-static-exec.test \
-  TESTSUITEFLAGS=-V
+gmake check TESTSUITEFLAGS=-V TESTS=tests/cdemo-static.test \
+tests/cdemo-static-make.test tests/cdemo-static-exec.test

Providing that you have a FAIL from the most recent group from a
particular demo directory (like the cdemo-static.test group above), you
@@ -118,28 +117,40 @@ the verbose output from all failed tests.
In order to enable debug shell tracing, you can set VERBOSE=debug when
running the old test suite.

+In the long run, Libtool will move to using only the new, Autotest-
+driven testsuite.  Its usage is documented in:

-In the long run, Libtool will move to using only the new,
-Autotest-driven testsuite.  Its usage is documented in
+info Autoconf 'testsuite Invocation'

-  info Autoconf 'testsuite Invocation'
+but simple help may also be obtained through:

-but simple help may also be obtained through
-
-  gmake check-local TESTSUITEFLAGS='--help'
+gmake check-local TESTSUITEFLAGS='--help'

For verbose output, add the flag `-v', for running only a subset of the
independent tests, merely specify them by number or by keyword, both of
which are displayed with the `--list' flag.  For example, the `libtool'
keyword is used for the tests that exercise only this script.  So it is
possible to test an installed script, possibly from a different Libtool
-release, with
-  gmake check-local TESTSUITEFLAGS=-k libtool LIBTOOL=/path/to/libtool
+release, with:
+
+gmake check-local \
+TESTSUITEFLAGS=-k libtool LIBTOOL=/path/to/libtool
+
+Some tests, like the one exercising max_cmd_len limits, make use of this
+to invoke the testsuite recursively on a subset of tests.  For these
+tests, the variable INNER_TESTSUITEFLAGS may be used.  It will be
+expanded right after the `-k libtool', without separating whitespace, so
+that further limiting of the recursive set of tests is possible.  For
+example, to run only the template tests within the max_cmd_len, use:
+
+gmake check-local TESTSUITEFLAGS=-v -x -k max_cmd_len \
+ INNER_TESTSUITEFLAGS=',template -v -x'

If you wish to report test failures to the libtool list, you need to
send the file `tests/testsuite.log' to the bug report mailing list,
bug-libt...@gnu.org.

+
4. Obtaining the Latest Sources
===




--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: [PATCH 5/6] maint: improve README's `Obtaining the Latest Sources'.

2010-09-18 Thread Bob Friesenhahn
 at:
+
+http://www.gnu.org/order/ftp.html
+
+* Alpha quality pre-releases of GNU Libtool, also with detached
+  signature files are available from:
+
+ftp://alpha.gnu.org/gnu/libtool
+
+  and some of the mirrors listed at:
+
+http://www.gnu.org/order/ftp.html
+
+* Nightly snapshots of the unreleased development trunk of GNU Libtool
+  are available from:
+
+http://pogma.com/libtool
+
+  These files do not have signatures, but will allow you to easily
+  determine whether the most recent development code still exhibits any
+  bugs you have discovered, without requiring you to install a complete
+  build environment and the extra tools needed to bootstrap a version
+  control checkout.
+
* The master libtool repository is stored in git.

  If you are a member of the savannah group for GNU Libtool, a writable
@@ -195,6 +241,14 @@ send the file `tests/testsuite.log' to the bug report 
mailing list,
  - Autoconf 2.59 or later
  - Automake 1.9.6 or later

+* The `bootstrap' script sets up the source directory for you to hack,
+  though it may take quite some time to run.  If you don't intend to
+  re-run the test suite, you can speed up the `bootstrap' step by an
+  order of magnitude if you call it like this instead:
+
+reconfdirs='. libltdl' ./bootstrap
+
+
5. Version Numbering


@@ -250,7 +304,7 @@ things:
For more details about version numbers, see:

http://www.gnu.org/software/libtool/contribute.html
---
+--
  Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
  Foundation, Inc.
  Written by Gary V. Vaughan, 2004



--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: [PATCH 2/6] maint: consolidate Introductions of README and README.alpha.

2010-09-18 Thread Bob Friesenhahn
 and passes the test suite (`gmake check'), please send
+   a short note to the libtool mailing list libt...@gnu.org with a
+   subject line including the string `[PLATFORM]', and containing the
+   details from the end of `./libtool --help' in the body.
+ * Otherwise, see `Reporting Bugs' below for how to help us fix any
+   problems you discover.
+
+To use Libtool, add the new generic library building commands to your
+Makefile, Makefile.in, or Makefile.am.  See the documentation for
+details.


2. Reporting Bugs



--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: [PATCH] maint: ship .xz, not .lzma

2010-09-14 Thread Bob Friesenhahn

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] maint: ship .xz, not .lzma

2010-09-14 Thread Bob Friesenhahn

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: Next Libtool Point Release Pending

2010-08-09 Thread Bob Friesenhahn

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

2010-08-06 Thread Bob Friesenhahn

On Fri, 6 Aug 2010, Gary V. Vaughan wrote:


OTOH, since I hope to have more larger changes in the future, I'm not
sure we really want another major number bump already.


That's only a minor bump, according to major.minor.micro:

 major bump = substantial rewrite
 minor bump = new features, new code and new bugs
 micro bump = regressions and bugs fixed

This is the scheme I believe most people recognize, and that suggests
to me that 2.4.0 would be the next logical release number?


You do make a good point.  It is better to advance the minor number 
(rather than continually increase the micro number) if significant new 
features have been added.  However, the objectives should be met (e.g. 
really able to build adequately with MSVC) before we bump to 2.4. 
This should not discourage including 99% of the necessary updates in 
another 2.2 release.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: Next Libtool Point Release Pending

2010-08-06 Thread Bob Friesenhahn

On Sat, 7 Aug 2010, Gary V. Vaughan wrote:


Nonetheless I still think that users should have some confidence that
releases get more stable as micro increases.  Rolling a ton of new
code into a micro bump violates that idea.


True.  Incrementing minor suggests production of a branch and that 
there may be a later bug-fix release from that branch which would 
increment micro.  There are various implications suggested by the 
numbering strategy.  These implications could result in more 
maintenance effort.  They may also result in OS distribution 
maintainers not picking up the update since the increment to minor 
makes the release seem more major than it actually is.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: MSVC: Preloading in ltdl doesn't heed libname_spec.

2010-07-08 Thread Bob Friesenhahn

On Tue, 6 Jul 2010, Ralf Wildenhues wrote:


Perhaps things are not all that bad.  While 35 of 110 tests fail
under Debian Linux, only these two extra are failing under FreeBSD,
OS-X, and Solaris:

FAIL: tests/mdemo2-make.test
FAIL: tests/pdemo-make.test


It would probably be even more helpful if you posted verbose test
failure output (or excerpts), that would make assigning blame easier,
I guess.


Yes.  And in fact it would be even better if the test suite always 
produced/retained verbose output for failed tests so that the 
information is always immediately available on demand.  The fact that 
it does not should be considered to be a bug.


I am thinking that the many test failures under Debian Linux are due 
to it using older tool versions such as Autoconf 2.61.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: verbose test output (was: MSVC: Preloading in ltdl doesn't heed libname_spec.)

2010-07-08 Thread Bob Friesenhahn

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.

2010-07-05 Thread Bob Friesenhahn

On Mon, 5 Jul 2010, Peter Rosin wrote:


Inspired by the remarkable progress, I'm bringing up this
patch again.


It would be good if the progress was even more remarkable. 
Yesterday's libtool was doing quite good with the tests but I am 
seeing plenty of failures now for all Unixish targets.  Even Linux 
blows failures all over the place.  Not to worry, it is likely 
something simple.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: MSVC: Preloading in ltdl doesn't heed libname_spec.

2010-07-05 Thread Bob Friesenhahn

On Mon, 5 Jul 2010, Bob Friesenhahn wrote:


On Mon, 5 Jul 2010, Peter Rosin wrote:


Inspired by the remarkable progress, I'm bringing up this
patch again.


It would be good if the progress was even more remarkable. Yesterday's 
libtool was doing quite good with the tests but I am seeing plenty of 
failures now for all Unixish targets.  Even Linux blows failures all over the 
place.  Not to worry, it is likely something simple.


Perhaps things are not all that bad.  While 35 of 110 tests fail under 
Debian Linux, only these two extra are failing under FreeBSD, OS-X, 
and Solaris:


FAIL: tests/mdemo2-make.test
FAIL: tests/pdemo-make.test

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)

2010-07-04 Thread Bob Friesenhahn

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?)

2010-07-03 Thread Bob Friesenhahn

On Sat, 3 Jul 2010, Charles Wilson wrote:


That's an...interesting take.  I've never assumed that ANY contribution
would be acceptable unless it received an actual approval by a
maintainer.  I mean, really: here's this patch, and no single maintainer
has endorsed it without some significant objection -- and I should feel
free as a non-maintainer to say well, I disagree, so I'm pushing anyway??


I think that you are attributing to much special status to official 
maintainers.  It should not matter where approval comes from as long 
as the approval is from a sufficiently qualified person with knowledge 
of the subject who has done a proper review and/or actual testing. 
The official maintainers are sometimes not qualified to properly 
review a patch.



That seems like a fast way to lose committer status, IMO.


While I am sure that it is possible to lose committer status due to 
misbehavior, I don't recall this happening in libtool history for any 
reason other than the person disappeared from the Internet or 
requested that their committer status be removed.  No one is 
threatening your committer status.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



libtool head fails under Solaris 10 FreeBSD

2010-06-29 Thread Bob Friesenhahn
As a heads-up, yesterday libtool was passing the normal number of 
tests (usually fails 2) under Solaris 10.  With latest changes from 
today, libtool tests are failing badly:



26 of 53 tests failed
(53 tests were not run)
Please report to bug-libt...@gnu.org


Usually the test suite works perfectly under FreeBSD 8.0 but it is 
failing 3 tests now:



3 of 96 tests failed
(10 tests were not run)
Please report to bug-libt...@gnu.org


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: libtool head fails under Solaris 10 FreeBSD

2010-06-29 Thread Bob Friesenhahn

On Wed, 30 Jun 2010, Gary V. Vaughan wrote:


I can't reproduce this one.  But that might be something to do with the fix I 
just committed...


I am dutifully re-running the tests with your latest patch 
(d8bdf9339ba7de82f40c49705650506e0cc3f979).  Early impressions are 
that there are far fewer failures than before under Solaris 10 but the 
stress tests are still running.  This one is still new though:


  6: enhanced shell option appending FAILED (getopt-m4sh.at:183)

I don't have access to FreeBSD 8.0, could you retest, and show 
verbose logs of the fails if they haven't gone away please?


Yes, sir.  Will do.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: libtool head fails under Solaris 10 FreeBSD

2010-06-29 Thread Bob Friesenhahn

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

2010-06-29 Thread Bob Friesenhahn

With OS-X Leopard PowerPC:

## - ##
## Test results. ##
## - ##

100 tests behaved as expected.
15 tests were skipped.

but with FreeBSD 8.0:


3 of 96 tests failed
(10 tests were not run)
Please report to bug-libt...@gnu.org


I found that the file tests/testsuite.log was from a very old run.  So 
I removed the build tree and did everything from scratch.  No 
tests/testsuite.log file was produced.  This similar failure was 
counted three times:


FAIL: tests/depdemo-make.test
FAIL: tests/depdemo-make.test
FAIL: tests/depdemo-make.test

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)

2010-06-27 Thread Bob Friesenhahn

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

2010-06-18 Thread Bob Friesenhahn

On Fri, 18 Jun 2010, Charles Wilson wrote:


The final loader called, for /usr/bin/last -- which exists -- is the
'last' loader.  In last_open(), it sets LT_ERROR_FILE_NOT_FOUND as a
sort of generic error value -- which, strangely, is exactly the
OPPOSITE of the problem here.

The real problem is there actually IS a file named /usr/bin/last, but
because that name does not match exactly last, last_open() reports
what it considers a generic error.


I seem to be backlogged by the flurry of email, but hopefully you guys 
will get this figured out.  I would be astonished if Windows 
LoadLibrary() is not willing to load a Windows executable file similar 
to the way it loads a DLL.  If so, this raises security implications 
that we want to avoid.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: lt_dlerror changes

2010-06-18 Thread Bob Friesenhahn

On Fri, 18 Jun 2010, Charles Wilson wrote:



If so, this raises security implications
that we want to avoid.


I don't think so.


Hopefully not.  If a binary from an executable program is placed at 
the path C:\cygwin\bin\last (with no .exe extension) does 
LoadLibrary() load it?


Since we are on the subject, it is good to make sure that Windows 
really is in good shape security-wise.


Windows paranoia about downloaded files might go away if the file 
extension is missing so it is good to know if it will still attempt to 
load an exectuable or DLL which has its file extension missing.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: Print Libtool project URL in program --help output.

2010-06-15 Thread Bob Friesenhahn

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.

2010-06-13 Thread Bob Friesenhahn
 --git a/libtoolize.m4sh b/libtoolize.m4sh
index 2aa82d4..04db82f 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -65,7 +65,9 @@ AS_INIT[]m4_divert_push([HEADER-COPYRIGHT])dnl
#   automake:   $automake_version
#   autoconf:   $autoconf_version
#
-# Report bugs to bug-libt...@gnu.org.
+# Report bugs to @PACKAGE_BUGREPORT@.
+# GNU @PACKAGE@ home page: @PACKAGE_URL@.
+# General help using GNU software: http://www.gnu.org/gethelp/.

: ${TAR=tar}




--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: Rewrite manual intro to be gender-neutral.

2010-06-06 Thread Bob Friesenhahn

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

2010-05-05 Thread Bob Friesenhahn

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.

2010-04-05 Thread Bob Friesenhahn
/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

2010-03-28 Thread Bob Friesenhahn

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.

2010-03-16 Thread Bob Friesenhahn

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

2010-02-22 Thread Bob Friesenhahn

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

2010-02-21 Thread Bob Friesenhahn
On my systems (and after Charles raft of submissions) this is the 
current final test status:


Solaris 10
==
ERROR: 94 tests were run,
6 failed (4 expected failures).
11 tests were skipped.

FreeBSD 8
=
92 tests behaved as expected.
13 tests were skipped.

OS-X Leopard

91 tests behaved as expected.
14 tests were skipped.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: Report proper errors from the loadlibrary loader.

2010-01-17 Thread Bob Friesenhahn

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

2010-01-12 Thread Bob Friesenhahn

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

2010-01-12 Thread Bob Friesenhahn

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

2010-01-10 Thread Bob Friesenhahn

On Sun, 10 Jan 2010, Ralf Wildenhues wrote:


My main comment is that it would be useful if the thrown class is
derived from std:exception (or one of its standard derived classes)
in order to flush out any issues which may stem from possible
partial template instantiation in libstdc++ (or pre-compiled
headers) as well as in the test translation unit.


OK, sounds useful.  Would that entail more than just something like
this incremental addition?


I think that the virtual what() method needs to be provided or else 
you have only a partially implemented class:


class MyException : public std::exception
{
  public;
MyException() {}

  virtual const char *what() const throw()
  {
 return My message;
  }
};

But this is a better class to test with since it uses more standard 
library stuff and is therefore more likely to fail if something is 
wrong:


#include exception
#include string
class MyException : public std::exception
{
  public;
MyException(std::string str)
 : message(str)
{
}

  virtual const char *what() const throw()
  {
 return message.c_str();
  }

  private:
std::string message;
};

Which can be thrown with

  throw MyException(My message);

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: Happy New Year

2010-01-06 Thread Bob Friesenhahn

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

2009-12-30 Thread Bob Friesenhahn

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

2009-12-30 Thread Bob Friesenhahn

On Wed, 30 Dec 2009, Peter Rosin wrote:


Aha, you have misunderstood the patch, that's why we don't understand
each other. The patch does indeed allocate a buffer, that's the whole
point of sending the error message to lt_dladderror. The error message
is cached indefinitely inside lt_dladderror. In order to not grow that


In what line of code is a string buffer allocated?  The only buffer 
allocation I see is a REALLOC to increase the buffer which holds 
diagnostic pointers.  Then the passed pointer is assigned directly to 
the pointer at errindex without any allocation or string copy.



cache, I implemented a comparison so that registering the same user
error multiple times results in returning the index of the old error
message instead of inventing a new error number each time.


Yes.  And so it is impossible to decipher meaningless errors from 
meaningful ones.  If the error comes from a loader which should not 
have worked in the first place, then the user should be able to ignore 
it.



Note that user_error_strings is an array of strings, not one big long
string.


Yes, it is an array of string pointers.


The patch does exactly the first part, but not the second. There is simply
no way to know when the user is done with the string, so it has to be
kept indefinitely. We could document the lifetime rules, but until then
there is no way to know when the message can be freed.


The documentation should say that this data is only valid until the 
next lt_* call, which is currently the case.



Yes, that is true. But that is not a new problem, just magnified by
increased usage of lt_dladderror.


It was essentially unused before since it was only used by a rarely 
used loader on OS-X.


This discussion should completely move to the patches list so I will 
delete the Cc: to the bugs list.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: ltdl .la file parsing (was: Coverage for libltdl/slist.c and fallout)

2009-12-08 Thread Bob Friesenhahn

On Tue, 8 Dec 2009, Ralf Wildenhues wrote:

interfaces.  For example, it is already known that the .la file
parser is fragile and trivial edits to an .la file will cause the
using program to core-dump.  The .la file parsing is an external
interface so it should get more priority.


Good idea.  Proposed patch.  What other things do you know about that
are mishandled?

OK to commit?


The fix and the tests look quite good and useful to me.  I don't 
currently know of other parsing issues.


As long as the application can trust that libltdl will search for .la 
files in secure locations, then there should not be great concern 
about corrupted .la files.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: Status update: pr-msvc-support branch

2009-11-25 Thread Bob Friesenhahn

On Wed, 25 Nov 2009, Peter Rosin wrote:


Today I have tested the pr-msvc-support branch on Linux
without noticing any regressions from master in the testsuite.
I have used debian testing (squeeze) since that's where
I found the required autotools versions.


I think that people are quite interested to hear about build 
performance differences.  Can you time execution of the test suite for 
both HEAD and pr-msvc-support branch and see what execution impact 
there may be?


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: Status update: pr-msvc-support branch

2009-11-25 Thread Bob Friesenhahn

On Wed, 25 Nov 2009, Peter Rosin wrote:


master again:

$ time make -k check
*snip*
real23m35.390s
user12m9.290s
sys 10m24.720s

This is in a VM on an XP box with some programs started but otherwise
doing nothing...


These results are good to see since there has been an expressed fear 
that the MSVC support might make other builds slower.  Of course the 
libtool test suite may not actually be a good test case since it 
really does not compile/link very much at all.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: Improve versioning algorithm description

2009-09-22 Thread Bob Friesenhahn

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

2009-08-22 Thread Bob Friesenhahn

On Sat, 22 Aug 2009, Ralf Wildenhues wrote:


Now, since most modern shells (except for dash, hello, Debian :-)
implement $LINENO support fairly well, I think there is little reason
to rely on this arcane way of expanding line numbers at configure script
generation time any more.  I thus propose this patch to remove them.

OK?


Yes, please.  This will be a welcome improvement for me.

Bob



Thanks,
Ralf

2009-08-20  Ralf Wildenhues  ralf.wildenh...@gmx.de

Remove __oline__ from macros, for less spurious configure diffs.
* libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK, _LT_COMPILER_OPTION)
(_LT_COMPILER_C_O, LT_PATH_NM): Replace __oline__ instances with
$LINENO.
* NEWS: Update.

diff --git a/NEWS b/NEWS
index be4dc4d..8666196 100644
--- a/NEWS
+++ b/NEWS
@@ -48,6 +48,8 @@ New in 2.2.8 2009-??-??: git version 2.2.7a, Libtool team:
  - Link mode works around a parallel build failure on Darwin 9.6.0 due
to the `ar' `flock'ing an archive upon extraction, by protecting the
extraction of convenience archives with a lock.
+  - The Libtool macro files do not contain instances of __oline__ any more,
+easing merges for configure scripts that are added to version control.

* Miscellaneous changes:

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index eebe990..7d4bc31 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1162,7 +1162,7 @@ ia64-*-hpux*)
  ;;
*-*-irix6*)
  # Find out which ABI we are using.
-  echo '[#]line __oline__ configure'  conftest.$ac_ext
+  echo '[#]line '$LINENO' configure'  conftest.$ac_ext
  if AC_TRY_EVAL(ac_compile); then
if test $lt_cv_prog_gnu_ld = yes; then
  case `/usr/bin/file conftest.$ac_objext` in
@@ -1351,11 +1351,11 @@ AC_CACHE_CHECK([$1], [$2],
   -e 's:.*FLAGS}\{0,1\} :$lt_compiler_flag :; t' \
   -e 's: [[^ ]]*conftest\.: $lt_compiler_flag:; t' \
   -e 's:$: $lt_compiler_flag:'`
-   (eval echo \\$as_me:__oline__: $lt_compile\ AS_MESSAGE_LOG_FD)
+   (eval echo \\$as_me:$LINENO: $lt_compile\ AS_MESSAGE_LOG_FD)
   (eval $lt_compile 2conftest.err)
   ac_status=$?
   cat conftest.err AS_MESSAGE_LOG_FD
-   echo $as_me:__oline__: \$? = $ac_status AS_MESSAGE_LOG_FD
+   echo $as_me:$LINENO: \$? = $ac_status AS_MESSAGE_LOG_FD
   if (exit $ac_status)  test -s $ac_outfile; then
 # The compiler can only warn and ignore the option if not recognized
 # So say no if there are warnings other than the usual output.
@@ -1821,11 +1821,11 @@ AC_CACHE_CHECK([if $compiler supports -c -o 
file.$ac_objext],
   -e 's:.*FLAGS}\{0,1\} :$lt_compiler_flag :; t' \
   -e 's: [[^ ]]*conftest\.: $lt_compiler_flag:; t' \
   -e 's:$: $lt_compiler_flag:'`
-   (eval echo \\$as_me:__oline__: $lt_compile\ AS_MESSAGE_LOG_FD)
+   (eval echo \\$as_me:$LINENO: $lt_compile\ AS_MESSAGE_LOG_FD)
   (eval $lt_compile 2out/conftest.err)
   ac_status=$?
   cat out/conftest.err AS_MESSAGE_LOG_FD
-   echo $as_me:__oline__: \$? = $ac_status AS_MESSAGE_LOG_FD
+   echo $as_me:$LINENO: \$? = $ac_status AS_MESSAGE_LOG_FD
   if (exit $ac_status)  test -s out/conftest2.$ac_objext
   then
 # The compiler can only warn and ignore the option if not recognized
@@ -3204,13 +3204,13 @@ _LT_DECL([], [NM], [1], [A BSD- or MS-compatible name 
lister])dnl
AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_nm_interface],
  [lt_cv_nm_interface=BSD nm
  echo int some_variable = 0;  conftest.$ac_ext
-  (eval echo \\$as_me:__oline__: $ac_compile\ AS_MESSAGE_LOG_FD)
+  (eval echo \\$as_me:$LINENO: $ac_compile\ AS_MESSAGE_LOG_FD)
  (eval $ac_compile 2conftest.err)
  cat conftest.err AS_MESSAGE_LOG_FD
-  (eval echo \\$as_me:__oline__: $NM \\\conftest.$ac_objext 
AS_MESSAGE_LOG_FD)
+  (eval echo \\$as_me:$LINENO: $NM \\\conftest.$ac_objext 
AS_MESSAGE_LOG_FD)
  (eval $NM \conftest.$ac_objext\ 2conftest.err  conftest.out)
  cat conftest.err AS_MESSAGE_LOG_FD
-  (eval echo \\$as_me:__oline__: output\ AS_MESSAGE_LOG_FD)
+  (eval echo \\$as_me:$LINENO: output\ AS_MESSAGE_LOG_FD)
  cat conftest.out AS_MESSAGE_LOG_FD
  if $GREP 'External.*some_variable' conftest.out  /dev/null; then
lt_cv_nm_interface=MS dumpbin




--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: [PATCH] [mingw] Improve sys_lib_search_path_spec detection.

2009-06-29 Thread Bob Friesenhahn

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

2009-04-22 Thread Bob Friesenhahn

On Wed, 22 Apr 2009, Christian Rössel wrote:


Ralf Wildenhues wrote:


First, please ensure that you have Autoconf 2.63 and Automake 1.10.2
installed somewhere (below the same --prefix) and found early in $PATH.


why do I need to install them below the *same* prefix. Is this a general
requirement? What will happen if I use distinct prefixes but put both
bindirs into my PATH?


Installation under the same prefix is necessary because the installed 
m4 files from the various packages share a directory and that is where 
aclocal looks for them.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: [PATCH] Improve compatibility with older automake

2009-03-29 Thread Bob Friesenhahn

On Sun, 29 Mar 2009, Charles Wilson wrote:


* libltdl/m4/lt~obsolete.m4: Add AC_DEFUNs for
_LT_PREPARE_SED_QUOTE_VARS and _LT_PROG_ECHO_BACKSLASH.
Report by Yaakov Selkowitz.

aclocal-1.8 and older fail:
aclocal: macro `_LT_PREPARE_SED_QUOTE_VARS' required but not defined
aclocal: macro `_LT_PROG_ECHO_BACKSLASH' required but not defined
autoreconf-2.63: aclocal failed with exit status: 1

Tested by running aclocal-1.8 successfully, but didn't do a full
bootstrap. Still, the fix seems obvious...okay to push?


Since the fix seems obvious, please do.

Bob




Chuck

---
libltdl/m4/lt~obsolete.m4 |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/libltdl/m4/lt~obsolete.m4 b/libltdl/m4/lt~obsolete.m4
index b60bbd2..5f6a956 100644
--- a/libltdl/m4/lt~obsolete.m4
+++ b/libltdl/m4/lt~obsolete.m4
@@ -92,3 +92,5 @@ m4_ifndef([AC_LIBTOOL_CONFIG],
[AC_DEFUN([AC_LIBTOOL_CONFIG])])
m4_ifndef([_LT_AC_FILE_LTDLL_C],[AC_DEFUN([_LT_AC_FILE_LTDLL_C])])
m4_ifndef([_LT_REQUIRED_DARWIN_CHECKS], 
[AC_DEFUN([_LT_REQUIRED_DARWIN_CHECKS])])
m4_ifndef([_LT_AC_PROG_CXXCPP], [AC_DEFUN([_LT_AC_PROG_CXXCPP])])
+m4_ifndef([_LT_PREPARE_SED_QUOTE_VARS],
[AC_DEFUN([_LT_PREPARE_SED_QUOTE_VARS])])
+m4_ifndef([_LT_PROG_ECHO_BACKSLASH],   [AC_DEFUN([_LT_PROG_ECHO_BACKSLASH])])
--
1.6.1.2





--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: [PATCH] Use correct export_dynamic_flag_spec for PE-COFF $hosts

2009-03-29 Thread Bob Friesenhahn

On Sun, 29 Mar 2009, Charles Wilson wrote:


* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin*|mingw*|pw32*|cegcc*]:
Define export_dynamic_flag_spec as -Wl,--export-all-symbols, as required
by GNU ld for PE-COFF.

Original patch by Yaakov Selkowitz. As he explained:

On Cygwin, the --export-all-symbols linker flag is required;
--export-dynamic has no effect
(see http://sourceware.org/bugzilla/show_bug.cgi?id=6744).

This patch fixes two problems:

(1) LT_SYS_DLOPEN_SELF returns a false negative;
(2) Using the -export-dynamic libtool flag does not affect the
  resulting binary.

Tested in combination with several other cygwin patches, as part of the
recent cygwin official 2.2.7a-N libtool release(s):
http://cygwin.com/ml/cygwin-announce/2009-03/msg00080.html
http://cygwin.com/ml/cygwin-announce/2009-03/msg00081.html

No regressions.  Okay to push?


If you are sure that --export-all-symbols will work with older (within 
reason) Cygwin and MinGW installs, then this seems ok to push.  I do 
see support for --export-all-symbols in my archaic MinGW install so 
the risk of problems seems low.


Bob


libltdl/m4/libtool.m4 |1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 477f6e3..15612c0 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4275,6 +4275,7 @@ _LT_EOF
  # _LT_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
  # as there is no search path for DLLs.
  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+  _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-all-symbols'
  _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
  _LT_TAGVAR(always_export_symbols, $1)=no
  _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
--
1.6.1.2





--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: [PATCH] [cygwin] Improve operation with gcc4

2009-03-29 Thread Bob Friesenhahn

On Sun, 29 Mar 2009, Charles Wilson wrote:


* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER) [cygwin*]:
Add w32api to sys_lib_search_path_spec without overriding gcc's
own search path.

Original patch by Yaakov Selkowitz. As he explained:

With gcc4 providing shared libs, it should now perfectly legitimate to
add any of these libs to the libtool link command.  Right now, though,
libtool can't find these libraries because $sys_lib_search_path_spec is
hard-coded to ignore it, and libtool will refuse to link against any
library it can't find (even though the linker itself can).

Instead, this patch simply adds /usr/lib/w32api to the default
gcc-specific search path.  The m4_if() makes sure that w32api is added
only once, as is done with Darwin a few lines later.

Tested in combination with several other cygwin patches, as part of the
recent cygwin official 2.2.7a-N libtool release(s):
http://cygwin.com/ml/cygwin-announce/2009-03/msg00080.html
http://cygwin.com/ml/cygwin-announce/2009-03/msg00081.html

No regressions.  Okay to push?


This change seems good to me.  Please push it.

I am looking forward to using Cygwin 1.7.

Bob



---
libltdl/m4/libtool.m4 |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 15612c0..63e831e 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2156,7 +2156,8 @@ cygwin* | mingw* | pw32* | cegcc*)
cygwin*)
  # Cygwin DLLs use 'cyg' prefix rather than 'lib'
  soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | 
$SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
-  sys_lib_search_path_spec=/usr/lib /lib/w32api /lib /usr/local/lib
+m4_if([$1], [],[
+  sys_lib_search_path_spec=$sys_lib_search_path_spec /usr/lib/w32api])
  ;;
mingw* | cegcc*)
  # MinGW DLLs use traditional 'lib' prefix
--
1.6.1.2





--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: Status of the MSYS/MSVC port

2009-01-29 Thread Bob Friesenhahn

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)

2009-01-24 Thread Bob Friesenhahn

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

2009-01-22 Thread Bob Friesenhahn

On Thu, 22 Jan 2009, Tim Rice wrote:


Or maybe it just seems so because those that want a change are those
that will speak up.
I prefer tabs. If I want the text in the 25th column it's just
3 tab keys and start typing. I don't have to count out pressing
the space bar 24 times and then wondering if it really was 24.
I find python code really annoying because it is spaces only.


Almost anyone will prefer tabs if they are the only ones working on 
the source code.  The problems occur when several/many people are 
working on shared source code using a variety of editors.



Can we agree to make the switch only after 2.2.8 though,
I would like to avoid unnecessary churn ATM.


I am in favor of instituting a rule that all new code and patch code 
should use spaces but that existing TABs can continue to exist until 
those specific regions of code are edited.  The formatting situation 
is not worse than now (we probably already have mixed spaces and tabs) 
and eventually the code will entirely use spaces.


Bob
==
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: [PATCH] Minor cygwin cleanup

2009-01-21 Thread Bob Friesenhahn

On Tue, 20 Jan 2009, Charles Wilson wrote:


libltdl/config/ltmain.m4sh (func_generate_dlsyms): Correct
case pattern for cygwin.
---
Ok to push?


Looks fine to me.

Bob



libltdl/config/ltmain.m4sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 6be529a..760f647 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1987,7 +1987,7 @@ extern \C\ {
  eval '$GREP -f $output_objdir/$outputname.exp  $nlist  
$nlistT'
  eval '$MV $nlistT $nlist'
  case $host in
-   *cygwin | *mingw* | *cegcc* )
+   *cygwin* | *mingw* | *cegcc* )
  eval echo EXPORTS ' $output_objdir/$outputname.def'
  eval 'cat $nlist  $output_objdir/$outputname.def'
  ;;
--
1.6.0.4





==
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: Run tests with low max_cmd_len on MSYS/MSVC

2009-01-21 Thread Bob Friesenhahn

On Wed, 21 Jan 2009, Ralf Wildenhues wrote:


We may need to think about speeding up func_to_host_path, e.g., by not
forking for arguments that don't need conversion, or by converting
several paths with a constant amount of forks.  But that can be done
separately.


There is also the possibility of building a translation cache which is 
preserved across libtool invokations.  The only concern is if the 
mounts get changed after the cache is generated.


Bob
==
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: spaces (was: Provide a means to activate dynamically the debug traces)

2009-01-19 Thread Bob Friesenhahn

On Mon, 19 Jan 2009, Akim Demaille wrote:

I have worked for years with the same set up as you, using an much TAB as is 
possible.  But I read someday something that Jim wrote about this topic, in 
which he was advocating the no-tab approach, and I was convinced.  What 
changed my viewpoint was that (i) Jim is in favor of it, so it's good :)  and 
(ii) because he did point out that it makes it really easier to discuss about 
code in emails.  It is true that I have been disturbed and even annoyed by 
tab vs. space in some patches that gave the impression of improper 
indentation.


Therefore, for a year or so, I am now using spaces only.


It is not necessary to use hard tabs.  They are a form of text 
compression which originated with anchient character terminals and 
typewriters.  Since many/most people have a habit of changing the 
meaning of TAB to something other than the standard 8 spaces, TAB 
causes a lot of formatting problems if TAB is used in conjunction with 
spaces.  Text editors have a very hard time agreeing on how to treat 
TAB and so when TAB is used, the text only appears correct for the 
person who wrote it.  For many years I have had my editor configured 
to always use spaces.  This ensures WYSIWYG for everyone involved.


Bob
==
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: set_program_name behavior

2009-01-19 Thread Bob Friesenhahn

On Mon, 19 Jan 2009, Ralf Wildenhues wrote:


Well,
 alias lgdb='libtool --mode=execute gdb'

is still shorter than what you suggest, but for reference, here's a
patch that does what you want.

What do the others think, should libtool be lenient here?  I don't have
a strong preference (sure don't mind), the requirement for a mode seems
to have been present for at least 10 years.


10 years already?  the only concern I can think of is if this blocks 
building the program called 'gdb', but hopefully it's build is already 
using --mode given the 10 years..



Aside, I am not quite sure whether it is portable (to other systems or
debugger versions) to assume that gdb will not be interactive when
started with stdin redirected to /dev/null.


This may be a valid concern for systems which do not support POSIX 
pty's or /dev/null (primarily Windows).


Bob
==
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: Rebase of the pr-msvc-support branch?

2009-01-09 Thread Bob Friesenhahn

On Fri, 9 Jan 2009, Ralf Wildenhues wrote:

Agreed, too; 2.2.8 soon would be good.  A couple of small issues need
looking at (esp. the aclocal.m4 messup reported by Akim).
Any volunteers for the release?


so that we can bite the bullet and integrate your branch into
mainline.


Agreed, too.  Them bullets sure taste rather bitter, though.  ;-)


Those of us who have been targeting Windows for many years have bitten 
many bitter bullets.  There is little doubt that my anticipated 
lifespan has already been reduced due to intense frustration 
associated with Windows.  It will solve a lot of problems if autotools 
can be used to build real Windows programs.


Bob
==
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: Rebase of the pr-msvc-support branch?

2009-01-08 Thread Bob Friesenhahn
Someone needs to cut the next libtool so that we can bite the bullet 
and integrate your branch into mainline.


Bob
==
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: [SCM] GNU Libtool branch, master, updated. v2.2.4-45-gc2b8636

2008-09-07 Thread Bob Friesenhahn

On Sun, 7 Sep 2008, Ralf Wildenhues wrote:



Why is Automake = 1.10.1 an issue though?  It's been around for
almost a year...


But some distros still have two-year latencies for stable - stable
releases.


Yes, and some stable users may take another two-years to update to the 
latest stable release. :-)


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: [SCM] GNU Libtool branch, master, updated. v2.2.4-45-gc2b8636

2008-09-07 Thread Bob Friesenhahn

On Mon, 8 Sep 2008, Gary V. Vaughan wrote:


How does one pull a release?  I don't think it is possible.


Replace the tarball with a message that says.  D'oh!  Sorry, this release was 
stillborn, please get this other one instead


The original tarball can be deleted from the official FSF site but it 
is likely already mirrored to a 1000 places which use various mirror 
rules.


Does FSF recommend 'a', 'b', 'c' notation for fixed releases, or does it 
recommend adding another decimal place?


Actually, I think they recommend 'a' suffix IIRC...


This is indeed a rather serious issue so I recommend creating a new 
release ASAP using the process that the FSF recommends for quick fix 
re-releases.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: Two small libltdl patches.

2008-08-24 Thread Bob Friesenhahn

On Sun, 24 Aug 2008, Charles Wilson wrote:


But wasn't there a thread back in June where we explicitly added a bunch
of argz functions, so that (a) we would be using the same file as
gnulib, and (b) that file would have a complete argz implementation?


I recall that it was decided that it was not necessary for the 
implementation to be identical to gnulib and that the code should not 
need to be updated unless it is found to be broken.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: Linking with '-L /path/to/lib' (note the space!)

2008-08-21 Thread Bob Friesenhahn

On Thu, 21 Aug 2008, Ralf Wildenhues wrote:

discover otherwise non-existing bugs somewhere else.


Well, libtool *could* also remove the space.  I'm just not sure whether
it's worth supporting this.


Removing the space might simply cause a failure later if it is an 
actual typo (like your test case).


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: [PATCH 370] Implement lt_dlopening of only preloaded modules.

2008-08-12 Thread Bob Friesenhahn

On Tue, 12 Aug 2008, Ralf Wildenhues wrote:


This patch causes a testsuite failure on GNU/Linux.


As a step toward stabilization, I would like to propose to revert the
above patch.  Its acceptance should rely on its test passing on at least
more than one of Darwin, MinGW, GNU/Linux, and AIX.  (Does it currently
pass on any of them?)

OK to revert?  Or, rather: does anybody have problems with the reversal?


Temporarily or permanently?

It seems that lt_dladvise_preload() is needed to allow ltdl to be more 
secure for applications which need it.  It should be ok to revert the 
patch temporarily so that the forthcoming release can be cut.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: [PATCH 370 bis] Implement lt_dlopening of only preloaded modules.

2008-06-18 Thread Bob Friesenhahn
 $LDFLAGS -o main main.$OBJEXT 
$preloaded $modules $LIBLTDL],

+[], [ignore], [ignore])
+
+# Remove loadable libpreload module, so we know it is the preloaded module
+# that is being executed by a successful test invocation:
+$LIBTOOL --mode=clean rm libpreload.la
+
+LT_AT_NOINST_EXEC_CHECK([./main], [$modules], [], [expout], [])
+
AT_CLEANUP
--
1.5.4.3





==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: argz whitespace

2008-05-20 Thread Bob Friesenhahn

On Tue, 20 May 2008, Eric Blake wrote:

Also, would anyone be interested in a patch that renames argz_.h to
argz.in.h to match gnulib?  Gnulib recently changed to avoid _ in file
names where possible, and these days, platforms that don't handle two . in
a file name are generally not worth porting to.
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=5155f7d


Isn't one of those platforms versions of Microsoft Windows?

What qualifies a platform as not being worth porting to?

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: argz whitespace

2008-05-20 Thread Bob Friesenhahn

On Tue, 20 May 2008, Eric Blake wrote:


According to Eric Blake on 5/20/2008 6:32 AM:
| Also, would anyone be interested in a patch that renames argz_.h to
| argz.in.h to match gnulib?  Gnulib recently changed to avoid _ in file
| names where possible, and these days, platforms that don't handle two . in
| a file name are generally not worth porting to.
| http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=5155f7d

Like so.  OK to apply?


There is a palpable cost to renaming libltdl/argz_.h and the cost 
should be carefully considered before renaming files.  Have you 
considered the cost?  What is the value behind this change and is the 
value obtained greater than the cumulative cost?


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: argz whitespace

2008-05-20 Thread Bob Friesenhahn

On Tue, 20 May 2008, Bob Friesenhahn wrote:


There is a palpable cost to renaming libltdl/argz_.h and the cost should be 
carefully considered before renaming files.  Have you considered the cost? 
What is the value behind this change and is the value obtained greater than 
the cumulative cost?


It comes to mind that perhaps the reason for the cost is not clear. 
This apparently minor change causes these issues:


* Template libltdl source code footprint changes.  This means that on 
a system where installed files are not precisely controlled by a 
package manager (so the prior version is completely uninstalled), 
after an upgrade, we are left with stale residue which remains for the 
rest of time.


* Every package using libltdl incorporates a copy of it.  These copies 
are maintained in version control systems.  The maintainer of the 
package needs to notice the change (unlikely since it is unexpected) 
so that the new name can be added, and the old name removed. 
Eventually the problem will be noticed, but only after it has caused 
some harm. Currently packages using libltdl offer to install the 
packaged version so there is opportunity for even more churn.


Now that libtool 2.2 is out the door we need to be conservative about 
file additions, removals, and renames in libltdl.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: argz whitespace

2008-05-20 Thread Bob Friesenhahn

On Tue, 20 May 2008, Eric Blake wrote:

| What qualifies a platform as not being worth porting to?

It's somewhat subjective.  The gnulib mailing list has come up with an
ad-hoc definition of any platform released within the last 3-5 years, and
preferably where the vendor has not declared the platform end-of-life,
while also supporting older platforms where the vendor is still actively
providing support.  So, as an example, Solaris 4 and Windows 95 are
generally not viable porting targets (their vendors no longer support


Clearly these are not suitable rules for libtool.  Autoconf and 
libtool need to be dicated by whether the features they need to 
execute are present (might require augmentation such as replacement 
compiler and shell), and not how old the target is, or if its 
manufacturer still cares about it.


I am quite certain that Solaris 2.4 is a solid POSIX-compliant OS 
which is capable of performing useful tasks today just as it did when 
it was released.  It does not have POSIX threads, but it has most 
other useful Unix things that we enjoy today.  Some Y2K and 
daylight-savings bugs may be present but this is not necessarily cause 
to throw the hardware away.


To me, a 5 year old system has reached middle age and a 3 year old 
system is practically new.  Ten years is senior citizen and should 
seek retirement.


Regardless, we should not be changing the libtool 2.2.X install 
footprint for the sake of change.  There should be a good reason.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: --with-included-ltdl infers --enable-ltdl-convenience

2008-05-06 Thread Bob Friesenhahn

On Tue, 6 May 2008, Ralf Wildenhues wrote:

This patch shuts up the warning about --enable-ltdl-convenience
(I suppose the fact that you write --with-included-ltdl in the paragraph
is a typo, as you use the correct one in the Subject:).  However, it


I don't believe that it is a typo since if --with-included-ltdl is 
supplied, then the configure script also sets 
--enable-ltdl-convenience to yes and this is inserted into the 
config.status file as a supplied option so that it is applied later.


The --enable-ltdl-convenience option was in development libtool 2.X 
for almost four years.



also exposes the flag to the user (via ./configure --help).  I'm not
sure whether that is a good idea.  What do you think?


It is perhaps not a great thing since it is now a secondary 
(non-dominant) option.  In fact, I noticed that 
--enable-ltdl-convenience is 'yes' even if libltdl is being built as a 
shared library for formal installation.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: [Patch] cwrapper invokes target directly

2008-04-30 Thread Bob Friesenhahn

On Tue, 29 Apr 2008, Charles Wilson wrote:


If I can get some feedback on the '*_with_wine.sh' script I could update the 
patch to also support $build=some_unixy_platform_with_wine and $host=mingw.


I have a MinGW cross-compiler hosted off of FreeBSD 7.0.  Presumably I 
can run Wine on it.  I know that Linux has special hooks in order to 
automatically run Windows executables using Wine.  Is the Wine 
execution support dependent on this Linux feature?


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: libltdl and cygwin 1.7.0

2008-04-30 Thread Bob Friesenhahn

On Wed, 30 Apr 2008, Eric Blake wrote:


Cygwin 1.7.0 will change the size of MAX_PATH in its headers, but the old
cygwin_conv_to_* API silently suffers from buffer overrun if more than 256
bytes occur in the conversion.  As a result, cygwin developers wisely
deprecated the old API when adding the new cygwin_path_conv, and compilation
now issues a warning (which in turn cripples -Werror builds):

libltdl/loaders/loadlibrary.c: In function `vm_open':
libltdl/loaders/loadlibrary.c:147: warning: `cygwin_conv_to_full_win32_path' is
deprecated (declared at /usr/include/sys/cygwin.h:52)
make[2]: *** [libltdl/loaders/loadlibrary.lo] Error 1

OK to apply?


This looks good to apply to me except for the minor nit that the 
bracing indentation within the HAVE_DECL_CYGWIN_CONV_PATH is wrong 
(and should be corrected).



-#if defined(__CYGWIN__)
+#if HAVE_DECL_CYGWIN_CONV_PATH
+  if (cygwin_conv_path (CCP_POSIX_TO_WIN_A, filename, wpath, MAX_PATH))
+{
+ LT__SETERROR (CANNOT_OPEN);
+ return 0;
+   }
+  len = 0;


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





Re: [PATCH 368] New libtoolize --no-warn option.

2008-04-29 Thread Bob Friesenhahn

On Tue, 29 Apr 2008, Gary V. Vaughan wrote:


I hope this will allay Ralf's concerns for users who want to stick
with deprecated macro interfaces, and don't want libtoolize to nag
them to upgrade.

Okay to commit?


The immediate concern I have with this approach (--no-warn) is that 
the main reason for using it is to make use of a package's 
autogen.sh (or whatever) more pleasing.  However, since old 
libtoolize does not support the option, it is likely to simply quit. 
As a result, --no-warn can not safely be used if it is possible that 
some developers are using old libtoolize while others are using modern 
libtoolize.  That makes it almost worthless.


This is one rare case where providing the option via an evironment 
variable is safer.  Then the many autogen.sh can set an environment 
variable to hush the warnings.  Did you consider that?


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/





  1   2   3   >