Summary: | ERROR: app-doc/doxygen-1.4.2 failed Function src_compile, Line 40, Exitcode 2 "make all" failed | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Roberto Griso <griso.roberto> |
Component: | Mac OSX | Assignee: | Gentoo for Mac OS X <ppc-macos> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dirk.schoenberger |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | PPC | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 63440 | ||
Bug Blocks: |
Description
Roberto Griso
2005-04-03 04:06:29 UTC
I am checking this on my own machine right now, but my suspicion is that it fails because of USE="qt". We have not hard masked USE="qt" because it supposedly works (another dev was working on it and keyworded it). However, the rest of us have been unable to emerge qt (meaning we cannot test qt functionality in packages that optionally use it). I'd like to know when/how you got qt emerged, or if you installed it yourself. I'll let you know definitely what the problem is in a few hours (still compiling). Yup. Works fine with USE="-qt". Please let me know how you got qt installed so I can install it myself and work on fixing that problem. *** Bug 89405 has been marked as a duplicate of this bug. *** *** Bug 94537 has been marked as a duplicate of this bug. *** so this is actually a bug around qt. Version 1.4.3-r1 works for me. Please try that and reopen if it is still a problem. * Applying doxygen-1.4.3-nls.patch ... [ ok ]
QA Notice: USE Flag 'userland_Darwin' not in IUSE for app-doc/doxygen-1.4.3-r1
* Applying bsd-configure.patch ... [ ok ]
>>> Source unpacked.
Autodetected platform macosx-c++...
QTDIR environment variable not set!
Checking for Qt...QTDIR not set and Qt not found at standard locations!
tmake requires the QTDIR environment variable to be set.
check the Qt installation instructions!
!!! ERROR: app-doc/doxygen-1.4.3-r1 failed.
!!! Function src_compile, Line 45, Exitcode 2
!!! "./configure" failed.
!!! If you need support, post the topmost build error, NOT this status message.
Something tells me that this env should be there as it is in /etc/env.d/*qt*
This is my build process: It definitely makes it past where yours died. Autodetected platform macosx-c++... Detected Qt via the QTDIR environment variable... headers /usr/qt/3/include, libraries /usr/qt/3/lib Checking for GNU make tool... using /usr/bin/make Checking for GNU install tool... using /usr/bin/install Checking for dot (part of GraphViz)... using /usr/bin/dot Checking for perl... using /usr/bin/perl Created Makefile from Makefile.in... Hasan (gongloo) gets the same as me. Does emerging baselayout and the recent QT patch fix the issue with doxygen for you? Please let me know as I would love to close this bug once again. :-) We need to have a discussion on that first. In the meanwhile all of my actions are frozen. Does the QT use flag affect the doxywizard GUI? I've emerged doxygen-1.4.2, ..., doxygen-1.4.4 (x86, not Mac), but the QT-flag doesn't seem to have any effect. The precompiled binary from the doxygen homepage (http://www.stack.nl/~dimitri/doxygen/) on the other hand takes advantage of QT. emerge -av qt doxygen These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] x11-libs/qt-3.3.4-r7 +cups -debug -doc -examples -firebird +gif -immqt -immqt-bc -ipv6 -mysql -nas -odbc +opengl -postgres -sqlite -xinerama +zlib 0 kB [ebuild R ] app-doc/doxygen-1.4.4 -doc* +qt +tetex 0 kB while emerging doxygen 1.4.4 on MacOS Tiger, I have the following problem: c++ -c -pipe -D__FreeBSD__=5=6 -Wall -W -O2 -DNO_DEBUG -I../../src -I/usr/qt/3/include -o obj/ doxywizard.o doxywizard.cpp c++ -c -pipe -D__FreeBSD__=5=6 -Wall -W -O2 -DNO_DEBUG -I../../src -I/usr/qt/3/include -o obj/ version.o version.cpp c++ -c -pipe -D__FreeBSD__=5=6 -Wall -W -O2 -DNO_DEBUG -I../../src -I/usr/qt/3/include -o obj/ inputstring.o inputstring.cpp In file included from /usr/include/gcc/darwin/4.0/c++/cstddef:48, from /usr/include/gcc/darwin/4.0/c++/cstring:49, from /usr/include/gcc/darwin/4.0/c++/bits/char_traits.h:45, from /usr/include/gcc/darwin/4.0/c++/string:46, from /usr/qt/3/include/qstring.h:56, from /usr/qt/3/include/qwindowdefs.h:44, from /usr/qt/3/include/qwidget.h:42, from /usr/qt/3/include/qframe.h:42, from /usr/qt/3/include/qlabel.h:42, from doxywizard.cpp:1: /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/include/stddef.h:57:86: error: token "=" is not valid in preprocessor expressions /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/include/stddef.h:61:31: error: token "=" is not valid in preprocessor expressions /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/include/stddef.h:311:31: error: token "=" is not valid in preprocessor expressions In file included from /usr/include/gcc/darwin/4.0/c++/cstddef:48, from /usr/include/gcc/darwin/4.0/c++/cstring:49, from /usr/include/gcc/darwin/4.0/c++/bits/char_traits.h:45, from /usr/include/gcc/darwin/4.0/c++/string:46, from /usr/qt/3/include/qstring.h:56, from /usr/qt/3/include/qwindowdefs.h:44, from /usr/qt/3/include/qwidget.h:42, from inputstring.h:18, from inputstring.cpp:15: /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/include/stddef.h:57:86: error: token "=" is not valid in preprocessor expressions /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/include/stddef.h:61:31: error: token "=" is not valid in preprocessor expressions /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/include/stddef.h:311:31: error: token "=" is not valid in preprocessor expressions input.h:7: warning: 'class IInput' has virtual functions but non-virtual destructor /usr/qt/3/include/qnetworkprotocol.h:58: warning: 'class QNetworkProtocolFactoryBase' has virtual functions but non-virtual destructor /usr/qt/3/include/qfiledialog.h:78: warning: 'class QFilePreview' has virtual functions but non-virtual destructor /usr/qt/3/include/qnetworkprotocol.h:58: warning: 'class QNetworkProtocolFactoryBase' has virtual functions but non-virtual destructor /usr/qt/3/include/qfiledialog.h:78: warning: 'class QFilePreview' has virtual functions but non-virtual destructor /usr/qt/3/include/qtooltip.h:86: warning: 'class QToolTip' has virtual functions but non-virtual destructor /usr/qt/3/include/qtooltip.h:86: warning: 'class QToolTip' has virtual functions but non-virtual destructor make[2]: *** [obj/inputstring.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [obj/doxywizard.o] Error 1 make[1]: *** [all] Error 2 make: *** [all] Error 2 Seems the problem is the part -D__FreeBSD__=5=6, where my gcc expects something like -D__FreeBSD__ can you find out if doxygen perhaps has some OSX/Darwin support looking through the configure/README/INSTALL and that kind of files? > can you find out if doxygen perhaps has some OSX/Darwin support looking through
> the configure/README/INSTALL and that kind of files?
According to the ebuild there is MacOSX support. However the following line in doxygen-1.4.4.ebuild
looks problematic
if use ppc-macos; then
epatch ${FILESDIR}/bsd-configure.patch
[[ "$MACOSX_DEPLOYMENT_TARGET" == "10.4" ]] && sed -i -e 's:-D__FreeBSD__:-
D__FreeBSD__=5:' \
tmake/lib/macosx-c++/tmake.conf
fi
[[ "$MACOSX_DEPLOYMENT_TARGET" == "10.4" ]] && sed -i -e 's:-D__FreeBSD__:- D__FreeBSD__=5:' \ tmake/lib/macosx-c++/tmake.conf without this, the package emerges and runs fine on, Tiger, at least with USE="qt doc". Currently I don't have tetex installed. hey, that's interesting Dirk! Less is More(tm) in this case ;) I am compiling now without the whole ppc-macos if (so I removed the patch as well) and so far it appears to be happy bleh... linker errors (but I doubt they will be prevented by the patch) /usr/bin/make -f Makefile.doxygen PERL=/usr/bin/perl all c++ -c -pipe -D__FreeBSD__=6 -Wall -W -O2 -I../qtools -I../libpng -I../libmd5 -I. -o ../objects/main.o main.cpp c++ -o ../bin/doxygen ../objects/main.o -L../lib -ldoxygen -ldoxycfg -lqtools -lpng -lmd5 /usr/bin/ld: Undefined symbols: _MD5Buffer _MD5SigToString collect2: ld returned 1 exit status make[2]: *** [../bin/doxygen] Error 1 make[1]: *** [all] Error 2 make: *** [all] Error 2 The fix should be simple. This is apparently a problem introduced in the later version of doxygen. Please change the line in question to: if use ppc-macos; then epatch ${FILESDIR}/bsd-configure.patch [[ "$MACOSX_DEPLOYMENT_TARGET" == "10.4" ]] && sed -i -e 's:-D__FreeBSD__=6:- D__FreeBSD__=5:' \ tmake/lib/macosx-c++/tmake.conf fi The older version simply had -D__FreeBSD__. The weird linker errors were taken care of by the specification of FreeBSD 5. Let me know what you get. the changed define didn't help for me, it still doesn't link properly :( /usr/bin/ld: Undefined symbols: _MD5Buffer _MD5SigToString Dirk, you managed to compile successly, didn't you? > /usr/bin/ld: Undefined symbols: > _MD5Buffer > _MD5SigToString > Dirk, you managed to compile successly, didn't you? Same problem on Tiger, after my last emmerge --sync > /usr/bin/ld: Undefined symbols: > _MD5Buffer > _MD5SigToString > Dirk, you managed to compile successly, didn't you? Seems like MacOSX gcc doesn't like to link against static libs (.a files). If you replace -lmd5 by ../lib/libmd5.a in src/Makefile.doxygen, it seems to link correctly. Pretty sure this is a result of it finding the dylib first. Adding -search_paths_first to the linker flags, or as Dirk suggested specifying the static archive should fix it, the latter probably easier to get accepted upstream. From the ld(1) manpage: -search_paths_first By default when the -dynamic flag is in effect, the -lx and -weak-lx options first search for a file of the form `libx.dylib' in each directory in the library search path, then a file of the form `libx.a' is searched for in the library search paths. This option changes it so that in each path `libx.dylib' is searched for then `libx.a' before the next path in the library search path is searched. Thanks kito for that helpful comment. Doxygen uses profiles for systems, so it was actually quite simple to add -search_paths_first to the linker options of the final linker stage and so to allow compilation to succeed. I'd like kito to have a look at my patch, then I'll submit it upstream. Closing the bug for now, based on Dirk's experiences with qt, and mine on tetex. update, I compiled with USE flags qt and tetex, and that worked too. |