libiconv: iconv() function prototype differences

[ryandesign (Ryan Carsten Schmidt)]

libiconv defines the second parameter of the iconv function differently on different operating systems. Specifically libiconv tries to mimic the behavior of the system's iconv, whatever that may be. The author of libiconv ​appears to intend this behavior.

However libiconv in MacPorts seems to have some peculiarities of its own in how and when that function's definition changes.

In ${prefix}/include/iconv.h we see the different definitions of the iconv function.

MacBook Pro Core 2 Duo, Tiger
libiconv @1.12_2 (non-universal):

extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);

MacBook Pro Core 2 Duo, Tiger
libiconv @1.12_2+darwin_8+universal (4-arch) before r46078 / using MacPorts built-in universal variant:

extern size_t iconv (iconv_t cd,  char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);

MacBook Pro Core 2 Duo, Tiger
libiconv @1.12_2+universal (4-arch) after r46078 / using muniversal portgroup:

#ifndef __LP64__
extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
#else /* __LP64__ */
extern size_t iconv (iconv_t cd,  char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
#endif /* __LP64__ */

I'm not certain why the function is different on 32-bit an 64-bit.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Cc Me!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Do the differences between the config.log in i386 and x86_64 give any indication why the prototypes are different between the 32 and 64 bit builds?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

The reason for this seems to be that the libiconv library is not 32/64-bit universal on Tiger.

$ file /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libiconv.dylib 
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libiconv.dylib: Mach-O universal binary with 2 architectures
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libiconv.dylib (for architecture ppc):	Mach-O dynamically linked shared library stub ppc
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libiconv.dylib (for architecture i386):	Mach-O dynamically linked shared library stub i386

As far as the configure scripts is concerned, libiconv is not installed, so it defaults to "char* * inbuf".

This behavior is easy to override.
Any thoughts on which convention we should choose?

[(none)]

Milestone Port Bugs deleted

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Fixed in r50387.