Charles Wilson wrote:
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?
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/
