> This is the Changle-Log of libggi:
I do know, what the changes are, but the point is that they work fine here
and at work on a machine that has never seen LibGGI before.
> I just tried a snapshot, which does _not_ contain this changes and I've
> got _no_ DLLEXT-problem.
> So, the error must be in these changes. A unified diff might be helpful...
The difference is in the m4 directory. It contains a new autoconf macro that
determines the extension.
The problem must be somewhere in the different setups of our systems.
Please try to insert some debugging code into the new macro and see what it
does. Does it run at all (some previous posts suggest it does) ? Does it
determine the correct extension ? Is that visible to the main generated
"configure" file ? It should contain:
echo $ac_n "checking for shared library extension""... $ac_c" 1>&6
echo "configure:2849: checking for shared library extension" >&5
case "${target}" in
*-*-mingw* | *-*-cygwin*)
DLLEXT="dll"
;;
*)
DLLEXT="so"
;;
esac
echo "$ac_t""$DLLEXT" 1>&6
O.K. - stop I got it now ! I can reproduce your problem ! It seems to be
caching-related or something ...
O.K. - found the problem. There was an AC_SUBST missing in the new DLLEXT
macro.
O.K. - the caching I talked off seems due to not deleting the acinclude.m4 .
I don't quite get that one, as autogen should overwrite it, but ...
Hmm - the problem only seems to occur for LibGGI - is that right ? LibGII
and WMH and such work correct ?
O.K. - I'll check that and if the diffs are o.k., I'll commit a fix.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
