Re: GNU Libtool 2.2 released.

[snowcrash+libtool]

hi,

> db's configuration requires it to know the shared library extension at
> configure time, it does this by running the generated libtool script.

> It is possible to generate one
> during configure, but it does not do so by default.

yup.

from my own, long-ago email from sleepycat support:

  "the procedure for updating Berkeley DB's version of libtool is
slightly different from just running libtoolize and aclocal"

and, they instructed me to do this (which i'm still doing, per my
earlier posts):

  rehash
  cd /build/db-4.6.21/dist
  glibtoolize --force --copy
  cp /usr/local/share/aclocal/libtool.m4 aclocal/libtool.ac
  sh s_config

>  Why do you relibtoolize every package prior to building it?

not every package, but ... generally, i do since i've been flogged so
many times to do so when things don't work. it's become an established
habit :-)

i've rec'd the "must be consistent with your env" speech more times
than i can count.  in db's case, as per the aforementioned support
email (yes, there were 'problems'), i was told to do it by sleepycat
"back when".

i also rely a bit on the re-autofoo/re-libtool to give insight as to
the 'awareness' (for lack of a better term) of an app's development.

a 'red-flag' does get raised for me when something *used* to work with
autofoo/libtool, then behavior changes.  usually worth some
investigation, i find,  which is why i raised it here.

now, it's still somewhat voudou-ish, imho, so i'm certainly willing to
be re-educated