doxygen

[Ryan Schmidt]

On Feb 10, 2009, at 05:54, cssdev at mac.com wrote:

> On Feb 7, 2009, at 1:32 PM, Ryan Schmidt wrote:
>
>> http://trac.macports.org/ticket/18258
>>
>> (I see you're already Cc'd on that ticket)
>
> Just FYI for others on the list, this is the result of a fun change  
> Apple made in an iconv() parameter between Tiger and Leopard. I'm  
> checking upstream on a fix so that we hopefully don't need to keep  
> around a custom MacPorts-only patch. (Or we could patch libiconv  
> for the POSIX compliant parameters used on Leopard, but that might  
> cascade to a whole host of other changes.)

Yes, in reading up on this issue myself, Apple changed the iconv()  
parameter in Leopard for POSIX compliance. And it appears to be the  
intention of libiconv to mimic the system's iconv() function,  
whatever it may be. This is explained in libiconv's iconv.h:


/* We would like to #include any system header file which could define
    iconv_t, 1. in order to eliminate the risk that the user gets  
compilation
    errors because some other system header file includes /usr/ 
include/iconv.h
    which defines iconv_t or declares iconv after this file, 2. when  
compiling
    for LIBICONV_PLUG, we need the proper iconv_t type in order to  
produce
    binary compatible code.
    But gcc's #include_next is not portable. Thus, once libiconv's  
iconv.h
    has been installed in /usr/local/include, there is no way any  
more to
    include the original /usr/include/iconv.h. We simply have to get  
away
    without it.
    Ad 1. The risk that a system header file does
    #include "iconv.h"  or  #include_next "iconv.h"
    is small. They all do #include <iconv.h>.
    Ad 2. The iconv_t type is a pointer type in all cases I have  
seen. (It
    has to be a scalar type because (iconv_t)(-1) is a possible  
return value
    from iconv_open().) */


So I don't think I want to change libiconv to always be POSIX- 
compliant, even if the OS is not, because that appears to contradict  
the intentions of the developer of libiconv, whom I am in no place to  
second-guess.

doxygen's portable.cpp has this code for determining which iconv()  
function prototype to use:


// libiconv is a mess. For some platforms/version the prototype of  
inbuf is
// "const char **", for others it is "char **". C++ requires the  
proper cast to
// avoid a compile error, that is were the CASTNEEDED is for.
#if ((defined(_LIBICONV_VERSION) && (_LIBICONV_VERSION>=0x0109) && \
       !((defined(_OS_MAC_) || defined(Q_OS_MACX) )&&  
(_LIBICONV_VERSION==0x010B))) \
     || defined(_OS_SOLARIS_) \
     || defined(_OS_NETBSD_)  \
     )
#define CASTNEEDED(x) (x)
#else
#define CASTNEEDED(x) (char **)(x)
#endif


This code would appear to be incorrect, because it is based only on  
the libiconv version and the OS, with no apparent differentiation for  
the OS version (i.e. Tiger vs. Leopard in our case, who knows what  
else on other OSes). The m4 macro I referenced earlier incorporates a  
test into your autoconf-based configure script to figure out what's  
in use on your OS. Unfortunately doxygen's configure script appears  
not to be autoconf-based.


Note that our libiconv port has some issues of its own when it comes  
to 64-bit universal binaries which I've filed here:

http://trac.macports.org/ticket/18440