On 11/4/07, Christopher Stone <chris.stone@xxxxxxxxx> wrote: > On 10/31/07, Eric Sandeen <sandeen@xxxxxxxxxx> wrote: > > Linus Walleij wrote: > > > OK so I have that problem where Doxygen generates links as hashes > > > including something like a time stamp, so the -devel packages end up > > > causing multilib conflicts. > > > > > > Is there some silver bullet to actually SOLVE this? > > > > > > I saw that Hans solved this by tar.gz:ing up the docs and add as separate > > > source and then suppress compile-time building of the docs, replacing with > > > pre-generated contents. > > > > > > Myself I simply deleted the docs for now. > > > > > > I sort of believe Doxygen should be fixed to do something more > > > predictable, atleast on request. > > > > I'd like to see that too - I took a quick look at how it generates the > > hashes, and couldn't find it. :) But if it could be seeded with some > > predictable thing based on what it's parsing, maybe it could be made > > consistent? > > doxygen is using its own home brewed md5 hash generator in the libmd5/ > directory. This code gets called from the MemberDef::setAnchor() > function in src/memberdef.cpp > > My guess is that doxygen's libmd5 code does not work correctly on > 64bit systems. Perhaps doxygen should be enhanced to use the > coreutils md5 algorithm or mhash or something. > Okay, I think I found the bug. md5lib/md5_loc.h does not appear to look correct when compiled on a system with 64bit integers. This might be a quick fix, but I think ideally doxygen should use some system wide library for computing md5 hashes. It also appears doxygen uses its own version of libpng. I think also the doxygen spec file should BR graphviz. The configure script checks for the location of dot. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
