GNOME Bugzilla – Bug 320786
util.cpp can't find fork() or execve()
Last modified: 2005-11-27 23:59:38 UTC
Distribution/Version: 2.6.12 This bug was found produceable on a Fedora Core 3, with gcc-4.0.1. This is a bug in the GNU C++ Compiler, exposed with the changes I had to make with bug 317773. When util.cpp in the src directory is compiled, I get: g++ -c -pipe -Wall -W -fno-exceptions -g -I../../src/../qtools -I../../src/../libpng -I../../src/../libmd5 -I../../src -o ../objects/util.o ../../src/util.cpp ../../src/translator.h:27: warning: ‘class Translator’ has virtual functions but non-virtual destructor ../../src/util.cpp: In function ‘int iSystem(const char*, const char*, bool)’: ../../src/util.cpp:188: error: ‘fork’ was not declared in this scope ../../src/util.cpp:197: error: ‘execve’ was not declared in this scope gmake[2]: *** [../objects/util.o] Error 1 A quick workaround that is standard among most systems is to add the following right after the "#include <unistd.h>" line. _UNISTD_H is the standard definition used in many C libraries to indicate that unistd.h is already included. #include <unistd.h> #ifndef _UNISTD_H #include "/usr/include/unistd.h" #endif /* not _UNISTD_H */
Created attachment 54378 [details] [review] Patch for the Compiler Bug Workaround This patch, applyable to doxygen-1.4.5-20051024, will add the workaround to the gcc bug.
I don't think this is a compiler bug. I've included a unistd.h file in doxygen src dir, which is normally included on windows only (and contains some stuff required for windows). If you put an explicit -I for the src dir (as you probably need to do now), my unistd.h will be found instead of the standard one. The main reason for not including some other file for windows is that the files generated by flex contain a #include <unistd.h>, so the file needs to exist :-( Maybe a good solution is to move the unistd.h file from src to wintools and add an explicit -I to that dir for the windows makefiles. I think that #including an absolute path is not the way to go.
Well then, let's make the change before me make another CVS release. Also, gcc-4.x is treating #include <> and #include "" identically. I am not sure if it is caused by a standard change. So, unistd.h is just going to have to be moved elsewhere.
This bug still appears in 1.4.5-20051109, and requires that on non-Windows platforms, the src/unistd.h file be deleted or moved. I am changing the priority of this bug to high, and severity to critical.
For some odd reason, doxygen compiled correctly without doing anything to the unistd.h file (maybe because of the 20051127 update), so I am closing this bug as resolved - fixed.