You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/09/22 05:43:54 UTC
Autoconf 2.5/Libtool 1.4 problem...
On my Mandrake-based systems (seen on 7.2 and Cooker), libtool 1.4
and autoconf 2.52 (reproducable with the stock gnu.org versions)
interact to cause shared libraries not to work. I haven't been
able to find out exactly what the cause is here. (I'll attempt to
dig in more as time allows...)
With libtool 1.4, this results in a non-buildable tree (as it
tries to use -soname which is not supported by gcc). Libtool
1.4.2 is a bit better, but refuses to build shared libraries at
*all* (but the tree is buildable - we'll just *silently* ignore
any requests for shared libraries - which is bad).
The kicker here is that this problem doesn't occur with autoconf
2.13/libtool 1.4 or autconf 2.52/libtool 1.3.3 (libtool complains
about an unexpected = in this combination, but builds okay). I
just tested with autoconf 2.50/libtool 1.4.2 and this combination
looks broken too.
Can anyone else reproduce this? Should we force buildconf to forbid
this combination (autoconf 2.50+ and libtool 1.4+)? -- justin
Re: Autoconf 2.5/Libtool 1.4 problem...
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Sep 22, 2001 at 01:10:30PM -0700, Greg Stein wrote:
>...
> I'm also seeing some caching issues. It doesn't seem to reuse config.cache
> for some reason. Haven't looked into that one.
Pilot error. The new autoconf doesn't create a cache by default any more
(for safety reasons). The user must manually add -C or --config-cache to the
configure line to get a cache created.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Autoconf 2.5/Libtool 1.4 problem...
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sat, Sep 22, 2001 at 01:10:30PM -0700, Greg Stein wrote:
> I just discovered that the AC_PROG_CC macro can only be used once within a
> configure script. Its definition includes "m4_expand_once()". We have *two*
> invocations: one in apr_hints.m4, and one in the main configure.in.
>
> The hints one is fully expanded, and the main one is partial. However, the
> hints invocation is in the AIX *conditional*. Therefore, a full check of the
> compiler characters *never* happens. That completely bombs out a bunch of
> other tests, particularly the libtool stuff.
>
> I've fixed the stuff and am testing now. Watch for a checkin later.
Yup, that's it. Thanks.
I was looking at the AC_PROG_CC macro before I went out to lunch. =)
-- justin
Re: Autoconf 2.5/Libtool 1.4 problem...
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Sep 22, 2001 at 01:10:30PM -0700, Greg Stein wrote:
>...
> I'm also seeing some caching issues. It doesn't seem to reuse config.cache
> for some reason. Haven't looked into that one.
Pilot error. The new autoconf doesn't create a cache by default any more
(for safety reasons). The user must manually add -C or --config-cache to the
configure line to get a cache created.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Autoconf 2.5/Libtool 1.4 problem...
Posted by Greg Stein <gs...@lyra.org>.
I just discovered that the AC_PROG_CC macro can only be used once within a
configure script. Its definition includes "m4_expand_once()". We have *two*
invocations: one in apr_hints.m4, and one in the main configure.in.
The hints one is fully expanded, and the main one is partial. However, the
hints invocation is in the AIX *conditional*. Therefore, a full check of the
compiler characters *never* happens. That completely bombs out a bunch of
other tests, particularly the libtool stuff.
I've fixed the stuff and am testing now. Watch for a checkin later.
I'm also seeing some caching issues. It doesn't seem to reuse config.cache
for some reason. Haven't looked into that one.
Cheers,
-g
On Fri, Sep 21, 2001 at 08:43:54PM -0700, Justin Erenkrantz wrote:
> On my Mandrake-based systems (seen on 7.2 and Cooker), libtool 1.4
> and autoconf 2.52 (reproducable with the stock gnu.org versions)
> interact to cause shared libraries not to work. I haven't been
> able to find out exactly what the cause is here. (I'll attempt to
> dig in more as time allows...)
>
> With libtool 1.4, this results in a non-buildable tree (as it
> tries to use -soname which is not supported by gcc). Libtool
> 1.4.2 is a bit better, but refuses to build shared libraries at
> *all* (but the tree is buildable - we'll just *silently* ignore
> any requests for shared libraries - which is bad).
>
> The kicker here is that this problem doesn't occur with autoconf
> 2.13/libtool 1.4 or autconf 2.52/libtool 1.3.3 (libtool complains
> about an unexpected = in this combination, but builds okay). I
> just tested with autoconf 2.50/libtool 1.4.2 and this combination
> looks broken too.
>
> Can anyone else reproduce this? Should we force buildconf to forbid
> this combination (autoconf 2.50+ and libtool 1.4+)? -- justin
--
Greg Stein, http://www.lyra.org/
Re: Autoconf 2.5/Libtool 1.4 problem...
Posted by Greg Stein <gs...@lyra.org>.
I just discovered that the AC_PROG_CC macro can only be used once within a
configure script. Its definition includes "m4_expand_once()". We have *two*
invocations: one in apr_hints.m4, and one in the main configure.in.
The hints one is fully expanded, and the main one is partial. However, the
hints invocation is in the AIX *conditional*. Therefore, a full check of the
compiler characters *never* happens. That completely bombs out a bunch of
other tests, particularly the libtool stuff.
I've fixed the stuff and am testing now. Watch for a checkin later.
I'm also seeing some caching issues. It doesn't seem to reuse config.cache
for some reason. Haven't looked into that one.
Cheers,
-g
On Fri, Sep 21, 2001 at 08:43:54PM -0700, Justin Erenkrantz wrote:
> On my Mandrake-based systems (seen on 7.2 and Cooker), libtool 1.4
> and autoconf 2.52 (reproducable with the stock gnu.org versions)
> interact to cause shared libraries not to work. I haven't been
> able to find out exactly what the cause is here. (I'll attempt to
> dig in more as time allows...)
>
> With libtool 1.4, this results in a non-buildable tree (as it
> tries to use -soname which is not supported by gcc). Libtool
> 1.4.2 is a bit better, but refuses to build shared libraries at
> *all* (but the tree is buildable - we'll just *silently* ignore
> any requests for shared libraries - which is bad).
>
> The kicker here is that this problem doesn't occur with autoconf
> 2.13/libtool 1.4 or autconf 2.52/libtool 1.3.3 (libtool complains
> about an unexpected = in this combination, but builds okay). I
> just tested with autoconf 2.50/libtool 1.4.2 and this combination
> looks broken too.
>
> Can anyone else reproduce this? Should we force buildconf to forbid
> this combination (autoconf 2.50+ and libtool 1.4+)? -- justin
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org