Gerrit P. Haase wrote:
[EMAIL PROTECTED] /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/../../.."
[EMAIL PROTECTED] /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/
