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