mkdll.sh

Tue Apr 30 11:58:00 GMT 2002

Harold Hunt wrote:

 > Chuck,
 >
 > Could you give a few more notes on "relibtoolize"?  A pointer to some 
good
 > documentation would be helpful...

Well, there's the goat book http://sources.redhat.com/autobook/ but it's 
a bit out of date, now...

Here's the procedure I used to "relibtoolize" libiconv.  Libiconv is a 
worst-case example: they distribute their own fork of autoconf itself, 
they redistribute system m4 macros, ... they're just plain evil.  But, 
if you can understand *this*, then "relibtoolizing" anything else should 
be a piece of cake...

Short version: remove autogenerated files.  Replace "standard" files 
with the newest versions (install-sh, mkinstalldirs, config.guess, 
config.sub) -- you can also just remove these and let the autotools copy 
in what they need (use the --force --c -a switches, or their analog: not 
every tool has exactly the same syntax).  Rerun the the autotools in the 
proper order (more later).

#1) libiconv actually ships its OWN VERSION of autoconf.  This is dumb.

rm autoconf/acgeneral.m4
rm autoconf/acspecific.m4
rm autoconf/aclocal.m4
rm autoconf/autoconf
rm autoconf/autoconf.m4
rm autoconf/mbstate_t.m4

#2) remove the "normal" distribution files that are created by autoconf.

rm autoconf/install-sh
rm autoconf/config.guess
rm autoconf/config.sub
rm configure

#3) remove the obsolete libtool files (libtool no longer uses "ltmain.sh")

rm autoconf/ltmain.sh

#4) I don't like hiding the autofiles, so I removed the subdir and will 
change configure.in appropriately, but you don't have to do that.

rmdir autoconf

#5) libiconv doesn't use automake, but it does distribute some scripts 
from automake.  Replace them with the current versions.  (Actually, 
libiconv only distributed install-sh; it used the mkinstalldirs from the 
libcharset subdirectory, "proper" auto* usage requires that each 
separately configure project have its own copy...and of course, I put 
install-sh in the top directory, libiconv had it in the autoconf subdir)

cp /usr/autotool/devel/share/automake/mkinstalldirs .
cp /usr/autotool/devel/share/automake/install-sh .

#6) repeat steps 1-4 for the libcharset subdirectory.  Normally, this is 
unnecessary, but libiconv actually treats libcharset as a separate 
project, with it's own configure script and suchlike...

rm libcharset/autoconf/aclocal.m4
rm libcharset/autoconf/mkinstalldirs
rm libcharset/autoconf/install-sh
rm libcharset/autoconf/config.guess
rm libcharset/autoconf/config.sub
rm libcharset/autoconf/ltmain.sh
rm libcharset/configure
rmdir libcharset/autoconf

#7) libcharset also includes its own copies of some .m4 scripts that are 
part of gettext.  Use the system ones.

rm libcharset/m4/codeset.m4
rm libcharset/m4/glibc21.m4

#8) AND we're going to use the system libtool...and cleanup.

rm libcharset/m4/libtool.m4
rm libcharset/m4/ChangeLog
rmdir libcharset/m4

#9) Similar to step #5, replace the "automake" files with the latest 
version (even though libcharset doesn't use automake...).  Both 
mkinstalldirs and install-sh WERE in the autoconf subdir of libcharset; 
I put them in the top level (of libcharset).  Each separately configured 
project needs its own copy...

cp /usr/autotool/devel/share/automake/mkinstalldirs libcharset/
cp /usr/autotool/devel/share/automake/install-sh libcharset/

#10) As promised, I need to change a few items in configure.in (e.g. 
don't use the "autoconf" subdir (or libcharset/autoconf or 
libcharset/m4).  Also, since the "special" versions of the autoconf 
files that libiconv distributes were slightly modified -- okay, they 
were distributing a fork -- I parsed out the differences they had, and 
put those macros into acinclude.m4...

The patch is attached.

The patch also AC_PREREQ's 2.52 instead of 2.13 (I want to use the 
-devel tree), but that required a few other changes due to 
incompatibilities (AC_OUTPUT_SUBDIRS ---> AC_CONFIG_SUBDIRS, etc)

Normally, you'd also re-run autoheader at some point, but that didn't 
work (thanks to the fact that libiconv uses a forked autoconf dist...) 
So I patched libcharset/config.h.in by hand...

#11) Okay, here's the meat:  First, we relibtoolize libcharset:

cd libcharset
aclocal
libtoolize -c -f
aclocal # (again)
autoconf

