Re: strang dual-architecture problem under OS X

[Peter O'Gorman]

On Mar 2, 2014, at 8:48 PM, Werner LEMBERG  wrote:

> 
> Some weeks ago I wrote:
> 
>> I've now found out that it *is* a libtool problem:
>> 
>>>  libtool: link: \
>>>(cd 
>>> /Users/wl/harfbuzz-0.9.26/src/.libs/libharfbuzz.lax/libhb-ucdn.a/unfat-91266/libhb-ucdn.a-i386
>>>  \
>>> && ar x "libhb-ucdn.a")
>>>  libtool: link: \
>>>(cd 
>>> /Users/wl/harfbuzz-0.9.26/src/.libs/libharfbuzz.lax/libhb-ucdn.a/unfat-91266/libhb-ucdn.a-x86_64
>>>  \
>>> && ar x "libhb-ucdn.a")
>>>  find: warning: \
>>>Unix filenames usually don't contain slashes (though pathnames do). \
>>>That means that '-name `unfat-91266/libhb-ucdn.a-i386/ucdn.o'' \
>>>will probably evaluate to false all the time on this system. ...
>> 
>> This warning message caused by this line in `libtool', in function
>> `func_extract_archives':
>> 
>>  darwin_files=`find unfat-$$ -name $darwin_file -print | sort | $NL2SP`
>> 
>> It searches for file names in the directory `unfat-$$'.  However, if
>> the value of `foo_LIBADD' contains a subdirectory, as in
>> 
>>  libharfbuzz_la_LIBADD = hb-ucdn/libhb-ucdn.la
>> 
>> this fails, since `$darwin_file' now contains something with slashes.
> 
> Is there anyone on the list who could confirm the analysis, or
> probably even fix it in libtool in case the analysis is correct?

I think your analysis is probably correct. If you have a patch that’d be 
awesome.

Peter


> 
> 
>Werner
> 
> ___
> https://lists.gnu.org/mailman/listinfo/libtool


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: static linking problem on Mac OS X Lion

[Peter O'Gorman]

[I replied to Werner without copying the list by mistake. Here is the 
reply.]


On 03/23/2012 09:50 AM, Werner LEMBERG wrote:

I get this link command together with the error message.

/bin/sh ../libtool \
--tag=CXX \
--mode=link \
g++ -pipe -O2


Please add a --debug after the ../libtool and send me the log of
stderr and stdout.


Attached.


Looks like Qt's faked up .la files have -framework flags in 
dependency_libs, remove them and it might work.


Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: make check and LD_LIBRARY_PATH

[Peter O'Gorman]

On 03/23/2012 06:40 AM, Christian Egli wrote:


libtool --mode=execute -dlopen ../liblouis/liblouis.la -n python $(TEST_SCRIPT)

What is the drawback of just setting LD_LIBRARY_PATH in
TESTS_ENVIRONMENT?


Not all systems use LD_LIBRARY_PATH. You can find the variable that 
libtool sets by checking the value of its $shlibpath_var, or you could 
just set all of:
LIBPATH, LD_LIBRARY_PATH, PATH, DYLD_LIBRARY_PATH, LIBRARY_PATH, 
SHLIB_PATH, LD_LIBRARY64_PATH, LD_LIBRARYN32_PATH, LD_LIBRARY_PATH_32, 
LD_LIBRARY_PATH_64


Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: static linking problem on Mac OS X Lion

[Peter O'Gorman]

Hi,

On 03/23/2012 07:58 AM, Werner LEMBERG wrote:


I have a problem with libtool on Mac OS X Lion, trying to link
statically to (a statically compiled version of) Qt.  Saying

   make LDFLAGS="-all-static" V=1

I get this link command together with the error message.

/bin/sh ../libtool \
   --tag=CXX \
   --mode=link \
   g++ -pipe -O2


Please add a --debug after the ../libtool and send me the log of stderr 
and stdout.


There are no static versions of any of the system frameworks or 
libSystem, etc., so -all-static isn't going to do anything different to 
-static-libtool-libs, afaik.


Thanks,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: LD_LIBRARY_PATH - disappear of libdir after patch

[Peter O'Gorman]

Hi Paul,

On 03/16/2012 12:35 PM, Paul Seidler wrote:


I think I've got it:
libtool.m4 @@ -2195,16 +2195,16 @@



+  lt_fooi  = "";
should be
+  lt_foo = "";
?


I think we you a beer.

Thank you very much.

I pushed this.

Peter
>From fbe09b44b5052273fe79ea24365c554a5d54d8ce Mon Sep 17 00:00:00 2001
From: Peter O'Gorman 
Date: Fri, 16 Mar 2012 13:23:13 -0500
Subject: [PATCH] Fix typo that caused sys_lib_search_path_spec to be wrong.

* m4/libtool.m4: s/lt_fooi/lt_foo/.
Reported by Paul Seidler 
---
 m4/libtool.m4 |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index e07ae4a..75bfdb4 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2201,7 +2201,7 @@ if test yes = "$GCC"; then
   done
   lt_search_path_spec=`$ECHO "$lt_tmp_lt_search_path_spec" | awk '
 BEGIN {RS = " "; FS = "/|\n";} {
-  lt_fooi  = "";
+  lt_foo = "";
   lt_count = 0;
   for (lt_i = NF; lt_i > 0; lt_i--) {
 if ($lt_i != "" && $lt_i != ".") {
-- 
1.7.4.4

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: LD_LIBRARY_PATH - disappear of libdir after patch

[Peter O'Gorman]

Hi Paul,

On 03/12/2012 10:47 AM, Paul Seidler wrote:

Hello,

running the test suite of eina-1.1 with 1.0 installed and
libtool-2.4{.2,} the tests will fail (symbol lookup errors) because of
the LD_LIBRARY_PATH (same with glib, gst-plugins-base, ...). The libdir
is in front of the "test-path":
LD_LIBRARY_PATH="/usr/lib64:/home/sepek/dev/eina-1.1.0/src/lib/.libs:
$LD_LIBRARY_PATH"

I don't get this with newer libtool versions (from git), "/usr/lib64:"
is no more in LD_LIBRARY_PATH. I traced it down to
06c6555d4a77a5e91f43da3451586534da93e0ae. With a cherry-picked version
everything works fine (with 2.4.2) but if I understand the complete
message correct it shouldn't affect the functionality of libtool?! At
least the tests of libtool throw no error.

So my Question: Is this behavior intentional?


That particular patch wasn't supposed to have changed anything, all it's 
meant to have done is remove quoting where it's not needed.


/usr/lib64 appearing in LD_LIBRARY_PATH is because libtool is brain dead 
in its detection of "system" library locations. Most vendors have 
patched their libtools to work around this, e.g.:


http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob;f=libtool-2.2.10-rpath.patch;h=d0d6d82178642658e6aca5a28d36813158980ca3;hb=HEAD

Perhaps somehow libtool.m4 bits of your vendor patched libtool are 
getting used?


Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool error reporting.

[Peter O'Gorman]

I pushed this, sorry for the long delay, and thank you.

Peter

On 01/09/2012 08:38 AM, Shamis, Pavel wrote:

Peter,

Did you have a chance to look at the patch. Please let me know if you have some 
comments.
I found it extremely useful for debug of module component architecture, that loads 
modules on the "fly".

Regards,

Pavel (Pasha) Shamis
---
Application Performance Tools Group
Computer Science and Math Division
Oak Ridge National Laboratory






On Dec 8, 2011, at 11:09 AM, Shamis, Pavel wrote:


Peter,

Actually, I already have a patch. Please see attached file. It is very simple, if module 
opening fails, in addition to "Failed" message, it prints out last error 
message.
So far it is only a spot where I found useful to add verbose error reporting.



Regards,

Pavel (Pasha) Shamis
---
Application Performance Tools Group
Computer Science and Math Division
Oak Ridge National Laboratory

On Dec 8, 2011, at 12:19 AM, Peter O'Gorman wrote:


On 12/05/2011 11:48 AM, Shamis, Pavel wrote:

Hi,

As have been mentioned on the list, libtool error reporting - "file not found" is not 
perfect. People suggested to fix it (hxxp://www.mail-archive.com/libtool@gnu.org/msg12156.html) but 
it seems, that the changes have never been incorporated into the trunk. I'm not well familiar with 
all the details of the problem, but I would suggest to improve the debug mode (-DLT_DEBUG_LOADERS) 
verbose messaging. Libtool already prints "Success/Failed", so I suggest to extend the 
message and  print out the last error (LT__GETERROR(error)) for the Failed case.


This seems like a good idea (if DEBUG_LOADERS is defined, print the
error to stderr every time an error is set). If you don't come up with a
patch, I'll try to find the time to do it.

Thanks,
Peter




___
hxxps://lists.gnu.org/mailman/listinfo/libtool





___
https://lists.gnu.org/mailman/listinfo/libtool

Re: The case of libkmod's .so versioning attempts, and induced collisions

[Peter O'Gorman]

On 02/07/2012 07:06 PM, Lucas De Marchi wrote:


Yes. We can always learn. It seems that this is not the case here.
There are other projects releasing like this and no one pointed out to
a reasonable argument against it. That means these arguments are not
valid in our case:


Again, use -version-number a:b:c to get libfoo.so.a.b.c instead of 
screwing around with the calculations yourself and using -version-info.


This flag is available since libtool-1.5.x and was added by the 
freedesktop.org folks, iirc, to retain version number information when 
they moved to the autotools.


Using this flag should satisfy all involved.

Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: The case of libkmod's .so versioning attempts, and induced collisions

[Peter O'Gorman]

On 02/06/2012 06:35 PM, Jan Engelhardt wrote:

Much to my disappointment, I found that the newly-released libkmod v5
has made the following non-trivial change to its source tree, the latter
of which I want to bring to attention:

commit e479598b7d19ae7be45bf5329d6e4df32d646c16
diff --git a/Makefile.am b/Makefile.am
index 69ab986..172d2ff 100644
--- a/Makefile.am
+++ b/Makefile.am
-LIBKMOD_CURRENT=4
+LIBKMOD_CURRENT=2
 LIBKMOD_REVISION=0
-LIBKMOD_AGE=3
+LIBKMOD_AGE=0


It doesn't really make sense to use libtool at all in this situation, 
there is no portability requirement. Perhaps -version-number instead of 
-version-info would make their lives easier as it does the calculations 
for them.


Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool mishandling of C++ libraries requiring -pthread

[Peter O'Gorman]

On 02/01/2012 05:49 PM, Bob Friesenhahn wrote:


The libltdl module loader does need to load the dependency libraries
since the system might not do this at all, or might not do it fully or
correctly. It can't do this without knowing the libraries used. This has
been known to be a definite factor for C-language modules which link
with C++ libraries.

If Gary is reading this, I assume that his memory would be better than
mine and perhaps he can add some wisdom.


Note that the GCC maintainters closed the bug requesting -pthread still
add -lpthread even under -nostdlib as invalid.


I would have done the same.

The easiest fix is likely for libtool to know that if -pthread was
specified to the compiler that it should add -lthread while linking.


Well, I don't know why libtool insists on -nostdlib, but I think we 
should just give up on it and assume the compiler works.


If g++ creates output on any platform that is unable to find libstdc++ 
at runtime then that is a broken compiler, in my opinion.


It's easier by far to stop trying to second guess the compiler than 
adding more complications (translating -pthread to whatever the threads 
library is).


Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: dlopen, DESTDIR, library dependencies and "cannot install" error

[Peter O'Gorman]

On 01/09/2012 09:31 AM, Diab Jerius wrote:


make DESTDIR=/home/dj/stage prefix=/rbtree-1.0.9 exec_prefix=/rbtree-1.0.9/x86 
install

The resultant file hierarchy is shallower:

/home/dj/stage
/home/dj/stage/rbtree-1.0.9
/home/dj/stage/rbtree-1.0.9/x86
/home/dj/stage/rbtree-1.0.9/x86/lib
/home/dj/stage/rbtree-1.0.9/x86/lib/pkgconfig
/home/dj/stage/rbtree-1.0.9/include
/home/dj/stage/rbtree-1.0.9/include/rbtree

and works well with the graft program.

In the context of my original question vis-a-vis libtool, I've been
using this approach for many years with a large number of distributions
which use libtool and have never had libtool refuse to install a library
into the staging area.


I'm sorry, but what you're doing isn't supported, even though it worked 
for you previously with libraries that did not require relinking.


I can only suggest make install DESTDIR=... ; and then mv the subdirs 
you want.


Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: dlopen, DESTDIR, library dependencies and "cannot install" error

[Peter O'Gorman]

On 01/09/2012 08:50 AM, Diab Jerius wrote:

On Sat, 2012-01-07 at 13:31 -0600, Bob Friesenhahn wrote:

On Fri, 6 Jan 2012, Diab Jerius wrote:


and the installation is performed via

make AM_MAKEFLAGS="DESTDIR=/proj/axaf/simul/pkgs prefix=/lua_udunits2-0.1.2_01 
exec_prefix=/lua_udunits2-0.1.2_01/x86_64-linux_debian-5.0" install




Why do you need to change prefix and exec_prefix at make install time? 
Just use DESTDIR alone and it should work.


Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Several questions about libtool

[Peter O'Gorman]

On 01/06/2012 12:31 PM, Peter O'Gorman wrote:

On 01/06/2012 11:21 AM, Stepan Kasal wrote:


1) .la file always contains the recursively evaluated list of libraries.
While this is necessary for static linking and dumb dynamic linkers,
it is an issue for dyn. linkers that can do recursive resolution
(which is the case on GNU/Linux distributions for many years).
(I believe that the rule that forbids packing .la files to -dev and
-devel subpackages on Debian and Fedora (respectively), is there just
to work around this problem.)


This is still an issue, libtool always adds all dependencies. Many
packages assume this and don't explicitly add required dependencies to
Makefile.am etc. I don't recall the arguments for not changing this when
building shared. IIRC Scott tried to include Debian's patch at some
point. I'll look it up in the archives later.


http://lists.gnu.org/archive/html/libtool/2004-11/msg00455.html

http://lists.gnu.org/archive/html/libtool/2004-12/msg00259.html

http://lists.gnu.org/archive/html/libtool/2004-12/msg00029.html

http://lists.gnu.org/archive/html/libtool/2007-09/msg00017.html

And from you, no response given:

http://lists.gnu.org/archive/html/libtool/2008-01/msg3.html

Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Several questions about libtool

[Peter O'Gorman]

On 01/06/2012 11:21 AM, Stepan Kasal wrote:


1) .la file always contains the recursively evaluated list of libraries.
While this is necessary for static linking and dumb dynamic linkers,
it is an issue for dyn. linkers that can do recursive resolution
(which is the case on GNU/Linux distributions for many years).
(I believe that the rule that forbids packing .la files to -dev and
-devel subpackages on Debian and Fedora (respectively), is there just
to work around this problem.)


This is still an issue, libtool always adds all dependencies. Many 
packages assume this and don't explicitly add required dependencies to 
Makefile.am etc. I don't recall the arguments for not changing this when 
building shared. IIRC Scott tried to include Debian's patch at some 
point. I'll look it up in the archives later.




2) People told me libtool is slow and shell has to parse huge script
just to find out that it has to call gcc twice, with and without
-fPIC.  Again, this is not about the general portability case, it is
a request for optimization on GNU/Linux platform, that they percepts
as one of the major customers of libtool.


Libtool is faster than it used to be, the shell does have to parse quite 
a bit of script, but compile mode has been moved as close to the 
beginning of the script as possible to reduce that time, and the number 
of forks has been reduced drastically for modern shells. I believe dash 
and ksh93 are faster than bash at running libtool. Last time I checked, 
libtool's compile mode wasn't significantly slower than using dolt 
(http://dolt.freedesktop.org/).




3) Does it happen often in practice that a project builds both -fPIC
and non-pic objects, even though only one of them is going to be
used?  If yes, and if it is because of a mistake on package
maintainer's side, can something be done about it?  (warnings, changed
defaults, autodetection in automake)


Perhaps the default should be --enable-shared --disable-static? It's 
worth considering.


Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Fwd: http://www.gnu.org/software/libtool/future.html is outdated

[Peter O'Gorman]

Hi Max,

Thanks, I did as you suggested and removed future.html.

Peter

On 12/21/2011 10:30 AM, Max Horn wrote:

Hi Peter,

I tried two times now to send the following email to webmast...@www.gnu.org, but the address seems 
to be dead and not accepting any delivery; after several days, each with a "timeout, trying 
again", I finally got a "retry timeout exceeded".

Anyway, since I know that you are (were?) involved with libtool development, I 
thought you might know a different way to deliver the message below to whoever 
it might be suitable for :).

Cheers,
Max

Anfang der weitergeleiteten E-Mail:


Von: Max Horn
Datum: 18. Dezember 2011 16:52:44 MEZ
An: webmast...@www.gnu.org
Betreff: http://www.gnu.org/software/libtool/future.html is outdated

Dear webmasters of www.gnu.org,

as per the instructions at the bottom 
of, I am emailing you -- if 
this the wrong address, I'd appreciate if you could let me know whom else to contact 
about this matter.

The page  in questions is heavily 
outdated. It talks about "future" developments of libtool, and with that means 1.5 
and 1.6. But as you probably know, version 2.4.2 is the latest.

I guess it might be easiest to simply delete that page, unless some libtool 
developers would like to update it with current content?

Best wishes,
Max





___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool, rpath, and libGL.so

[Peter O'Gorman]

On 11/29/2011 11:48 PM, Adam Mercer wrote:

On Mon, Nov 28, 2011 at 23:30, Andy Spencer  wrote:


This seems to be caused by libtool adding a -rpath flag which forces the
application to use the /usr/lib64 version provided by mesa even though
ld.so.conf has been properly configured to use the nvidia version.


I raised this question a week or so ago and the workaround suggested was to set:

lt_cv_sys_lib_dlsearch_path_spec="/lib64 /usr/lib64"


Does anyone want to try again?

http://lists.gnu.org/archive/html/libtool-patches/2010-11/msg00027.html

I only have red hat like distros, so if someone could update the patch 
and look at other distros that'd be great.


Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool error reporting.

[Peter O'Gorman]

On 12/05/2011 11:48 AM, Shamis, Pavel wrote:

Hi,

As have been mentioned on the list, libtool error reporting - "file not found" is not 
perfect. People suggested to fix it (http://www.mail-archive.com/libtool@gnu.org/msg12156.html) but 
it seems, that the changes have never been incorporated into the trunk. I'm not well familiar with 
all the details of the problem, but I would suggest to improve the debug mode (-DLT_DEBUG_LOADERS) 
verbose messaging. Libtool already prints "Success/Failed", so I suggest to extend the 
message and  print out the last error (LT__GETERROR(error)) for the Failed case.


This seems like a good idea (if DEBUG_LOADERS is defined, print the 
error to stderr every time an error is set). If you don't come up with a 
patch, I'll try to find the time to do it.


Thanks,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Local function in shared object?

[Peter O'Gorman]

On 12/07/2011 11:45 AM, Mark R Bannister wrote:

Hi,

I wonder if someone could point out my error. I've defined a function,
nothing special, takes a couple of args and returns a pointer to a
structure.

The function is not declared with any special keywords. It is not static.

Yet, when compiled with gcc on Solaris and a .so target is built with
libtool, the function is reported by nm as LOCAL, instead of GLOBAL.
Why? Other functions in the project come out as GLOBAL. If I run nm
against the .o file in .libs the function is GLOBAL. So the linker is
obviously deciding when building the .so that this particular function
must be LOCAL.

As I'm not using the static keyword, I don't understand why this could
be happening. What am I missing?


Hi,

How is the .so being created? Is a linker script or libtool's export 
symbols flags being used?


Peter



___
https://lists.gnu.org/mailman/listinfo/libtool

daily snapshot broken again

[Peter O'Gorman]

Hi,

Looks like there was no daily snapshot for a couple of weeks because the 
script was doing (the apparently naive):

git pull
./bootstrap
./configure
make
make distcheck

and the gnulib submodule never got updated, so bootstrap failed with:
  top/README-release
  top/maint.mk
2 out of 2 hunks FAILED -- saving rejects to file 
/tmp/glI22454/gitlog-to-changelog.rej
gnulib/gnulib-tool: *** patch file gl/build-aux/gitlog-to-changelog.diff 
didn't apply cleanly

gnulib/gnulib-tool: *** Stop.

I just manually did cd libtool/gnulib; git pull to "fix" it, but it 
seems like something is broken somewhere if git pull; ./bootstrap does 
not do the right thing.


Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: linking problems on SL6

[Peter O'Gorman]

On 11/22/2011 11:36 PM, Adam Mercer wrote:

On Mon, Nov 21, 2011 at 15:39, Peter O'Gorman  wrote:


Glad it works around it. The problem is libtool brokenness, most vendors
patch around it in their packaged libtool, e.g.

http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob;f=libtool-2.2.10-rpath.patch;h=d0d6d82178642658e6aca5a28d36813158980ca3;hb=HEAD


Is there any reason something like this isn't done in the source so
vendors don't have to patch? Apart from it being a hack that is :-)


I'm not sure if we ever looked for what distros use what layout for 
multilibs, and how to detect them.


There was a patch somewere which was slow, but ended up correct, using 
ldconfig. I'll look for it again.


Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: linking problems on SL6

[Peter O'Gorman]

On 11/21/2011 03:22 PM, Adam Mercer wrote:

Setting lt_cv_sys_lib_dlsearch_path_spec="/lib64 /usr/lib64" at
configure time results in "-Wl,-rpath -Wl,/usr/lib64" not being passed
and the correct libraries linked. So this is a workaround but I'd like
to understand why these flags are being added in the first place.


Glad it works around it. The problem is libtool brokenness, most vendors 
patch around it in their packaged libtool, e.g.


http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob;f=libtool-2.2.10-rpath.patch;h=d0d6d82178642658e6aca5a28d36813158980ca3;hb=HEAD

Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: linking problems on SL6

[Peter O'Gorman]

Hi,

On 11/19/2011 01:03 AM, Adam Mercer wrote:

Hi

In building a development snapshot of one of my projects, to a custom
path, on SL6 I am running into what appears to be a linking problem.
The libtool command used to link the library is as follows:

libtool: link: gcc -std=gnu99 -shared  -fPIC -DPIC .libs/Aggregation.o
.libs/FrameCache.o .libs/FrameCalibration.o .libs/FrameData.o
.libs/FrameSeries.o .libs/FrameStream.o .libs/LALFrameIO.o
.libs/LALFrameVCSInfo.o .libs/LowLatencyData.o -Wl,-rpath
-Wl,/usr/lib64 -Wl,-rpath
-Wl,/usr1/ram/lalsuite/lal/packages/support/src/.libs -Wl,-rpath
-Wl,/usr1/ram/lalsuite/lal/lib/.libs -Wl,-rpath -Wl,/usr/lib64
-Wl,-rpath -Wl,/home/ram/lalsuite/lib64 /usr/lib64/libFrame.so
../../lal/packages/support/src/.libs/liblalsupport.so -lz
../../lal/lib/.libs/liblal.so -lgsl -lgslcblas -lfftw3 -lfftw3f -lm
-O2   -Wl,-soname -Wl,liblalframe.so.0 -o .libs/liblalframe.so.0.2.0


Are these -Wl,-rpath flags coming from libtool? They seem to be there 
already on the libtool command line. Could you post this snippet of your 
makefile.am, please?




The problem is that there is the current release version, installed
from the release RPM, in /usr and because of the "-Wl,-rpath
-Wl,/usr/lib64" on the link line this older version is getting picked
up in preference to the more recent development version in
/home/ram/lalsuite. Why would libtool be passing /usr/lib64 to the
compiler? On Debian Squeeze, using the same git tag, the build
succeeds so I am led to believe that this is an issue with the
autotools on SL6 but I'm not sure where to start looking. Has any got
any suggestions?


Libtool has issues with multilib systems. Someone had a patch at some 
point that correctly figured out the multilib library paths using 
ldconfig, but I've long forgotten who. You can set 
lt_cv_sys_lib_dlsearch_path_spec and lt_cv_sys_lib_search_path_spec at 
configure time if libtool is getting 
sys_lib_dlsearch_path_spec/sys_lib_search_path_spec wrong (check the 
generated libtool script for ^sys_lib_dlsearch_path_spec and 
^sys_lib_search_path_spec to see what it's guessing).


Debian/Red Hat systems do multilib differently, one has lib32 and lib, 
the other lib and lib64, I wouldn't be surprised if someone has a linux 
system with lib32 lib and lib64 (like IRIX!).


Peter




___
https://lists.gnu.org/mailman/listinfo/libtool

Re: [gnu.org #701121] Duplicate content?

[Peter O'Gorman via RT]

On 10/24/2011 01:54 PM, Peter O'Gorman wrote:
> On 10/24/2011 11:05 AM, Jason Self via RT wrote:

>> Hello libtool maintainers, just forwarding the above feedback to you for
>> your consideration. Perhaps one option might be linking to the GNU Emacs
>> manual instead of maintaining an independent copy?
>
> Do we control this? Using curl I see it redirect with a 301:

Never mind, ".symlinks" controls this. These are there for a reason:
http://lists.gnu.org/archive/html/libtool/2011-04/msg4.html

Peter




___
https://lists.gnu.org/mailman/listinfo/libtool

Re: [gnu.org #701121] Duplicate content?

[Peter O'Gorman via RT]

On 10/24/2011 11:05 AM, Jason Self via RT wrote:
> Josh wrote:
>> Hi,
>>
>> I search the Emacs manual using Google's "site:" operator. For example:
>>
>> http://www.google.com/search?q=site:www.gnu.org/software/emacs+EXAMPLE
>>
>> I've been noticing that pages in the manual don't always show up in the
>> search results when I use this method. For example, when I search the
>> manual for "refill", the Refill page doesn't show up:
>>
>> http://www.google.com/search?q=site:www.gnu.org/software/emacs+refill
>>
>> I think this may be due to the fact that the Emacs manual is shown via
>> multiple distinct URLs, which Google perceives as duplicate content:
>>
>> http://www.gnu.org/software/emacs/manual/html_node/emacs/
>> http://www.gnu.org/software/libtool/manual/emacs/
>>
>> Here's an article that addresses the problem of duplicate content:
>>
>> http://www.google.com/support/webmasters/bin/answer.py?answer=66359
>>
>> Thanks for maintaining gnu.org. It's one of the most useful sites on the
>> web.
>>
>> Take care,
>> Josh
>
> Hello libtool maintainers, just forwarding the above feedback to you for
> your consideration. Perhaps one option might be linking to the GNU Emacs
> manual instead of maintaining an independent copy?

Do we control this? Using curl I see it redirect with a 301:

* Connected to www.gnu.org (140.186.70.148) port 80 (#0)
 > GET /software/libtool/manual/emacs HTTP/1.1
 > User-Agent: curl/7.21.0 (x86_64-redhat-linux-gnu) libcurl/7.21.0 
NSS/3.12.10.0 zlib/1.2.5 libidn/1.18 libssh2/1.2.4
 > Host: www.gnu.org
 > Accept: */*
 >
< HTTP/1.1 301 Moved Permanently
< Date: Mon, 24 Oct 2011 18:51:19 GMT
< Server: Apache/2.2.14
< Location: http://www.gnu.org/software/emacs/manual/html_node/emacs/
< Cache-Control: max-age=0
< Expires: Mon, 24 Oct 2011 18:51:19 GMT
< Vary: Accept-Encoding
< Content-Length: 333
< Content-Type: text/html; charset=iso-8859-1

I don't see 'emacs' in libtool's web cvs:

http://web.cvs.savannah.gnu.org/viewvc/libtool/manual/?root=libtool

Peter






___
https://lists.gnu.org/mailman/listinfo/libtool

Re: [gnu.org #701121] Duplicate content?

[Peter O'Gorman]

On 10/24/2011 11:05 AM, Jason Self via RT wrote:

Josh wrote:

Hi,

I search the Emacs manual using Google's "site:" operator. For example:

http://www.google.com/search?q=site:www.gnu.org/software/emacs+EXAMPLE

I've been noticing that pages in the manual don't always show up in the
search results when I use this method. For example, when I search the
manual for "refill", the Refill page doesn't show up:

http://www.google.com/search?q=site:www.gnu.org/software/emacs+refill

I think this may be due to the fact that the Emacs manual is shown via
multiple distinct URLs, which Google perceives as duplicate content:

http://www.gnu.org/software/emacs/manual/html_node/emacs/
http://www.gnu.org/software/libtool/manual/emacs/

Here's an article that addresses the problem of duplicate content:

http://www.google.com/support/webmasters/bin/answer.py?answer=66359

Thanks for maintaining gnu.org. It's one of the most useful sites on the
web.

Take care,
Josh


Hello libtool maintainers, just forwarding the above feedback to you for
your consideration. Perhaps one option might be linking to the GNU Emacs
manual instead of maintaining an independent copy?


Do we control this? Using curl I see it redirect with a 301:

* Connected to www.gnu.org (140.186.70.148) port 80 (#0)
> GET /software/libtool/manual/emacs HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-redhat-linux-gnu) libcurl/7.21.0 
NSS/3.12.10.0 zlib/1.2.5 libidn/1.18 libssh2/1.2.4

> Host: www.gnu.org
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Mon, 24 Oct 2011 18:51:19 GMT
< Server: Apache/2.2.14
< Location: http://www.gnu.org/software/emacs/manual/html_node/emacs/
< Cache-Control: max-age=0
< Expires: Mon, 24 Oct 2011 18:51:19 GMT
< Vary: Accept-Encoding
< Content-Length: 333
< Content-Type: text/html; charset=iso-8859-1

I don't see 'emacs' in libtool's web cvs:

http://web.cvs.savannah.gnu.org/viewvc/libtool/manual/?root=libtool

Peter



___
https://lists.gnu.org/mailman/listinfo/libtool

Re: potential linking issue with Xcode-4.2 on Lion

[Peter O'Gorman]

On 10/17/2011 05:02 PM, Adam Mercer wrote:

On Mon, Oct 17, 2011 at 16:40, Peter O'Gorman  wrote:

Peter


Does it work if you remove -mmacosx-version-min=10.4?


That resulted in the same error, but your idea led me to remove each
flag one by one and it turns out that the insane optimization level
that was being used is the culprit. Removing this flag results in a
successful build.


Great, please file a radar with apple for it.

Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: potential linking issue with Xcode-4.2 on Lion

[Peter O'Gorman]

On 10/17/2011 01:48 PM, Adam Mercer wrote:

Hi

I testing some software I maintain using the recently release
Xcode-4.2 on Mac OS X 10.7.2, and am running into the follow error
during link:



Hi,

Does it work if you remove -mmacosx-version-min=10.4?

Peter



/bin/sh ../../../libtool  --tag=CC   --mode=link gcc -std=gnu99  -g
-O2 -g3 -O4 -Wall -W -Wmissing-prototypes -Wstrict-prototypes -Wshadow
-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -fno-common
-Wnested-externs -Wno-format-zero-length -fno-strict-aliasing -Werror
-mmacosx-version-min=10.4 -version-info 0:0:0  -o liblalsupport.la
-rpath /opt/lscsoft/lal/lib Audio.lo ConfigFile.lo FileIO.lo
LALCache.lo LALInitBarycenter.lo LALMath3DPlot.lo LALMathNDPlot.lo
LogPrintf.lo PrintFrequencySeries.lo PrintTimeSeries.lo PrintVector.lo
ReadFiltersFile.lo ReadFrequencySeries.lo ReadTimeSeries.lo
ReadNoiseSpectrum.lo SegmentsIO.lo StreamSeriesInput.lo
StreamSeriesOutput.lo StreamSequenceInput.lo StreamGridInput.lo
StreamGridOutput.lo StreamVectorInput.lo StreamVectorSequenceInput.lo
UserInput.lo getopt.lo getopt1.lo -lz -lfftw3 -lfftw3f -lgsl
-lgslcblas -lm  -L/opt/local/lib -lgsl -lgslcblas -lm
-L/opt/local/lib -lfftw3 -lfftw3f -lm
libtool: link: gcc -std=gnu99 -dynamiclib -Wl,-undefined
-Wl,dynamic_lookup -o .libs/liblalsupport.0.dylib  .libs/Audio.o
.libs/ConfigFile.o .libs/FileIO.o .libs/LALCache.o
.libs/LALInitBarycenter.o .libs/LALMath3DPlot.o .libs/LALMathNDPlot.o
.libs/LogPrintf.o .libs/PrintFrequencySeries.o .libs/PrintTimeSeries.o
.libs/PrintVector.o .libs/ReadFiltersFile.o
.libs/ReadFrequencySeries.o .libs/ReadTimeSeries.o
.libs/ReadNoiseSpectrum.o .libs/SegmentsIO.o .libs/StreamSeriesInput.o
.libs/StreamSeriesOutput.o .libs/StreamSequenceInput.o
.libs/StreamGridInput.o .libs/StreamGridOutput.o
.libs/StreamVectorInput.o .libs/StreamVectorSequenceInput.o
.libs/UserInput.o .libs/getopt.o .libs/getopt1.o   -lz
-L/opt/local/lib /opt/local/lib/libgsl.dylib
/opt/local/lib/libgslcblas.dylib /opt/local/lib/libfftw3.dylib
/opt/local/lib/libfftw3f.dylib -lm  -O2 -O4 -mmacosx-version-min=10.4
  -install_name  /opt/lscsoft/lal/lib/liblalsupport.0.dylib
-compatibility_version 1 -current_version 1.0 -Wl,-single_module
ld: in .libs/Audio.o, could not parse object file .libs/Audio.o:
Malformed metadata record for architecture x86_64

the compiler being used is:

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2336.1.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$

A brief Googling on the error suggests configuring with the
--build=x86_64 option, this allows the build to proceed a little
further but then another source files fails to link with the same
error.

Could this potentially be some kind of libtool issue, i.e. it not
being passed the appropriate options, or not knowing about this
compiler.

Any suggestions on how to debug this further?

Cheers

Adam

___
https://lists.gnu.org/mailman/listinfo/libtool




___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Help needed to build shared library with libtool

[Peter O'Gorman]

On 10/14/2011 08:45 AM, David Aldrich wrote:

Hi Peter

Thanks for your reply.

-shared is not a libtool flag


Oh, that's weird! We've been using that option for building other shared 
libraries for a long time.


Yes, and older libtools used to pass it along to the compiler driver, so 
on systems using gcc/g++ or where the compiler accepted the -shared flag 
to create a shared library it would work.





does it work if you do:

libtool --mode=link g++ -o libGUI.la  -rpath /usr/local/lib



That doesn't work, but the result is different:

libtool --mode=link g++ -o libGUI.la   -rpath /usr/local/lib 
-rpath /usr/lib64 -L/usr/lib64 -pthread   -L/usr/lib64   -lwx_gtk2u_richtext-2.8 
-lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 
-lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 
-lwx_baseu-2.8  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 
-lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig 
-lgobject-2.0 -lgmodule-2.0 -lglib-2.0

*** Warning: Linking the shared library libGUI.la against the non-libtool
*** objects  is not portable!


Your object files are created without using libtool?


ln: creating symbolic link `libGUI.so.0': Operation not supported
make: *** [libGUI.so] Error 1


That's a new one for me, you snipped the ln command that fails though.

I don't know how much you care about portability, if you aren't worried 
about it (previously your Makefile with older libtool would only create 
working shared libraries with compilers that understand -shared and 
where the shared library extension is .so), then you may be better off 
not using libtool at all, and just doing

g++ -shared -o libGUI.so 

That does exclude Windows, Mac OS X, HP-UX, though, just on the ".so".

Peter




___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Help needed to build shared library with libtool

[Peter O'Gorman]

On 10/14/2011 02:10 AM, David Aldrich wrote:

Hi

I am using libtool in a makefile to create a shared library containing my 
application code, which also links to wxWidgets libraries.  As a consequence of 
changing both platform (including gcc version) and wxWidgets packages, my 
makefile ceases to work.  It seems that the libtool command is trying to make a 
static, rather than a shared library.  I don't understand libtool well enough 
to fix the problem and would be grateful of some help.  Although I have 
mentioned wxWidgets, I am inclined to think that it is more appropriate to ask 
help from the libtool community than the wxWidgets community.

Here is the failing command:

libtool --mode=link g++ -shared -o libGUI.so   -rpath 
/usr/local/lib


-shared is not a libtool flag, does it work if you do:

libtool --mode=link g++ -o libGUI.la  -rpath /usr/local/lib

?

Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Shared library versioning

[Peter O'Gorman]

On 06/14/2011 11:26 AM, Lasse Collin wrote:

On 2011-06-14 Bob Friesenhahn wrote:

On Tue, 14 Jun 2011, Lasse Collin wrote:

Please read the section "Understanding shared libraries
number rules" (it's short):

http://www.openbsd.org/faq/ports/specialtopics.html


If this web page text is correct, then I agree that libtool is doing
the wrong thing for OpenBSD.  But of course we should search for any
additional information and consult with relevant OpenBSD maintainers
before making any such change since FAQ text could easily be wrong.


The FAQ is correct. Talking with maintainers can still be good, of
course.



Changing versioning schemes is "hard". It will break binary 
compatibility for anyone who has built software themselves outside of 
ports etc.


Before doing this I'd really want to get input from the various BSD folks.

Thanks,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: What makes a convenience library (use --whole-archive)?

[Peter O'Gorman]

On 06/07/2011 08:07 PM, Michael Poole wrote:

Some of the files in my convenience libraries have static
initializers.  By default, the linker discards these symbols because
they are not referenced.  I am trying to figure out how to keep them
in an automake-driven build.

Mailing list threads I have seen on the Internet, plus the "libtool"
script code (as of version 2.2.6b), indicate that convenience
libraries should be linked with -Wl,--whole-archive (or the
equivalent).  I do not see that here.


Yes, when convenience libraries are used to create a shared library, all 
the objects are included in the output, when the output is an 
application they are used like a normal archive library.


Either use them to create a shared library or, if creating an 
application, don't use them, use the objects instead.


Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: why does libtool strip my -lm away on mingw32 builds?

[Peter O'Gorman]

On 04/27/2011 07:25 AM, Ed Hartnett wrote:

Howdy all!


Hi Ed,



Recently I managed to get my C library building and testing cleanly on
Linux for windows, using mingw32 and wine. This is the greatest idea
since sliced bread. (In fact, I would rather live without sliced bread!)



I am building it like this:
./configure -C --disable-dap --disable-netcdf-4 --disable-fortran --disable-cxx 
--build=x86_64-unknown-linux-gnu --host=i686-mingw32&&  make -j check

When it builds in the nc_test directory, there is a program (nc_test)
which needs to link to the math library. I have AC_CHECK_LIB(m) in the
configure.ac, so the math library has been found and added to LIBS. But
libtool strips it away!

As I read the above, when make calles libtool, it has the -lm, but when
libtool calls gcc, the -lm is missing.

Any idea what I might be doing wrong here?


It's explicitly removed -

   if test "X$arg" = "X-lc" || test "X$arg" = "X-lm"; then
  case $host in
  *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-beos* | *-cegcc* | 
*-*-haiku*)
# These systems don't actually have a C or math library (as 
such)

continue
;;

I don't know what library you need for floor() on mingw, maybe mingwex?

Perhaps try
AC_SEARCH_LIBS([floor],[m minbgwex])

But you'd probably be better waiting for someone who actually has a clue 
about mingw to answer :)


Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: shared library problem on macos with free software scientific package...

[Peter O'Gorman]

On 01/31/2011 11:21 AM, Ed Hartnett wrote:

Peter O'Gorman  writes:



/usr/bin/libtool: unknown option character `f' in: -force_load
Usage: /usr/bin/libtool -static [-] file [...] [-filelist
  listfile[,dirname]] [-arch_only arch] [-sacLT]
Usage: /usr/bin/libtool -dynamic [-] file [...] [-filelist
  listfile[,dirname]] [-arch_only arch] [-o output] [-install_name
  name] [-compatibility_version #] [-current_version #] [-seg1addr
  0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#]
  [-seg_addr_table] [-seg_addr_table_filename
  ] [-all_load] [-noall_load]
make[2]: *** [libnetcdff.la] Error 1
make[1]: *** [check] Error 2
make: *** [check-recursive] Error 1





To work around this you can set lt_cv_ld_force_load=no when you
configure netcdf on Mac OS X.



I tried this, but it seems to have no effect...


Please attach the output of ./libtool --config

Thanks,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: RFC: on AIX, which "soname"-equivalent to prefer with runtime linking?

[Peter O'Gorman]

On 01/21/2011 08:19 AM, Michael Haubenwallner wrote:

Hello!


Hi.

Library versioning for AIX would be a great feature.



After playing around with different ways[1], this is my proposed one,
using an AIX feature called "Import Files":

*) Create the shared object "shr.o" (using '-G' linker flag).
*) Set the LOADONLY flag for "shr.o" (using 'strip -e').
*) Create the Import File "shr.imp", containing
- this header:
#! libNAME.so.1(shr.o)
# autoload
#! libNAME.so.1(shr.o)
- the list of symbols exported.
*) Create the archive library "libNAME.so.1.2.3" from both
"shr.imp" and "shr.o".
*) Create the symlinks as usual:
libNAME.so.1 ->  libNAME.so.1.2.3
libNAME.so ->  libNAME.so.1.2.3

Using this way, for existing packages it might be necessary to give the
package manager the choice whether to "--enable-aix-soname", or to keep
the old way the package used to create "libNAME.so" before.


If I upgrade a library from say version 1.2.3 to 1.2.5, with both having 
the same libtool version information, but with 1.2.3 linked with the 
current -brtl libtool system, and 1.2.5 using your proposed method, will 
clients of the library still work?




The reasons to choose this way:

*) It is possible to dlopen() with or without a version number:
- dlopen("libNAME.so(shr.o)", RTLD_MEMBER), besides the preferred
- dlopen("libNAME.so.1(shr.o)", RTLD_MEMBER), and even
- dlopen("libNAME.so.1.2.3(shr.o)", RTLD_MEMBER) does work.


Does dlopen("libNAME.so", RTLD_GLOBAL|RTLD_NOW) (for example) without 
RTLD_MEMBER work?


Do you currently have patches for libtool, or do you want pre-approval 
before working on them? If you have any, even if only half finished, I 
would like to see them.


Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: shared library problem on macos with free software scientific package...

[Peter O'Gorman]

On 01/07/2011 06:30 AM, Ed Hartnett wrote:


libtool: link: g95 -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
 .libs/libnetcdff.0.dylib  .libs/fort-attio.o .libs/fort-control.o
 .libs/fort-dim.o .libs/fort-genatt.o .libs/fort-geninq.o
 .libs/fort-genvar.o .libs/fort-lib.o .libs/fort-misc.o
 .libs/fort-v2compat.o .libs/fort-vario.o .libs/fort-var1io.o
 .libs/fort-varaio.o .libs/fort-varmio.o .libs/fort-varsio.o
 -Wl,-force_load,../f90/.libs/libnetcdff90.a  -lz -lcurl  -m32
 -install_name
 /machine/netcdf/nc_test_51783/in1/lib/libnetcdff.0.dylib
 -compatibility_version 1 -current_version 1.0 -Wl,-single_module
/usr/bin/libtool: unknown option character `f' in: -force_load
Usage: /usr/bin/libtool -static [-] file [...] [-filelist
 listfile[,dirname]] [-arch_only arch] [-sacLT]
Usage: /usr/bin/libtool -dynamic [-] file [...] [-filelist
 listfile[,dirname]] [-arch_only arch] [-o output] [-install_name
 name] [-compatibility_version #] [-current_version #] [-seg1addr
 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#]
 [-seg_addr_table] [-seg_addr_table_filename
 ] [-all_load] [-noall_load]
make[2]: *** [libnetcdff.la] Error 1
make[1]: *** [check] Error 2
make: *** [check-recursive] Error 1

Am I doing something wrong here?


No, you're not ... g95/GNU libtool is. Modern GCCs on Mac OS X do not 
use /usr/bin/libtool to create shared libraries, they use ld, for that 
reason, when -force_load was added to ld in 10.6, it was not also added 
to /usr/bin/libtool, so even though the link would be ok with, for 
example, gfortran, it is not ok with your g95.


To work around this you can set lt_cv_ld_force_load=no when you 
configure netcdf on Mac OS X.


It would be best if this were fixed in g95 too.

I will look into a fix for libtool. This reminds me that I got another 
report about -force_load months and months ago, I should probably fix 
that too.


Peter


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Peter O'Gorman]

On 12/20/2010 10:54 AM, Bruce Korb wrote:



If the default build is 64 bit, why does it make sense that the
default library directory is the 32 bit library?


Because the user may not be building for multiple architectures, in 
which case a default of $prefix/lib for libdir makes perfect sense and 
causes no problems. For example, even though /usr/local/lib64 exists on 
my CentOS system, it is empty, /usr/local/lib is not, but contains only 
64bit libs.


Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Peter O'Gorman]

On 12/17/2010 02:59 PM, Peter O'Gorman wrote:

On 12/17/2010 11:09 AM, Nelson H. F. Beebe wrote:


I normally do builds on the AMD64 platforms with something like this
(at a minimum):

env LDFLAGS='-L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64' ./configure
make all check
make install libdir=/usr/local/lib64

It does no good to specify libdir in the env of the configure run,
because it does not propagate to the Makefile.



Hi Nelson, Bruce,

I think this is the issue, by configuring without setting libdir and
then changing it at make install time, libtool gets confused, and builds
libraries .la files etc with the configure time setting of libdir.

I haven't had a problem with setting --libdir at configure time and then
running make && make install, do you perhaps recall what packages gave
you issues with this?


Oh, I misread again, just for a change :( I don't think setting libdir 
in the environment at configure time is supposed to work, it needs to be 
passed as a configure argument, for example:


./configure --libdir=/usr/local/lib64

Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Peter O'Gorman]

On 12/17/2010 11:09 AM, Nelson H. F. Beebe wrote:


I normally do builds on the AMD64 platforms with something like this
(at a minimum):

env LDFLAGS='-L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64' ./configure
make all check
make install libdir=/usr/local/lib64

It does no good to specify libdir in the env of the configure run,
because it does not propagate to the Makefile.



Hi Nelson, Bruce,

I think this is the issue, by configuring without setting libdir and 
then changing it at make install time, libtool gets confused, and builds 
libraries .la files etc with the configure time setting of libdir.


I haven't had a problem with setting --libdir at configure time and then 
running make && make install, do you perhaps recall what packages gave 
you issues with this?


Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool and CUDA

[Peter O'Gorman]

On 12/06/2010 03:25 PM, Ralf Wildenhues wrote:


Where do you see that?  As far as I understand, Paweł hasn't actually
tried configuring Libtool with something like


Yeah, I failed to read your entire email this morning, definitely didn't 
have enough coffee. It makes sense now :)


We have some compilers with whitespace in lt_prog_compiler_pic, I assume 
nvcc doesn't run on those platforms?


Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool and CUDA

[Peter O'Gorman]

On 12/06/2010 01:07 AM, Ralf Wildenhues wrote:

OK to apply?


Unless Pawel reports that it works for him, no. This doesn't make
sense to me.




Hi Ralf,


Why?


Well, perhaps I haven't been drinking enough coffee, but...





_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker '


This assignment didn't work, or was overwritten later.


-  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC'


So, why will this make any difference?


+  if test -n "$_LT_TAGVAR(lt_prog_compiler_pic, $1)"; then
+_LT_TAGVAR(lt_prog_compiler_pic, $1)="-Xcompiler 
$_LT_TAGVAR(lt_prog_compiler_pic, $1)"
+  fi


Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool and CUDA

[Peter O'Gorman]

On 12/05/2010 09:34 PM, Ralf Wildenhues wrote:


Does this patch fix things for you?  As far as I see, you should be
getting -fPIC passed instead of -fno-common, so it's not completely
clear that this is right, or what other changes MacPorts has done to
their glibtool code over upstream Libtool.  Please also send 'glibtool
--config' output.

OK to apply?


Unless Pawel reports that it works for him, no. This doesn't make sense 
to me.


MacPorts doesn't appear to have patched their libtool at all:
http://trac.macports.org/browser/trunk/dports/devel/libtool/Portfile

Peter


_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker '
-  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC'
+  if test -n "$_LT_TAGVAR(lt_prog_compiler_pic, $1)"; then
+_LT_TAGVAR(lt_prog_compiler_pic, $1)="-Xcompiler 
$_LT_TAGVAR(lt_prog_compiler_pic, $1)"
+  fi




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: [RFC] [PATCH] libltdl error reporting

[Peter O'Gorman]

On 06/14/2010 04:41 PM, Peter O'Gorman wrote:


dlopen nonexisting file
dlopen existing file
check dlerror()


Ok, systems that return an error in this case:

Solaris, AIX, HPUX/IA64, FreeBSD

systems that don't return an error:
HP-UX/HPPA, Tru64 5.1, IRIX 6.5, linux/glibc, Mac OS X.

Whee.

Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

test coverage

[Peter O'Gorman]

I just tried to figure out lcov, and ran the testsuite with --coverage.

http://pogma.com/lcov/libltdl/index.html

I'll try at some stage to automate the process and do it weekly or so.

Peter


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: [RFC] [PATCH] libltdl error reporting

[Peter O'Gorman]

On 06/10/2010 12:33 AM, Peter O'Gorman wrote:


At least glibc and Mac OS X reset the dlerror() string to NULL every
time a dl*() api is called (I will check what other systems do in the
next few days). This is so programmers can do:


Sigh, but FreeBSD doesn't.

dlopen nonexisting file
dlopen existing file
check dlerror()

Says 'Cannot open "nonexisting file"' on FreeBSD (null with glibc and 
Mac OS X).


Oh well, will be interesting to see what other systems to.

Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: [RFC] [PATCH] libltdl error reporting

[Peter O'Gorman]

On 06/10/2010 02:28 PM, Bob Friesenhahn wrote:

On Thu, 10 Jun 2010, Peter O'Gorman wrote:


As I am sure many are aware, libltdl's error reporting is pretty dumb,
lt_dlerror() regularly reports things like "file not found" where the
actual problem might be something completely different, and a
reasonable error string may be readily available from dlerror().


As we have known for quite a while now, libltdl's error reporting is not
sane. For example, the preloader always issues a useless error ("file
not found") when preloading is not used for the module. Since the
loaders were nicely modularized, each loader is tried in turn (issuing
an error on failure) until a loader is successful, or there are no more
loaders. This is perhaps worse on OS-X where there are two OS APIs for
loading modules. I think that some improvements were made, but
functionality is still lacking.


The patch that I attached should solve most of those issues. On Mac OS 
X, the dyld loader is not built if dlopen is available, if I remember 
correctly.


Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rewrite of ltdl and c++ (was: Re: [RFC] [PATCH] libltdl error reporting)

[Peter O'Gorman]

On 06/10/2010 09:45 AM, Gary V. Vaughan wrote:



I think it would be better in c++.


No, that would mean you have to jump through hoops to use it from C.
And it would make me cry myself to sleep at night.  I avoid C++, Perl,
McDonalds and suicide bomber recruiters as much as I possibly can. I'm
still undecided as to which one is worst for your health...



It's simple to write a library in C++ but make its public interface C. 
There are many projects that use what I would describe as sane C++ 
(unfortunately there are also many that use every possible feature).


IMO, setjmp/longjmp is significantly uglier.

But, let's end this debate, it's unlikely to lead to anything productive :)

Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: [RFC] [PATCH] libltdl error reporting

[Peter O'Gorman]

Aside: I'm leaning away from upholding the
'drop-in-with-minimum-edits' philosophy for my rewrite, since the
dlfcn.h API seems like a pretty bad design to me.  After all, all
people really need to do is call functions with a known name and
known signature which happen to be in another library. I'm seriously
contemplating using a *much* smaller and cleaner API, which ends up
with client code more along the lines of:


With that as a starting point, it's easy enough to maintain an error
stack in an exception struct that wraps around setjmp/longjmp, and to



plus some glue to make catching an error thrown from libltdl2 and for
unwinding the error stack inside it as easy as possible.  WDYT?


I think it would be better in c++. I am unsure that a rewrite is 
necessary though.


Peter


___
http://lists.gnu.org/mailman/listinfo/libtool

[RFC] [PATCH] libltdl error reporting

[Peter O'Gorman]

Hi,

As I am sure many are aware, libltdl's error reporting is pretty dumb, 
lt_dlerror() regularly reports things like "file not found" where the 
actual problem might be something completely different, and a reasonable 
error string may be readily available from dlerror().


When I looked at the manual, and read the description for lt_dlerror() I 
saw "Return a human readable string describing the most recent error 
that occurred from any of libltdl's functions. Return NULL if no errors 
have occurred since initialization or since it was last called." and I 
thought "Well, that's stupid - that's not what dlerror() does". So, I 
went to see what POSIX says - it's also wrong - 
http://www.opengroup.org/onlinepubs/9699919799/functions/dlerror.html, I 
will file a bug with them later.


At least glibc and Mac OS X reset the dlerror() string to NULL every 
time a dl*() api is called (I will check what other systems do in the 
next few days). This is so programmers can do:


 .
 dlsym(handle, "foo");
 if ((err = dlerror()) != NULL) printf(stderr,"dlsym error: %s\n",err);
 ...

without dlerror() returning some other error that occurred long before 
the call to dlsym().


Unfortunately, it looks like libltdl attempts to save error state across 
calls to lt_*() functions, and generally does not do it well.


This patch resets the error every time a public ltdl function is called, 
and when setting an error tests if it is already set and doesn't 
overwrite it if it is. The fist error "wins".


The patch is fairly simple, and undoubtedly still imperfect, but test 
results are good, one test required a small patch to stop segfaulting, 
another should have unexpectedly passed, but doesn't, I think it is 
another error in the test, but haven't looked too closely yet.


If something like this does get in, I'd prefer to not change the libltld 
soname, I don't believe better error reporting will cause client 
applications to break. I could be wrong, of course :)


Patch attached (or course, a final patch will have to change the manual 
as well) - thoughts?


Peter
diff --git a/libltdl/libltdl/lt__private.h b/libltdl/libltdl/lt__private.h
index f4c4a3d..84f5622 100644
--- a/libltdl/libltdl/lt__private.h
+++ b/libltdl/libltdl/lt__private.h
@@ -138,7 +138,10 @@ struct lt__advise {
 
 #define LT__GETERROR(lvalue)	  (lvalue) = lt__get_last_error()
 #define LT__SETERRORSTR(errormsg) lt__set_last_error(errormsg)
-#define LT__SETERROR(errorcode)	  LT__SETERRORSTR(LT__STRERROR(errorcode))
+#define LT__SETERROR(errorcode)   if (0 == lt__get_last_error()) \
+	LT__SETERRORSTR(LT__STRERROR(errorcode))
+#define LT__RESETERROR(x)	  lt__set_last_error(0)
+#define LT__FORCEERROR(errorstr)  LT__SETERRORSTR(errorstr)
 
 LT_SCOPE const char *lt__error_string	(int errorcode);
 LT_SCOPE const char *lt__get_last_error	(void);
diff --git a/libltdl/loaders/preopen.c b/libltdl/loaders/preopen.c
index 7149287..58464ca 100644
--- a/libltdl/loaders/preopen.c
+++ b/libltdl/loaders/preopen.c
@@ -293,6 +293,7 @@ int
 lt_dlpreload_default (const lt_dlsymlist *preloaded)
 {
   default_preloaded_symbols = preloaded;
+  LT__RESETERROR ();
   return 0;
 }
 
@@ -303,6 +304,7 @@ int
 lt_dlpreload (const lt_dlsymlist *preloaded)
 {
   int errors = 0;
+  LT__RESETERROR ();
 
   if (preloaded)
 {
@@ -331,6 +333,7 @@ lt_dlpreload_open (const char *originator, lt_dlpreload_callback_func *func)
   symlist_chain *list;
   int		 errors = 0;
   int		 found  = 0;
+  LT__RESETERROR ();
 
   /* For each symlist in the chain...  */
   for (list = preloaded_symlists; list; list = list->next)
diff --git a/libltdl/ltdl.c b/libltdl/ltdl.c
index e1b4e2f..098effa 100644
--- a/libltdl/ltdl.c
+++ b/libltdl/ltdl.c
@@ -216,6 +216,8 @@ int
 lt_dlinit (void)
 {
   int	errors	= 0;
+  const char* saved_error = 0;
+  LT__RESETERROR ();
 
   /* Initialize only at first call. */
   if (++initialized == 1)
@@ -232,6 +234,7 @@ lt_dlinit (void)
   /* Now open all the preloaded module loaders, so the application
 	 can use _them_ to lt_dlopen its own modules.  */
 #ifdef HAVE_LIBDLLOADER
+  LT__GETERROR(saved_error);
   if (!errors)
 	{
 	  errors += lt_dlpreload (preloaded_symbols);
@@ -241,6 +244,7 @@ lt_dlinit (void)
 	{
 	  errors += lt_dlpreload_open (LT_STR(LTDLOPEN), loader_init_callback);
 	}
+  LT__FORCEERROR(saved_error);
 #endif /* HAVE_LIBDLLOADER */
 }
 
@@ -258,6 +262,7 @@ lt_dlexit (void)
   lt_dlloader *loader   = 0;
   lt_dlhandle  handle   = handles;
   int	   errors   = 0;
+  LT__RESETERROR ();
 
   if (!initialized)
 {
@@ -359,7 +364,6 @@ tryall_dlopen (lt_dlhandle *phandle, const char *filename,
 	   lt_dladvise advise, const lt_dlvtable *vtable)
 {
   lt_dlhandle	handle		= handles;
-  const char *	saved_error	= 0;
   int		errors		= 0;
 
 #ifdef LT_DEBUG_LOADERS
@@ -368,7 +372,6 @@ tryall_dlopen (lt_dlhandle *phandle, const char *filename,
 	   vtable ? vtable->name : "(ALL)");
 #endif
 
-  LT__GETERROR 

Re: use of shrext_cmds on mac os x (fwd)

[Peter O'Gorman]

On 04/23/2010 01:30 PM, Vincent Torri wrote:
> 
> 
> -- Forwarded message --
> Date: Fri, 23 Apr 2010 12:27:27 -0600
> From: Eric Blake 
> To: Vincent Torri 
> Cc: autoc...@gnu.org
> Subject: Re: use of shrext_cmds on mac os x
> 
> On 04/23/2010 12:09 PM, Vincent Torri wrote:
>>
>> Hey,
>>
>> on mac os x, shrext_cmds is defined like that:
>>
>> shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
> 
> Wrong list.  shrext_cmds is defined by libtool, so you may have better
> luck asking your question there.
> 

Are you asking a question here? I think I already gave the answer:

module=yes
eval loadable_shrext=$shrext_cmds
module=no
eval linkable_shrext=$shrext_cmds

Peter


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: module name on mac os x

[Peter O'Gorman]

On 04/22/2010 12:01 AM, Vincent Torri wrote:
> 
> 
> On Wed, 21 Apr 2010, Peter O'Gorman wrote:
> 
>> On 04/21/2010 04:00 PM, Vincent Torri wrote:
>>>
>>> Hey,
>>>
>>> A guy mentioned that problem: on mac os x, a "standard" shared lib has
>>> suffix name .dylib:
>>>
>>> lib_LTLIBRARIES = libfoo.la  --> libfoo.dylib
>>>
>>> but with a "module":
>>>
>>> pkg_LTLIBRARIES = bar.la
>>> bar_la_LDFLAGS = -module -avoid-version
>>>
>>> then the name is bar.so and not bar.dylib
>>>
>>> Is it a known behavior ? If so, is it a bug ?
>>
>> Yes, it is known, no, it is not a bug.
> 
>  linux windows   mac
> libsodll dylib
> module sodll so
> 
> mac is the only system where the module has a different name than a lib.
> Why ? That complicates things for nothing (we use shrext_cmds variable
> in autoconf as suffix of files that are dlopened).


Mostly for historical reasons, when Apple first introduced Mac OS X, it
did not have dlopen() and could not open shared libraries at runtime,
only modules. Since most modules had the .so extension, it was decided
that runtime loadable modules should have the extension .so, but shared
libraries, in order to be found by the static linker, have the extension
.dylib.

Now, the static linker will look for libfoo.dylib, libfoo.so (though
this is not documented) and libfoo.a when it sees -lfoo, that was not
always the case. Now the dynamic linker can load both MH_DYLIB and
MH_BUNDLE file types, that was not always the case either.

You can tell at configure time which extension will be used by:

module=yes
eval loadable_shrext=$shrext_cmds
module=no
eval linkable_shrext=$shrext_cmds

or so.

Peter


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: module name on mac os x

[Peter O'Gorman]

On 04/21/2010 04:00 PM, Vincent Torri wrote:
> 
> Hey,
> 
> A guy mentioned that problem: on mac os x, a "standard" shared lib has
> suffix name .dylib:
> 
> lib_LTLIBRARIES = libfoo.la  --> libfoo.dylib
> 
> but with a "module":
> 
> pkg_LTLIBRARIES = bar.la
> bar_la_LDFLAGS = -module -avoid-version
> 
> then the name is bar.so and not bar.dylib
> 
> Is it a known behavior ? If so, is it a bug ?

Yes, it is known, no, it is not a bug.

Peter


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: genarating map files for libraries

[Peter O'Gorman]

On Mon, Jan 25, 2010 at 08:44:12AM -0800, Prokash Sinha wrote:
> First very sorry for the delayed response.
> 
> If I do this in the Makefile.in  then I don't get any error and it also does
> not produce the map file.
> 
> ##$(LINK) -Wl,-map,libbuffer.map  -rpath $(libdir) $(libbuffer_la_LDFLAGS)
> $(libbuffer_la_OBJECTS) $(libbuffer_la_LIBADD) $(LIBS)
> libbuffer.la: $(libbuffer_la_OBJECTS) $(libbuffer_la_DEPENDENCIES)
> $(LINK) -rpath $(libdir) $(libbuffer_la_LDFLAGS)
> $(libbuffer_la_OBJECTS) $(libbuffer_la_LIBADD) -Wl,-Map -Wl, libbuffer.map
> $(LIBS)
> 
> If I made sure that there is no blank space between -Wl, and libbuffer.map
> then I get the following error -
> 
> usr/bin/gcc-4.0 -arch i386 -r -keep_private_externs -nostdlib -o
> .libs/libbuffer.0.0.1.dylib-master.o  buffer.lo && /usr/bin/gcc-4.0 -arch
> i386 -dynamiclib -flat_namespace -undefined suppress -o
> .libs/libbuffer.0.0.1.dylib .libs/libbuffer.0.0.1.dylib-master.o  -lpthread
> -lc -Map libbuffer.map -install_name /usr/local/lib/libbuffer.0.dylib
> -compatibility_version 1 -current_version 1.1

[adding the list back to CC]

What version of libtool is generating this? Where is the -r coming from?
Why are you passing -Map instead of -map?

Passing -Wl,-map,libbuffer.map will likely work, but I am not sure why
the -Wl, quoting was removed above. Nor am I sure why gcc generates no
warning or error when it sees -Map, and just ignores it.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: genarating map files for libraries

[Peter O'Gorman]

On Wed, Jan 20, 2010 at 09:32:08PM +0100, Ralf Wildenhues wrote:
> Hello Prokash,
> 
> * Prokash Sinha wrote on Tue, Jan 19, 2010 at 07:28:30PM CET:
> > I've an open source project that I'm trying to port to Mac os X. The project
> > builds a shared library ( i.e. dylib). It builds fine, but I can't seem to
> > generate the map file.
> > 
> > I was trying to insert some linker flags in the Makefile.in like the
> > following -
> > 
> > -Wl,-map,foo.map
> > 
> > -Wl,-Map -Wl, foo.map
> > 
> > but libtool's link step is flagging error saying foo.map file or directory
> > does not exist.
> 
> Well, libtool does not create your map file itself; you need to ensure
> that it exists.  You shouldn't have a space in the command line before
> foo.map.  If these hints don't help you, then I suggest you post the
> output of the failing 'make' command.

Hi Ralf, Prokash,

Apple's ld takes a -map  argument that generates a map file along
with the output. A quick test using ./libtool --mode=link --tag=CC gcc
-o libfoo.la foo.lo -rpath /foo -Wl,-map,foo.map works for me though.

Prokash, please show the link line, the error, ld -v, and ./libtool
--version.

Thanks,
Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: use of -flat_namespace on darwin

[Peter O'Gorman]

Hi Adam,

On 12/22/2009 04:56 PM, Adam Mercer wrote:


In one of our projects we are experiencing a problem which seems to be
related to the fact that the -flat_namespace option is not being
passed to the linker, looking into why this is the case I see the
following code in libtool.m4:


What is the problem?




I see that the -flat_namespace is only passed for 10.0, 10.1, and
10.2. Why is this? Are there adverse effects to using a flat namespace
on more recent OS X versions?


Two level namespace is the default, last time I checked every library on 
the system was two level namespace (there used to be one flat namespace 
X11 library, I think that changed). Two level namespace is faster, and 
solves numerous portability problems.


Peter
--
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: MacOSX module linking with static archive libtool problem

[Peter O'Gorman]

On 12/01/2009 06:04 PM, Jonas Thiem wrote:

This topic is rather old, and I'm referring to a particular post which
can be found here:
http://www.mail-archive.com/libtool@gnu.org/msg03642.html
Obviously it isn't possible to link a static lib from a shared lib
compiled in libtool as libtool blocks it (technically it would be
possible on many, but not all platforms). This affects all platforms
including Windows, not just Mac OS X.

Robert Boehne suggested some solutions to this:
 > Suggestion 1, you could link to shared libraries rather than archives.
 >Suggestion 2, if you're building it yourself, make the static libs
 >convenience libraries, this will have the same effect as linking to
static libs, but is portable.


This should work, we changed the dep libs check method to pass_all, if 
you are using libtool-1.5 (April 2003) or later, you shouldn't see a 
problem on Mac OS X.


Peter
--
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: release procedure

[Peter O'Gorman]

On 11/16/2009 11:29 AM, David Fang wrote:

For some reason our release procedure calls for running make distcheck
5 times. This is a tad onerous (one make distcheck takes almost an
hour on my system).

HACKING asks for:
and `make distcheck CC=g++'


I think keeping CC=g++ might be a good idea because many users (self
included) use libltdl in C++ projects. Sure, the header forces symbols
to have C-linkage in any case, but I'd sleep better knowing this was
covered somehow.


Using libltdl from a C++ package should already be covered by the 
testsuite. If you find it is not adequately covered, please let us know.


libltdl itself does not even build with g++, that check does not belong, 
really.


Peter
--
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

release procedure

[Peter O'Gorman]

Hi,

For some reason our release procedure calls for running make distcheck 5 
times. This is a tad onerous (one make distcheck takes almost an hour on 
my system).


HACKING asks for:
* Run `make distcheck'
  and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'
  and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--program-prefix=g'
  and `make distcheck CC=g++'

then later:
* Run `make -fMakefile.maint git-dist' (which also runs make distcheck).

Seriously, wtf?

I suggest that just the first two would be adequate.

We also fetch latest config* and some automake files from git/cvs. These 
files are all included in automake releases, what's wrong with just 
using the automake versions. Ralf releases automake fairly regularly ...


If we must continue to fetch (I did not do so for todays release because 
when I tried I got test failures in make check/distcheck etc.), then we 
need to change the Makefile to use git for the config project.


Why on earth do we have a commit script that just provides an opaque 
interface to git?


Let's just use gnuupload from gnulib to upload the tarballs. Maintaining 
our own system is silly.


I think that's about all, I will provide patches for HACKING and 
Makefile.maint later.


Peter
--
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Backport of libltdl changes to branch-1-5

[Peter O'Gorman]

If you happen to be stuck using an older libltdl for some reason, the 
attached untested patch should give you the same changes in behavior as 
the badly numbered 2.2.6b release.


Peter
--
Peter O'Gorman
http://pogma.com
diff -urN libtool-1.5.26.orig/libltdl/ltdl.c libtool-1.5.26/libltdl/ltdl.c
--- libtool-1.5.26.orig/libltdl/ltdl.c	2007-11-15 13:36:41.0 -0600
+++ libtool-1.5.26/libltdl/ltdl.c	2009-11-15 21:13:37.0 -0600
@@ -2192,7 +2192,8 @@
 static	int	try_dlopen	  LT_PARAMS((lt_dlhandle *handle,
 		 const char *filename));
 static	int	tryall_dlopen	  LT_PARAMS((lt_dlhandle *handle,
-		 const char *filename));
+		 const char *filename,
+		 const char * useloader));
 static	int	unload_deplibs	  LT_PARAMS((lt_dlhandle handle));
 static	int	lt_argz_insert	  LT_PARAMS((char **pargz,
 		 size_t *pargz_len,
@@ -2390,9 +2391,10 @@
 }
 
 static int
-tryall_dlopen (handle, filename)
+tryall_dlopen (handle, filename, useloader)
  lt_dlhandle *handle;
  const char *filename;
+ const char *useloader;
 {
   lt_dlhandle	 cur;
   lt_dlloader   *loader;
@@ -2459,6 +2461,11 @@
 
   while (loader)
 {
+  if (useloader && strcmp(loader->loader_name, useloader))
+	{
+	  loader = loader->next;
+	  continue;
+	}
   lt_user_data data = loader->dlloader_data;
 
   cur->module = loader->module_open (data, filename);
@@ -2528,7 +2535,7 @@
   error += tryall_dlopen_module (handle,
  (const char *) 0, prefix, filename);
 }
-  else if (tryall_dlopen (handle, filename) != 0)
+  else if (tryall_dlopen (handle, filename, NULL) != 0)
 {
   ++error;
 }
@@ -2549,7 +2556,7 @@
   /* Try to open the old library first; if it was dlpreopened,
  we want the preopened version of it, even if a dlopenable
  module is available.  */
-  if (old_name && tryall_dlopen (handle, old_name) == 0)
+  if (old_name && tryall_dlopen (handle, old_name, "dlpreload") == 0)
 {
   return 0;
 }
@@ -2813,7 +2820,7 @@
 
   /* Try to dlopen the file, but do not continue searching in any
  case.  */
-  if (tryall_dlopen (handle, filename) != 0)
+  if (tryall_dlopen (handle, filename,NULL) != 0)
 *handle = 0;
 
   return 1;
@@ -3103,7 +3110,7 @@
   /* lt_dlclose()ing yourself is very bad!  Disallow it.  */
   LT_DLSET_FLAG (*phandle, LT_DLRESIDENT_FLAG);
 
-  if (tryall_dlopen (&newhandle, 0) != 0)
+  if (tryall_dlopen (&newhandle, 0, NULL) != 0)
 	{
 	  LT_DLFREE (*phandle);
 	  return 1;
@@ -3225,7 +3232,7 @@
 	}
 #endif
 	}
-  if (!file)
+  else
 	{
 	  file = fopen (filename, LT_READTEXT_MODE);
 	}
@@ -3412,7 +3419,7 @@
 #endif
 		   )))
 	{
-  if (tryall_dlopen (&newhandle, filename) != 0)
+  if (tryall_dlopen (&newhandle, filename, NULL) != 0)
 {
   newhandle = NULL;
 }
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: GNU Libtool 2.2.6b released

[Peter O'Gorman]

On 11/16/2009 09:32 AM, Jeff Squyres wrote:

On Nov 16, 2009, at 7:21 AM, Peter O'Gorman wrote:


We are intending to release 2.2.8 sometime (hopefully soon) with all
the new features and lots of bug fixes from git HEAD.


So why not call this release 2.2.8 and bump the version number of the
next one to 2.2.10? Is it technically difficult to do so?


Because I never thought to do so.


My only point is that the last 2 public releases of LT have had
semantically different meanings of the version number. It is therefore
VERY unclear that 2.2.6b is a significant security/bug fix release (even
if the actual changes are minor). If I (a random user) saw that LT
released 2.2.6b but didn't read anything in the notes, I'd assume that
it was another packaging change, like 2.2.6a was. I certainly would not
immediately grok that it contains a security update.


I agree with your points, and had I put any thought at all into version 
numbering I would have done it differently.


Apologies all around.

Peter
--
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: GNU Libtool 2.2.6b released

[Peter O'Gorman]

On 11/16/2009 09:18 AM, Jeff Squyres wrote:

Congrats on the release!

I'm a little confused by the version number, though.

2.2.6a was explicitly billed as a packaging change vs. 2.2.6. This was
also the rationale provided as to why the "a" suffix was not included in
the directory name from the expanded tarball. This new release has the
suffix "b" *and* includes "b" in the directory name.


We are intending to release 2.2.8 sometime (hopefully soon) with all the 
new features and lots of bug fixes from git HEAD.


This release only contains two bugfixes to libltdl that were deemed 
important enough to warrant a separate release from the "stable" 2.2.6 
series.


Peter
--
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

retagged 2.2.6b

[Peter O'Gorman]

So, I screwed up ...

Yes, I know it's not best. I tagged 2.2.6b yesterday, and moved the tag 
this morning, so you may have the tag pointing at the wrong commit.


Sorry,
Peter
--
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

GNU Libtool 2.2.6b released

[Peter O'Gorman]

We are pleased to announce the release of GNU Libtool 2.2.6b.

GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl,
which hides the complexity of loading dynamic runtime libraries
(modules) behind a consistent, portable interface.

This release is a bug fix release for version 2.2.6. The following
bugs are fixed:

  - Fixed libltdl to no longer attempt to dlopen() the old_library
listed in the .la file. Now will use only the preopen loader to
attempt to load it. This may be a security issue, all users are
advised to upgrade.
  - Similarly, don't open module.la from the current directory, this
changes the behavior of libltdl to match the documentation.

libtool-2.2.6b is available now from ftp.gnu.org, along with diffs
against libtool-2.2.6a.  Please use a mirror to reduce stress on the
main gnu machine:

  http://www.gnu.org/order/ftp.html

Here are the compressed sources:

  ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6b.tar.gz
  ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6b.tar.lzma

Here are the diffs against libtool-2.2.6a:

  ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6a-2.2.6b.diff.gz

The MD5 and SHA1 checksums are:
 libtool-2.2.6b.tar.gz 07da460450490148c6d2df0f21481a25
 libtool-2.2.6b.tar.lzma   a4b36980765003b47dd75ac9429f4f11
 libtool-2.2.6a-2.2.6b.diff.gz a485788eb8fac09f7bb19b9f471ecf16

 libtool-2.2.6b.tar.gz 5afa73c8ef9ebe64bbb438a0f8779c9036e43c55
 libtool-2.2.6b.tar.lzma   18baaac89eed8be7bd2af2d2181598e176029cc6
 libtool-2.2.6a-2.2.6b.diff.gz 161b4f775d2e17890a25fd791c2deb3a69dcf293

This release was bootstrapped with automake-1.11 and autoconf-2.64.

You can fetch the unbootstrapped source code with git by using the
following commands:

  $ git clone git://git.savannah.gnu.org/libtool.git
  $ cd libtool
  $ git checkout v2.2.6b

Please report bugs to , along with the verbose
output of any failed test groups, and the output from `./libtool
--config.' The README file explains how to capture the verbose test
output.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: [2.2.7a Test Results] SLES 10 on pentiumpro with gcc 4.1.2 20070115 (SUSE Linux)

[Peter O'Gorman]

On 11/10/2009 03:02 PM, Gary V. Vaughan wrote:

Sorry again for the delay.

I haven't begun to analyse any of this or the upcoming test results, and may 
not have the time to do so in any depth before the end of the year.  I will, 
however, provide more details on request, apply proposed patches and rerun the 
testsuite in a timely fashion for any advances made by fellow libtoolers.



I just looked at this, and would guess that most are the same -

bash: {CXX:-g++}: command not found

Missing a $.

Peter
--
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Better soname linking

[Peter O'Gorman]

On 11/01/2009 06:23 AM, Jan Engelhardt wrote:


On Sunday 2009-11-01 09:46, Ralf Wildenhues wrote:


-version-info 23:0:1 will create a libfoo.so.22.1.0 and there is a
symlink libfoo.so.22 to it, so that programs originally linked for
v22 continue to work with a v23 that implements APIs 22–23.




Wow.  This would be a heavy change. [...]
Can't we use some other method to make it obvious to the distributor
that libfoo has gone from 22.0.0 to 22.1.0?


Well the problem is really independent of any of the per-distro package
mechanisms:



I don't agree that this is a problem with libtool, it is a packaging issue.

If libfoo went from 22.0.0 (provided by foo-2.0.0) to 22.1.0 (provided 
by foo-2.0.2) then new binary packages created that use the new libfoo 
need to have a versioned dependency >= foo-2.0.2, end of story.


Peter
--
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libltdl is inefficient and a security hazard

[Peter O'Gorman]

On 10/25/2009 09:04 PM, Bob Friesenhahn wrote:


The conditions in the code can simply be reversed so that the shared
library extension is tested first. Does anyone know a reason for the
current order?



It's been a while since I've looked at libltdl, so the following may not 
be correct.


It tries the .a first for the preopen loaders, as you guessed, but, of 
course, the other loaders don't know that and look for it anyway, 
failing, and flailing along, until the preopen loader has a chance, and 
(in most cases) fails.


Changing the search order would "break" things that use the preopen 
loader if there is a shared module also available. I don't think such a 
change is acceptable.


I would suggest that libltdl explicitly limit the searching for the .a 
archive to the preopen loader(s) to stop the filesystem getting involved 
there.


If lt_dlopen is passed an absolute path, it shouldn't really be 
searching at all. I'd call that a different bug though.


Feel free to delve in and propose patches.

Peter
--
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

repository updated

[Peter O'Gorman]

I just did git push --all; git push --tags; to update savannah's copy of
the repository.

So much easier than last time :)

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: unexpected emergence of --whole-archive

[Peter O'Gorman]

Matěj Týč wrote:

>>> /bin/sh ../libtool --tag=CC   --mode=link gcc  -DNOINLINE -Wextra -g -O0
>>> -module  -ljpeg   -o jpeg.la -rpath /usr/local/lib/IL jpeg_la-il_jpeg.lo
>>> -lm -lz 
>>> results in:
>>> libtool: link: gcc -shared  .libs/jpeg_la-il_jpeg.o
>>> -Wl,--whole-archive /home/bubla/projects/devil_modular/lib/.libs/libjpeg.a 
>>> -Wl,--no-whole-archive  -ljpeg -lm -lz-Wl,-soname -Wl,jpeg.so.0 -o 
>>> .libs/jpeg.so.0.0.0
>>> and consequently an error occurs:
>>> gcc: /home/bubla/projects/devil_modular/lib/.libs/libjpeg.a: No such
>>> file or directory

> The funny and mysterious thing about this is that it should not be
> created. Actually, it is not created, but it is somehow required in the
> linking phase.
> The rules to create the 'png' and 'jpeg' modules are exactly the same in
> the Makefile.am!
> I can't understand at all how come that it is different in the end...
> It would be good to know what makes libtool to come up with that idea
> about the convenience library...
> Also notice that libtool demands libjpeg.a, not libjpeg.la
> Matej

In the directory /home/bubla/projects/devil_modular/lib/ you have a
libjpeg.la file. This is not the jpeg module that you are creating, it
is a different library. libtool finds this when you pass -ljpeg (not
sure why, as there is no -L flag for that directory). This libjpeg.la is
a libtool created file that instructs libtool that the libjpeg.a sitting
next to it is a libtool convenience archive.

How was the file libjpeg.la, in the directory
/home/bubla/projects/devil_modular/lib created?

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: unexpected emergence of --whole-archive

[Peter O'Gorman]

Matěj Týč wrote:
> Hello,
> I use autotools libtool to make a library. That library consists of the
> main shared library file and a set of dynamically loadable modules.
> Those modules depend on external shared libraries.
> I have written configure.ac and Makefile.am that are quite complex and
> some things are generated during the configure time (it is an image
> loading library supporting quite a lot of formats). So I can't post
> stuff here, there is too much of it.
> 
> The problem is: During the build of libraries, some modules refuse to
> build. The cause is, however, absolutely strange.
> During the 'make' phase, the following happens:
> 
> /bin/sh ../libtool --tag=CC   --mode=link gcc  -DNOINLINE -Wextra -g -O0
> -module  -lpng12   -o png.la -rpath /usr/local/lib/IL png_la-il_png.lo
> -lm -lz
> results in:
> libtool: link: gcc -shared  .libs/png_la-il_png.o   -lpng12 -lm -lz
> -Wl,-soname -Wl,png.so.0 -o .libs/png.so.0.0.0
> That is OK. However:
> 
> /bin/sh ../libtool --tag=CC   --mode=link gcc  -DNOINLINE -Wextra -g -O0
> -module  -ljpeg   -o jpeg.la -rpath /usr/local/lib/IL jpeg_la-il_jpeg.lo
> -lm -lz 
> results in:
> libtool: link: gcc -shared  .libs/jpeg_la-il_jpeg.o
> -Wl,--whole-archive /home/bubla/projects/devil_modular/lib/.libs/libjpeg.a 
> -Wl,--no-whole-archive  -ljpeg -lm -lz-Wl,-soname -Wl,jpeg.so.0 -o 
> .libs/jpeg.so.0.0.0
> and consequently an error occurs:
> gcc: /home/bubla/projects/devil_modular/lib/.libs/libjpeg.a: No such
> file or directory
> 
> To have something to start with, you have an idea where does that
> -Wl,--whole-archive  -Wl,--no-whole-archive section come from?

/home/bubla/projects/devil_modular/lib/libjpeg.la is a libtool
convenience library (or at least libtool thinks it is). How was it
created? What is the Makefile.am rule for it?

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool problem with library dependencies on ppc64

[Peter O'Gorman]

aration-after- 
statement -Werror -g -O2 -I/home/mpj/binutils-install-2-18//include  
-Wl,-R -Wl,/home/mpj/binutils-install-2-18//lib64 -o opjitconv  
opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o  
debug_line.o -L/home/mpj/binutils-install-2-18//lib64 ../libutil/ 
libutil.a /home/mpj/binutils-install-2-18//lib64/libbfd.a -lz - 
liberty -ldl

+++
Notice that libtool added the -lz to the link command in this  
case.  So, it seems to me that passing in a -L to indicate an  
alternative binutils dir provides libtool with enough info to  
figure out it needed to add the -lz.  Is it a bug that it can't  
figure this out when it should link with the default /usr/lib64/ 
libbfd.a?
Sorry for the length of this message.  Thanks in advance for any  
help.

Regards,
-Maynard Johnson




--
Peter O'Gorman
http://pogma.com




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: fixing linkage against uninstalled libtool archives on macos?

[Peter O'Gorman]

On 11-Nov-08, at 6:16 AM, Andy Wingo wrote:


Hi,

I posted a message to bug-libtool that hasn't gotten a response:

   http://lists.gnu.org/archive/html/bug-libtool/2008-11/msg00012.html

In short, "libtool --tag=CC --mode=link gcc ... /path/to/libfoo.la"  
does

not do the right thing on Mac OS with libtool 2.2.6a. Can I get
confirmation of this bug?

Just to recap, the bug is that having
"../../../gst/libgstreamer-0.10.la" on the link line expands into
"-L../../../gst/.libs -lgstreamer-0.10" instead of
"../../../gst/.libs/libgstreamer-0.10.dylib". I tested replacing the
"-L -l" combination with the path to the dylib, and that seems to  
work.

So it seems to be a bug in libtool.



Sorry, I did not get back to you.

Could you please send the output of ./libtool --config.

Thanks,
Peter
--
Peter O'Gorman
http://pogma.com




___
http://lists.gnu.org/mailman/listinfo/libtool

[sr #106497] Broken download link ("2.2.6" instead of "2.2.6a")

[Peter O'Gorman]

Update of sr #106497 (project libtool):

  Status:None => Done   
 Assigned to:None => pogma  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you. Fixed.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool 2.2.6a

[Peter O'Gorman]

Jeff Squyres wrote:
> 
> 
> I notice that libtool-2.2.6a.tar.* unzips into the libtool-2.2.6/
> directory (dropping the "a" from the directory name).  This is
> unexpected.  It actually throws off all my auto-install scripts because
> the version number is now not the same as the directory.
> 
> Grumble.
> 
> 

Hi Jeff,

Yeah, it is mostly a repacking of the libtool-2.2.6.tar.* that were
released the day before. Putting up files with the same name but
different sums is also bad. It is noted in the release announcement:

http://lists.gnu.org/archive/html/autotools-announce/2008-09/msg1.html

I can only suggest you mv libtool-2.2.6a.tar.gz libtool-2.2.6.tar.gz and
pass that tarball to your auto-build scripts.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool 2 and dsohowto's comments?

[Peter O'Gorman]

Daniel Qarras wrote:
> Hi all,
> 
> I was studying something related to shared libraries and found this old 
> conversation about dsohowto.pdf and libtool 2:
> 
> http://www.mail-archive.com/libtool@gnu.org/msg05676.html
> 
> That tells the status four years ago, I'm wondering are the dsohowto comments 
> relevant to libtool2 anymore?

The dsohowto paper is still incorrect, just as it was 4 years ago. If
you follow the thread, you'll see Ralf's reply:

http://www.mail-archive.com/libtool@gnu.org/msg05679.html

Libtool does, and did 4 years ago, use a linker script to limit exported
symbols on linux if ld supports it.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Problem with shrext on Mac OS X

[Peter O'Gorman]

Ian Kerr wrote:
> Hello,
> 

Hi,

> I'm trying to build a JNI library and, from what I understand, the
> library needs to have a '.jnilib' extension on Mac OS X. 

Yes, the requirement was recently lifted, now java will also look for
.dylib.

http://developer.apple.com/releasenotes/Java/JavaLeopardRN/ResolvedIssues/chapter_3_section_14.html#

 As I
> understand it, I should be able to use the -shrext flag to get libtool
> to use the jnilib extension rather than the standard shared library
> extension.  However, I can't get this to work.  I issue the command:
> 
> /bin/sh ../../../libtool --mode=link g++ -shared -rpath /usr/local/lib
> -shrext .jnilib -o libjmath.la swig_math.lo
> 
> and the following g++ invocation is made:
> 
> g++ -dynamiclib  -single_module -flat_namespace -undefined suppress -o
> .libs/libjmath.0.dylib  .libs/swig_math.o   -install_name
> /usr/local/lib/libjmath.0.dylib -compatibility_version 1
> -current_version 1.0
> 
> As you can see, the extension isn't changed from dylib to jnilib. As I'm
> new to libtool I figure I'm doing something wrong.  Any ideas?

What version of libtool and what version of Mac OS X? This does work for me.

On Leopard, I get:
$ /usr/bin/glibtool --mode=link --tag=CXX g++ -shrext .jnilib -o java.la
java.lo -rpath /usr/local/lib -module -avoid-version

g++ ${wl}-undefined ${wl}dynamic_lookup -o .libs/java.jnilib -bundle
.libs/java.o

$ /usr/bin/glibtool --version
ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)

on a more recent libtool-2.2.x, I get:

libtool: link: /usr/bin/g++ -Wl,-undefined -Wl,dynamic_lookup -o
.libs/java.jnilib -bundle  .libs/java.o
libtool: link: dsymutil .libs/java.jnilib || :

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool causing oprofile build failure when configuring with --with-binutils

[Peter O'Gorman]

Maynard Johnson wrote:
> Hello,
> We recently released OProfile 0.9.4, which for the first time includes
> some libraries that must be installed along with the usual OProfile
> tools.  We introduced the use of libtool in our project to support the
> installation of these new OProfile libraries.  Now, a user has reported
> the following error when building OProfile:
> 
> ./configure --with-kernel-support --with-binutils=/my-binutils
> (NOTE: If you don't have an alternate binutils to point to,
> specifying --with-binutils=/usr will give same failure)

Your configure script adds spaces after -I and -L before the directory.
GCC is ok with this, libtool not so much.

Peter
-- 
Peter O'Gorman
http://pogma.com
--- configure.in~	2008-07-17 18:04:22.0 -0500
+++ configure.in	2008-07-31 14:13:35.0 -0500
@@ -39,9 +39,9 @@
 	if test "$CXXFLAGS" = ""; then
 		CXXFLAGS="-g -O2"
 	fi
-	CFLAGS="$CFLAGS -I $BINUTILSDIR/include"
-	CXXFLAGS="$CXXFLAGS -I $BINUTILSDIR/include"
-	LDFLAGS="$LDFLAGS -L $BINUTILSDIR/lib -Xlinker -R -Xlinker $BINUTILSDIR/lib"
+	CFLAGS="$CFLAGS -I$BINUTILSDIR/include"
+	CXXFLAGS="$CXXFLAGS -I$BINUTILSDIR/include"
+	LDFLAGS="$LDFLAGS -L$BINUTILSDIR/lib -Xlinker -R -Xlinker $BINUTILSDIR/lib"
 fi
 
 AC_ARG_WITH(gcc,
@@ -50,7 +50,7 @@
 if test "$GCCDIR" != ""; then
 	CC="$GCCDIR/bin/gcc"
 	CXX="$GCCDIR/bin/g++"
-	LDFLAGS="$LDFLAGS -L $GCCDIR/lib -Xlinker -R -Xlinker $GCCDIR/lib"
+	LDFLAGS="$LDFLAGS -L$GCCDIR/lib -Xlinker -R -Xlinker $GCCDIR/lib"
 fi
 
 AC_PROG_CC
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: 1 compiler (called from 2 symbolic links) -> 2 different libtool scripts

[Peter O'Gorman]

Ethan Mallove wrote:
> Hello,
> 
> I'm using libtool with the Sun Studio Ceres compilers, and I
> see a different resulting libtool script when I configure
> with CC=sunCC versus CC=cc (though they both point to the
> same executable). The Sun Studio installation has the below
> symbolic links:
>   
>   $ ls -l /opt/SUNWspro/bin/*CC
>   lrwxrwxrwx 1 nik staff 14 Jul 11 15:33 /opt/SUNWspro/bin/CC -> 
> ../prod/bin/CC
>   lrwxrwxrwx 1 nik staff 14 Jul 11 15:33 /opt/SUNWspro/bin/sunCC -> 
> ../prod/bin/CC

> Is it possible the libtool macros do things differently
> depending on a symlink name?

The test is:
case $cc_basename in
CC*)

So this does not match 'sunCC'.

I guess we can change the test to match sunCC*|CC*).

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libool picking the wrong library for dbus

[Peter O'Gorman]

Sandeep Puddupakkam (spuddupa) wrote:
> Peter,
> Your suggestion worked. Since we build libdbus, I modified the libdbus
> build to set libdir=/nobackup/spuddupa/nova/linkfarm/ppc/usr/lib in the
> libdbus-1.la file.
> Compiling upstart now works fine.
> One question though.
> Are *.la file only used for linking by libtool?
> Since all the files in /nobackup/spuddupa/nova/linkfarm/ppc/* are copied
> to the target hardware into the root directory.
> The libdbus-1.la file on the target hardware (/usr/lib/libdbus-1.la)
> would still have the
> libdir=/nobackup/spuddupa/nova/linkfarm/ppc/usr/lib.

Hi Sandeep,

If you are shipping a system that makes no use of lt_dlopen, where the
user is never expected to build anything then there is no need to ship
.la files. If, on the other hand, you expect the user to compile
projects, or some parts of the system make use of lt_dlopen, I would
suggest using sed to modify the .la files after the root is complete.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libool picking the wrong library for dbus

[Peter O'Gorman]

Sandeep Puddupakkam (spuddupa) wrote:
> *** Reposting with zipped (winzip) logfile***
> 
> Hi,
> 
> I am trying to cross-compile upstart for ppc.
> 
> Upstart requires libdbus-1 which I compiled for ppc and it is located in
> the directory
> 
> /nobackup/spuddupa/nova/linkfarm/ppc/usr/lib

Thanks for posting the log file.
/nobackup/spuddupa/nova/linkfarm/ppc/usr/lib/libdbus-1.la contains:

 libdir=/usr/lib

So libtool goes and looks in libdir for libdbus-1.so.

libtool does not do well building to a sysroot like this. You could
modify all the .la files in the root so that they contain the actual
location of the libraries in libdir.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libool picking the wrong library for dbus

[Peter O'Gorman]

Sandeep Puddupakkam (spuddupa) wrote:
> The log file generated is big (400k) and my mail is not going thru. If
> anyone wants to look at the logfile, I can mail it to you directly.
> 

Please compress it and send it to the list.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: extra copy of manual on www.gnu.org

[Peter O'Gorman]

Brian Dessent wrote:
> The GNU website has both the current manual:
> http://www.gnu.org/software/libtool/manual/libtool.html
> 
> ...as well as this older version from 1.5.24:
> http://www.gnu.org/software/libtool/manual.html
> 
>>From the similarity of the URLs I'm guessing that this is accidental. 
> Unfortunately search engines have an uncanny habit of finding those old
> copies and putting them near the top of the results, which leads to a
> lot of confusion if the neglected version evades deletion long enough
> such that it documents a long-obsolete version.

Thanks, fixed.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: shared libraries on darwin using Intel compiler

[Peter O'Gorman]

Christopher Hulbert wrote:
> On Fri, Jun 13, 2008 at 11:55 AM, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
>> Christopher Hulbert wrote:
>>
>>> GIT version still reports that the ifort linker does not support
>>> shared libraries. The config.log is attached.
>> Hi Chris,
>>
>> Your config.log confirms that ifort does not define __GNUC__, thanks.
>>
>> Could you confirm that this patch fixes it.
> 
> Yes, the ifort linker now supports shared libraries.

Ok, thanks, I pushed the patch.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: shared libraries on darwin using Intel compiler

[Peter O'Gorman]

Christopher Hulbert wrote:

> GIT version still reports that the ifort linker does not support
> shared libraries. The config.log is attached.

Hi Chris,

Your config.log confirms that ifort does not define __GNUC__, thanks.

Could you confirm that this patch fixes it.

Peter
-- 
Peter O'Gorman
http://pogma.com
>From a33319273b5b70b8dc98c698fe99d039a1873c23 Mon Sep 17 00:00:00 2001
From: Peter O'Gorman <[EMAIL PROTECTED]>
Date: Fri, 13 Jun 2008 10:53:34 -0500
Subject: [PATCH] Support ifort on darwin.

* libltdl/m4/libtool.m4 (_LT_DARWIN_LINKER_FEATURES): Build
shared libraries with ifort.
Reported by Christopher Hulbert.
---
 ChangeLog |7 +++
 libltdl/m4/libtool.m4 |6 +-
 2 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 92b3214..c22304d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2008-06-13  Peter O'Gorman  <[EMAIL PROTECTED]>
+
+	Support ifort on darwin.
+	* libltdl/m4/libtool.m4 (_LT_DARWIN_LINKER_FEATURES): Build
+	shared libraries with ifort.
+	Reported by Christopher Hulbert.
+
 2008-06-01  Charles Wilson  <[EMAIL PROTECTED]>
 
 	[mingw] fix cross-compile-with-wine case
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 654f54a..103269d 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -990,7 +990,11 @@ m4_defun([_LT_DARWIN_LINKER_FEATURES],
   _LT_TAGVAR(whole_archive_flag_spec, $1)=''
   _LT_TAGVAR(link_all_deplibs, $1)=yes
   _LT_TAGVAR(allow_undefined_flag, $1)="$_lt_dar_allow_undefined"
-  if test "$GCC" = "yes"; then
+  case $cc_basename in
+ ifort*) _lt_dar_can_shared=yes ;;
+ *) _lt_dar_can_shared=$GCC ;;
+  esac
+  if test "$_lt_dar_can_shared" = "yes"; then
 output_verbose_link_cmd=echo
 _LT_TAGVAR(archive_cmds, $1)="\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring $_lt_dar_single_mod${_lt_dsymutil}"
 _LT_TAGVAR(module_cmds, $1)="\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dsymutil}"
-- 
1.5.4.1

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: shared libraries on darwin using Intel compiler

[Peter O'Gorman]

Christopher Hulbert wrote:
> In libtool 2.2.2, building shared libraries using Intel fortran
> compilers seem to be disabled (although the icc compiler appears to
> say yes). Thus, mixed language shared libraries or purely fortran
> shared libraries can't be built. I have the intel 10.1 compilers. As a
> quick way to get shared libraries working, I hacked the
> _LT_LINKER_SHLIBS function for the darwin case to what's below, but
> I'm sure there's a better way of doing this. What would be the more
> preferable way of adding support for shared libraries using Intel
> fortran compiler? I'm not sure why it works for icc but not ifort.
> Using the hack below I can successfully link with the fortran linker
> and build the shared library.

Hi Chris,

I will look at this, but to answer your question about why icc works -
it defines __GNUC__ and behaves almost exactly the same as gcc (I
believe it calls gcc to do its linking), so the existing commands for
gcc work fine with icc.

I am unsure why they do not work with ifort, I would have thought that
would similarly define __GNUC__. Could you please send me a config.log
from a libtool using package (or from libtool itself) without this patch
applied.

Thanks,
Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: building but not installing shared library...

[Peter O'Gorman]

Ed Hartnett wrote:

> I am the developer of netcdf, a free software tool for scientific data
> storage.
> 
> I am using libtool 2.2 and am having a strange problem on an AIX
> system.
> 
> When building a shared C library with gcc everything seems to

> libtool: link: ar cru .libs/libnetcdf.a .libs/libnetcdf.so.4

Hi Ed,

I think this is because you are not using -brtl. The shared object is
added to the archive. If you had configured and built with -Wl,-brtl in
your LDFLAGS, you would get a separate shared library.

Because the shared library is part of the archive it is being installed
with the archive.

dump -X32_64 -H /path/to/libnetcdf.a should show you the shared members.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool 2.2.2, darwin and target prefixes

[Peter O'Gorman]

Peter O'Gorman wrote:
> Richard Purdie wrote:
>> Hi,
>>
>> As previously mentioned, I've been stress testing libtool 2.2.2 with
>> Poky a bit.
>>
>> I've found one issue when I tested the darwin builds, specifically that
>> it tried to use "otool" and "otool64" and not the versions with the host
>> prefix which my setup has. I fixed this with the patch below which is
>> fine for Poky since its always cross compiling but its a sign a better
>> fix is probably needed in general.
> 
> Thanks,
> I have pushed this, it also cleans up the sed sed echo ickyness.

It is always better if quotes get closed. I had tested, honest!

Pushed this.

Peter
-- 
Peter O'Gorman
http://pogma.com
>From fe06ce018f30c17b034c318f76bbe16164bf0d3a Mon Sep 17 00:00:00 2001
From: Peter O'Gorman <[EMAIL PROTECTED]>
Date: Fri, 2 May 2008 00:54:49 -0500
Subject: [PATCH] It helps to close quotes.

* libltdl/config/ltmain.m4sh (func_mode_link): Add closing '.
---
 ChangeLog  |5 +
 libltdl/config/ltmain.m4sh |4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 5db30d7..b9a695c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2008-05-02  Peter O'Gorman  <[EMAIL PROTECTED]>
+
+	It helps to close quotes.
+	* libltdl/config/ltmain.m4sh (func_mode_link): Add closing '.
+
 2008-05-01  Peter O'Gorman  <[EMAIL PROTECTED]>
 
 	Use AC_CHECK_TOOL for otool and otool64.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 84f7078..33689b9 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4951,9 +4951,9 @@ func_mode_link ()
 		done
 		if test -f "$absdir/$objdir/$depdepl" ; then
 		  depdepl="$absdir/$objdir/$depdepl"
-		  darwin_install_name=`${OTOOL} -L $depdepl | awk '{if (NR == 2) {print $1;exit}}`
+		  darwin_install_name=`${OTOOL} -L $depdepl | awk '{if (NR == 2) {print $1;exit}}'`
   if test -z "$darwin_install_name"; then
-  darwin_install_name=`${OTOOL64} -L $depdepl  | awk '{if (NR == 2) {print $1;exit}}`
+  darwin_install_name=`${OTOOL64} -L $depdepl  | awk '{if (NR == 2) {print $1;exit}}'`
   fi
 		  compiler_flags="$compiler_flags ${wl}-dylib_file ${wl}${darwin_install_name}:${depdepl}"
 		  linker_flags="$linker_flags -dylib_file ${darwin_install_name}:${depdepl}"
-- 
1.5.3.7

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool 2.2.2, darwin and target prefixes

[Peter O'Gorman]

Richard Purdie wrote:
> Hi,
> 
> As previously mentioned, I've been stress testing libtool 2.2.2 with
> Poky a bit.
> 
> I've found one issue when I tested the darwin builds, specifically that
> it tried to use "otool" and "otool64" and not the versions with the host
> prefix which my setup has. I fixed this with the patch below which is
> fine for Poky since its always cross compiling but its a sign a better
> fix is probably needed in general.

Thanks,
I have pushed this, it also cleans up the sed sed echo ickyness.

Peter
-- 
Peter O'Gorman
http://pogma.com
>From 92e15986a43a8009decffc4d5d290272449487a4 Mon Sep 17 00:00:00 2001
From: Peter O'Gorman <[EMAIL PROTECTED]>
Date: Thu, 1 May 2008 12:40:24 -0500
Subject: [PATCH] Use AC_CHECK_TOOL for otool and otool64.

* libltdl/m4/libtool.m4 (_LT_REQUIRED_DARWIN_CHECKS): Check.
* libltdl/config/ltmain.m4sh (func_mode_link): Use.
Reported by Richard Purdie <[EMAIL PROTECTED]>
---
 ChangeLog  |7 +++
 libltdl/config/ltmain.m4sh |6 ++
 libltdl/m4/libtool.m4  |6 ++
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b3c0616..5db30d7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2008-05-01  Peter O'Gorman  <[EMAIL PROTECTED]>
+
+	Use AC_CHECK_TOOL for otool and otool64.
+	* libltdl/m4/libtool.m4 (_LT_REQUIRED_DARWIN_CHECKS): Check.
+	* libltdl/config/ltmain.m4sh (func_mode_link): Use.
+	Reported by Richard Purdie <[EMAIL PROTECTED]>
+
 2008-04-30  Eric Blake  <[EMAIL PROTECTED]>
 
 	Support cygwin 1.7.0 in loadlibrary loader.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index ac334dc..84f7078 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4951,11 +4951,9 @@ func_mode_link ()
 		done
 		if test -f "$absdir/$objdir/$depdepl" ; then
 		  depdepl="$absdir/$objdir/$depdepl"
-		  darwin_install_name=`otool -L $depdepl | $SED -n -e '3q;2,2p' | $SED -e 's/(.*//'`
-		  darwin_install_name=`$ECHO $darwin_install_name`
+		  darwin_install_name=`${OTOOL} -L $depdepl | awk '{if (NR == 2) {print $1;exit}}`
   if test -z "$darwin_install_name"; then
-  darwin_install_name=`otool64 -L $depdepl | $SED -n -e '3q;2,2p' | $SED -e 's/(.*//'`
-  darwin_install_name=`$ECHO $darwin_install_name`
+  darwin_install_name=`${OTOOL64} -L $depdepl  | awk '{if (NR == 2) {print $1;exit}}`
   fi
 		  compiler_flags="$compiler_flags ${wl}-dylib_file ${wl}${darwin_install_name}:${depdepl}"
 		  linker_flags="$linker_flags -dylib_file ${darwin_install_name}:${depdepl}"
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 9906e11..c23451a 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -894,12 +894,18 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[
 AC_CHECK_TOOL([DSYMUTIL], [dsymutil], [:])
 AC_CHECK_TOOL([NMEDIT], [nmedit], [:])
 AC_CHECK_TOOL([LIPO], [lipo], [:])
+AC_CHECK_TOOL([OTOOL], [otool], [:])
+AC_CHECK_TOOL([OTOOL64], [otool64], [:])
 _LT_DECL([], [DSYMUTIL], [1],
   [Tool to manipulate archived DWARF debug symbol files on Mac OS X])
 _LT_DECL([], [NMEDIT], [1],
   [Tool to change global to local symbols on Mac OS X])
 _LT_DECL([], [LIPO], [1],
   [Tool to manipulate fat objects and archives on Mac OS X])
+_LT_DECL([], [OTOOL], [1],
+  [ldd/readelf like tool for Mach-O binaries on Mac OS X])
+_LT_DECL([], [OTOOL64], [1],
+  [ldd/readelf like tool for 64 bit Mach-O binaries on Mac OS X 10.4])
 
 AC_CACHE_CHECK([for -single_module linker flag],[lt_cv_apple_cc_single_mod],
   [lt_cv_apple_cc_single_mod=no
-- 
1.5.3.7

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool performance status (part 1.2965)

[Peter O'Gorman]

Bob Friesenhahn wrote:

> libtool 1.5.26:
> real 4:53.877
> user 3:26.912
> sys  1:25.275

> 
> libtool 1.2965 2008-04-22 (bash)
> real 4:03.745
> user 3:19.232
> sys41.018

Bob, thank you for testing and giving us these numbers.

This improvement is almost entirely due to Ralf, so I encourage everyone
who is subscribed to this list to seek him out and buy him many beers.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash

[Peter O'Gorman]

Ross Burton wrote:

> I tried just using $export_dynamic_flag_spec in the configure.ac
> directly, but that refers to ${wl} which isn't defined by libtool inside
> the configure run. :/  Any cunning plans for how this could work with
> libtool 2.2?

Something like:
wl=$lt_prog_compiler_wl eval
gtk_export_dynamic=\"$export_dynamic_flag_spec\"

For C++, it would be wl=$lt_prog_compiler_wl_CXX etc.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash

[Peter O'Gorman]

Gary V. Vaughan wrote:

>> Was this behaviour present in libtool 1.5?
> 
> No it wasn't, because libtool was generated in a two stage process which
> required
> calling ./libtool --config directly.

Hi Gary,

I think you may be wrong. You can check the value of libtool variables
in configure for libtool > 1.4. In 1.3 and earlier there was a separate
ltconfig script which was run, so those variables were not available.
With 1.4 libtool's checks became part of the configure script itself, so
anything after AC_PROG_LIBTOOL can check the variables values.

With 2.x, of course, it is preferred to use the vars directly, creating
libtool just to check these is expensive and pointless.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: _lt_libltdl_LTX_preloaded_symbols in consistence.

[Peter O'Gorman]

Steven Wu wrote:
> Hi,
> 
> On MacOS X, 10.5.2, intel machine, the symbol
> _lt_libltdl_LTX_preloaded_symbols libraries (from the generated file
> libltdlS.o) is inconsistent with the symbol defined in ltdl.h, where the
> symbol is declared as _lt__PROGRAM__LTX_preloaded_symbols. This causes
> link time error. I fixed this problem by changing the name in the ltdl.h
> file to match the symbol in the libraries.

When linking libltdl?

What are the errors that you saw? And what changes did you have to make?

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

[Peter O'Gorman]

Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Thu, Apr 10, 2008 at 07:51:57AM CEST:
>> On Wed, 9 Apr 2008, Peter O'Gorman wrote:
>>> This is a list off shell functions that appear in the generated libtool
>>> script on my linux system (one of Ralf's patches is applied). Yes, we
>>> could probably move these around some to get func_mode_compile closer to
>>> the top.
>> The important thing is not how close func_mode_compile() is to the top, 
>> but how close the code which invokes it is to the top.
> 
> Most of these optimizations are already done in 2.2.2.  The code
> invoking func_mode_compile is right after its definition.
> 
> Wrt. moving functions, func_win32_libid, func_generate_dlsyms, and
> func_extract_an_archive, func_extract_archives can still be moved
> after func_mode_compile.  That gets another 10% overhead reduction.
> My patches from last night get about the same amount.

func_mode_help can also be easily moved, I am testing a patch currently
that moves all of these functions to after mode_compile.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

[Peter O'Gorman]

Bob Friesenhahn wrote:
> On Wed, 9 Apr 2008, Peter O'Gorman wrote:
>>
>> (using bash)
>> $ for y in {1..100}; do echo "func_notused${y} () {" >> parse.sh; for x
>> in {1..1}; do echo foo >> parse.sh; done; echo '}' >> parse.sh;
>> done; echo 'echo Done' >> parse.sh
>>
> 
> It seems that the slowest possible shell is selected by default. Maybe
> that is bad?

Only if this test is actually a good benchmark (which is doubtful) :-)

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

[Peter O'Gorman]

Bob Friesenhahn wrote:
> On Wed, 9 Apr 2008, Eric Blake wrote:
>> | Since shell scripts are not compiled, the size of a shell script has
>> | very little to do with its execution time.
>>
>> On the other hand, recent improvements in autoconf 2.62 proved that we
>> were able to speed up testsuite performance by more than 10% by merely
>> refactoring Autotest output to avoid shell parsing of code that would not
>> be executed.  In other words, the time the shell spends on parsing its
>> input, whether or not that input is executed, is not trivial.
> 
> This is true.  The script could be 10MB in size but if only the first
> five lines are ever executed the execution time should be similar to a
> similar five line script.  This means that parts which are executed
> often should be up front.
> 
> If there is a long list of shell functions which appear up front, then
> all those shell functions need to be parsed and remembered before the
> real executable code is executed.

This is a list off shell functions that appear in the generated libtool
script on my linux system (one of Ralf's patches is applied). Yes, we
could probably move these around some to get func_mode_compile closer to
the top.

func_dirname_and_basename ()
func_dirname ()
func_basename ()
func_dirname_and_basename ()
func_stripname ()
func_opt_split ()
func_lo2o ()
func_append ()
func_echo ()
func_verbose ()
func_error ()
func_warning ()
func_fatal_error ()
func_fatal_help ()
func_grep ()
func_mkdir_p ()
func_mktempdir ()
func_quote_for_eval ()
func_quote_for_expand ()
func_show_eval ()
func_show_eval_locale ()
func_version ()
func_usage ()
func_help ()
func_missing_arg ()
func_fatal_configuration ()
func_config ()
func_features ()
func_enable_tag ()
func_mode_help ()
func_check_version_match ()
func_lalib_p ()
func_lalib_unsafe_p ()
func_ltwrapper_script_p ()
func_ltwrapper_executable_p ()
func_ltwrapper_scriptname ()
func_ltwrapper_p ()
func_execute_cmds ()
func_source ()
func_win32_libid ()
func_infer_tag ()
func_generate_dlsyms ()
func_extract_an_archive ()
func_extract_archives ()
func_write_libtool_object ()
func_mode_compile ()
func_mode_execute ()
func_mode_finish ()
func_mode_install ()
func_emit_wrapper ()
func_emit_cwrapperexe_src ()
func_mode_link ()
func_mode_uninstall ()

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

[Peter O'Gorman]

Eric Blake wrote:
> According to Bob Friesenhahn on 4/9/2008 11:15 AM:
> | On Wed, 9 Apr 2008, Josh Triplett wrote:
> |>
> |> I tested against 1.5.26.  I'll give 2.2.2 a shot and see what I find.
> |> However, when I looked at 2.2.2, it still seems to have a
> |> multi-thousand-line shell script; do you just expect the benefit to
> |> come from the new shell-specific optimizations?
> |
> | Since shell scripts are not compiled, the size of a shell script has
> | very little to do with its execution time.
> 
> On the other hand, recent improvements in autoconf 2.62 proved that we
> were able to speed up testsuite performance by more than 10% by merely
> refactoring Autotest output to avoid shell parsing of code that would not
> be executed.  In other words, the time the shell spends on parsing its
> input, whether or not that input is executed, is not trivial.
> 

Just for fun, lets compare shells at parsing useless code.

(using bash)
$ for y in {1..100}; do echo "func_notused${y} () {" >> parse.sh; for x
in {1..1}; do echo foo >> parse.sh; done; echo '}' >> parse.sh;
done; echo 'echo Done' >> parse.sh

On linux:
$ time bash parse.sh
Done

real0m4.567s
user0m3.970s
sys 0m0.188s

$ time dash parse.sh
Done

real0m1.421s
user0m1.242s
sys 0m0.096s

$ time zsh parse.sh
Done

real0m1.635s
user0m1.293s
sys 0m0.161s

On mac os x:
$ time zsh parse.sh
Done

real0m1.429s
user0m1.176s
sys 0m0.193s

$ time bash parse.sh
Done

real0m4.921s
user0m4.706s
sys 0m0.215s

$ time ksh parse.sh
Done

real5m31.311s ***
user5m29.284s
sys 0m1.876s

I know that libtool has not yet reached a million+ lines of useless
shell functions though :)

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

[Peter O'Gorman]

Ralf Wildenhues wrote:
That gave the biggest speedup on
> GNU/Linux (where forks are relatively cheap).
> <http://thread.gmane.org/gmane.comp.gnu.libtool.patches/7230>

This entire message just goes to prove that I do not have a good memory.
I had completely forgotten that you sped up compile mode too.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

[Peter O'Gorman]

Josh Triplett wrote:

> I tested against 1.5.26.  I'll give 2.2.2 a shot and see what I find.
> However, when I looked at 2.2.2, it still seems to have a
> multi-thousand-line shell script; do you just expect the benefit to
> come from the new shell-specific optimizations?
>

Hi Josh,

There are speedups for link mode, I don't think you will see much of an
improvement for compile mode over 1.5.26, but I do not have numbers to
back that up.

Splitting off libtool compile might be worthwhile, but there should be
no need for:

AC_MSG_CHECKING([if libtool sucks])
AC_MSG_RESULT([yup, it does])

:-)

Or to restrict the shell, compiler and OS to bash, gcc and GNU/linux. It
should be possible to have a portable (at least a more portable than
this) ltcompile script.

Are you willing to work on libtool to improve its performance for
compile mode? If so, we can send you copyright assignment forms etc.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Customizing soname

[Peter O'Gorman]

Alon Bar-Lev wrote:
> On 3/28/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>> Is the set of possible names limited?  If yes, please read
>>  
>> <http://www.gnu.org/software/automake/manual/html_node/Conditional-Libtool-Libraries.html>
> 
> Hi,
> No... Sorry... I need to produce a different name chosen by configure
> and/or user.
> But exactly in the spirit of -rpath I believe -soname should be added... :)

-rpath is required for proper execution in many environments, the
ability to change the soname is, as far as I can tell, not.

Please present a more convincing argument.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Customizing soname

[Peter O'Gorman]

Alon Bar-Lev wrote:
> On 3/27/08, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
>> Why? I can understand wanting to change the extension, we have -shrext
>>  for that. But why do you want the user to have the option to set the name?
> 
> Hi!
> 
> Because I generate a plugin, each configuration results in different plugin.
> I also have this when I produce proxy shared library.
> 
> I can do this very simple with automake/libtool if I rename the output. But
> not got any solution of how to correct the soname.
> 
> Maybe I can do this with some ELF hacking utility, but I think that adding
> the ability to override the soname via libtool is the simplest and cleanest.

Does automake complain if you do something like:

@PLUGIN_TARGET@: foo.lo
$(LIBTOOL) --mode=link --tag=CC $(CCLD) -o @PLUGIN_TARGET@ \
foo.lo -avoid-version -module

install-exec-hook: @PLUGIN_TARGET@
$(LIBTOOL) --mode=install $(INSTALL) @PLUTIN_TARGET@ \
$(DESTDIR)$(libdir)

?

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Customizing soname

[Peter O'Gorman]

Alon Bar-Lev wrote:
> Hello,
> 
> I had an issue that I solved in patching libtool, I am not sure this was
> the right thing to do, but if it was, I think it should go into libtool.
> 
> I require to produce a shared library that whose name is customizable by
> the user.

Why? I can understand wanting to change the extension, we have -shrext
for that. But why do you want the user to have the option to set the name?

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: git mirror of Libtool CVS repo

[Peter O'Gorman]

Eric Blake wrote:
> According to Ralf Wildenhues on 3/9/2008 7:49 AM:
> | We expect to be switching toward git as primary hosting for the Libtool
> | code sometime soon, but probably not before 2.2.2.  We encourage you to
> | try out the git repo, report any issues, conversion bugs, suggestions.
> 
> For starters, you can't bootstrap the git repo.  Note these lines in
> configure:
> 
> TIMESTAMP=`${CONFIG_SHELL} ${ac_aux_dir}/mkstamp < ${srcdir}/ChangeLog`
> package_revision=`( set $TIMESTAMP; echo $1; )`
> 
> TIMESTAMP depends on libltdl/config/mkstamp parsing ChangeLog and
> producing non-empty output.  But without CVS $Id:$ expansion, there is no
> output, and set proceeds to display the entire environment into
> package_revision rather than setting the positional parameters.  This in
> turn leads to a corrupt Makefile.
> 
> We need to patch mkstamp to guarantee non-empty output, even when not used
> on a CVS checkout (or change the TIMESTAMP computation to deal with empty
> output from mkstamp).
> 

Not sure that we need the timestamp (the suggested way to report bugs
after make check failures includes a chunk of changelog), but if it is
decided that we do, then we can just make do with the topmost date in
the changelog file.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool