Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "Cygwin" <cygwin AT sources DOT redhat DOT com>
Subject: RE: libtool-devel and kde2 - problem with AC_PROG_CXX
Date: Fri, 18 Jan 2002 12:50:08 +0100
Message-ID: <003901c1a016$47079b10$7ca907d5@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3C47D5E0.4070702@ece.gatech.edu>

>
> 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).
>
Aha

> >>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.

I understand

> 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.
>
Okay that make sense

> 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...)

I have seen this on the libtool 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.

I have not problem with this

> 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)

I have an additional patch for ltmain.(sh|in)

> 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.

I understand this very well and I respect your contribution also. I think you have done a
very great work. (What do you think, why I have written about putting your name into the
acknowledgement chapter of the kde-cygwin project). I know this because as I have started to
understand this auto.... stuff I'm gone creasy about this dimension.

I felt like a man who runs through a jungle with many pitfalls and waspy snakes, which can
paralyse anyone who lookes to long at it. :-/ Porting kde is really easy against this.

What you do are think, why I have patched again Roberts patched libtool (which I have send to
you at first and recognized later as senseless) and not libtool.m4 and so on for makeing
kde - I wasn't able to go through it. There are so many dependencies and quirks. The job I
have currently to do with kde releasing and testing and preparing rules and discuss with
others takes so many time that the libtool part could only be handled very spare. What should
I say, you have written the same about your job.

But on the other side I need to prepare the kde sources for the kde-cygwin cvs with a full
configuration process so that more people can contribute to the necessary optimations to get
a real working kde port and for this I need a full working configuration process.

It is true, that the kde configuration process is relative complicate (needed CXX and several
complicate sub configuration), but for checking the functionality I'm using seperate test
projects for C and C++; the C version I have send on the list.

I'm doing this because the full configuration process of kde2 libs needs about 20 minutes and
this reduces the debugging cycles very much. So I have to look what goes wrong with kde and
adapt the test project for debugging.

That's what I want to say about this. Again, I respect the work and efforts of all who have
contribute anything to this topic and I don't like to "let the cart get in front of the
horse". I know the problems with this stuff.

At last I like to write about some additional topic I recognized with the libtool stuff:

1. providing -Wl,--enable-auto-import for linking executables (ltmain.in)
I have prepared a patch for this, but I recognized that there must be a general strategy for
handling the auto-import stuff. There are questions about when this flag should has to be
set.
Should is be set when a ld with auto-import is found by default or should this set only with
a specific configure flag like --with-auto-import or how should this go on ? I don't know the
answer, because I don't have the overview. The currently patch I'm using is to enable this
flag, when a ld with auto-import stuff is found.
So if anyone can give me a hint for the direction, I can provide this.

2. problems with dependency code
While compiling kdelibs I recognized that some dependency libs located in some *.la files are
not put on the link line, which causes linkage failure. I will analyse this a little bit
more.

3. Robert asks for a diff file with my patches.
Speaks anything against patching the head src from subversions.gnu.org and providing this
patch ?

Regards
 Ralf


--
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/