headers
Brent Goodrick | 6 Jan 2003 06:02
Favicon

Who should copy ltmain.sh? libtool?


Shouldn't the libtoolize command within libtool version 1.4.3 copy
ltmain.sh from <libtool_prefix>/share/libtool/ltmain.sh to ./libltdl when the
--ltdl --copy switches are thrown?  If you don't, automake version 1.7
complains. Here is a demonstration of the "bug":

  lazarus <at> brentg : rm -rf libltdl
  lazarus <at> brentg : libtoolize --force --ltdl --copy
  Putting files in AC_CONFIG_AUX_DIR, `make'.
  lazarus <at> brentg : find libltdl
  libltdl
  libltdl/acinclude.m4
  libltdl/aclocal.m4
  libltdl/config-h.in
  libltdl/configure
  libltdl/configure.in
  libltdl/COPYING.LIB
  libltdl/ltdl.c
  libltdl/ltdl.h
  libltdl/Makefile.am
  libltdl/Makefile.in
  libltdl/README
  libltdl/stamp-h.in
  lazarus <at> brentg : cd libltdl
  lazarus <at> brentg : aclocal -I /net/lazarus/scratch1/libtool-1.4.3/Linux_2_4_18_3/share/aclocal
  lazarus <at> brentg : automake --add-missing --copy
  configure.in: installing `./install-sh'
  configure.in: installing `./mkinstalldirs'
  configure.in: installing `./missing'
  configure.in:33: installing `./config.guess'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brent Goodrick | 6 Jan 2003 06:35
Favicon

libtoolize --ltdl copies old version of configure script


The libtoolize --ltdl --copy switch copies an old configure script
into the ./libltdl directory.  Thats good, but the problem is that the
configure script that is copied does not handle VAR=value options on
the command line.  The configure script that invokes it passes
arguments for values for CC, CXX etc. via this mechanism, and thus
expects the ./libltdl/configure script to respect it.

My hunch is that the configure script that comes bundled with libtool
1.4.3 is made using autoconf 2.13, and the autoconf I'm using is
2.57.  So, if this a real bug, then the solution could always be to
have the libtool's libltdl configure script be kept in sync with
autoconf if that were feasible.

My workaround is to simply rerun autoconf to regenerate the configure
script inside the libltdl subdirectory of my package.

Thanks,
Brent Goodrick
Permalink | Reply | 4 comments |
headers
Brent Goodrick | 6 Jan 2003 16:54
Favicon

Re: libtoolize --ltdl copies old version of configure script


Hi Raphaël,

Ok, I'm using libtool-1.4.3 libtool, and not libtool-1.4.2.

I don't know if I understand what you meant by "2.13-specific
feature".  That is because AC_LIBTOOL_DLOPEN is defined by libtool,
and not autoconf, correct?  

Or, is it that you mean that is is incorrect for libtool m4 code to
use "AC_PROVIDE_" inside a macro name because that is an
implementation detail of old autoconf's, namely autoconf-2.13?

Just in case it matters, this is with use with autoconf-2.57 and
automake-1.7.

bg

>>>>> "Raphaël" == Raphaël Poss <raph <at> lrde.epita.fr> writes:

Raphaël> Brent Goodrick <bgoodrick <at> ipns.com> writes:
>> 
>> My workaround is to simply rerun autoconf to regenerate the configure
>> script inside the libltdl subdirectory of my package.

Raphaël> This  is a   problem, since the   acinclude.m4  file of 1.4.2  uses  a
Raphaël> 2.13-specific feature triggering a bug when used with 2.53:

Raphaël> ifdef([AC_PROVIDE_AC_LIBTOOL_DLOPEN], enable_dlopen=yes, enable_dlopen=no)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Raphaël Poss | 6 Jan 2003 13:47
Picon
Picon
Picon

Re: libtoolize --ltdl copies old version of configure script

Brent Goodrick <bgoodrick <at> ipns.com> writes:

>
> My workaround is to simply rerun autoconf to regenerate the configure
> script inside the libltdl subdirectory of my package.

This  is a   problem, since the   acinclude.m4  file of 1.4.2  uses  a
2.13-specific feature triggering a bug when used with 2.53:

ifdef([AC_PROVIDE_AC_LIBTOOL_DLOPEN], enable_dlopen=yes, enable_dlopen=no)

Indeed,

AC_PROVIDE([AC_LIBTOOL_DLOPEN])

does not  defined `AC_PROVIDE_AC_LIBTOOL_DLOPEN' any  more with  2.5x,
and thus in  a way autoconf 2.5x "disables"  shared library support in
ltdl.

--

-- 
/------------------------------------------------------------------.
| Raphaël Poss                          EPITA CSI 2003 - EpX - ACU |
| ICQ 1757157 - GnuPG fp bda2eb602866390c7a7d:a13ad7c86dd33b72e72b |
`------------------------------------------------------------------/
Permalink | Reply | 3 comments |
headers
Raphaël Poss | 6 Jan 2003 20:32
Picon
Picon
Picon

Re: libtoolize --ltdl copies old version of configure script

Brent Goodrick <bgoodrick <at> ipns.com> writes:

> Hi Raphaël,
>
> Ok, I'm using libtool-1.4.3 libtool, and not libtool-1.4.2.
>
> I don't know if I understand what you meant by "2.13-specific
> feature".  That is because AC_LIBTOOL_DLOPEN is defined by libtool,
> and not autoconf, correct?  
>
> Or, is it that you mean that is is incorrect for libtool m4 code to
> use "AC_PROVIDE_" inside a macro name because that is an
> implementation detail of old autoconf's, namely autoconf-2.13?

The latter.  AC_PROVIDE(X) does not  define()'s  AC_PROVIDE_X any more
with autoconf 2.5x.

--

-- 
/------------------------------------------------------------------.
| Raphaël Poss                          EPITA CSI 2003 - EpX - ACU |
| ICQ 1757157 - GnuPG fp bda2eb602866390c7a7d:a13ad7c86dd33b72e72b |
`------------------------------------------------------------------/
Permalink | Reply | 1 comment |
headers
Bruno Haible | 8 Jan 2003 14:06

