Description of problem: anchor done by doxygen are the same when run more than once on my i386, but different from the ones in x86_64. I don't have a multiarch, so it isn't that easy for me to test. For an example, you can have a look at http://koji.fedoraproject.org/scratch/pertusus/task_206255/ mkdir doxy_bug cd doxy_bug archs="i386 x86_64" mkdir $archs scratch_dir=scratch/pertusus/task_206255/ package=boolstuff-devel-0.1.11-2.fc9 for arch in $archs; do wget http://koji.fedoraproject.org/$scratch_dir/${package}.$arch.rpm (cd $arch && rpm2cpio ../${package}.$arch.rpm | cpio -id) done diff -u i386/usr/share/doc/boolstuff-devel-0.1.11/api-html/ x86_64/usr/share/doc/boolstuff-devel-0.1.11/api-html/ Version-Release number of selected component (if applicable): doxygen-1.5.2-1.fc7 How reproducible: Not easily by me ;-) Steps to Reproduce: 1. use doxygen on x86_64 and on i386 and look at the different anchors. 2. 3. Actual results: Expected results: Reproducible anchor names. Additional info: This is important for fedora as a whole since this is a major cause for conflict in multiarch doc that should be arch independent.
*** Bug 360131 has been marked as a duplicate of this bug. ***
I looked into the source code a little bit, and it appears that doxygen uses its own md5 hash generator in the libmd5/ directory. My guess is that this code does not produce the same results between 32bit and 64bit systems. I would have to do some testing with the doxygen md5 library to find out if this is the case. Perhaps doxygen should be enhanced to use mhash library instead? See the MemberDef::setAnchor() function in src/memberdef.cpp, I think this is where the anchors are being generated.
I think the bug lies in the libmd5/md5_loc.h file. This does does not look correct for 64bit systems. Should be easy to make a patch and test it. Anyone up for it? I've spent too much time on this already...
I was under the assumption that an int was 64bits on an x86_64 arch for comment #3, but it is actually 32bits, so this file is actually correct.
You know what, I cannot reproduce this bug with doxygen-1.5.3, maybe you just need to push the new release.... It appears your spec is updated for 1.5.3 but rawhide still uses 1.5.2. When I build my packages using doxygen 1.5.3 the documentations are identical. Please push 1.5.3.
Than, ping? If all that's needed to fix several multiarch conflicts in doxygen using packages is an update to 1.5.3, is there any good reason not to push that update? If not, I'll build an update for rawhide tomorrow so the folks with affected packages can test and confirm that 1.5.3 fixes this. (I've already tagged doxygen-1_5_3-1_fc9.) For the impatient, scratch builds are available to test: http://koji.fedoraproject.org/koji/taskinfo?taskID=257735
doxygen-1.5.3-1.fc9 has been built. It should show up in rawhide sometime soon. After it does, can you folks with affected packages give it a test and confirm whether it fixes the anchor problem or not?
Patrice, I did a scratch build of boolstuff-0.1.11-2.fc9 with doxygen-1.5.3, and the conflicts appear to be resolved. The scratch builds are at http://koji.fedoraproject.org/koji/taskinfo?taskID=261661 (http://koji.fedoraproject.org/scratch/tmz/task_261661/) I used Jeremy's multilib-cmp.py[1] script to check for the conflicts (as I don't have an x86_64 box either). If you can confirm that this resolves the problem, we can let other maintainers know that a rebuild with the updated doxygen will allow them to close any multilib conflict bugs cause by the differing anchors. [1] http://katzj.fedorapeople.org/multilib-cmp.py
it seems the bug is fixed in rawhide. I now close the bug
Looking at your scratch build, everything looks good.