doxygen-1.5.4 issues
 

Now I'm having issues with doxygen.

It doesn't compile anymore due to doxygen-1.5.3-darwin9 patch, which
is dealing with constness of an argument passed to iconv. Because on
my darwin8 __APPLE__ is defined, the result of the patched code is to
cast const char ** to char **. This seems unnecessary because both
system libiconv and portage libiconv accept const char ** as second
argument to iconv(). The patch has darwin9 in its name, with which I
have no experience, so I can't say what good the patch does there.
Where have I gone blind?


Also I notice that the cast causes problems on Solaris as well.
Wouldn't it be a cleaner solution to have the configure script check
whether iconv() accepts a const second argument, and then cast based
on the result of the probe? A quick patch doing just that is attached.


// Cheers; Johan

doxygen-1.5.4 issues
 

On 30-11-2007 10:55:57 +0100, Johan Hattne wrote:
> Now I'm having issues with doxygen.

I don't understand why the darwin9 patch is necessary at all. As I
don't have such machine myself (at the moment) I can't test. However,
it looks very wrong, so I will disable the patch for now.

libiconv is libiconv, so it shouldn't differ in signature, right?


> It doesn't compile anymore due to doxygen-1.5.3-darwin9 patch, which is
> dealing with constness of an argument passed to iconv. Because on my
> darwin8 __APPLE__ is defined, the result of the patched code is to cast
> const char ** to char **. This seems unnecessary because both system
> libiconv and portage libiconv accept const char ** as second argument to
> iconv(). The patch has darwin9 in its name, with which I have no
> experience, so I can't say what good the patch does there. Where have I
> gone blind?
>
> Also I notice that the cast causes problems on Solaris as well. Wouldn't
> it be a cleaner solution to have the configure script check whether iconv()
> accepts a const second argument, and then cast based on the result of the
> probe? A quick patch doing just that is attached.
>
> // Cheers; Johan



--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

doxygen-1.5.4 issues
 

On Dec 1, 2007, at 14:25 , Fabian Groffen wrote:


On 30-11-2007 10:55:57 +0100, Johan Hattne wrote:

Now I'm having issues with doxygen.


I don't understand why the darwin9 patch is necessary at all. As I
don't have such machine myself (at the moment) I can't test. However,
it looks very wrong, so I will disable the patch for now.

libiconv is libiconv, so it shouldn't differ in signature, right?


I thought so, too! But it makes me wonder where the patch originally
came from. On darwin8 iconv() takes a const argument, and I find it
difficult to believe that darwin9 downgraded libiconv or otherwise
changed this behaviour.


In any case, I think doxygen should depend on libiconv in order to
avoid future breakage due to accidental inclusion of any strange
libiconv the system may have lying around.


And forget about the patch I sent last time. While I think that this
is the sort of thing a configure script should probe for, it won't
work because the compiler, preprocessor flags, etc, etc, aren't known
by Doxygen's homebrew configuration tool. I can't see how a
configure script like that is going to test whether calling iconv()
needs a cast or not. It seems just as dangerous as trying to derive
the implementation of libiconv by looking at the name of the
operating system.


// Cheers; Johan

--
gentoo-alt@gentoo.org mailing list

doxygen-1.5.4 issues
 

On 03-12-2007 10:54:56 +0100, Johan Hattne wrote:
> On Dec 1, 2007, at 14:25 , Fabian Groffen wrote:
>
>> On 30-11-2007 10:55:57 +0100, Johan Hattne wrote:
>>> Now I'm having issues with doxygen.
>>
>> I don't understand why the darwin9 patch is necessary at all. As I
>> don't have such machine myself (at the moment) I can't test. However,
>> it looks very wrong, so I will disable the patch for now.
>>
>> libiconv is libiconv, so it shouldn't differ in signature, right?
>
> I thought so, too! But it makes me wonder where the patch originally came
> from. On darwin8 iconv() takes a const argument, and I find it difficult
> to believe that darwin9 downgraded libiconv or otherwise changed this
> behaviour.

The real issue seems to be that the iconv.h from /usr/include is taken
not the one from the prefix. On Darwin9 this file has changed indeed.
The Solaris patch we apply is wrong too, as it basically patches it to
work with /usr/include/iconv.h.

I've yet to find out why c++ finds iconv.h from the host OS first...


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

doxygen-1.5.4 issues
 

On 06-12-2007 21:43:53 +0100, Fabian Groffen wrote:
> The real issue seems to be that the iconv.h from /usr/include is taken
> not the one from the prefix. On Darwin9 this file has changed indeed.
> The Solaris patch we apply is wrong too, as it basically patches it to
> work with /usr/include/iconv.h.
>
> I've yet to find out why c++ finds iconv.h from the host OS first...

