From cygwin-xfree-return-9457-listarch-cygwin-xfree=sourceware dot cygnus dot com at cygwin dot com Wed May 01 04:21:00 2002 Return-Path: Delivered-To: listarch-cygwin-xfree at sourceware dot cygnus dot com Received: (qmail 30876 invoked by alias); 1 May 2002 04:20:59 -0000 Mailing-List: contact cygwin-xfree-help at cygwin dot com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner at cygwin dot com Mail-Followup-To: cygwin-xfree at cygwin dot com Delivered-To: mailing list cygwin-xfree at cygwin dot com Received: (qmail 30869 invoked from network); 1 May 2002 04:20:58 -0000 Received: from unknown (HELO pilot24.cl.msu.edu) (35.9.5.44) by sources dot redhat dot com with SMTP; 1 May 2002 04:20:58 -0000 Received: from huntharo (huntharo.user.msu.edu [35.11.210.160]) by pilot24 dot cl dot msu dot edu (8 dot 10 dot 2/8 dot 10 dot 2) with SMTP id g414KXX41750; Wed, 1 May 2002 00:20:33 -0400 From: "Harold Hunt" To: "Charles Wilson" Cc: "cygx" Subject: RE: mkdll.sh Date: Wed, 1 May 2002 00:20:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal In-Reply-To: <3CCEBCAD dot 30904 at ece dot gatech dot edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 > 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. > >> > >>--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 > >>> > >>> > >>> > >>> > >> > >> > > > >