Doxygen and multilib

[Christopher Stone]

On 11/4/07, Christopher Stone <chris.stone at gmail.com> wrote:
> On 10/31/07, Eric Sandeen <sandeen at redhat.com> 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.