[unixODBC-dev] gnu build

Tom Lane tgl at sss.pgh.pa.us
Thu Sep 15 04:55:50 BST 2005


Peter Harvey <pharvey at mysql.com> writes:
> I never want to use the libtool embedded in the unixODBC source (or any 
> other source package). I prefer to ensure that I have a libtool 
> installed and available before I build.

Say, guys, I've been meaning to pester you about that.  I have an open
bug against the Red Hat packaging of unixODBC:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161399
(but the actual technical details are in another entry that's not
publicly visible, sigh).  Basically the issue is that the RPM specfile
forcibly uses the current Red Hat libtool, like this:

%prep
...

# 2.2.8 includes a libtool that is too old for some of our architectures.
# Blow it away and replace with build system's libtool.  (We intend to use
# the installed libtool anyway, but this makes sure they match.)
rm -rf config.guess config.sub ltmain.sh libltdl
cp -r /usr/share/libtool/* .

# Use newer install-sh and mkinstalldirs, too
if [ -f libltdl/install-sh ]; then
  cp -f libltdl/install-sh .
fi
if [ -f libltdl/mkinstalldirs ]; then
  cp -f libltdl/mkinstalldirs .
fi

%build
...

aclocal
automake
autoconf
pushd libltdl
aclocal
automake
autoconf
popd

and it seems that this breaks some odd hacks that you are using.
You can see in the above-mentioned bugzilla entry that Alexandre Oliva
thinks I'm an idiot for doing this, but it definitely fixed a few
problems a year or two back.

Does this sound familiar at all?  Do you intend that unixODBC depends on
the particular libtool version you ship with it?  I can get more of the
details, but it's late enough in my timezone that I don't have them all
at my fingertips...

			regards, tom lane



More information about the unixODBC-dev mailing list