[syslog-ng] Newer libtool and autoconf versions?

[Corinna Vinschen]

On Dec  9 21:13, Balazs Scheidler wrote:
> On Thu, 2010-12-09 at 20:45 +0100, Balazs Scheidler wrote: 
> > Hi,
> > 
> > On Thu, 2010-12-09 at 15:12 +0100, Corinna Vinschen wrote:
> > > Hi,
> > > 
> > > Right now, the current 3.2.1 sources can't be build on Cygwin.  Apart
> > > from two minor problems which are fixed in git (bugzilla items 101 and
> > > 102) and a refresh of the files in contrib/cygwin-packaging (bugzilla
> > > entry 103), there's a somewhat more troubeling problem.
> > > 
> > > The source tarballs contain libtool/autoconf-generated files which have
> > > been created with older versions of these tools, namely libtool 2.2.6b
> > > and autoconf 2.65.
> > > [...]
> > > So, here's my question:  Is it possible to generate subsequent source
> > > tarballs using these newer versions of libtool and autoconf?
> > 
> > Well, it should be. Those files are generated on  my development laptop,
> > currently with Ubuntu lucid.
> > 
> > maverick has autoconf 2.67, but still libtool 2.2.6b
> > 
> > So it'll not be solved even if I upgrade to the next distro release.
> > 
> > Any ideas why Ubuntu uses such an old libtool?
> 
> I've checked around, and as it seems the newest libtool is in Debian
> experimental (2.2.10). Even the latest Fedora is carrying 2.2.6b

The latest Fedora (Fedora 14) comes with libtool 2.2.10.

> So for now, I can only promise to migrate to autoconf 2.67, but I'm
> reluctant to upgrade to libtool 2.4, so the autoreconf stuff will be
> needed for a little while.

Ok, thank you.  I can live with that.

Especially since even with libtool 2.4 there's still a problem.  Due to
the way shared libs are handled on Windows, ther's a hardcoded mechanism
in libtool which doesn't work overly well with syslog-ng.  When
installing the shared libs into $(localstatedir), libtool copies the .a
(static lib) and .dll.a (link stub for DLL) files into that directory,
while the actual module DLLs are copied to $(localstatedir)/../bin.  My
contrib/cygwin-packaging/cygwin-postinstall script fixes this situation.
It removes the .a and .dll.a files and moves the DLLs over to
/usr/lib/syslog-ng.  That works, but I'd be glad to find a solution
which does the right thing already at `make install' time, not only
after applying some postinstall magic.  I'll investigate this further.

Anyway, for the time being, the new cygwin-postinstall script
(https://bugzilla.balabit.com/show_bug.cgi?id=103) will do the job.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat