GNU Automake 1.10.1 released

I'm pleased to announce the release of Automake 1.10.1. Automake is a tool for automatically generating `Makefile.in's suitable for use with Autoconf, compliant with the GNU Makefile standards, and portable to various make implementations. This is primarily a bug-fix release, it contains a couple

Re: multilib dirs and ld.so

Hi Peter, * Peter O'Gorman wrote on Mon, Jan 21, 2008 at 07:29:08PM CET: > > I give up on trying to find fancy ways to set the paths, ok to apply > this to branch-1-5 (and similar for HEAD)? I suppose, yes, but I guess some mention in the documentation would not be bad. Thank you, Ralf __

Re: make -s

* Peter O'Gorman wrote on Mon, Jan 14, 2008 at 11:00:35PM CET: > Ralf Wildenhues wrote: > > > > Since repeatedly nobody stepped forward to do this, I wrote that patch > > myself now. OK to apply to HEAD? > > Yes. Thank y

Re: -prefer-pic

Hello Olly, * Olly Betts wrote on Thu, Jan 10, 2008 at 07:42:16PM CET: > The output from: > > libtool --help --mode=compile > > contains: > > -prefer-pic try to building PIC objects only > -prefer-non-pic try to building non-PIC objects only > > Firstly, that's poor grammar ("try t

Re: make -s

* Ralf Wildenhues wrote on Thu, Jan 10, 2008 at 08:29:33AM CET: > > For whatever output is left done by libtool I expect that whoever want's > it silenced hard enough will have enough motivation to send a patch to > <[EMAIL PROTECTED]>. Since repeatedly nobody stepped forw

Re: make -s

* Richard Hacker wrote on Mon, Jan 14, 2008 at 10:24:12AM CET: > On Sunday 13 January 2008 17:46, Ralf Wildenhues wrote: > > * Richard Hacker wrote on Fri, Jan 11, 2008 at 01:21:50PM CET: > > > > However, libtool is responsible for parsing *make's *FLAGS > >

Re: make -s

* Richard Hacker wrote on Fri, Jan 11, 2008 at 01:21:50PM CET: > On Thursday 10 January 2008 21:30, Ralf Wildenhues wrote: > > > > If you want all tools silenced which are called by make, then I suggest > > > > to simply use > > > > make >/dev/null

Re: relinking makes libtool link to the wrong library

* Simon Josefsson wrote on Fri, Jan 11, 2008 at 04:47:44PM CET: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > 1) ../lib/libgnutls.la has dependency_libs entry that contains -L/usr/lib > > and -L/usr/local/lib, both wrongly I think. Why is that? To find out,

Re: relinking makes libtool link to the wrong library

Hi Simon, 0) I forgot to ask: is this libtool 1.5.24? 1) ../lib/libgnutls.la has dependency_libs entry that contains -L/usr/lib and -L/usr/local/lib, both wrongly I think. Why is that? To find out, please send `libtool --debug --mode=link' output (not relink) for the creation of ../lib/libgnutl

Re: relinking makes libtool link to the wrong library

Hello Simon, * Simon Josefsson wrote on Fri, Jan 11, 2008 at 03:20:44PM CET: > Hi! We have received a bug report about some parts of recent gnutls > (libgnutls-extra.so.26) incorrectly links to the libgnutls.so in > /usr/lib/ rather than in $prefix, see original report: To be able to analyze it,

Re: Problem with libtool

Hello Richard, * Richard Graham wrote on Thu, Jan 10, 2008 at 10:14:46PM CET: > I am trying to build Open MPI on the Cray's (Compute Node Linux), and ran > into the following problem. In our configure script we get the wl parameter > set to -Wl, > > But when the following part of the build is ru

Re: support AIX 6.1 in config.rpath

* Ralf Wildenhues wrote on Tue, Jan 08, 2008 at 09:34:37PM CET: > * Rainer Tammer wrote on Tue, Jan 08, 2008 at 05:03:30PM CET: > > > The first part of the test run did produce some errors: > [...] > > did not find the `myfunc' function > > error was: Function not

Re: make -s

* Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:58:09PM CET: > On Thursday 10 January 2008, Ralf Wildenhues wrote: > > > > What I meant was: even with > > make -s LIBTOOLFLAGS=--silent > > > > there will be some leftover output done by libtool. If somebody wan

Re: multiple libraries with inter-dependencies and relinking with DESTDIR

* Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:29:29PM CET: > On Thursday 10 January 2008, Ralf Wildenhues wrote: > > * Mike Frysinger wrote on Mon, Dec 31, 2007 at 09:52:36PM CET: > > > when doing `make install DESTDIR=/some/place`, the relinking is fine for > >

Re: make -s

Hello Richard, * Richard Hacker wrote on Thu, Jan 10, 2008 at 01:39:31PM CET: > On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote: > > For whatever output is left done by libtool I expect that whoever want's > > it silenced hard enough will have enough motivatio

Re: multiple libraries with inter-dependencies and relinking with DESTDIR

Hello Mike, * Mike Frysinger wrote on Mon, Dec 31, 2007 at 09:52:36PM CET: > archives seem to indicate this has always been an issue, and while it's been > getting better over time, it hasnt really been considered "fully fixed". > what i'm looking at here is: > src/one/libone.la: > SOURCE

Re: libtool problem when cross compiling net-snmp

* Göran Hillebrink wrote on Thu, Jan 10, 2008 at 10:17:31AM CET: > > Attached are the logs you asked for. > libc is located in /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib. Thanks. So this is indeed the same issue as Mike Frysinger described in

Re: build check in AIX 5.2 / 5.3 / 6.1 - gcc/g++

Hello Rainer, * Rainer Tammer wrote on Thu, Jan 10, 2008 at 09:39:01AM CET: >>> If you like me to perforce some tests with gcc then I can try that too.. >> >> Yes, that would be great. The systems I test on currently don't have >> g++ or gfortran (or gcj) installed, so if you could test >> ./co

Re: make -s

Hello Mike, * Mike Frysinger wrote on Wed, Jan 09, 2008 at 10:17:45PM CET: > the request is to have the --silent flag passed automatically to > libtool if the -s flag is passed to make. alias 'make_s=make -s LIBTOOLFLAGS=--silent' For whatever output is left done by libtool I expect that whoever

Re: make -s

Hello Bob, * Bob Rossi wrote on Wed, Jan 09, 2008 at 08:52:20PM CET: > > When I do a 'make -s', I usually get no output from the compiler > commands. However with libtool, when it goes into, > mkdir .libs > then I see the compiler output. To me, you speak in riddles. Please just post what com

Re: "error while loading shared libraries: foo.so.0: cannot open shared object file: No such file or directory"

