Emerging kde-base/kdelibs-3.5.10-r2 with USE=doc results in doxygen hanging. The process in question is "doxygen kdeprint/Doxyfile" running in directory /var/tmp/portage/kde-base/kdelibs-3.5.10-r2/work/kdelibs-3.5.10/apidocs stracing it lists large numbers of mmap and munmap (probably malloc treated by the sanbox allocator), but also a few stat, lstat and readlink, all of those for "/var/.../work/kdelibs-3.5.10/kdeprint/kdeprint" which is a symlink to "./management". gdb indicates an endless loop somewhere around the resolveSymlink function in doxygen.cpp. I canceled the build for kdelibs and emerged an unoptimized version of doxygen in order to get useful debugging information. Unfortunately, it seems like the Doxyfile was removed by some cleanup from the kdelibs build, so I had to start that whole build again, and I'd like to submit this form here before I start the next round of debugging. This reminds me of bug #156115. Don't know if it really is related.
It's building up an ever growing path of the form /var/tmp/portage/kde-base/kdelibs-3.5.10-r2/work/kdelibs-3.5.10/kdeprint/kdeprint/management/management/... The cause is this line: target = QDir::cleanDirPath(prefix+"/"+target.data()); where prefix is the full path to the symlink, not its parent diretory. Upstream addressed this - among others - in their revision 678: http://doxygen.svn.sourceforge.net/viewvc/doxygen/trunk/src/doxygen.cpp?view=patch&r1=678&r2=677&pathrev=678 The first three hunks of that patch should be enough to solve this issue. The upstream commit has log message "Release-1.5.8-20090129", and there is a tag for this as well. There is also a tag for an even newer version, Release_1_5_8_20090304. So instead of applying that single fix, you might also try to grab a tarball for one of these and add it to portage. Your choice. In any case, kde-base/kdelibs-3.5.10-r2 must depend on the fixed version. The gnome bugzilla, which seems to be the official bugtracker for doxygen, also has a report for this: http://bugzilla.gnome.org/show_bug.cgi?id=571988 UNCONFIRMED at the time of this writing. I'll try to cross reference.
Created attachment 188864 [details, diff] Part of upstream r678 This solved the issue for me. It's part of the upstream patch, as described in comment #1.
doxygen-1.5.9 is out now which includes the aforementioned changes. It seems that the fix was actually addressed in response to http://bugzilla.gnome.org/show_bug.cgi?id=566925. Anyway, after bumping doxygen locally, I have confirmed that kdelibs-3.5.10 with USE="doc" builds fine with 1.5.9.
Is there a workaround that doesn't require applying the patch yourself? Kdelibs-3.5.10-r6 was marked stable for x86 today and still has this problem with doxygen-1.5.8.
this should be easy - bump doxygen to 1.5.9 and fast track to stable...
(In reply to comment #5) > this should be easy - bump doxygen to 1.5.9 and fast track to stable... > There is no 1.5.9 in my portage, not even ~amd64, 1.5.8 is the latest available.
Why do things like this keep happening? The problem is known for months, a user really worked on this and provided detailed information and a patch. Why do others, like me, have to stumble upon this again? Workaraound: echo "kde-base/kdelibs -doc" >> /etc/portage/package.use
doxygen-1.5.7.1 works too.
Doxygen-1.5.8 is now updated; thanks for the patch.
What about -r1 for the fixed version?
(In reply to comment #10) > What about -r1 for the fixed version? > I second this. If this was in an -r1 I don't think I would have have to mess with this issue.
Steve, please, always do revbump for changes that change installed package. In other case "fix" will never get our users. E.g. personally I already had doxygen-1.5.8 installed and the patch you added ... well I definitely missed it and lost night of computer work + time I spent on searching google until found this bug... ( That's said, I did revbump now strait to stable now. Any way thank you for your work.
