License of m4/ltoptions.m4

Hello! There is no exception from the GPL in m4/ltoptions.m4, like there is in the other lt*.m4 files in that directory. Is that an oversight or is this file only needed for backwards compatibility or something like that? Cheers, Peter ___ Libtool mai

serial number of ltversion.m4 and libtoolize

Hello! The serial number of the generated m4/ltversion.m4 is not recognized by the libtoolize script. func_serial() does not expect dots in the serial numbers of the macro files. This is for branch-2-0. Cheers, Peter ___ Libtool mailing list [EMAIL

RE: serial number of ltversion.m4 and libtoolize

I wrote: > The serial number of the generated m4/ltversion.m4 is not > recognized by the libtoolize script. func_serial() does > not expect dots in the serial numbers of the macro files. > > This is for branch-2-0. I should perhaps also mention why I think this is a problem. Consider the last lin

RE: Using libtool 2.0 in autoconf tests

Sander Niemeijer wrote: > Hi, > > I have send this question to the list about a month ago, but > unfortunately, there hasn't been an answer yet, and the release of > libtool 2.0 is not that far away (right?). > > >

RE: Using libtool 2.0 in autoconf tests

Gary V. Vaughan wrote: > Ralf Wildenhues wrote: >> * Sander Niemeijer wrote on Thu, Nov 18, 2004 at 01:54:12PM CET: >>> >>> I have some self written autoconf tests that check for linking >>> shared libraries against some specific other libraries (these other >>> libraries should be available as sh

IRIX 6.5 and exporting symbols.

Hello! I tried to build a library on IRIX 6.5 using libtool branch-2.0 (fairly up to date) and gcc 3.2, and it fails. The failing command is this: /bin/sh ../libtool --mode=link --tag=CC gcc -g -O2 -Wall -pedantic -D_REENTRANT -D_THREAD_SAFE -DDEBUG -g -std=gnu99 -Wpointer-arith -Wsign-compare

Install of libtool module on AIX 4.2 does not work.

Hello! When installing a "libtool module" on aix 4.2, the .so file is not installed, even though the .la file specifies: dlname='x.so' Copying x.so to the intended directory makes it work. However, trying to dlopen more than one such DSO does not work for some reason yet unknown to me. But one is

RE: IRIX 6.5 and exporting symbols.

Albert Chin wrote: > On Tue, Jan 11, 2005 at 10:07:13AM +0100, Peter Ekberg wrote: >> gcc -shared .libs/cleanup.o .libs/cleanup_stubs.o .libs/cpuid.o >> .libs/conf.o .libs/debug.o .libs/dl.o .libs/init.o .libs/misc.o >> .libs/parse.o .libs/string.o .libs/time.o .libs/

RE: Install of libtool module on AIX 4.2 does not work.

Albert Chin wrote: > On Tue, Jan 11, 2005 at 06:31:19PM +0100, Peter Ekberg wrote: >> When installing a "libtool module" on aix 4.2, the .so file is not >> installed, even though the .la file specifies: >> dlname='x.so' >> >> Copying

RE: Install of libtool module on AIX 4.2 does not work.

Albert Chin wrote: > On Thu, Jan 13, 2005 at 07:32:46PM +0100, Peter Ekberg wrote: >> Albert Chin wrote: >>> On Tue, Jan 11, 2005 at 06:31:19PM +0100, Peter Ekberg wrote: >>>> When installing a "libtool module" on aix 4.2, the .so file is not >>&g

RE: libtool ChangeLog [branch-2-0]

Peter O'Gorman wrote: > Peter Ekberg wrote: > | CVSROOT:/cvsroot/libtool > | Module name:libtool > | Branch: branch-2-0 > | Changes by: Peter Ekberg <[EMAIL PROTECTED]> > 05/07/28 09:06:07 > > Thank you very much for all these commits

Libtool never sets exeext.

I'm curious about these lines in m4/libtool.m4: AC_REQUIRE([AC_EXEEXT])dnl _LT_DECL([], [exeext], [0], [Executable file suffix (normally "")])dnl exeext is empty on Windows, shouldn't it be: AC_REQUIRE([AC_EXEEXT])dnl _LT_DECL([exeext], [ac_exeext], [0], [Executable file suffix (normally "")])dn

mdemo2-make.test on MinGW failure in libtool 2-0 and head.

Hi! I have looked at the reason why the mdemo2-make.test fails on MinGW. The reason is that the mlib_func symbol is not properly exported from libmlib (i.e. not present in the import lib). I see two solutions to make the test pass. 1. Add ' -export-symbols-regex "mlib_func"' to libmlib_la_LDFLA

RE: libtool ChangeLog [branch-2-0]

Ralf Wildenhues wrote: > * Peter Ekberg wrote on Thu, Jul 28, 2005 at 03:18:18PM CEST: > > > > I came across a surprise in the commit script though. When > > commiting on branch-2-0, the script checked for conflicts > > against head, which forced me to --force one comm

RE: config.status (or something) writes out a crippled libtool script

I wrote: > PS. Should not Makefile.am be added to libltdl/Makefile.am? Blast, that should have been "added to libltdl/.cvsignore"... Cheers, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

RE: CVS branch-2-0 R.I.P.

Gary V. Vaughan wrote: > Sent: Friday, August 26, 2005 14:10 > To: Libtool > Subject: CVS branch-2-0 R.I.P. > > Fellow Libtoolers (if you're reading, that means you!), > > I still have reservations, but am otherwise somewhat convinced that > dropping development of branch-2-0 in favour of HEAD is

RE: config.status (or something) writes out a crippled libtool script

Ralf Wildenhues wrote: > > > > 10. make > > > [ triggers ltmain.m4sh -> ltmain.sh recreation ] > > > > /bin/sh: autom4te: command not found > > > *snip* > > > > > > Thanks for this report. Can you try the attached patch? > It has the > > > > Seems to work nicely. Thanks! > > Yet it's the wron

RE: Libtool API suggestion: LTDL_SHLIB_PRE and/or char*ltdl_map_shared_name(const char* name)

* Alexandre Oliva wrote on Thursday, September 08, 2005 22:13 CEST: > On Aug 23, 2005, Albert Chin <[EMAIL PROTECTED]> wrote: > > >> [2] ltdl.c from HEAD: > >> 812 if (strncmp(p, "-l", 2) == 0) > >> 813 { > >> 814 size_t name_len = 3+ /* "lib" */ LT_

RE: Got shared libraries to build with libtool on MinGW, but it was a struggle

* Alan W. Irwin wrote on Friday, September 16, 2005 19:22 CEST: *snip* > Perhaps the flags on the sed command affect the outcome for > MinGW? Here is > the full command in func_win32_libid that is failing on MinGW. > > win32_nmres=`eval $NM -f posix -A $1 | \ > sed -n -e '1,100{/ I /{x;/import/!

Re: archive_commands

On Fri, Feb 10, 2006 at 04:30:08PM -0500, Christopher Hulbert wrote: > archive_cmds="\$CC -o \$lib \$libobjs \$compiler_flags \\\`echo > \\\"\$deplibs\\\" | \$SED -e 's/ -lc\$//'\\\` -link -dll~linknames=" > > > What is the -link and -dll doing? This messes up my linking with the > PGI C compile

Re: static lib containing backends

Hi! On Thu, Feb 09, 2006 at 05:08:59PM +0100, Ralf Wildenhues wrote: > * Bob Friesenhahn wrote on Thu, Feb 09, 2006 at 05:02:37PM CET: > > On Thu, 9 Feb 2006, Ralf Wildenhues wrote: > > > > > >It's not really libltdl that needs changes for MSVC. The libtool script > > >itself does (more precisely

Re: MSVC Support

On Sat, Jun 10, 2006 at 07:02:02PM +1000, Brendon Costa wrote: > I will have a better look at the MSVC patch mentioned before when i > better understand how libtool operates. > > > I guess i am asking you people with more experience, is this a > reasonable path to be taking? Also i am almost cert

Different content for static and shared library.

Hello! (For the record, I think what I'm trying to achieve can be solved with libltdl, but I do not wish to use libltdl for licensing reasons. I have complete understanding with not getting any sympathy for that decision. I'm just asking if there is a way out of my linking troubles...) In a p

Re: Different content for static and shared library.

How annoying. I didn't test the example tarball and of course didn't notice two files missing until after I hit 'send'. I also added a -ldl for good measure, it wasn't needed on my test platform. Here's an updated example. Sorry for the inconvenience. Cheers, Peter example.tar.gz Description: a