autoconf (in 1.8 at least) and feature defs vs. macros
Jay Levitt
machine.
(Background: Stratus servers - I can't really call them "minicomputers"
anymore - run a proprietary operating system called VOS. It's written by
some of the same people who wrote Multics, and shares many of its features.
Two decades ago, there wasn't even a C compiler available. In recent
years, they've made some large strides toward portability, switching to a
Xeon-based platform, with POSIX.1 compliance built in, and gcc, perl5,
SAMBA, and other mainstays available.)
I spent today getting ./configure to build; this is the first time I've
really dug into an autoconf script, and I'd rather take time and do it
elegantly than just make a quick hack that "seems to work".
But, to my surprise, the best way to make configure.in work for ME was to
take out a bunch of hardcoded checks that affected other platforms as well.
And that makes me wonder why they were there.
The first and worst was libm. VOS, at least, finds its math functions
without having to link in libm - they're in the "internal don't touch"
libraries behind the curtain. libm doesn't exist, so anything assuming it
does will fail.
Result: On the first run, a whole bunch of different things failed for what
seemed to be entirely different reasons! Oops.
I finally figured it out. And I *think* the fix is simple - replace all the
hardcoded "LIBS = "$LIBS -lm" lines for each architecture with a simple
AC_SEARCH_LIBS (cos, m) check that will find it, whether it's "intrinsic"
to the compiler and architecture, or whether it'll need adding to the LIBS
list.
SO that seems nice and dry, but I worry that removing it from other
architectures I can't touch is a risky patch. Yet leaving it in is risky,
because theoretically it should now find their copy as well, just in a
different way...
Similarly, I changed AC_CHECK_LIB (crypt, crypt) to AC_SEARCH_LIBS (crypt,
crypt), since you want to know "do we have crypt with either the default
libraries or those plus crypt", not "do we have crypt in and only in the
lib called crypt". And yet again, one of the mingw platforms explicitly
set ac_cv_lib_crypt_crypt, which I don't think actually gets used by any of
the Makefile decisions. ALl you want to know is that LIBS is correct by
the time we get to building.
At least that's my novice take from a day of patching and autoconf
debugging, but I'd love to hear from someone more experienced who can tell
me why this isn't a good refactoring...
Any thoughts? I'll put together a straw-man patch tomorrow once I get it
at least building.
--
Jay Levitt |
Boston, MA | My character doesn't like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm | - Kristoffer
Hugh Sasse
> I'm fiddling around trying to get Ruby 1.8.6-p110 to build on a Stratus VOS
> machine.
>
> (Background: Stratus servers - I can't really call them "minicomputers"
[...]
>
> I spent today getting ./configure to build; this is the first time I've
> really dug into an autoconf script, and I'd rather take time and do it
> elegantly than just make a quick hack that "seems to work".
>
[...]
> I finally figured it out. And I *think* the fix is simple - replace all the
> hardcoded "LIBS = "$LIBS -lm" lines for each architecture with a simple
> AC_SEARCH_LIBS (cos, m) check that will find it, whether it's "intrinsic"
> to the compiler and architecture, or whether it'll need adding to the LIBS
> list.
[...]
> At least that's my novice take from a day of patching and autoconf
> debugging, but I'd love to hear from someone more experienced who can tell
> me why this isn't a good refactoring...
>
> Any thoughts? I'll put together a straw-man patch tomorrow once I get it
> at least building.
I will be happy to give such a patch a spin on sun-sparc-solaris2.9
and report what happens.
Hugh