gcc: .rdata problem

[Charles Wilson]

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?

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/