[ http://thread.gmane.org/gmane.comp.gnu.libtool.general/8726 ] Hello Laurence, Apologies for the delay, and apologies again for not citing better, and thanks for the report. There are two slightly differents setups, as far as Libtool is concerned. For the first one I can confirm your issue, bu

Re: build check in AIX 5.2 / 5.3 / 6.1

> is not allowed. While we're at it, let's fix that buglet, and a couple of other ones I found. Applied to branch-1-5 (HEAD is fixed already). Cheers, Ralf 2008-01-09 Ralf Wildenhues <[EMAIL PROTECTED]> * mdemo/main.c: Include string.h, for s

Re: build check in AIX 5.2 / 5.3 / 6.1

Hello Rainer, * Rainer Tammer wrote on Wed, Jan 09, 2008 at 12:25:03PM CET: > I have checked the following libtool versions on several AIX versions: > > 1. branch-1.5-20080108-cvs > > on AIX 5.2, 5.3, 6.1 > > result: > > AIX 5.2 / branch-1.5 / OK > AIX 5.3 / branch-1.5 / OK > AIX 6.1 / branch-1.5

Re: libtool problem when cross compiling net-snmp

Hello Göran, * Göran Hillebrink wrote on Wed, Jan 09, 2008 at 04:27:27PM CET: > > I'm trying to cross compile net-snmp but have run into a libtool > problem. I'm using libtool 1.5.24 together with net-snmp 5.4.1. > > I've tracked down the problem to archive_cmds in libtool. The $deplibs > parame

Re: ld --rpath problem using libtool

Hello Richard, * Richard Hacker wrote on Wed, Jan 09, 2008 at 07:40:57AM CET: > > Attached are the two logs that you have requested. I hope this helps you > further. At least my assumption that libtool should get a library's path > information from libx.la is not wrong. ;) > > Sorry for sendin

Re: mingw install directory for shared lib

Hello Bob, * Bob Rossi wrote on Tue, Jan 08, 2008 at 08:18:56PM CET: > > plugindir = $(libdir)/plugins > plugin_LTLIBRARIES = > plugin_LTLIBRARIES += libfoo.la > libfoo_la_SOURCES = foo.cc > libfoo_la_LDFLAGS = "-no-undefined" > > Now when I do 'make install' with --prefix=install I se

Re: ld --rpath problem using libtool

Hello Richard, I agree with your analysis that libtool should add the rpath, from what I can tell. * Richard Hacker wrote on Mon, Jan 07, 2008 at 08:59:37AM CET: > > /bin/sh ../libtool --mode=install /usr/bin/install -c '_rtcom.la' > '/opt/etherlab/lib/python2.5/site-packages/rtcom/_rtcom.la'

Re: rm -f

* Ralf Wildenhues wrote on Sat, Dec 22, 2007 at 06:47:41PM CET: > Proposed patch below should fix all instances. Please test, thanks. The patch does fix this issue, but the low max_cmd_len test still fails for another reason (failure of test `enforced lib prefix' with or without low max

Re: Relink on AIX: Doesn't Just Work (TM)

Hello Daniel, * Daniel Sands wrote on Thu, Dec 27, 2007 at 04:45:34AM CET: > When relink for install is done, any libs that are part of the same package > will be linked by their full installed path and not by -L,-l. This is > because hardcode_direct is set to "yes". It is true that if you speci

Re: rm -f

Proposed patch below should fix all instances. Please test, thanks. I'll probably apply after the holidays. Merry christmas everyone! Ralf 2007-12-22 Ralf Wildenhues <[EMAIL PROTECTED]> * libltdl/config/ltmain.m4sh (func_mode_link): When creating reloadable o

Re: rm -f

Hi Patrick, * Patrick Welche wrote on Fri, Dec 21, 2007 at 03:54:37PM CET: > > I think that question still stands, but my rm -f is actually from just above > that spot: Sorry, I haven't had time to look at this issue, and it may well be a few more days. > 6183# Handle the remainin

Re: My first experience as a libtool user: "A pain in the ar*se"

Hello bapluda, * bapluda wrote on Wed, Dec 19, 2007 at 09:08:21PM CET: > > [EMAIL PROTECTED]:~/temp/rcssserver-11.1.2/src> /bin/sh ../libtool --tag=CXX > --mode=link g++ -W -Wall -I./src -g -O2 -pthread -L/home/mysql/robocup/lib > -L/home/mysql/boost/lib -o rcssserver hetroplayer.o main.o fiel

Re: rm -f

Hello, * Patrick Welche wrote on Fri, Dec 14, 2007 at 08:58:51PM CET: > On Fri, Dec 14, 2007 at 12:27:48PM -0700, Eric Blake wrote: > > > > The general idiom for this is 'rm -f dummy $files', so that even if $files > > is empty, you are still passing an argument to rm, and the -f avoids > > failu

Re: Debugging subversion compile failure for 64bit platform.

* [EMAIL PROTECTED] wrote on Thu, Dec 13, 2007 at 04:39:44PM CET: > > > Which `./libtool --version'? > ltmain.sh (GNU libtool) 1.5.2 (1.1220.2.60 2004/01/25 12:25:08) That's way old. Please don't report bugs against such old versions, rather, if that libtool was generated by subversion's config

Re: Avoid la files.

* Duft Markus wrote on Thu, Dec 13, 2007 at 11:27:34AM CET: > > I'm not sure if i can easily put in HEAD, we use 1.5.24. Would it be > enough to get HEAD built somewhere, and bootstrap only the last > component with it (leave all libraries untouched)? Yes. > Maybe we can try on a linux box, w32

Re: Debugging subversion compile failure for 64bit platform.

Hello Igor, * [EMAIL PROTECTED] wrote on Thu, Dec 13, 2007 at 03:25:03PM CET: > > However the compilation of the swig-* components fails, as libtool is > dropping the -m64 flag somewhere. Which `./libtool --version'? Typically you can work around this using ./configure CC='cc -m64 -xarch=...'

Re: Avoid la files.

Hello Markus, Thanks for the report. * Duft Markus wrote on Thu, Dec 13, 2007 at 10:34:16AM CET: > > I have a quick question about libtool: What can I break, if I fool > libtool into thinking that there are no .la files for any library on the > command line? > > The background: We have a bunch

Re: Opening libraries by soname

Hello Paolo, * Paolo Bonzini wrote on Mon, Dec 10, 2007 at 09:44:55AM CET: > In debian, libncurses.so is not installed unless libncurses-dev is also > installed. Therefore, programs should open libncurses.so.5 directly. And on Solaris, the program should know that libncurses.so.5 on GNU/Linux h

Re: Make errors

Hello Joseph, * Joseph Maxwell wrote on Mon, Dec 03, 2007 at 06:01:39AM CET: > Installing libtool-1.5.24 > > make > libtool.texi:3733: Misplaced }. > libtool.texi:3734: Unknown command `command'. Several things to say here: Your makeinfo program (from the texinfo package) is way too old

Re: Moving Installed Libraries built with libtool

Hello, * Benoit Sigoure wrote on Tue, Dec 04, 2007 at 08:39:42AM CET: > So yeah it's a bit of an issue, I guess people often come up with > wrapper scripts that set the right LD_LIBRARY_PATH and then exec the > binary but that's not always a viable solution. You may want to check out the relo

Re: MinGW/Cygwin wrapper bug

* Bob Friesenhahn wrote on Tue, Dec 04, 2007 at 10:30:25PM CET: > >Which of the two suspected setups is the failing one? > > To make things more clear, the problem is entirely which DLL is used > when the wrapper script/program is executed. Libtool builds a correct > DLL, but when 'make check'

Re: MinGW/Cygwin wrapper bug

* Bob Friesenhahn wrote on Tue, Dec 04, 2007 at 10:09:25PM CET: > > I am not sure how to wrap it up in a test. The problem is not an > obscure error since it is always present. I am surprised that I am > the only one who has reported the problem. OK so here's a try of mine. Can you confirm t

Re: MinGW/Cygwin wrapper bug

Hi Bob, * Bob Friesenhahn wrote on Tue, Dec 04, 2007 at 03:24:41AM CET: > I notice that the wrapper that libtool builds for MinGW/Cygwin still > has a nasty bug in which tests of a shared build will wrongly use an > already installed DLL rather than the one just built. The system uses > PATH t

Re: Favoring static linking at configure time

Hello, * Brian Dessent wrote on Tue, Dec 04, 2007 at 07:20:40PM CET: > Benoit Sigoure wrote: > > > > Of course there is: -Wl,-Bstatic -lfoo -Wl,-Bdynamic > > > > Hmm I didn't know this. How portable is it? I guess a gccism, but > > is it even portable across versions/ports of GCC? [...] > -B s

Re: doc in more formats

Hello Karl, * Karl Berry wrote on Sun, Dec 02, 2007 at 11:08:53PM CET: > > It is desirable to make GNU package documentation available online in > lots of formats, not just HTML, which is all I see at > http://www.gnu.org/software/libtool/manual.html. Sure. I was planning to do that at the same

Re: [PATCH] small fix for the libtool manual

Hello Stefan, * Stefan Sperling wrote on Wed, Nov 28, 2007 at 05:13:39PM CET: > > the "Using libtool" section in the manual starts talking about > a "wrapper script" in one paragraph without explaining beforehand > what that script is. [...] > The following patch simply reverts the order of those

Re: relocatable .la files

Hello C.J., * C.J. Adams-Collier wrote on Mon, Nov 19, 2007 at 04:27:41AM CET: > There was a thread some time ago (11/2004) about having a variable in .la > files evaluated at runtime. This seems like a good idea to me, and would > work well with pkg-config's ${pcfiledir} variable. But it won't

Re: foreach_dirinpath on Solaris 10

heck that this eliminates the type warnings for you. Cheers, Ralf 2007-11-15 Ralf Wildenhues <[EMAIL PROTECTED]> Avoid mixing functions and data pointers in callback functions. * libltdl/ltdl.c (file_worker_func): New type. (lt_dlforeachfile): Instead of passing a functi

Re: only build/install shared library for a particular directory

* Bob Rossi wrote on Thu, Nov 15, 2007 at 07:25:28PM CET: > On Thu, Nov 15, 2007 at 06:45:15PM +0100, Ralf Wildenhues wrote: > > > > You can try putting --tag=disable-static in *_LIBTOOLFLAGS (i.e., to > > appear before --mode on the command line; *_LIBTOOLFLAGS require

Re: libtool using problem

Hello Volter, * Volter Yen wrote on Wed, Nov 14, 2007 at 03:12:18AM CET: > > $/bin/sh ../libtool --tag=CC --mode=link arm_v5t_le-gcc -g -O2 > -L/opt/mv_pro_4.0/montavista/pro/devkit/arm/v5t_le/target/usr/lib -o > libgstflumpegdemux.la -rpath > /home/test/workdir/filesys/usr/lib/gstreamer-0.

Re: only build/install shared library for a particular directory

Hello Bob, * Bob Rossi wrote on Thu, Nov 15, 2007 at 04:54:05PM CET: > > Is it possible to only build and install shared libraries for a > particular directory? I don't want to waste time building and installing > static libraries, considering these library are used by dlopen. You can try puttin

Re: C++ Plugins and virtual destructors.

* Daniel Herring wrote on Mon, Nov 12, 2007 at 07:46:55AM CET: > > Here's a relevant post from the GCC list; it mentions how to work around > some dlopen difficulties (including RTTI, exceptions, custom new/delete). > http://gcc.gnu.org/ml/gcc-help/2007-10/msg00248.html Thanks for this link. FWI

Re: Sun Studio linking issues in Solaris 9

Hello David, Thanks for the report. * David Halik wrote on Sun, Nov 11, 2007 at 07:03:21PM CET: > > /bin/bash ./libtool --tag=CC --mode=link cc -I.. -I./.. -module -rpath > /usr/local/lib/courier-authlib -export-symbols-regex 'courier_auth.*_init' > -lldap -llber -lresolv -lsocket -lnsl -L/

Re: C++ Plugins and virtual destructors.

Hello Brendon, * Brendon Costa wrote on Fri, Nov 09, 2007 at 03:20:27AM CET: > > Is using virtual destructors fine with a C++ plugin interface? Good question. > I have an example below that works. Means you've got it to work with which set of compilers on what list of systems? > However i am

Re: Saving the -R flags in the .la file?

the run path is not as easy as it looks like (it basically shares most of the error-prone-ness with hardcode.test). Cheers, Ralf 2007-11-08 Ralf Wildenhues <[EMAIL PROTECTED]> * tests/runpath-in-lalib.at: New test. * Makefile.am: Update. Report by Benoi

Re: install .so library on aix

* Беляев Анатолий Анатольевич wrote on Tue, Nov 06, 2007 at 01:30:11PM CET: > I need run time linking for library and > I already use this flag for LDFLAGS but it doesn't help. > There are compiling and gmake install log from my AIX > Any other ideas about it? [...] > /bin/sh ../libtool --tag=C

Re: Libtool modules and symbol clashes

Hello Simon, * Simon White wrote on Tue, Nov 06, 2007 at 04:03:48PM CET: > > I have some modules with the same exported interface. All modules are > built to hide all symbols by default with only the public ones being > marked as __attribute__((visibility("default"))). They are designed > to be

Re: Libtool uses obsolete Autoconf macros

Hello Benoit, * Benoit SIGOURE wrote on Sat, Nov 03, 2007 at 10:52:31PM CET: > I don't know whether this is intended (for, say, backward > compatibility with older Autoconf) but Libtool uses obsolete macros > which generates "spurious" warning in my testsuite. Yes, exactly for backward compat

Re: Libtool doesn't set -rpath automatically when needed?

* Benoit SIGOURE wrote on Sat, Nov 03, 2007 at 02:52:25PM CET: > > Oh I see. Great. All in all, I think I do better document that > "libtool is required" because it does solve all sorts of problems. > What's the recommended way of doing this? Simply stating the > dependency in the docume

Re: Libtool doesn't set -rpath automatically when needed?

* Benoit SIGOURE wrote on Sat, Nov 03, 2007 at 11:44:15AM CET: > On Nov 3, 2007, at 9:53 AM, Ralf Wildenhues wrote: > > > >Libtool doesn't add run paths to installed libraries without .la > >files. (How should it know that it should not only add > >/usr/local/lib

Re: Libtool doesn't set -rpath automatically when needed?

Hello Benoit, * Benoit SIGOURE wrote on Fri, Nov 02, 2007 at 10:34:13PM CET: > On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4 > (1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under /usr/ > local/lib (pre-built binaries: http://www.tsunanet.net/~tsuna/ > boost_1_34_1-i

Re: removing rpath from libtool

Hello Michel, * BRIAND, Michel M wrote on Tue, Oct 30, 2007 at 05:22:02PM CET: > > I would like to know why LD_LIBRARY_PATH is evil. > > Because, here, we have several thousand of applications (!) installed on > NFS shares that have each : > - a bin directory > - a lib directory > ... > - an env

Re: HP-UX shared lib detection (1.5.24)

* Roger While wrote on Wed, Oct 31, 2007 at 08:13:45PM CET: > host='hppa2.0w-hp-hpux11.11' > host_alias='' > host_cpu='hppa2.0w' > host_os='hpux11.11' > > It's being passed +DA2.0W not +DD64 as documented by HP > for PA. > > AFAIK, DD64 was meant for IA64. Ah, ok I was looking at older documenta

Re: HP-UX shared lib detection (1.5.24)

Hello Roger, * Roger While wrote on Wed, Oct 31, 2007 at 04:55:09PM CET: > In all the 32-bit versions of shared libraries, it seems that > the blank is absent between PA-RISC and the x.x. What's the value of $host in the generated libtool file? The trick to get config.guess to compute for example

Re: install .so library on aix

Hello, * [EMAIL PROTECTED] wrote on Mon, Oct 29, 2007 at 01:23:54PM CET: > Hi, > I manage to build .so shared library on aix using libtool. But I have > problem > with installing it using gmake install. Libtool install two files. > One is .a and second is .la(wich is actualy the libtool script)

Re: libtool versioning and sonames

* Andreas Metzler wrote on Sun, Oct 28, 2007 at 01:28:54PM CET: > > Are there libtool-supported archs whose versioning will break if we do > this > num c r a > 2.1.1 22 1 9 > 2.1.2 14 0 0 > > instead of > num c r a > 2.1.1 22 1 9 > 2.1.

Re: libtool versioning and sonames

Hello Andreas, * Andreas Metzler wrote on Sun, Oct 28, 2007 at 09:34:25AM CET: > > [...] However, the way libtool > tries to represent this information in sonames (on Linux) is rather > strange, it goes straight from libgnutls.so.13 to libgnutls.so.23. Is > this huge jump just bug or is there a r

Re: Why is "setting LD_LIBRARY_PATH very bad"?

Hello Jan, all, * Jan Horan wrote on Thu, Oct 25, 2007 at 11:06:55AM CEST: > > Note also that using of RPATH is obsolete (DT_RPATH in ELF) due to > it's incorrect precedence to LD_LIBRARY_PATH. > RUNPATH (DT_RUNPATH) should be used instead. This is from man ld.so: This is very platform specific (

Re: removing rpath from libtool

Hello Wintaki, * Wintaki Hagabashi wrote on Wed, Oct 24, 2007 at 09:59:29PM CEST: > * Ralf Wildenhues wrote: > > * Wintaki Hagabashi wrote on Tue, Oct 23, 2007 at 08:21:57PM CEST: > > > How can we disable libtools use of rpath? [...] > > The use of run paths ensures tha

Re: removing rpath from libtool

Hello Wintaki, * Wintaki Hagabashi wrote on Tue, Oct 23, 2007 at 08:21:57PM CEST: > > We are using libtool 1.5.6. The current release is 1.5.24. Not that it has much to do with your issue, but otherwise there are many changes since. Please update. > How can we disable libtools use of rpath?

Re: Libtool errors when trying to compile mod-xslt2

Hello Bill, * Bill Farrar wrote on Wed, Oct 24, 2007 at 08:24:30PM CEST: > > $(LIBTOOL) --mode=compile > > Add this: > > --tag CC > > This allows the compile to complete. Better yet, if the sources are all C, just set LIBTOOL = @LIBTOOL@ --tag=CC in the Makefile.in files. Rerun "./config

Re: inter-library linking

* Joachim Worringen wrote on Tue, Oct 16, 2007 at 11:24:27AM CEST: > Ralf Wildenhues wrote: >>>> 1) Explicit linkage of libshared against libfoo should cause the runtime >>>> linker to pull it in: >>>> lib_LTLIBRARIES = libfoo.la libshared.la

Re: inter-library linking

* Joachim Worringen wrote on Fri, Oct 12, 2007 at 06:39:20PM CEST: > Ralf Wildenhues wrote: > > >Another general remark: convenience libraries don't enter the picture > >here much; think of them as a short-hand notation for a collection of > >objects that will all be

Re: [libtool 2.1a] testsuite: 25 26 un-"expected failure" onhppa2.0w-hpux11.11

Hello Michael, Thanks for the report. * Michael Haubenwallner wrote on Fri, Oct 12, 2007 at 11:26:06AM CEST: > > libtool-2.1a (Build: 1.2519 2007/10/09 19:32:44) cannot do DESTDIR > installs (at least) on hppa2.0w-hp-hpux11.11. That is correct. On systems where ./libtool --config | grep fast

Re: inter-library linking

Hello Joachim, * Joachim Worringen wrote on Fri, Oct 12, 2007 at 02:39:16PM CEST: > > "libshared" needs to be a shared library, as it will be used with > LD_RELOAD. It builds from its own sources, but also depends on two other > libraries that are built within the same source three: "libnoinst"

Re: Relinking to wrong version

* Dustin J. Mitchell wrote on Fri, Oct 12, 2007 at 07:39:04AM CEST: > > Why is libtool letting the linker look for the library in the > mode=relink invocation, when it used an explicit path to the .so in > the mode=link invocation? Hmm, I would have to go and check whether there is something that

Re: Relinking to wrong version

Hello Dustin, * Dustin J. Mitchell wrote on Thu, Oct 11, 2007 at 11:41:20PM CEST: > Excuse the long intro here, but I'm not sure how to slim this down. You shouldn't. It was just about a perfect report, thank you! > The problem comes when, on 'make install', libtool relinks the library: [...] >

Re: Relinking issue

Hello Markus, * Duft Markus wrote on Tue, Oct 09, 2007 at 09:25:15AM CEST: > > Regarding CVS HEAD: since this is all for production use on many, many > platforms, i can't upgrade (it's simply not my decision). Is HEAD > somewhat stable anyway? I noticed that binutils 2.18 use 2.1a, and - arg > -

Re: Relinking issue

Hello Markus, * Duft Markus wrote on Mon, Oct 08, 2007 at 10:40:24AM CEST: > > I'm again having issues with relinking: I have > shlibpath_overrides_runpath set to yes (which is really true now for my > compiler), which effectively prevents relinking, but only of libraries. > > Somehow executable

Re: Question about shlibpath_overrides_runpath / relinking

Hello Markus, * Duft Markus wrote on Tue, Oct 02, 2007 at 09:03:20AM CEST: > Ralf Wildenhues <> wrote: > > * Duft Markus wrote on Mon, Oct 01, 2007 at 01:55:55PM CEST: > >> > >> Still i feel, that relinking should not be neccessary with my > >> com

Re: Question about shlibpath_overrides_runpath / relinking

Hello Markus, * Duft Markus wrote on Mon, Oct 01, 2007 at 01:55:55PM CEST: > > Still i feel, that relinking should not be neccessary with my compiler [...] > Is there any other way to tell libtool, that it should not relink, which > does not break anything else. AFAIR we fixed that in CVS HEAD,

Re: bug with dlpreopening c++ modules (shared objects)

Hello Christian, * Christian Keil wrote on Mon, Sep 24, 2007 at 05:14:44PM CEST: > > I might have discovered a bug with regard to dlpreopening when dealing > with c++ modules. > > The attached tar.gz contains a very small project that just tries to > open a module specified on the command line a

Re: libtool make check bug

Hello Rafael, * Rafael De Jesus wrote on Wed, Sep 26, 2007 at 07:18:33PM CEST: > While doing a make check I got the following error(see below). Can > someone tell me how to proceed? [...] > FAIL: hardcode.test [...] > > 1 of 112 tests failed > Please report to

Re: Libtool 1.5.24 tests failed on Solaris 10

Hello Piotr, Thanks for the report. * Piotr Tarnowski wrote on Fri, Sep 28, 2007 at 03:40:49PM CEST: > Machine hardware: sun4u > OS version: 5.10 > Processor type: sparc > Hardware: SUNW,Sun-Fire-V890 [...] > Sun Studio 12 C++ Compiler [...] > 3 of 108 tests failed

Re: Migration to Git?

Hello Benoit, all, * Benoit SIGOURE wrote on Sun, Sep 30, 2007 at 04:08:46PM CEST: > Hello, > several GNU projects (including autoconf) have moved to Git, is there > any similar plan for automake and libtool? Is anyone in charge of > this? Help needed? Gary has had Libtool stuff in tla some

Re: link_all_deplibs feature

* Alexander Leidinger wrote on Fri, Sep 07, 2007 at 07:43:56PM CEST: > Quoting Ralf Wildenhues (Fri, 7 Sep 2007 14:56:46 +0200): > > * Alexander Leidinger wrote on Thu, Sep 06, 2007 at 10:23:32AM CEST: > > > > > > In revision 1.47.2.12 (bra

Re: lt_dlcaller_set_data interface question

Hello Eric, Thanks for the problem report and analysis. * Eric Blake wrote on Wed, Sep 05, 2007 at 08:18:17PM CEST: > > Ultimately, this boils down to an interface question of what should happen if > prior errors are ignored: > > Is this a bug in m4, for not calling lt_dlerror to clear errors

Re: link_all_deplibs feature

* Ralf Wildenhues wrote on Thu, Sep 06, 2007 at 05:58:05PM CEST: > Hello Alexander, [...] It seems that my message did not get through to Alexander, he contacted me off-list. Well, I had you in To: in my previous message, so there is little reason to assume that another off-list message of m

Re: i18n and lt_dlerror

Hi Eric, * Eric Blake wrote on Wed, Sep 05, 2007 at 10:30:39PM CEST: > Has anyone tried to use gettext to provide translations for all of the > strings returned by lt_dlerror? AFAIK no. That would be a good project for right after 2.2. > Should all of the strings in lt_error.h be marked N_, the

Re: link_all_deplibs feature

Hello Alexander, * Alexander Leidinger wrote on Thu, Sep 06, 2007 at 10:23:32AM CEST: > > In revision 1.47.2.12 (branch-1-5) of ltdl.m4 you set > libltdl_cv_sys_dlopen_deplibs to yes for DragonFlyBSD and FreeBSD. This is > because the runtime linkers recursively open dependencies (libs) themself

Re: multilib dirs and ld.so

Hi Peter, * Peter O'Gorman wrote on Wed, Sep 05, 2007 at 08:02:59AM CEST: > Proposed patches for branch-1-5 and HEAD. > > Okay to apply? Not quite, I'm afraid. First, please put $CPPFLAGS before $LDFLAGS, for consistency. Then, this code is used in each tag -- Fortran compilers don't like file

Re: Linking with both -release and -version-info

Hello Joe, * Joe Orton wrote on Sun, Sep 02, 2007 at 10:00:06PM CEST: > Hi. Is it correct to assume that libtool does support the simultaneous > use of -release and -version-info when linking a given library, by > design? The manual only talks about -release as an alternative to > -version-in

Re: multiple compilers

Hello Christopher, * Christopher Hulbert wrote on Tue, Aug 28, 2007 at 12:35:43AM CEST: > > The cell processor has 2 different "architecture" cores. There's a > compiler for the PowerPC and a compiler for the SPU. The SPU image can > be embedded into the powerpc executable via a special command,

Linux 2.6.23: getconf ARG_MAX?

Hello Libtool list readers, does anybody know whether the lift of the argument length limit that is to appear in Linux 2.6.23 will (now or in the future) affect output of getconf ARG_MAX and if yes, how? We may want to adjust AC_LIBTOOL_SYS_MAX_CMD_LEN resp. LT_CMD_MAX_LEN early to avoid issue

Re: multiple compilers

Hello Christopher, * Christopher Hulbert wrote on Mon, Aug 27, 2007 at 03:39:21PM CEST: > I'm starting to think about how to compile/link for the cell processor > using the autotools. My first thought was to configure for the PowerPC > processor, then override the C compiler for the SPU source fil

Re: libltdl convenience missing make targets

* Philip Kovacs wrote on Fri, Aug 24, 2007 at 01:17:58AM CEST: > * Benoit SIGOURE <[EMAIL PROTECTED]> [2007-08-23 09:40:50 +0200]: > > > > That's nothing to do with your problem but... why don't you use autoreconf > > --force --verbose --install instead of manually calling all these tools? > > J

Re: libltdl convenience missing make targets

Hello, * Bob Friesenhahn wrote on Thu, Aug 23, 2007 at 06:47:38AM CEST: > On Thu, 23 Aug 2007, Philip Kovacs wrote: > >> I'm using libtool 1.5.24 with libltdl as a convenience library in subdir >> ./libltdl. [...] >> The problem is that make targets 'dist' and 'distcheck' yield the error: >> >> m

Re: Libtool woes

Hello Jason, Brian, all, * Jason Curl wrote on Mon, Aug 20, 2007 at 11:41:03AM CEST: > Brian Dessent wrote: >> [ snip nice, concise and well-written explanations ] >> > Brian - thanks for the concise description. Ralf - any way to may be > add an addendum to the libtool docs for this, just for inf

Re: linking against local libs across directories and DESTDIR

Hello Mike, * Mike Frysinger wrote on Mon, Aug 20, 2007 at 05:46:14AM CEST: > there a list of good hints out there for managing libs across > directories ? i flipped through the libtool manual and the autobook > but didnt really find anything ... I think the total ordering implied via partial SU

Re: Libtool woes

* Brian Dessent wrote on Fri, Aug 17, 2007 at 09:49:48PM CEST: > Jason Curl wrote: > > > lib -OUT:.libs/libtp.lib version.o > > ../libtool: line 5973: lib: command not found > > I'm not sure why it's trying to use lib here, that seems wrong if you're > using gcc/binutils. Possibly a configure p

<    2   3   4   5   6   7   8   9   10   11   >