Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: "cygwin" <cygwin AT cygwin DOT com>
Subject: RE: [PATCH] libtool patch for direct-linking-to-dll
Date: Mon, 10 Mar 2003 21:15:31 +0100
Message-ID: <008301c2e741$ccd5a840$dc6207d5@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3E6C8F6C.5060907@ece.gatech.edu>
Importance: Normal

> Okay, I've actually looked at the patch now.  Apparently I misunderstood.
>
> I thought this was a patch to enable using libtool to link against an
> outside shared library in which the implib was actually a symlink to a
> DLL -- which I didn't think would require much if any hacking with
> libtool, so I was curious to see what you did

Right, for this case there is no additional patch required. It will work already
with the recent libtool release.

> I didn't realize it was a patch to rip out all of the import-lib
> building stuff, and replace it with the new link-to-dll support.
>
> I don't think that's a good idea just yet; I hate to be a wet blanket,
> but I think this should stay out of the main tree for a while.
> [Basically, I'm nervous about such a radical change in libtool's
> fundamental behavior this close to its release date].

> Now that the appropriate support is in the released binutils, let it
> simmer for a while -- a long while.  If you want to use this in your
> build of qt/kde, fine by me -- that'd be a good test bed. (I'm sure we
> can work out something about the 'official packages must only use other
> official packages to build' so that your qt stuff can be added to the
> distro.  -- see below).  If there are no problems after a few months,
> then we'll look at getting it into libtool 1.5.1 or 1.5.2 or whatever.
> But not 1.5 -- it's just too big a change. :-(
>
No problem, but I would like to hear from someone who knows this libtool stuff,
If I'm on the wrong way with this implementation, because it is very difficult
to change an implementation, if it is already on the road.
I will prepare a final patch with recent libtool, which will handle dlopened
files too (which isn't in the recent patch)

> (*) For instance, libtoolize/autoconf/whatever with the 'stock cygwin
> version' -- and then supply a *qt* patch that inserts your nifty changes
> into the qt-3.0.3/ltmain.sh during the qt build process.  Or heck, just
> ship qt patched with your local version of libtool; the autotools are
> not supposed to be necessary for the "ordinary" user who just wants to
> compile the package.  And hardly anyone will recompile qt on their own,
> anyway -- they just want to link TO it.  So long as it's *possible*
> (even if difficult; hello cgf-packaging-system <g>) to rebuild your qt
> on a stock cygwin system, then you're okay IMO.

Qt does not use libtool, but kde does. For qt only the new binutils is required,
so this is no problem.
The kde build system contains a separate copy of libtool.m4 and ltmain.sh, which
I have already patched.
Because this is independent from the offical cygwin libtool, there is no problem
with the timeline and it is possible to incorporate the changes at a later
point.

BTW: In the meantime I have fixed some more issues especially with specific path
setting.

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/