Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm trying to compile Ruby and really understanding what's going on while doing so. I've used and written Makefiles before, but not autoconf's configure.in files, so maybe the result I'm getting is by design:

$ git clone https://github.com/ruby/ruby.git
...
$ cd ruby
$ git clean -fdx
$ autoconf 
$ ./configure
...
checking for dot... no
checking for doxygen... no
checking for pkg-config... no
...
checking direct.h usability... no
checking direct.h presence... no
checking for direct.h... no
...
checking for daemon... (cached) no

However, all of these are at least installed:

$ dot -V
dot - graphviz version 2.26.3 (20100126.1600)
$ doxygen --version
1.7.4
$ pkg-config --version
0.26
$ sudo updatedb
$ locate /direct.h
/usr/src/linux-headers-3.0.0-16-generic/include/config/pci/direct.h
/usr/src/linux-headers-3.0.0-17-generic/include/config/pci/direct.h
$ daemon --version
daemon-0.6.4

I realize there might be different causes for each of these, but why aren't they detected by the configure script?

I'm running Ubuntu 11.10 with the latest patches.

$ uname -a
Linux username 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Tried on another host. From config.log:

configure:6408: checking for dot
configure:6424: found /usr/bin/dot
configure:6438: result: no
configure:6445: checking for doxygen
configure:6461: found /usr/bin/doxygen
configure:6475: result: no
configure:6483: checking for pkg-config
configure:6504: found /usr/bin/pkg-config
configure:6530: result: no

What? They were found, but still no go?

configure:11880: checking direct.h usability
configure:11880: gcc -c  -O3 -ggdb    conftest.c >&5
conftest.c:135:20: fatal error: direct.h: No such file or directory
compilation terminated.
configure:11880: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
...
| #endif
| #include <direct.h>
configure:11880: result: no
configure:11880: checking direct.h presence
configure:11880: gcc -E  conftest.c
conftest.c:102:20: fatal error: direct.h: No such file or directory
compilation terminated.
configure:11880: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| /* end confdefs.h.  */
| #include <direct.h>
configure:11880: result: no
configure:11880: checking for direct.h
configure:11880: result: no

Funky test script - Maybe it needs to be in a default path of some sort?

configure:15175: checking for daemon
configure:15175: result: no

Turns out this is not checking for an executable, but for a C function using AC_CHECK_FUNCS.

share|improve this question
1  
Look at the config.log file, might give some clues. (And remove config.cache if there was a stale one.) –  Mat Apr 17 '12 at 17:20

1 Answer 1

up vote 1 down vote accepted

I know almost nothing about Ruby. I do, however know a fair amount about build systems. I'm gonna go way out on a limb here and suggest you've found a bona-fide bug in the Ruby build system.

Here's my reasoning:

  1. I get the same result you do, on completely different systems (even Cygwin/Windows 7), both with the git repo you specify and the stock Ruby 1.9 sources

  2. The reason you see found: /usr/bin/dot in your configure.log is because it genuinely found it on the path. This is easy to see in the generated configure script, especially if you modify its first line to #!/bin/sh -x to get shell debug output:

    + test -z /bin
    + for ac_exec_ext in ''\'''\''' '$ac_executable_extensions'
    + test -f /bin/dot
    + test -x /bin/dot
    + ac_cv_prog_DOT=
    + printf '%s\n' 'configure:6424: found /bin/dot'
    + break 2
    + IFS='     
    
  3. The reason you see result: no is because, as you can see the snippet above, ac_cv_prog_DOT was set to empty string, and the following lines in configure simply reflect that missing value:

    + DOT=
    + test -n ''
    + printf '%s\n' 'configure:6438: result: no'
    + printf '%s\n' no
    no
    
  4. The reason that was set to empty string is (and this is the crux of the matter) that configure.in specified empty string on line 371:

    AC_CHECK_PROG(DOT, dot)
    AC_CHECK_PROG(DOXYGEN, doxygen)
    

    I belive that's a buggy invocation of the AC_CHECK_PROG macro, which the GNU Autoconf docs specify takes three required arguments, not two:

    ― Macro: AC_CHECK_PROG (variable, prog-to-check-for, value-if-found, [value-if-not-found], [path = ‘$PATH’], [reject])
    
    Check whether program prog-to-check-for exists in path. If it
    is found, set variable to value-if-found, otherwise to
    value-if-not-found, if given. Always pass over reject (an
    absolute file name) even if it is the first found in the search
    path; in that case, set variable using the absolute file name
    of the prog-to-check-for found that is not reject. If variable
    was already set, do nothing. Calls AC_SUBST for variable. The
    result of this test can be overridden by setting the variable
    variable or the cache variable ac_cv_prog_variable.
    

    There's no default value. Leaving it off effectively means "if you find dot, set DOT to empty string"

  5. I believe the reason this mistake was made was because the original definition for that line used a different macro, AC_CHECK_TOOL, that only takes two arguments.

    From checkin to svn.ruby-lang.org on Nov 11, 2010

    AC_CHECK_TOOL becomes AC_CHECK_PROG on

  6. It's possible this may have been busted for a while, and some ChangeLog comments seem to indicate that they've been having trouble with DOXYGEN, for example:

    Fri Mar 26 19:55:41 2010  Akinori MUSHA  <knu@iDaemons.org>
    
        * Makefile.in (DOXYGEN): Define a missing variable DOXYGEN.  Build
          has been failing when doxygen(1) is found by configure but the
          variable is not defined by the system and make(1) does not allow
          an empty command. ("@$(DOXYGEN)" was the cause)
    

Finally, it's possible I have this all wrong. But I'm pretty sure that configure is finding those tools, and it has been instructed to set the corresponding Makefile variables to empty string.

Curious to hear what others think of this analysis.

share|improve this answer
    
Excellent analysis. Reported a bug for this. –  l0b0 Apr 18 '12 at 9:18
    
It was a bug - Fixed in the repository. 1000 thanks, as we say at home. –  l0b0 Apr 19 '12 at 13:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.