Re: [Fink-devel] OS/X Libtool && -bundle
On Wednesday, February 5, 2003, at 10:46 PM, Robert Boehne wrote: In an older version of Libtool, a library built with -module is linked with: cc -flat_namespace -undefined suppress -o .libs/libdb_tcl-4.2.so *.lo -lc -dynamiclib -install_name /Users/rboehne/testdb/lib/libdb_tcl-4.2.so That is wrong, that was a bug in libtool. Thats a shared library, not a bundle. But this method doesn't seem to work: [dsl092-075-147:~/new-db-4.2.8/build_unix] rboehne% file ..libs/libdb_tcl-4.2.so ..libs/libdb_tcl-4.2.so: Mach-O bundle ppc [dsl092-075-147:~/new-db-4.2.8/build_unix] rboehne% ./libtool --version ltmain.sh (GNU libtool) 1.4e (1.1182 2003/01/29 04:57:52) Actually, that is correct. libtool works fine. modules are type bundle. It looks to me like this should work, a module should be dlopen-able, wheras a Libtool library not built with -module may not. If I take out the -module from the link line, I get .libs/libdb_tcl-4.2.dylib and tclsh is able to dlopen it. Part of what really troubles me is that "file" doesn't return You aren't supposed to be dlopening dylibs, though it is possible. the same thing on the libraries. I do notice that "file" gives the same result I'm getting on all the *.so files under /usr/lib/ though. So am I supposed to be able to dlopen() a "bundle", and if not, what can be done with it? I'm confused. Mach-O "bundles" (tyee MH_BUNDLE) are libtool -modules (shared modules) on OS X. Mach-O "shared libraries" (type MH_DYLIB) are different. On linux, they are the same. Dyanmic libraries get the extension "dylib" Modules get the extension ".so" You can dlopen dylibs, but you can only dlclose() bundles. You cannot close a MH_DYLIB once it is opened. See "man ld" for (much) more info than i can give. :) btw, i think the bind_at_load two-step stuff is only need for C++. It shouldn't be in the C part of libtool. pogma? If you are trying to build tcltk, you might need the fink patches to the makefile. See /sw/fink/10.2/unstable/main/finkinfo/languages/tcltk-8.3.4-1.info and /sw/fink/10.2/unstable/main/finkinfo/languages/tcltk-8.3.4-1.patch -Ben ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
OS/X Libtool && -bundle
Hello, I'm having problems with Mac OS/X in CVS Libtool, and I wonder if some of you more familiar with the platform could help out. In an older version of Libtool, a library built with -module is linked with: cc -flat_namespace -undefined suppress -o .libs/libdb_tcl-4.2.so *.lo -lc -dynamiclib -install_name /Users/rboehne/testdb/lib/libdb_tcl-4.2.so Which works like I'd expect: [dsl092-075-147:~/db-4.2.8/build_unix] rboehne% file .libs/libdb_tcl-4.2.so .libs/libdb_tcl-4.2.so: Mach-O dynamically linked shared library ppc [dsl092-075-147:~/db-4.2.8/build_unix] rboehne% ./libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) [dsl092-075-147:~/db-4.2.8/build_unix] rboehne% man ld [dsl092-075-147:~/db-4.2.8/build_unix] rboehne% /usr/bin/tclsh8.3 % source ../test/test.tcl % exit More recent (CVS) Libtool uses a two-step linking process when -module is present on the Libtool link line, like so: cc -r -Wl,-bind_at_load -keep_private_externs -nostdlib -o .libs/libdb_tcl-4.2.so-master.o .libs/*.o && cc -bundle -flat_namespace -undefined suppress -o .libs/libdb_tcl-4.2.so . libs/libdb_tcl-4.2.so-master.o But this method doesn't seem to work: [dsl092-075-147:~/new-db-4.2.8/build_unix] rboehne% file .libs/libdb_tcl-4.2.so .libs/libdb_tcl-4.2.so: Mach-O bundle ppc [dsl092-075-147:~/new-db-4.2.8/build_unix] rboehne% ./libtool --version ltmain.sh (GNU libtool) 1.4e (1.1182 2003/01/29 04:57:52) Copyright 1996, 1997, 1998, 1999, 2000, 2001 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. [dsl092-075-147:~/new-db-4.2.8/build_unix] rboehne% /usr/bin/tclsh8.3 % source ../test/test.tcl dyld: /usr/bin/tclsh8.3 malformed library: .libs/libdb_tcl-4.2.so (not a Mach-O library file, bad filetype value) % exit It looks to me like this should work, a module should be dlopen-able, wheras a Libtool library not built with -module may not. If I take out the -module from the link line, I get .libs/libdb_tcl-4.2.dylib and tclsh is able to dlopen it. Part of what really troubles me is that "file" doesn't return the same thing on the libraries. I do notice that "file" gives the same result I'm getting on all the *.so files under /usr/lib/ though. So am I supposed to be able to dlopen() a "bundle", and if not, what can be done with it? I'm confused. Thanks, Robert Boehne ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: linux/alpha and ccc compiler
Bob, Does this patch actually work? It looks to me like you're inheriting gcc's configuration and then changing one flag. If you have not run the test suite yet, run it and post the results. Where did this compiler come from? I've been using Alphas since mips/ULTRIX went away, and I've never heard of this compiler. Follow the advice I gave you previously, read the documenation and run the test suite to see how you're going. For comparison, CVS Libtool passes all 105 tests with c89, cxx and f90 on my Tru64 4.0f machine. Robert Bob McElrath wrote: > > Here is a trivial patch to add Compaq's alpha c compiler (ccc) to > libtool.m4. This is against CVS head. > > Cheers, > Bob McElrath [Univ. of Wisconsin at Madison, Department of Physics] > > "You measure democracy by the freedom it gives its dissidents, not the > freedom it gives its assimilated conformists." -- Abbie Hoffman > > > Name: >libtool.m4.ccc.cvshead.20030205.patch >libtool.m4.ccc.cvshead.20030205.patchType: Plain Text (text/plain) > Encoding: quoted-printable > >Part 1.1.2Type: application/pgp-signature > > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
On Tuesday, February 4, 2003, at 09:46 PM, Albert Chin wrote: I think we should support the two-level namespace, even if it is OSX-specific. I look at libtool more as a way to easily build shared libraries across multiple platforms. Think about AIX. An AIX shared library (non-brtl) can contain *both* a static and shared member. We don't emulate this across all platforms. The main issue is that right now, libtool is doing the equivalent of "on darwin, force all libraries to be built statically." There is no way to force a twolevel namespace using libtool without doing a sed on ltmain.sh or the resultant configure and stripping out the -flat_namespace libtool puts on the link line. :P At least if it gets switched to "-multiply_defined suppress", you still have the option of making the library flat by adding "-undefined supress -flat_namespace" after the fact. If there was some way to turn it off, it would at least be workable. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Pending release of 1.5
FWIW, "current" CVS (most recent changelog entry when I checkedout was "2003-02-04 Nick Hudson ") has no new test failures on cygwin. autoconf-2.57 automake-1.7.2 cygwin-1.3.18-1 gcc-3.2-3 binutils-20021117-1 the only existing testsuite failures are two longstanding ones, build-relink2 and quote.test. There is one remaining (non-showstopper) issue -- a library linking speedup on cygwin -- that I'd like to get into libtool-1.5, but I didn't write it. I've encouraged the original author to post to libtool-patches. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_CHECK_LIB(m, main, LIBM="-lm") broken with C++ [PATCH]
On Wed, 5 Feb 2003, Robert Boehne wrote: > > Yeah, I think this is too much. 's/main/cos/' fixes the problem > without risking anything. > With Bob's approval I'm going to check this patch in. Approved! :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_CHECK_LIB(m, main, LIBM="-lm") broken with C++ [PATCH]
Albert Chin wrote: > > Is this too much: > AC_CHECK_FUNC(cos, , AC_CHECK_LIB(m, cos, LIBM="$LIBM -lm")) > > We could do the same for: > AC_CHECK_LIB(mw, _mwvalidcheckl, LIBM="-lmw"). > > -- > albert chin ([EMAIL PROTECTED]) Yeah, I think this is too much. 's/main/cos/' fixes the problem without risking anything. With Bob's approval I'm going to check this patch in. Thanks! Robert ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: linux/alpha and ccc compiler
Here is a trivial patch to add Compaq's alpha c compiler (ccc) to libtool.m4. This is against CVS head. Cheers, Bob McElrath [Univ. of Wisconsin at Madison, Department of Physics] "You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists." -- Abbie Hoffman --- libtool.m4.orig Wed Feb 5 21:35:38 2003 +++ libtool.m4 Wed Feb 5 21:36:44 2003 @@ -4696,6 +4696,11 @@ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static' fi + if test "$CC" = "ccc"; then + _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' +# All ccc code is PIC. + _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared' + fi ;; osf3* | osf4* | osf5*) msg03579/pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_CHECK_LIB(m, main, LIBM="-lm") broken with C++ [PATCH]
On Wed, Feb 05, 2003 at 08:57:08PM -0600, Robert Boehne wrote: > Index: libtool.m4 > === > RCS file: /cvsroot/libtool/libtool/libtool.m4,v > retrieving revision 1.297 > diff -u -r1.297 libtool.m4 > --- libtool.m45 Feb 2003 07:03:55 - 1.297 > +++ libtool.m46 Feb 2003 02:50:39 - > @@ -2246,10 +2246,10 @@ >;; > *-ncr-sysv4.3*) >AC_CHECK_LIB(mw, _mwvalidcheckl, LIBM="-lmw") > - AC_CHECK_LIB(m, main, LIBM="$LIBM -lm") > + AC_CHECK_LIB(m, cos, LIBM="$LIBM -lm") Is this too much: AC_CHECK_FUNC(cos, , AC_CHECK_LIB(m, cos, LIBM="$LIBM -lm")) We could do the same for: AC_CHECK_LIB(mw, _mwvalidcheckl, LIBM="-lmw"). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_CHECK_LIB(m, main, LIBM="-lm") broken with C++ [PATCH]
On Wed, 5 Feb 2003, Robert Boehne wrote: > How about this patch? The patch looks great to me. Bob > The math library is not actually used by anything but the > test suite in Libtool, so as long as the C standard and > common practice put "cos" in -lm it's all good. > > ChangeLog entry: > > 2003-02-05 Robert Boehne <[EMAIL PROTECTED]> > > * libtool.m4 (AC_CHECK_LIBM): Search for a real symbol in > the math library rather than 'main', it causes problems for > C++ compilers with certain Auto* tools. > (AC_LIBLTDL_INSTALLABLE): ditto. > > Index: libtool.m4 > === > RCS file: /cvsroot/libtool/libtool/libtool.m4,v > retrieving revision 1.297 > diff -u -r1.297 libtool.m4 > --- libtool.m45 Feb 2003 07:03:55 - 1.297 > +++ libtool.m46 Feb 2003 02:50:39 - > @@ -2246,10 +2246,10 @@ >;; > *-ncr-sysv4.3*) >AC_CHECK_LIB(mw, _mwvalidcheckl, LIBM="-lmw") > - AC_CHECK_LIB(m, main, LIBM="$LIBM -lm") > + AC_CHECK_LIB(m, cos, LIBM="$LIBM -lm") >;; > *) > - AC_CHECK_LIB(m, main, LIBM="-lm") > + AC_CHECK_LIB(m, cos, LIBM="-lm") >;; > esac > ])# AC_CHECK_LIBM > @@ -2294,7 +2294,7 @@ > # In the future, this macro may have to be called after > AC_PROG_LIBTOOL. > AC_DEFUN([AC_LIBLTDL_INSTALLABLE], > [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl > - AC_CHECK_LIB(ltdl, main, > + AC_CHECK_LIB(ltdl, lt_dlinit, >[test x"$enable_ltdl_install" != xyes && enable_ltdl_install=no], >[if test x"$enable_ltdl_install" = xno; then > AC_MSG_WARN([libltdl not installed, but installation disabled]) > > > Albert Chin wrote: > > > > On Wed, Feb 05, 2003 at 03:00:39PM -0600, Bob Friesenhahn wrote: > > > I posted a detailed message to [EMAIL PROTECTED] and > > > [EMAIL PROTECTED] but there has been no response at all so I will > > > post again. > > > > > > CVS libtool.m4 contains lines like > > > > > > AC_CHECK_LIB(m, main, LIBM="-lm") > > > > > > and > > > > > > AC_CHECK_LIB(ltdl, main, ... blah > > > > Gross! > > > > > What is the best path forward? > > > > Replace main with a *real* function in one of the libraries. > > > > -- > > albert chin ([EMAIL PROTECTED]) > > > > ___ > > Libtool mailing list > > [EMAIL PROTECTED] > > http://mail.gnu.org/mailman/listinfo/libtool > > > ___ > Libtool-patches mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool-patches > == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_CHECK_LIB(m, main, LIBM="-lm") broken with C++ [PATCH]
How about this patch? The math library is not actually used by anything but the test suite in Libtool, so as long as the C standard and common practice put "cos" in -lm it's all good. ChangeLog entry: 2003-02-05 Robert Boehne <[EMAIL PROTECTED]> * libtool.m4 (AC_CHECK_LIBM): Search for a real symbol in the math library rather than 'main', it causes problems for C++ compilers with certain Auto* tools. (AC_LIBLTDL_INSTALLABLE): ditto. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/libtool.m4,v retrieving revision 1.297 diff -u -r1.297 libtool.m4 --- libtool.m4 5 Feb 2003 07:03:55 - 1.297 +++ libtool.m4 6 Feb 2003 02:50:39 - @@ -2246,10 +2246,10 @@ ;; *-ncr-sysv4.3*) AC_CHECK_LIB(mw, _mwvalidcheckl, LIBM="-lmw") - AC_CHECK_LIB(m, main, LIBM="$LIBM -lm") + AC_CHECK_LIB(m, cos, LIBM="$LIBM -lm") ;; *) - AC_CHECK_LIB(m, main, LIBM="-lm") + AC_CHECK_LIB(m, cos, LIBM="-lm") ;; esac ])# AC_CHECK_LIBM @@ -2294,7 +2294,7 @@ # In the future, this macro may have to be called after AC_PROG_LIBTOOL. AC_DEFUN([AC_LIBLTDL_INSTALLABLE], [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl - AC_CHECK_LIB(ltdl, main, + AC_CHECK_LIB(ltdl, lt_dlinit, [test x"$enable_ltdl_install" != xyes && enable_ltdl_install=no], [if test x"$enable_ltdl_install" = xno; then AC_MSG_WARN([libltdl not installed, but installation disabled]) Albert Chin wrote: > > On Wed, Feb 05, 2003 at 03:00:39PM -0600, Bob Friesenhahn wrote: > > I posted a detailed message to [EMAIL PROTECTED] and > > [EMAIL PROTECTED] but there has been no response at all so I will > > post again. > > > > CVS libtool.m4 contains lines like > > > > AC_CHECK_LIB(m, main, LIBM="-lm") > > > > and > > > > AC_CHECK_LIB(ltdl, main, ... blah > > Gross! > > > What is the best path forward? > > Replace main with a *real* function in one of the libraries. > > -- > albert chin ([EMAIL PROTECTED]) > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Pending release of 1.5
>>> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> Alexandre,
Robert> Snapshots of CVS are made daily and reside at
Robert> ftp://alpha.gnu.org/pub/gnu/cvs/libtool.tgz
CVS snapshots are differents from `make dist' tarballs. The
former still requires maintainer tools like Autoconf, Automake,
Texinfo... I don't think they are easier to test than a CVS
checkout. It is better to test a real candidate of what the
release will be, IMHO.
Besides, since generated files are not under CVS we don't know
what yours will look like. We should test the files that you
will distribute, not the files that we can build with our own
versions of the autotools.
Robert> I'm not sure where to announce a pending release other
Robert> than here, but I had just intended to re-release after
Robert> bugs were fixed & found in 1.5. If you have a suggestion
Robert> on where to announce the pre-release, let us know.
I sent you a private mail entitled `RFC: [EMAIL PROTECTED]' on
January 15. (Only Akim, Jim, Pavel, and Paul answered to this; I was
hopping comments from you and Bruno.) Since then I've asked for
the creation of this list, but haven't heard anything from the GNU
sysadmins yet (the ticket ID is [gnu.org #17673]).
Presently, Autoconf and Automake prereleases are announced to
{autoconf,automake,libtool,bug-gnu-utils}@gnu.org. Also for
Automake prereleases I have been spamming anybody listed in
ChangeLog entries since the last release (this is mainly to make
sure bug reporters have a chance to check that their bug is
fixed before the real release).
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Pending release of 1.5
Alexandre, Snapshots of CVS are made daily and reside at ftp://alpha.gnu.org/pub/gnu/cvs/libtool.tgz I'm not sure where to announce a pending release other than here, but I had just intended to re-release after bugs were fixed & found in 1.5. If you have a suggestion on where to announce the pre-release, let us know. Thanks, Robert Alexandre Duret-Lutz wrote: > > >>> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes: > > Robert> Hello, > Robert> I'm just about to make the release of Libtool 1.5. If anyone would > Robert> like to test the current CVS on their favorite platform and report > Robert> any problems, please do so! If not, your woes may have to wait for > Robert> 1.5.1. > > Great news! How about making a test release (1.4f, say), and > announcing it to more that just [EMAIL PROTECTED] to get wider > testing? > > The last snapshot of this branch (1.4d) is one year old, and not > everybody is able to test Libtool off CVS. > > Cheerio, > -- > Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to tell libtool to have/work with one of [.lo|.o] file ( ifpossible )
On Wed, 5 Feb 2003, Praveen Jain wrote: > >> > >> The main motivation is to reduce the build time > >> approximately by a factor of 2 which would be a > >> tremendous help for us. > > > >--disable-shared or --disable-static. If you want static and shared, > >you don't have a choice. > > Where do you pass these options? I tried to pass it to libtool and > it says unrecognized options? Unfortunately, there is a design problem with libtool. There should be libtool command-line switches to support this, but instead these options must be set when libtool is configured. These options are set via an autoconf configure script. If you are using an already installed libtool then you are out of luck. If you do have a configure script available, then you can add something like: AC_DISABLE_SHARED AC_ENABLE_STATIC to set the libtool defaults prior to using AC_PROG_LIBTOOL. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to tell libtool to have/work with one of [.lo|.o] file( if possible )
At 04:18 PM 2/5/2003 -0600, Albert Chin wrote: >On Wed, Feb 05, 2003 at 02:11:39PM -0800, Asim Suter wrote: >> I see that libtool compiles every C source file two times >> 1) once to generate ".lo" files >> 2) second time to generate ".o" files >> >> Is it possible to "tell" libtool to generate >> only one type of object file ? My belief is that >> only one type of file should be sufficient. >> >> The main motivation is to reduce the build time >> approximately by a factor of 2 which would be a >> tremendous help for us. > >--disable-shared or --disable-static. If you want static and shared, >you don't have a choice. Where do you pass these options? I tried to pass it to libtool and it says unrecognized options? bash-2.04$ libtool --disable-shared libtool: unrecognized option `--disable-shared' Try `libtool --help' for more information. We are using version 1.4.2 of libtool. Thanks for your help and prompt response. Praveen >-- >albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_CHECK_LIB(m, main, LIBM="-lm") broken with C++
On Wed, Feb 05, 2003 at 03:00:39PM -0600, Bob Friesenhahn wrote: > I posted a detailed message to [EMAIL PROTECTED] and > [EMAIL PROTECTED] but there has been no response at all so I will > post again. > > CVS libtool.m4 contains lines like > > AC_CHECK_LIB(m, main, LIBM="-lm") > > and > > AC_CHECK_LIB(ltdl, main, ... blah Gross! > What is the best path forward? Replace main with a *real* function in one of the libraries. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to tell libtool to have/work with one of [.lo|.o] file ( ifpossible )
On Wed, Feb 05, 2003 at 02:11:39PM -0800, Asim Suter wrote: > I see that libtool compiles every C source file two times > 1) once to generate ".lo" files > 2) second time to generate ".o" files > > Is it possible to "tell" libtool to generate > only one type of object file ? My belief is that > only one type of file should be sufficient. > > The main motivation is to reduce the build time > approximately by a factor of 2 which would be a > tremendous help for us. --disable-shared or --disable-static. If you want static and shared, you don't have a choice. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
How to tell libtool to have/work with one of [.lo|.o] file ( ifpossible )
Hello, We build shared libraries and executables on a Linux system for Pentium processor. We use libtool along with automake and autoconf as part of our build infrastructure. I see that libtool compiles every C source file two times 1) once to generate ".lo" files 2) second time to generate ".o" files Is it possible to "tell" libtool to generate only one type of object file ? My belief is that only one type of file should be sufficient. The main motivation is to reduce the build time approximately by a factor of 2 which would be a tremendous help for us. Regards, Asim ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_CHECK_LIB(m, main, LIBM="-lm") broken with C++
On Wed, 5 Feb 2003, Bob Friesenhahn wrote: > > The solution seems to be to either fix autoconf so that it emmits a > different test program for the special case where 'main' is tested for > (which is in fact a valid test!), or to fix libtool.m4 so that it > requests a known symbol from the library being tested. I should mention that libtool is clearly in the wrong with requesting a test for "main" in the library since it is depending on a side-effect and the technique is the result of sloth. Autoconf is also in the wrong since it didn't generate code which actually tests for main in the library. There are indeed libraries which may contain a main routine (e.g. the Perl library) so it is valid to test for 'main' in a library. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
AC_CHECK_LIB(m, main, LIBM="-lm") broken with C++
I posted a detailed message to [EMAIL PROTECTED] and [EMAIL PROTECTED] but there has been no response at all so I will post again. CVS libtool.m4 contains lines like AC_CHECK_LIB(m, main, LIBM="-lm") and AC_CHECK_LIB(ltdl, main, ... blah Unfortunately, these result in Autoconf generating a test program which contains a recursive call to main(). Some of these tests are done while configuring the CXX tag with CC set to the C++ compiler. While g++ and C compilers accept this, it has been discovered that several commercial C++ compilers reject the code so the test fails. The solution seems to be to either fix autoconf so that it emmits a different test program for the special case where 'main' is tested for (which is in fact a valid test!), or to fix libtool.m4 so that it requests a known symbol from the library being tested. What is the best path forward? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: More problems with the current CVS version
Albert Chin wrote: On Wed, Feb 05, 2003 at 06:04:06PM +0100, Roberto Bagnara wrote: when I do make install, the files installed have the wrong name. Here is what I see $ ls libppl. libppl.a libppl_c..0.1.0 libppl.la libppl..0libppl_c.libppl_c.a libppl..0.2.0 It looks like "so" was omitted from "libppl.so" and similarly for the other files. This happens on an x86 GNU/Linux system (Red Hat 8.0), latest releases of both autoconf and automake. Cheers What version of libtool? Are you using the libtool that shipped with RH8.0? No: I am using the CVS version that was current at the time of my message. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Pending release of 1.5
>>> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes: Robert> Hello, Robert> I'm just about to make the release of Libtool 1.5. If anyone would Robert> like to test the current CVS on their favorite platform and report Robert> any problems, please do so! If not, your woes may have to wait for Robert> 1.5.1. Great news! How about making a test release (1.4f, say), and announcing it to more that just [EMAIL PROTECTED] to get wider testing? The last snapshot of this branch (1.4d) is one year old, and not everybody is able to test Libtool off CVS. Cheerio, -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: More problems with the current CVS version
On Wed, Feb 05, 2003 at 06:04:06PM +0100, Roberto Bagnara wrote: > when I do make install, the files installed have the wrong name. > Here is what I see > > $ ls > libppl. libppl.a libppl_c..0.1.0 libppl.la > libppl..0libppl_c.libppl_c.a > libppl..0.2.0 > > It looks like "so" was omitted from "libppl.so" and similarly > for the other files. This happens on an x86 GNU/Linux system > (Red Hat 8.0), latest releases of both autoconf and automake. > Cheers What version of libtool? Are you using the libtool that shipped with RH8.0? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Pending release of 1.5
On Tue, Feb 04, 2003 at 01:10:54AM -0600, Robert Boehne wrote: > I'm just about to make the release of Libtool 1.5. If anyone would > like to test the current CVS on their favorite platform and report > any problems, please do so! If not, your woes may have to wait for > 1.5.1. What date do you plan to release? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
More problems with the current CVS version
Hi there, when I do make install, the files installed have the wrong name. Here is what I see $ ls libppl. libppl.a libppl_c..0.1.0 libppl.la libppl..0libppl_c.libppl_c.a libppl..0.2.0 It looks like "so" was omitted from "libppl.so" and similarly for the other files. This happens on an x86 GNU/Linux system (Red Hat 8.0), latest releases of both autoconf and automake. Cheers Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: CVS, bootstrapping and DJGPP
On Wed, 5 Feb 2003, Richard Dawe wrote: > Hello. > > I've been trying to bootstrap a CVS check-out of libtool and I've hit some > problems. The problems occur when I run the "boostrap" script. I'm using the > DJGPP ports of autoconf 2.57 and automake 1.7.2. > > Firstly, I keep getting the following message: > > configure.ac: `AM_INIT_AUTOMAKE' must be used > automake: your implementation of AM_INIT_AUTOMAKE comes from an > automake: old Automake version. You should recreate aclocal.m4 > automake: with aclocal and run automake again. > automake: no `Makefile.am' found or specified I have run into this error message before under Cygwin. My recollection is vague, but I believe that the solution was to manually erradicate all traces of the existing Autoconf and Automake installs and install from scratch. Some old file is throwing it off. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
ArtBarker.com: Winter Promotion
ArtBarker.com Your #1 Art-Related Marketplace (http://www.ArtBarker.com ) Just in case you were interested, we are currently running a Winter special of HALF OFF the listed advertising rates (for as many months as you wish to list!), so please contact us if you would like more details on advertising your business. ArtBarker.com is a way for anyone in the art-related industry to effectively bring traffic to their site for only pennies per click. We continually advertise a new set of pet-related keywords across the web (including all the major pay per click search engines such as WebCrawler, Yahoo, Overture, Lycos, AltaVista, Excite, & Google). This system places us in the top 3 positions on over 90% of the search engines for a specific set of keywords. Soon we will be advertising tens of thousands of keywords maintaining the top 3 spots for each. Please visit our website (http://www.ArtBarker.com ) in order to see firsthand the benefits that exposure can bring to you art-related business. Remember, our half-price advertising promotion is for a limited time only. Best regards, Robert Lash 941-544-5422 [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: CVS, bootstrapping and DJGPP
Hello. Robert Boehne wrote: > It looks to me like automake isn't installed correctly. Automake > provides macros like AM_INIT_AUTOMAKE to Autoconf, so Autoconf > needs to find them. It works with other packages like GNU coreutils 4.5.4. That's why I'm puzzled by this. I'll try to dig a little deeper into why it fails... Thanks, bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: CVS, bootstrapping and DJGPP
Richard, It looks to me like automake isn't installed correctly. Automake provides macros like AM_INIT_AUTOMAKE to Autoconf, so Autoconf needs to find them. HTH, Robert Richard Dawe wrote: > > Hello. > > I've been trying to bootstrap a CVS check-out of libtool and I've hit some > problems. The problems occur when I run the "boostrap" script. I'm using the > DJGPP ports of autoconf 2.57 and automake 1.7.2. > > Firstly, I keep getting the following message: > > configure.ac: `AM_INIT_AUTOMAKE' must be used > automake: your implementation of AM_INIT_AUTOMAKE comes from an > automake: old Automake version. You should recreate aclocal.m4 > automake: with aclocal and run automake again. > automake: no `Makefile.am' found or specified > > So I ran aclocal and re-ran bootstrap. I got the same error message. I also > tried changing the following in configure.ac: > > AM_INIT_AUTOMAKE(AC_PACKAGE_TARNAME, AC_PACKAGE_VERSION) > > to have no arguments, []-quoted arguments, etc., but that made no difference. > > Has anyone else seen this problem? If not, then it must be a problem with the > DJGPP port of automake 1.7.2. > > Secondly, bootstrap doesn't seem to create any Makefile.in files. The line > that runs automake is: > > eval $AUTOMAKE $AUTOMAKE_FLAGS > > Shouldn't there be a Makefile name after that? Also, shouldn't the script > create Makefile.in in the top-level directory and doc directories? > > Thanks, regards, > > -- > Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ] > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
CVS, bootstrapping and DJGPP
Hello. I've been trying to bootstrap a CVS check-out of libtool and I've hit some problems. The problems occur when I run the "boostrap" script. I'm using the DJGPP ports of autoconf 2.57 and automake 1.7.2. Firstly, I keep getting the following message: configure.ac: `AM_INIT_AUTOMAKE' must be used automake: your implementation of AM_INIT_AUTOMAKE comes from an automake: old Automake version. You should recreate aclocal.m4 automake: with aclocal and run automake again. automake: no `Makefile.am' found or specified So I ran aclocal and re-ran bootstrap. I got the same error message. I also tried changing the following in configure.ac: AM_INIT_AUTOMAKE(AC_PACKAGE_TARNAME, AC_PACKAGE_VERSION) to have no arguments, []-quoted arguments, etc., but that made no difference. Has anyone else seen this problem? If not, then it must be a problem with the DJGPP port of automake 1.7.2. Secondly, bootstrap doesn't seem to create any Makefile.in files. The line that runs automake is: eval $AUTOMAKE $AUTOMAKE_FLAGS Shouldn't there be a Makefile name after that? Also, shouldn't the script create Makefile.in in the top-level directory and doc directories? Thanks, regards, -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: To sed or not to sed
Albert Chin writes: > On Tue, Feb 04, 2003 at 04:04:29PM +, Lars Hecking wrote: > > On Solaris 7/8, this list of objects is too long for the native sed, > > and linking fails (some error messages about "line too long"). I reported > > this as a bug and was told to use GNU sed instead. > > Fixed in libtool 1.4.3. Libtool now searches for the "best" sed in > $PATH on your system. Excellent! I'll ask the kind php people to upgrade then ... ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
test report
Hello, I just tried libtool CVS version (with cvs -z3 up -PAd) this is the make check output: Platform is FreeBSD 5.0-RELEASE FAIL: demo-make.test FAIL: depdemo-make.test FAIL: mdemo-inst.test FAIL: mdemo-unst.test = 4 of 101 tests failed = I can provide more infos if needed. Bye, enrico -- Enrico Sirola <[EMAIL PROTECTED]> gpg public key available from www.keyserver.net, Key ID 0x377FE07F Key fingerprint = B446 7332 ED55 BC68 5FE8 DE0F 98DF EC86 377F E07F ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
