Bugzilla Bug 221879

dev-db/unixODBC fails to build with libtool-2.x:

config.status: creating config.h
config.status: config.h is unchanged
make  all-am
make[2]: Entering directory
`/var/tmp/portage/dev-db/unixODBC-2.2.12/work/unixODBC-2.2.12/libltdl'
/bin/sh ./libtool --tag=CC   --mode=compile i686-pc-linux-gnu-gcc
-DHAVE_CONFIG_H -I.     -O2 -march=i686 -pipe -mtune=i686 -c -o ltdl.lo ltdl.c
./libtool: line 460: CDPATH: command not found
./libtool: line 1152: func_opt_split: command not found
libtool: Version mismatch error.  This is libtool 2.2.4, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.4
libtool: and run autoconf again.
make[2]: *** [ltdl.lo] Error 63
make[2]: Leaving directory
`/var/tmp/portage/dev-db/unixODBC-2.2.12/work/unixODBC-2.2.12/libltdl'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/var/tmp/portage/dev-db/unixODBC-2.2.12/work/unixODBC-2.2.12/libltdl'
make: *** [all-recursive] Error 1

Created an attachment (id=153003) [details]
unixODBC-2.2.12.ebuild.patch

This patch fixes the problem for me, although I'm not sure if this solution is
correct...

First of all, as you probably noticed, this ebuild is a bit messed up (it seems
to be doing thing it should not or does them in the wrong place).
Now, I think something simpler should work.
I agree with moving eautoreconf, but
I think other two lines can be reduced to one:
rm "${S}"/libltdl/acinclude.m4 || die

Rafał I've tried that and it fails...

Created an attachment (id=153033) [details]
A working ebuild

You're right, it does.
While trying to simplify current ebuild I ended up with a more complex verion.
Some explanations:
unless I'm wrong, using gnuconfig_update is no longer required
autotools are run only in src_unpack
now it does not build libtool, but uses system one...
however defining WITHLT is still required for correct linking with libltdl
for use gnome:
autopoint -f is for adding config.rpath
ACLOCAL_AMFLAGS are changed from macros to m4, cause macros in macros dir break
eautoreconf, but eautoreconf needs old gettext macro in m4, otherwise install
fails

(In reply to comment #4)
> unless I'm wrong, using gnuconfig_update is no longer required

yup it's better to drop it as portage should do this for us.

> autotools are run only in src_unpack

ack, I did this change too

> now it does not build libtool, but uses system one...
> however defining WITHLT is still required for correct linking with libltdl

The following change seems strange to me:
sed -i -e '/WITHLT/s:^.*$:AM_CONDITIONAL(WITHLT, true):' "${S}"/configure.in

Seems that it states that we are using of included liblt.

And I think with your suggested solution we have to update runtime dependency
to add libtool there.

No, WITHLT in this situation means only that it should link with libtool,
cause without it I was getting linking errors regarding symbols from libltdl.

However, that's no longer important.

Well, after some reading (of the main configure.in),
I finally figured out why libtool didn't get correctly updated.
Its really sick.
It looks like the fix is:
remove block
AC_MSG_CHECKING( Have we enabled using RTLD_GROUP )
if test "x$rtldgroup" = "xtrue"; then
AC_MSG_RESULT( yes )
AC_LIBLTDL_CONVENIENCE
else
AC_MSG_RESULT( no );
AC_LIBLTDL_CONVENIENCE_G
fi
add
AC_WITH_LTDL
after
AM_PROG_LIBTOOL

When this is done eautoreconf will correctly detect use of libltdl
and update it.

But some of my other fixes still seem sane. And it always had a runtime
dependency on libtool.

(In reply to comment #6)
> I finally figured out why libtool didn't get correctly updated.
> It looks like the fix is:
> remove block

Yes, I haven't tested but reading sources I seems that this is best approach.
I'd just removed all "rtdl group" (btw what is this? seems like some ancient
piece of code) related code in configure.in and acinclude.m4 as passing
--enable-rtdlgroup=no to libltld/configure is really not necessary.

Also it's worth to create clean patch send it upstream... Do you have time for
this?

> But some of my other fixes still seem sane. And it always had a runtime
> dependency on libtool.

Just noticed that autotools.eclass adds this DEPEND. So it's there. Thank you
for very much, for your fruitful collaboration :)

Well, yeah. I also think that's something that was needed for some really old
libtool.
And about that patch, I think it would be better if it was sent by someone, who
actually uses unixODBC, instead of only buils it "just in case".

Created an attachment (id=153357) [details]
a patch that works with libtool 2

Damn, there's a little problem, an incompatibility between libtool macros v1
and v2, the same they have in bug 220765.
This patch works with >=libtool-2.2, but probably breaks with v1 series.
So probably is has to be applied conditionally (I apply it always).

Created an attachment (id=153359) [details]
ebuild for that patch

Personally, I think that the incompatibility should be addressed
by libtool upstream.

Just committed a fix which goes another way: Removing libltdl completely and
use the system one. Builds fine here and on amd64 stable.