And to complete the confusion... c++ -E shows that it DOES include
prefix' iconv.h and that the expanded function doesn't have any const in
there, neither does the declared function it has pulled in...

I'm completely puzzled now...


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

doxygen-1.5.4 issues
 

On 06-12-2007 21:48:42 +0100, Fabian Groffen wrote:
> On 06-12-2007 21:43:53 +0100, Fabian Groffen wrote:
> > The real issue seems to be that the iconv.h from /usr/include is taken
> > not the one from the prefix. On Darwin9 this file has changed indeed.
> > The Solaris patch we apply is wrong too, as it basically patches it to
> > work with /usr/include/iconv.h.
> >
> > I've yet to find out why c++ finds iconv.h from the host OS first...
>
> And to complete the confusion... c++ -E shows that it DOES include
> prefix' iconv.h and that the expanded function doesn't have any const in
> there, neither does the declared function it has pulled in...
>
> I'm completely puzzled now...

Some tool at Apple decided to change libiconv's invocation...
http://www.opensource.apple.com/darwinsource/10.5/libiconv-24/patches/unix03.patch
http://www.opensource.apple.com/darwinsource/10.5/libiconv-24/patches/manpage.patch

and then some tool from doxygen thought this was the "default"
behaviour, whereas "upstream" libiconv is just plain sec how it should
be...


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

doxygen-1.5.4 issues
 

On 06-12-2007 21:58:08 +0100, Fabian Groffen wrote:
> On 06-12-2007 21:48:42 +0100, Fabian Groffen wrote:
> > On 06-12-2007 21:43:53 +0100, Fabian Groffen wrote:
> > > The real issue seems to be that the iconv.h from /usr/include is taken
> > > not the one from the prefix. On Darwin9 this file has changed indeed.
> > > The Solaris patch we apply is wrong too, as it basically patches it to
> > > work with /usr/include/iconv.h.
> > >
> > > I've yet to find out why c++ finds iconv.h from the host OS first...
> >
> > And to complete the confusion... c++ -E shows that it DOES include
> > prefix' iconv.h and that the expanded function doesn't have any const in
> > there, neither does the declared function it has pulled in...
> >
> > I'm completely puzzled now...
>
> Some tool at Apple decided to change libiconv's invocation...
> http://www.opensource.apple.com/darwinsource/10.5/libiconv-24/patches/unix03.patch
> http://www.opensource.apple.com/darwinsource/10.5/libiconv-24/patches/manpage.patch
>
> and then some tool from doxygen thought this was the "default"
> behaviour, whereas "upstream" libiconv is just plain sec how it should
> be...

Ok... even worse. Looks like libiconv changes its headerfile itself
based on the host OS...


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

doxygen-1.5.4 issues
 

Long story short:

I fixed the problem. Thanks.


On 30-11-2007 10:55:57 +0100, Johan Hattne wrote:
> Now I'm having issues with doxygen.
>
> It doesn't compile anymore due to doxygen-1.5.3-darwin9 patch, which is
> dealing with constness of an argument passed to iconv. Because on my
> darwin8 __APPLE__ is defined, the result of the patched code is to cast
> const char ** to char **. This seems unnecessary because both system
> libiconv and portage libiconv accept const char ** as second argument to
> iconv(). The patch has darwin9 in its name, with which I have no
> experience, so I can't say what good the patch does there. Where have I
> gone blind?
>
> Also I notice that the cast causes problems on Solaris as well. Wouldn't
> it be a cleaner solution to have the configure script check whether iconv()
> accepts a const second argument, and then cast based on the result of the
> probe? A quick patch doing just that is attached.



--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

doxygen-1.5.4 issues
 

On 06-12-2007 22:31:02 +0100, Fabian Groffen wrote:
> Long story short:

A longer version:

libiconv now has been "fixed" to always have the same declaration in
Prefix, regardless the host OS declaration. I don't know why one would
like to have that, most programs with decent autoconf have checks for
that anyway. Anyhow, you should update libiconv first, then compilation
of doxygen should succeed. I tested this on Solaris 10, OS X 10.4 and
OS X 10.5.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

doxygen-1.5.4 issues
 

On Dec 7, 2007, at 10:10 , Fabian Groffen wrote:


On 06-12-2007 22:31:02 +0100, Fabian Groffen wrote:

Long story short:


A longer version:

libiconv now has been "fixed" to always have the same declaration in
Prefix, regardless the host OS declaration. I don't know why one
would

like to have that, most programs with decent autoconf have checks for
that anyway. Anyhow, you should update libiconv first, then
compilation

of doxygen should succeed. I tested this on Solaris 10, OS X 10.4 and
OS X 10.5.


Seing that these are all pretty live events, I may be slightly out of
sync here. But I just upgraded libiconv and experienced massive
breakage due to symlinks missing in usr/lib.


// Johan

--
gentoo-alt@gentoo.org mailing list