On Feb 10, 2009, at 05:54, [email protected] 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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
