Re: libtoolize and glib-1.2.10 [Was: [ITP] libungif-4.1.0-1]

[Nicholas Wourms <nwourms at netscape dot net>]

Charles Wilson wrote:

> Lapo Luchini wrote:
>
> > > BTW, you can also relibtoolize glib (and probably gtk) in a similar 
> > > way.
> >
> >
> > Uhm.. I had no problem relibtoolizing libungif, but I indeed have 
> > problems with glib:
> > ltconf part of confgiure says:
> >
> > checking if libtool supports shared libraries... yes
> > checking if package supports dlls... no
> > checking whether to build shared libraries... no
> > checking whether to build static libraries... yes
> >
> > Probably I still miss some point in libtoolize usage (btw: is it 
> > normal that executing it just after an "aclocal" it stilla says to 
> > regenerate an updated .m4 using aclocal?)... 
>
>
> Yes, that is normal.
>
> > do you have any hint to get things going?
>
>
> Check configure.in:  if it says "AC_PREREQ(2.13) or older, then it 
> gets tricky -- usually it is easier to change that to AC_PREREQ(2.52), 
> and then make the appropriate changes so that configure.in becomes 
> compatible with the newer autoconr.
>
> Nicholas says that it is easier to (a) change AC_PREREQ to 2.52, and 
> then run 'autoupdate'; I tend to do it all by hand.
>
> By updating to the newer autocof, you also trigger using the new 
> libtool which more cleanly support DLLs on windows.
>
> --Chuck
A) FWICT, he isn't running autoheader/automake/autoconf, which means 
configure is not being regenrated.

B)He could try adding AC_LIBTOOL_WIN32_DLL right before AM_PROG_LIBTOOL 
in configure.in, which should tell configure that building dlls is "OK". 
However, I will note that the end result is "undefined symbol 
Win@Main16" %50 of the time.

C)Can you help him by referring him to the best documentation for the 
whole process?  I would try, but I learned mostly from trial and error. 
(A howto for cygwin really should be written...).

D)As I have told you on countless occasions, I use autoupdate to get me 
started.  I then 'diff -u configure.in~ configure.in' to see what it 
changed.  After evaluating what it changed, I will then go in and hand 
edit/revert anything  else.  This method works quite well in that 
autoupdate 99% of the time does all the busywork for me,  leaving it to 
me to fix up any special cases or macros.

Cheers,
Nicholas

P.S. - Lapo: using ":" and ";" in the recipient headers of e-mails is 
frowned upon and certainly is not rfc compliant.  As such, I have had to 
manually edit all of your cc:'s because yahoo doesn't like it.  Can you 
please change this?  Thank you :-)