Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C18186.263B277A"
Subject: RE: libtool packages 
Date: Mon, 10 Dec 2001 09:22:51 -0500
Message-ID: <6EB31774D39507408D04392F40A10B2BC1FE62@FDYEXC202.mgroupnet.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: libtool packages 
Thread-Index: AcGBTD7MnB3tCUk2Tr+6jHpIODVntAAOZLbR
From: "Roth, Kevin P." <KPRoth AT MarathonOil DOT com>
To: <cygwin-apps AT cygwin DOT com>
X-OriginalArrivalTime: 10 Dec 2001 14:22:51.0322 (UTC) FILETIME=[266AD1A0:01C18186]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C18186.263B277A
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

For your "stable" release, you might consider rolling in the libtool
1.4.2 patch mentioned in this note
(http://sources.redhat.com/ml/cygwin-apps/2001-10/msg00110.html) the
allows libtool-ized 'exe's to be installed correctly with a typical
`make install`. AFAICT, it's an official patch in the libtool CVS that
will be included with 1.4.3 whenever it's released.

--Kevin


-----Original Message-----
From:	Charles Wilson
Sent:	Mon 12/10/2001 2:28 AM
To:	cygwin-apps AT cygwin DOT com
Cc:=09
Subject:	libtool packages=20

I've put three new packages here:
   http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/

I am not yet ready to even ask for official inclusion.  This is just a=20
kind of "here, heads up, what do you think?" message.

There's
   libtool-20010531-rc6.tar.bz2
   libtool-20010531-rc6-src.tar.bz2
   libtool-devel-20010531-rc6.tar.bz2
   libtool-devel-20010531-rc6-src.tar.bz2
   libtool-stable-1.4.2-1.tar.bz2
   libtool-stable-1.4.2-1-src.tar.bz2

Just like the auto* packages, the libtool-devel package installs into=20
/usr/autotool/devel/, and the libtool-stable package installs into=20
/usr/autotool/stable/.  The libtool package is a set of wrapper scripts=20
that install into /usr/, and set the PATH and other ENV vars=20
appropriately before exec'ing the "correct" real libtool.

libtool-stable:
   contains libtool-1.4.2 (mostly OOB, patches are documentation only)
   works (more or less).  Follow the goat book examples to build DLLs=20
using this version.

libtool-devel:
   Robert Collin's hacked version.  (BTW, I recall that "edward=20
tailbert" submitted a number of libtool fixes to cygwin@ and libtool@=20
lists back in March.  Some (I think) were actually folded into libtool=20
cvs and are part of libtool-1.4official.  Do any of Robert's changes=20
harken back to edward?)  Anyway, it is based off of libtool-cvs on=20
20010531, with a 40k patch and then a bootstrap (redo the autoconf,=20
automake, autoheader, etc).  Now that I've parsed out the minimum=20
changes, I'll submit that to Gary Vaughan -- hopefully he'll find that=20
easier to deal with than the earlier 400k patch....
   Anyway, this version seems to be able to build DLLs OOB, using the=20
autoimport stuff.  (Of course, you have to re-libtoolize your target=20
package with the new version to get that to work -- which may also=20
entail updating configure.in to work with the new autoconf, and=20
re-autoconf'ing and re-automaking...)

libtool:
   contains "libtool-scripts-20010531' (I'm basing the versioning of my=20
-scripts- packages off of the cygwin -devel- version that they are=20
supposed to work with.)  Again, the choice of whether to use -stable- or

-devel- is based on configure.in: AC_PREREQ(X) X <=3D 2.13, stable; X >=20
2.13 or nonexistant, devel.

Note that BOTH libtool-1.4.2 (1.4.1, 1.4) and hacked libtool do NOT use=20
ltconfig.sh at all.  They only need ltmain.sh.  So, when=20
re-libtoolizing, be sure to rm ltconfig.sh...

packaging:
   As with the auto* packages, the -devel- version installs its info=20
files into /usr/info as well as /usr/autotool/devel/info/.  However,=20
since libtool also ships a library, ltdl, I'm in a bit of a bind.

