Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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: <42D489A6.6020200@cwilson.fastmail.fm>
Date: Tue, 12 Jul 2005 23:25:26 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: gcc: .rdata problem
References: <SERRANOIHKZtitZi6pH000004cb AT SERRANO DOT CAM DOT ARTIMI DOT COM> <42D403FC DOT 2060402 AT familiehaase DOT de>
In-Reply-To: <42D403FC.2060402@familiehaase.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gerrit P. Haase wrote:

>> dk AT mace /artimi/firmware> grep 3.3.3 /bin/libtool
>> predep_objects="/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/crtbegin.o"
>> postdep_objects="/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/crtend.o"
>> compiler_lib_search_path="-L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3
>> -L/usr/lib/gcc
>> -lib/i686-pc-cygwin/3.3.3/../../.."
>> dk AT mace /artimi/firmware>
>>
>>   Hey, why not extract that stuff from gcc somehow?  The 
>> -print-search-dirs
>> output could be manipulated to give you that stuff, couldn't it?
> 
> 
> Why wasn't this included in the specs?

There's a lot more machinery to the predeps and postdeps detection code 
than simply hardcoding a directory or a .o.  Yes, for g++-3.4, it is 
that simple and could be replaced with some non-configure-based, 
parse-gcc--version-at-runtime code.

But it would be 3.4.4 specific.  And most likely cygwin specific (I 
think linux has a non-empty postdeps, even with g++-3.4.4).  Can you 
guarantee that there won't be any postdeps in 3.4.5 or 4.0?

The whole design of libtool really militates against runtime detection 
of system paramters; it is designed to be incorporated as part of a 
project's build/configure.  There has even been talk -- quickly squashed 
   by me -- of removing support for so-called "standalone libtool".  So, 
"standalone libtool" remains but is definitely a red-headed stepchild.

Trust me, moving towards runtime detection of these parameters is not 
gonna happen -- it's too brittle for the majority use, which is and will 
remain internal configure-driven, per-project libtool scripts.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/