[BuildTools] Testing AC_COIN_CREATE_LIBTOOL (faking mingw as -mno-cygwin)

Lou Hafer lou at cs.sfu.ca
Thu Dec 14 11:25:10 EST 2006


Andreas,

	Sad to say, this blows up in several interesting ways.  I have it
working, but want to spend more time today tidying up and integrating the msvc
(cl/link) build environment before sending revisions.  But, there's an
interesting tale taking shape.

	I reintegrated the enhanced --enable-doscompile option I've been
proposing and gave it a spin.  The first problem that appeared was inconsistent
test results for include files.  This goes back to the fact that coin.m4 doesn't
set CPPFLAGS to include -mno-cygwin --- this flag changes the preprocessor's
search directories (as well as compile and link search directories).  One of
dylp's m4 patches was supposed to deal with this.  Turns out that because the
revised AC_COIN_INIT_AUTO_TOOLS simply sets variables based on the top level
config.status, my tweaks need to follow lest they be erased. Easy enough.

	Now to the interesting part.  The above got me through configuration,
but I started seeing build errors --- `cygpath can't cope with empty path', or
similar.  After some grepping about, I traced this back to libtool and realised
that the fix to properly quote fix_srcfile_path wasn't being applied.  A bit
more poking about turns up that something down inside AC_PROG_LIBTOOL must
use an AC_REQUIRE, because all the shell code to create libtool is pushed up
outside the body of AC_COIN_PROG_LIBTOOL.  By the time configure execution gets
to the line `if test "x$LIBTOOL" = x; then', LIBTOOL is defined, hence the
various fixes never execute. Try putting
AC_MSG_NOTICE([Entering coin_prog_libtool, LIBTOOL = "$LIBTOOL".])
just prior to the test. Note that not tweaking libtool won't break any of the
full unix environments, which don't really need these tweaks.

	This next is speculation, but I'll test it shortly.  I've always
wondered why it was necessary to AC_REQUIRE a special test for dlfcn.h.  But put
the two things together.  It's necessary to AC_REQUIRE([AC_COIN_DLFCN_H]) in
order to get it out in front of the AC_REQUIRED code for AC_PROG_LIBTOOL.  And
you need a special test to avoid warnings about inconsistent discovery because
dlfcn.h is present in the cygwin world but not in the mingw world.  Because
CPPFLAGS is not set to include -mno-cygwin, the preprocessor test finds the file
(CPPFLAGS only) but the compile test (CPPFLAGS plus CFLAGS) does not.
COIN_CHECK_HEADER effectively forces an include of the header file under test,
even after the preprocessor has decided it's not present.  I should have made
this connection several months back, when I was generating the m4 patch to
correct CPPFLAGS for dylp. (Recall also that -mno-cygwin used to be the default
for the cygwin build.)

	Given the enhanced --enable-doscompile, I think I can patch up coin.m4 
to get CPPFLAGS correct. We'll see how it goes.
	
							Lou



More information about the BuildTools mailing list