RE: mkdll.sh

["Harold Hunt" <huntharo at msu dot edu>]

Chuck,

Excellent.  You know that your write-up won't be a wasted effort on me.  :)

I'll be looking at this next week.

Harold

> -----Original Message-----
> From: Charles Wilson [mailto:cwilson@ece.gatech.edu]
> Sent: Tuesday, April 30, 2002 11:48 AM
> To: Harold Hunt
> Cc: cygx
> Subject: Re: mkdll.sh
>
>
> 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
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
>
>