Doxygen and multilib

[Christopher Stone]

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

gah, actually it appears ints are 32bits on 64bit systems, so this
file is probably correct.

Unrelated, but this looks wrong in the pilot-link-devel package:
pi-md5.h:#define UINT32 unsigned long