Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3C47D5E0.4070702@ece.gatech.edu>
Date: Fri, 18 Jan 2002 02:59:28 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Ralf Habacker <Ralf DOT Habacker AT freenet DOT de>
CC: Cygwin <cygwin AT sources DOT redhat DOT com>,
   Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
Subject: Re: libtool-devel and kde2 - problem with AC_PROG_CXX
References: <01a201c19f66$36b66c10$fe6207d5 AT BRAMSCHE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ralf Habacker wrote:

> Robert Collins wrote:
> 
> 
>>Quoting from the fink site (it was handy):
>>"The current development branch: This is the development version that
>>will some day be released as libtool 1.5. It has resulted from the merge
>>of 1.4 and the MLB. It supports C, C++ and Java (via gcj).
>>Unfortunately, it can't be easily told apart from 1.4, you'll have to
>>check the version number inside ltmain.sh."
>>
>>For the _last time_, the devel libtool DOES NOT and WILL NOT  create
>>ltconfig. Don't expect it, because its NOT MEANT TO create it.
>>
> 
> It does not create ltconfig, but it need it as you could see in my last mail


As of 20010531, there seem to have been a few remaining references to 
ltconfig -- within the _LT_AC_LANG_CXX and _LT_AC_LANG_GCJ m4 macros. 
Not surprising that those were missed -- C++/java don't have nearly the 
history that C does.  Studying the ChangeLogs, ltconfig was removed on 
2000-09-19, but "stale references" were continually being found and 
fixed thru 2001 (2001-04-05, 2001-04-24).

>>checking if libtool supports shared libraries... yes
>>checking how to run the C++ preprocessor... g++ -E
>>admin/ltconfig: Can't open admin/ltconfig: No such file or directory
>>configure: error: libtool tag configuration failed
>>
> 
> I have searched in the libtool cvs on subversions.gnu.org and seen that on 20010531 the merge
> of the mlb code wasn't ready. You can verify this by unpacking the recent
> libtool-devel-20010531-6.tar.bz2 and looking in the libtool.m4 if there are references to
> ltconfig.


Not entirely correct.  As I said, it seems that the _CXX and _GCJ 
references hadn't been removed as of 20010531.  However, the MLB merge 
was -- if not complete, then at least partially begun:

2001-05-27: ltmain.in: Merged from multi-language-branch
2001-05-27: libtool.m4: Merged from multi-language-branch
2001-05-30: libtool.m4: Merged ltconfig.in from multi-language-branch
             ^^^^^^^^^^ not a typo

However, as you say, there were some ADDITIONAL merges from MLB that 
happened later: on 2001-06-24.

 
> If you follow the below mentioned link you can see that the tag creation support was
> completed at 2001 Jun 24 , so the libtool from 20010531 can't contain full tag creation
> support. !!!!


[snip]

 
> I have appended a patched libtool.m4 from the libtool cvs HEAD release numver 1.245 and
> patched mostly of the changes Charles provided in the rc5 diffs and got a working CXX/GCJ/RC
> tag creating. Try it. It may not be complete for all cases, but I think you are able to
> verify this.


Actually, I am not able to guarantee that
   1) taking the Robert's patches to libtool.m4(20010531)
   2) applying those changes to libtool.m4(20011128)
   3) but NOT updating any of the other interdependent files that form 
the libtool toolset

results in a stable libtool.  You have said that it works well for you 
on a given set of dlls -- but you've already demonstrated that your case 
is rather special: multi-language, CXX/GCJ, etc.  I don't want to fix 
the corner case by breaking the mainline cases: single language, C.

Look, Ralf, this libtool port is a work in progress.  Right now, I'd 
like for folks to test the "normal" stuff.  (So far, that looks good). 
Then, we need to port forward ALL of the patches to ALL of the files -- 
not just libtool.m4 -- to current HEAD cvs libtool.

Gary Vaughan (the libtool maintainer) is on the case, he WANTS to put 
this stuff into current cvs.  He was waiting for Robert's FSF copyright 
assignment to go thru before he started : and that just happened last 
week (see the libtool mailing list...)

Be patient -- it was hard enough getting the infrastructure in place to 
have an auto-import capable libtool become part of the cygwin dist in 
the first place.  I couldn't very well pester Gary to accept the patches 
until we had a working example installation...and that just happened 
last week.

Just to review the tool-side things that have been happening in the past 
six months (not all me, but I *have* been pushing most of them)
   test Paul Sokolovsky's auto-import stuff
   push it into official binutils

   migrate (old) autoconf package to autoconf-stable
   create autoconf-devel package (and talk very very fast to get corinna 
to support it)
   create autoconf (wrappers)

   migrate (old) automake package to automake-stable
   create automake-devel package (and talk very very fast...)
   create automake (wrappers)
    >>> special automake hack to make the split-install ALSO search 
/usr/share/aclocal in addition to /usr/autotool/*/share/aclocal <<<

   create libtool-stable (1.4.2)
   create libtool-devel package from Robert's patches (but based on an 
old version of libtool cvs: 20010531)
   create libtool-wrappers

AND, spread amonst all of those steps, was a lot of advocacy and 
discussion on the various mailing lists (like this message).  Email -- 
especially involved ones like "let's restructure the entire way we 
install the autotools -- here's my plan" -- takes almost as much time as 
coding...

What's left:
   port ALL of Roberts changes (not just his changes to libtool.m4) 
forward to HEAD cvs.
   test
   push those changes *into* libtool cvs -- hopefully before libtool-1.5
   release new libtool-devel based on libtool-1.5

We're almost there -- but don't let the cart get in front of the horse.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/