The static lib can *probably* stay where it is (usr/autotool/*/lib) and=20
ltdlized packages will link to it okay.  (If not, most ltdlized packages

ship with the source code anyway, and build it themselves locally if it=20
"wants" to link statically.  Kinda like gettext/libintl).  However, both

stable and devel versions ALSO ship a dll.  And, since the source code=20
hadn't changed, the libtool version is 3:0:0 for both, so both the=20
stable and devel packages contain a 'cygltdl-3.dll'.

But they are not interchangeable.  One was linked "the old way" with=20
__declspec's and everything, while the other is a new-style=20
autoimport/autoexport library.  (I *think* the new one can sub for the=20
old one, but not vice versa)

Anyway, since they can't BOTH be in /usr/bin, and you DON'T want to set=20
PATH to /usr/autotool/*/bin (kinda defeats the whole wrapper script=20
idea) -- I arbitrarily put the -devel- version of the ltdl libs into
/usr

Questions, comments, test reports?  They seem to work okay for my=20
minimal tests...

--Chuck






------_=_NextPart_001_01C18186.263B277A
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DWindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4712.0">
<TITLE>RE: libtool packages </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>For your &quot;stable&quot; release, you might =
consider rolling in the libtool 1.4.2 patch mentioned in this note (<A =
HREF=3D"http://sources.redhat.com/ml/cygwin-apps/2001-10/msg00110.html">h=
ttp://sources.redhat.com/ml/cygwin-apps/2001-10/msg00110.html</A>) the =
allows libtool-ized 'exe's to be installed correctly with a typical =
`make install`. AFAICT, it's an official patch in the libtool CVS that =
will be included with 1.4.3 whenever it's released.<BR>
<BR>
--Kevin<BR>
<BR>
<BR>
-----Original Message-----<BR>
From:&nbsp;&nbsp; Charles Wilson<BR>
Sent:&nbsp;&nbsp; Mon 12/10/2001 2:28 AM<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; cygwin-apps AT cygwin DOT com<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp;<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; libtool packages<BR>
<BR>
I've put three new packages here:<BR>
&nbsp;&nbsp; <A =
HREF=3D"http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/">http=
://www.neuro.gatech.edu/users/cwilson/cygutils/testing/</A><BR>
<BR>
I am not yet ready to even ask for official inclusion.&nbsp; This is =
just a<BR>
kind of &quot;here, heads up, what do you think?&quot; message.<BR>
<BR>
There's<BR>
&nbsp;&nbsp; libtool-20010531-rc6.tar.bz2<BR>
&nbsp;&nbsp; libtool-20010531-rc6-src.tar.bz2<BR>
&nbsp;&nbsp; libtool-devel-20010531-rc6.tar.bz2<BR>
&nbsp;&nbsp; libtool-devel-20010531-rc6-src.tar.bz2<BR>
&nbsp;&nbsp; libtool-stable-1.4.2-1.tar.bz2<BR>
&nbsp;&nbsp; libtool-stable-1.4.2-1-src.tar.bz2<BR>
<BR>
Just like the auto* packages, the libtool-devel package installs =
into<BR>
/usr/autotool/devel/, and the libtool-stable package installs into<BR>
/usr/autotool/stable/.&nbsp; The libtool package is a set of wrapper =
scripts<BR>
that install into /usr/, and set the PATH and other ENV vars<BR>
appropriately before exec'ing the &quot;correct&quot; real libtool.<BR>
<BR>
libtool-stable:<BR>
&nbsp;&nbsp; contains libtool-1.4.2 (mostly OOB, patches are =
documentation only)<BR>
&nbsp;&nbsp; works (more or less).&nbsp; Follow the goat book examples =
to build DLLs<BR>
using this version.<BR>
<BR>
libtool-devel:<BR>
&nbsp;&nbsp; Robert Collin's hacked version.&nbsp; (BTW, I recall that =
&quot;edward<BR>
tailbert&quot; submitted a number of libtool fixes to cygwin@ and =
libtool@<BR>
lists back in March.&nbsp; Some (I think) were actually folded into =
libtool<BR>
cvs and are part of libtool-1.4official.&nbsp; Do any of Robert's =
changes<BR>
harken back to edward?)&nbsp; Anyway, it is based off of libtool-cvs =
on<BR>
20010531, with a 40k patch and then a bootstrap (redo the autoconf,<BR>
automake, autoheader, etc).&nbsp; Now that I've parsed out the =
minimum<BR>
changes, I'll submit that to Gary Vaughan -- hopefully he'll find =
that<BR>
easier to deal with than the earlier 400k patch....<BR>
&nbsp;&nbsp; Anyway, this version seems to be able to build DLLs OOB, =
using the<BR>
autoimport stuff.&nbsp; (Of course, you have to re-libtoolize your =
target<BR>
package with the new version to get that to work -- which may also<BR>
entail updating configure.in to work with the new autoconf, and<BR>
re-autoconf'ing and re-automaking...)<BR>
<BR>
libtool:<BR>
&nbsp;&nbsp; contains &quot;libtool-scripts-20010531' (I'm basing the =
versioning of my<BR>
-scripts- packages off of the cygwin -devel- version that they are<BR>
supposed to work with.)&nbsp; Again, the choice of whether to use =
-stable- or<BR>
-devel- is based on configure.in: AC_PREREQ(X) X &lt;=3D 2.13, stable; X =
&gt;<BR>
2.13 or nonexistant, devel.<BR>
<BR>
Note that BOTH libtool-1.4.2 (1.4.1, 1.4) and hacked libtool do NOT =
use<BR>
ltconfig.sh at all.&nbsp; They only need ltmain.sh.&nbsp; So, when<BR>
re-libtoolizing, be sure to rm ltconfig.sh...<BR>
<BR>
packaging:<BR>
&nbsp;&nbsp; As with the auto* packages, the -devel- version installs =
its info<BR>
files into /usr/info as well as /usr/autotool/devel/info/.&nbsp; =
However,<BR>
since libtool also ships a library, ltdl, I'm in a bit of a bind.<BR>
<BR>
The static lib can *probably* stay where it is (usr/autotool/*/lib) =
and<BR>
ltdlized packages will link to it okay.&nbsp; (If not, most ltdlized =
packages<BR>
ship with the source code anyway, and build it themselves locally if =
it<BR>
&quot;wants&quot; to link statically.&nbsp; Kinda like =
gettext/libintl).&nbsp; However, both<BR>
stable and devel versions ALSO ship a dll.&nbsp; And, since the source =
code<BR>
hadn't changed, the libtool version is 3:0:0 for both, so both the<BR>
stable and devel packages contain a 'cygltdl-3.dll'.<BR>
<BR>
But they are not interchangeable.&nbsp; One was linked &quot;the old =
way&quot; with<BR>
__declspec's and everything, while the other is a new-style<BR>
autoimport/autoexport library.&nbsp; (I *think* the new one can sub for =
the<BR>
old one, but not vice versa)<BR>
<BR>
Anyway, since they can't BOTH be in /usr/bin, and you DON'T want to =
set<BR>
PATH to /usr/autotool/*/bin (kinda defeats the whole wrapper script<BR>
idea) -- I arbitrarily put the -devel- version of the ltdl libs into =
/usr<BR>
<BR>
Questions, comments, test reports?&nbsp; They seem to work okay for =
my<BR>
minimal tests...<BR>
<BR>
--Chuck<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C18186.263B277A--