Post by EarniePost by Roger PackHello.
G:\installs\mingw-raw\bin\libtool
compiler_lib_search_dirs="c:/mingw/bin
Is this expected?
Another reason to dislike libtool.
Everybody hates libtool, until they get involved in making it better.
Then two things happen: (1) they hate it more (2) they realize that all
that ugliness is there for a reason.
It really is necessary. Sad, but true.
One of my long-term goals for libtool on cygwin|msys|mingw is to teach
libtool to simply use the language driver -- $(CC), $(CXX), $(F77), etc
-- to link, rather than it's current (more universal) approach which is to:
1) detect at libtool-creation-time what "stuff" the language driver adds
to the link command -- pre-deps, post-deps, additional flags, extra
libs, runtime objects, etc -- and "save" those.
2) Use the linker ($LD) directly to link -- adding back in all the
"extra stuff" that was discovered in step one.
BTW -- it's step #1 that leads to the hardcoded compiler (version)
dependent paths getting embedded in the "built" libtool.
All that extra work is necessary for a number of arcane reasons on
various platforms, so the same procedure is used on ALL platforms. But,
if the language driver is from the GNU Compiler Collection, and the
linker is the GNU linker, then theoretically you can skip all of that --
and just use the language driver as $(LD) and not worry about
pre/post-deps, libs, extra objs, etc.
It's a big job to convince libtool to work this way, and I haven't had
the tuits to tackle it yet. Maybe after $git-port. It would benefit
*all* GCC+GnuLD platforms, not just cygming.
Post by EarnieSurely this should become
compiler_lib_default_search_dirs to allow other directories to be
specified. Maybe it does already, don't know that much about libtool.
What I would expect for MinGW is that this becomes `cd /mingw&& pwd -W`
to make it directory portable.
It really can't do the latter, for two reasons: (1) multiple passes of
evaluation. At some point it's GOING to turn into what it represents, on
the builder's machine, and not the shell exec command. (2) This breaks
libtool's ability to cross-compile.
Post by EarnieOne work-around is to get the junction.exe tool from sysinternals and
issue ``junction c:\mingw g:\installs\mingw-raw''. The other, get the
libtool source and build the package yourself. Make sure to use a
--prefix=`cd /mingw&& pwd -W` during the configure process.
NO!
The installed (mingw32) libtool itself is built using --prefix=/mingw;
just like the other (mingw32) autotools, it is perl/m4/shell-based and
thus lives in a hybrid world. mingw32-libtool itself is an *msys* tool,
because it uses /bin/sh -- but is USED to create mingw32 "stuff" (unlike
msys-libtool, which is also msys-based but is used to create msys
"stuff" and thus isn't "hybrid" at all).
Now, if you have a $foo source package that has been libtoolized, then
during $foo's configure it will create a local libtool script. Since
you probably configured $foo with --prefix=`cd /mingw && pwd -W`, then
THAT local libtool script will ALSO have internal references to
$(whatever `cd /mingw && pwd -W` evaluates to locally). That's fine,
and it works -- because you're using it locally, and if you've used the
magic prefix expression above then obviously you're building with
$build=mingw for $host=mingw -- that is, native mingw.
--
Chuck