cd <topsrc>
aclocal
libtoolize -c -f
aclocal # (again)
autoconf

Why the second aclocal step?  Because libtoolize adds additional stuff 
in configure.in, which require additional macros to be pulled into 
aclocal.m4.  Why not run libtoolize first, and then aclocal?  Because 
libtoolize needs a pre-existing aclocal.m4...

Normally, you'd run "automake -a -c" between the second aclocal and 
autoconf, but libiconv doesn't use automake.  Also, you'd normally run 
autoheader after the second aclocal -- but we can't because libiconv sucks.

Finally, you should be able to configure and make as "normal":

conf() {
   (cd ${objdir} && \
   ${srcdir}/configure --build=${host} --target=${target} \
   --srcdir=${srcdir} --prefix=${prefix} \
   --exec-prefix=${prefix} --sysconfdir=${sysconfdir} \
   --libdir=${prefix}/lib --includedir=${prefix}/include \
   --enable-shared --enable-static )
}

 > Is the general idea here that I would just be working on the config files
 > and makefiles, rather than having to make extensive internal changes 
to the
 > way that libraries are loaded?

Yes.

--Chuck

Harold Hunt wrote:

> Chuck,
> 
> Could you give a few more notes on "relibtoolize"?  A pointer to some good
> documentation would be helpful...
> 
> Is the general idea here that I would just be working on the config files
> and makefiles, rather than having to make extensive internal changes to the
> way that libraries are loaded?
> 
> Harold
> 
> 
>>-----Original Message-----
>>From: cygwin-xfree-owner@cygwin.com
>>[mailto:cygwin-xfree-owner@cygwin.com]On Behalf Of Charles Wilson
>>Sent: Tuesday, April 30, 2002 2:48 AM
>>To: cygwin-xfree@cygwin.com
>>Cc: cygx
>>Subject: Re: mkdll.sh
>>
>>
>>You could probably do the following:
>>
>>get rid of mkdll.sh
>>relibtoolize/autoconf using the "-devel" tools (e.g. make sure that
>>configure.in has "AC_PREREQ(2.52)")
>>
>>./configure; make;
>>
>>It oughta work. </famous last words>
>>
>>--chuck
>>
>>
>>Harold Hunt wrote:
>>
>>
>>>Steve,
>>>
>>>I'm working on creating Cygwin setup.exe packages for Gnome...
>>>
>>I know, it's
>>
>>>buggy but I'd like to get a start.  One problem I'm having with
>>>
>>your patches
>>
>>>is that they use mkdll.sh but they don't cause configure to
>>>
>>copy the file to
>>
>>>a build directory.
>>>
>>>For example:
>>>
>>>tar xzf glib-1.2.10.tar.gz
>>>cd glib-1.2.10
>>>patch -p1 < ../glib-1.2.10-cygwin.patch
>>>mkdir build
>>>cd build
>>>../configure
>>>[yada yada yada]
>>>make
>>>[yada yada yada]
>>>mkdir .libs
>>>ar cru .libs/libglib.a  garray.o gcache.o gcompletion.o
>>>
>>gdataset.o gdate.o
>>
>>>gerro
>>>r.o ghash.o ghook.o giochannel.o giounix.o glist.o gmain.o gmem.o
>>>gmessages.o gm
>>>utex.o gnode.o gprimes.o grel.o gscanner.o gslist.o gstrfuncs.o
>>>
>>gstring.o
>>
>>>gtimer
>>>.o gtree.o gutils.o
>>>ranlib .libs/libglib.a
>>>creating libglib.la
>>>(cd .libs && rm -f libglib.la && ln -s ../libglib.la libglib.la)
>>>cd .libs && PREFIX=/usr sh ../mkdll.sh libglib.la
>>>../mkdll.sh: Can't open ../mkdll.sh: No such file or directory
>>>make[2]: *** [libglib.la] Error 2
>>>make[2]: Leaving directory
>>>`/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2.
>>>10/.build'
>>>make[1]: *** [all-recursive] Error 1
>>>make[1]: Leaving directory
>>>`/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2.
>>>10/.build'
>>>make: *** [all-recursive-am] Error 2
>>>
>>>
>>>Eventually I always reach a point where mkdll.sh can't be found because
>>>configure didn't copy it to the out-of-the-tree build directory.
>>>
>>>Got any ideas on how to fix this?
>>>
>>>Harold
>>>
>>>
>>>
>>>
>>
>>
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libiconv-1.7-2.patch2
URL: <http://cygwin.com/pipermail/cygwin-xfree/attachments/20020430/3952a6f1/attachment.ksh>