delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2005/07/13/06:32:13

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: <42D4ED48.9070403@familiehaase.de>
Date: Wed, 13 Jul 2005 12:30:32 +0200
From: "Gerrit P. Haase" <gerrit AT familiehaase DOT de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
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> <42D489A6 DOT 6020200 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <42D489A6.6020200@cwilson.fastmail.fm>
X-IsSubscribed: yes

Charles Wilson wrote:

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


No guarantee from me.  I will try to keep it simple ;)



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

I see.  Since I always run autoreconf and a new specific libtool is
created during configure run, it should be ok as long as the genrated
libtool does the right thing.  This is time consuming and requires
much more interaction than just doing `cp /bin/libtool .`, but it is
safe.

I would vote pro removing the stand alone libtool.


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

Ok.


Gerrit

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019