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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
