gcc: .rdata problem

Gerrit P. Haase gerrit@familiehaase.de
Wed Jul 13 10:31:00 GMT 2005


Charles Wilson wrote:

> Gerrit P. Haase wrote:
> 
>>> dk@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@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/



More information about the Cygwin mailing list