Re: gettext/0.11.5 revision

On Friday 22 November 2002 22:28, David Kaelbling wrote:
> Sorry, I didn't check the 0.11 details -- I just verified that both were
> named libintl.so.3 with IVERSION sgi3.0.  The specific error was similar
> to this one:
> 
> 29824784:/usr/people/drk/toolroots/freeware/working/proot/usr/freeware/bin/msgfmt:
> rld: Error: unresolvable symbol in
> /usr/people/drk/toolroots/freeware/working/proot/usr/freeware/bin/msgfmt:
> libintl_ngettext
> 
> This turned up during "make check" and in while configuring other
> packages.  It is caused because of the way rld does shared library
> matching on IRIX.  Basically rld was looking at the old installed
> libintl.so.3 because it picked up a DT_RPATH from the new
> libgettextsrc-0.11.5.so

So this means that you had an old libintl and a new libgettextsrc in
directoryA/lib, and the new libgettextsrc was meant to refer to a libintl in
a directoryB/lib ?

This is a situation which will not work on most Unix systems.

> I worked around this by setting LTV_REVISION=1 and linking with
> -require_minor, so that while both libraries are still called
> libintl.so.3, the new one as internal version sgi3.1.  Then because
> minor version matching was enabled rld discarded the old library in
> DT_RPATH and kept looking until it found the new library in
> LD_LIBRARYN32_PATH.

This might be a bug in libtool. When
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boogie Shafer | 8 Jan 2003 19:14

libtool-1.4.3 qoute.test failure

having problems with quote.test on solaris 8 x86
(output attached)
i noticed some similar reports of problems in the message archive, but didnt
seem to find a solution

any help appreciated

thanks

boogie

=============================

$ cd tests
$ VERBOSE=1 sh -x ./quote.test
need_prefix=no
+ test -z
+ sed + s%/[^/]*$%%
echo ./quote.test
srcdir=.
+ test . = ./quote.test
+ test set != set
+ . ./defs
+ cd .
+ pwd
srcdir=/home/boogie/libtool-1.4.3/tests
+ sed s%^.*/%%
+ echo ./quote.test
progname=quote.test
libtool=../libtool
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Herod | 10 Jan 2003 17:31

Build failure on Solaris

Hello,

I'm getting build failure on Solaris with a missing library.  Details
are below.  libtool is version 1.4.3 downloaded from ftp.gnu.org on
1/10/2003.

[libtool-1.4.3]$ uname -a
SunOS codv02 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-60

[libtool-1.4.3]$ autoconf > ~/logs/autoconf.out

[libtool-1.4.3]$ ./configure --prefix=$HOME &> ~/logs/make.out

[libtool-1.4.3]$ more ~/logs/configure.out
checking for a BSD-compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... missing
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brent Goodrick | 11 Jan 2003 05:17
Favicon

Re: libtoolize --ltdl copies old version of configure script


>> Or, is it that you mean that is is incorrect for libtool m4 code to
>> use "AC_PROVIDE_" inside a macro name because that is an
>> implementation detail of old autoconf's, namely autoconf-2.13?

Raphaël> The latter.  AC_PROVIDE(X) does not  define()'s  AC_PROVIDE_X any more
Raphaël> with autoconf 2.5x.

Ok, thats what I was afraid of.  "AC_PREREQ(2.13)" is referenced
several places over the libtool-1.4.3 code.  I'm now thinking this
isn't a libtool bug necessarily, but a change made by autoconf that
made new ./configure scripts not operate with old ./configure scripts.
Specifically, the new ./configure scripts (generated by newer
autoconfs) cannot call old ./configure scripts with VAR=VALUE
parameters.

Do you believe that is what is really happening here?  Then, I should
submit the bug to the autoconf bug list.

bg
Permalink | Reply | 0 comments |
headers
Karl Berry | 13 Jan 2003 18:29

libtool and soname's

Dear libtool gurus,

I'm forwarding this suggestion for a libtool enhancement for a long-time
TeX contributor.  Web2c/kpathsea is hopefully going to switch to using
libtool soon, and this feature would be very helpful.

Thanks for your consideration,
karl

Date: Mon, 13 Jan 2003 11:32:42 +0100 (CET)
From: Peter Breitenlohner <peb <at> mppmu.mpg.de>

The current libtool always uses an soname=libfoo.so.x or equivalent (on
systems supporting such things). In the past I had to fiddle around with
things in cases where an soname=libfoo.so.x.y was needed, and once web2c
switches to libtool, libkpathsea may turn out to be such a case.

It would be extremely helpful to have a libtool parameter that allows to
change the default soname=libfoo.so.x into one of the other possibilities:
soname=libfoo.so, libfoo.so.x.y, or even libfoo.so.x.y.z -- although that
last case isn't really needed, one can use libtool's -release with the same
effect.

This could be done either when configuring libtool or at run-time. Doing
this at runtime seems preferable to me, there may be situations when there
are several libraries with different needs. But, on the other hand, doing
this when libtool is configured may be easier to implement.
Permalink | Reply | 0 comments |

Gmane