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
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3E604381.40008@ece.gatech.edu>
Date: Sat, 01 Mar 2003 00:22:09 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [PATCH] libtool patch for direct-linking-to-dll
References: <001801c2df1f$6647b1b0$0a1c440a AT BRAMSCHE>
In-Reply-To: <001801c2df1f$6647b1b0$0a1c440a@BRAMSCHE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[BTW, Ralf, patches to libtool don't belong on cygwin-apps.  It's not a 
packaging issue, a packaging-policy issue, nor a setup issue.  This 
thread belongs on the main cygwin list.]

Ralf Habacker wrote:
 >>
 >> Any hints or comments ?

Haven't reviewed or tested the patch yet [that'll come later], but I do
have an opinion about the adoption timeline...

In the past, when some nifty-new libtool feature depended on a binutils
or gcc improvement, we did the following:
    1) push the change into the appropriate cygwin package, and release it
       -- this usually involves wheedling cgf <g>

Chris - it appears that Fabrizio's release form ("allow PE executables
to have an export table") is on the slow boat.  Can we go ahead and have
a new release of binutils with Ralf's (already in CVS) "link directly to
dlls" stuff?  Mebbe after the dumper/objdump thing [whatever; I haven't
been paying close attention] is cleared up?

    2) after the "curr" binutils or gcc has the feature, wait a month or
       so to allow most people to test that release (we don't want to be
       caught putting out a new libtool that requires
       nifty-binutils-feature-X, only to see the that binutils release
       withdrawn for some reason).  so, wait...

tick tock tick tock

    3) about two weeks or so into this "official binutils/gcc vetting
       process, release a **test** version of the new-and-improved
       libtool

tick tock tick tock

    4) If all goes well, promote the test libtool to curr.

Note that I didn't say "worry about whether nifty feature X is available
in binutils".  Given that we're still talking about *CVS* libtool, we
can reasonably require that users of CVS libtool (e.g. -devel) have the
latest-and-greatest binutils/gcc/etc.  We don't need to futz with
check-this-thing, check-that-thing.  Sheesh, libtool-on-cygwin, even
with the latest improvements, is still slow as frozen molasses.  We
don't need to slow it further, just to deal with something that (IMO) is
really a distribution-integration issue.

Now, about your implementation; I'll check that later...

--Chuck

 >> 2003-02-27  Ralf Habacker  <ralf DOT habacker AT freenet DOT de>
 >>
 >> 	* libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER): Removed
 >> 	postinstall_cmds and postuninstall_cmds,
 >>       added shared library to 'library_names_spec'.
 >> 	(AC_LIBTOOL_LANG_CXX_CONFIG): Removed import library
 >>  	generation from 'archive_cmds'.
 >>
 >> 	* ltmain.sh: (install cygwin/mingw): added installing
 >> 	of shared libraries into 'bin' dir
 >> 	(uninstall cygwin/mingw): added uninstalling
 >> 	of shared libraries
 >>
 >> 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/