[Doxygen-develop] Build failure because src/Makefile is not properly parsed (some of the time)

[Hanspeter N. <fi...@sn...>]

The Fink project (an OS X package manager) has had a recent rash of 
build failures with doxygen 1.8.3.1 that I've been able to track down to 
src/Makefile not being properly read.  However, we have no idea what the 
actual event that leads to failure is.  The maddening aspect is that the 
build succeeds a little less than half the time, and it is unclear what 
causes one build to properly parse src/Makefile in while another doesn't 
(no change in the build system in between runs).

This is the fatal error, but the cause is earlier in the build (which 
I'll describe further below).

******
c++ -Wl,-search_paths_first -o ../bin/doxygen ../objects/main.o 
-L../lib -L/sw/lib -ldoxygen -ldoxycfg -lqtools ../lib/libmd5.a 
-lpthread -liconv -framework CoreServices
Undefined symbols:
   "_iconv_close", referenced from:
       _portable_iconv_close in libdoxycfg.a(portable_c.o)
      (maybe you meant: _portable_iconv_close)
   "_iconv", referenced from:
       _portable_iconv in libdoxycfg.a(portable_c.o)
      (maybe you meant: _portable_iconv, _portable_iconv_close , 
_portable_iconv_open )
   "_iconv_open", referenced from:
       _portable_iconv_open in libdoxycfg.a(portable_c.o)
      (maybe you meant: _portable_iconv_open)
*****

OS X comes with BSD iconv, which provides the _iconv_* symbols. 
However, the common OS X package managers (Fink, Macports, Homebrew) all 
prefer gnu libiconv (which uses _libiconv_* symbols).  In this case, 
doxygen is trying to link to our gnu libiconv (Fink's prefix is /sw), 
but portable_c.o was accidentally compiled with the system BSD iconv.h.

The compiler line for the miscompiled portable_c.o is this (/usr/local 
doesn't exist, btw):

cc -c -pipe -Wall -W -Wno-deprecated-declarations  -g -fstack-protector 
-I../qtools -I/usr/local/include -o ../objects/portable_c.o portable_c.c

When the build succeeds, the compiler command is:

cc -c -pipe -MD -Wall -W -Wno-deprecated-declarations -O2 -I../qtools 
-I/sw/include -o ../objects/portable_c.o portable_c.c

After trying to understand the doxygen build system, I can say this:

1) the bad compiler commands come from src/Makefile.libdoxycfg.  In the 
failed builds, src/Makefile.libdoxycfg is not regenerated by tmake and 
therefore uses the file that came with the tarball

2) src/Makefile.libdoxycfg is not regenerated because the 
"Makefile.libdoxycfg" target in src/Makefile is skipped

For reasons that we have not been able to figure out, this target is not 
run about 50% of the time.  This is the log output from a successful run:

******
env 
TMAKEPATH=/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/lib/macosx-c++ 
/usr/bin/perl 
/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/bin/tmake 
libdoxygen.pro >Makefile.libdoxygen
env 
TMAKEPATH=/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/lib/macosx-c++ 
/usr/bin/perl 
/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/bin/tmake 
libdoxycfg.pro >Makefile.libdoxycfg
env 
TMAKEPATH=/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/lib/macosx-c++ 
/usr/bin/perl 
/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/bin/tmake 
doxygen.pro >Makefile.doxygen
******

In failed runs, the 2nd line from this output is missing and 
Makefile.libdoxycfg is never regenerated.  So something is 
non-deterministically causing that target to be skipped.  The build is 
run in a clean environment every time and we are using -j1 to avoid 
possible race conditions.

Do you have any ideas as to what might be causing the failure to 
regenerate Makefile.libdoxycfg?  We have a temporary fix, but it would 
be nice to understand the underlying cause for this bug.  Thanks,

Hanspeter

ps.  Makefile.libmd5 also suffers from this indeterminate regeneration 
but it doesn't mix headers so there's no direct failure.