doxygen 1.5.4 build error in portable_iconv()

[dambler@…]

Using 10.4 ppc G5 system

getting output:

--->  Building doxygen with target all pdf
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_doxygen/work/doxygen-1.5.3" && make all pdf " returned error 2
Command output: /usr/bin/make -C qtools
/usr/bin/make -f Makefile.qtools    all
make[2]: Nothing to be done for `all'.
/usr/bin/make -C libpng
/usr/bin/make -f Makefile.libpng
make[2]: Nothing to be done for `all'.
/usr/bin/make -C libmd5
/usr/bin/make -f Makefile.libmd5
make[2]: Nothing to be done for `all'.
/usr/bin/make -C src
/usr/bin/make -f Makefile.libdoxycfg PERL=/usr/bin/perl all
c++ -c -pipe -D__FreeBSD__=6 -Wall -W -O2 -I../qtools -o ../objects/portable.o portable.cpp
portable.cpp: In function 'size_t portable_iconv(void*, const char**, size_t*, char**, size_t*)':
portable.cpp:381: error: invalid conversion from 'char**' to 'const char**'
portable.cpp:381: error:   initializing argument 2 of 'size_t libiconv(void*, const char**, size_t*, char**, size_t*)'
make[2]: *** [../objects/portable.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

Error: Status 1 encountered during processing.

[afb@…]

Sounds similar to #13008

[afb@…]

patch-portable.cpp should probably be moved to darwin 9 platform only.

[css@…]

I never had a chance to check the previous patch before it was committed. Also, please assign issues to port maintainers rather than the list.

[css@…]

It might be worthwhile to check with the newest doxygen as referenced in #13171. I still fail to encounter any error compiling on Tiger, although I'm going to try reinstalling XCode to see if I can duplicate it in the first place.

[css@…]

I still want to track down why I've been unable to reproduce the original error. What versions of XCode are each of you using?

[dambler@…]

I'm using xcode 2.4.1

[afb@…]

Xcode 2.4 on Tiger, Xcode 3.0 on Leopard (and apologies for rushing the original patch out)

[css@…]

I had XCode 2.4 installed, and I installed XCode 2.5 yesterday. I'm not having any luck reproducing the error. Do you have anything in /usr/local? Perhaps attach the output from:

sudo port clean doxygen && sudo port -v configure doxygen

I wonder if there's something else getting picked up somewhere.

[afb@…]

Could it be a difference whether port "libiconv" is currently installed or not ?

Casting the function pointer over to void* would work with either constness...

[css@…]

I have libiconv @1.11_6+darwin_8, but I built fine with it deactivated. The default iconv.h installed into /usr/include should create the correct catch in that statement, and it's version 0x0109. Can you verify your libiconv?

grep _LIBICONV_VERSION /opt/local/include/*.h /usr/include/*.h

[css@…]

I updated the port to doxygen 1.5.4, and I added libiconv as a dependency. That seems like the safest path since most packages use it automatically when it's found. Could you please check after a port sync?

[dambler@…]

/opt/local/include/iconv.h:#define _LIBICONV_VERSION 0x010B /* version number: (major<<8) + minor */ /usr/include/iconv.h:#define _LIBICONV_VERSION 0x0109 /* version number: (major<<8) + minor */

[css@…]

Could someone please sudo port -v build >& doxygen.txt and add the log as an attachment? I'm determined to figure out why it works on my machine and not for others. :)

[css@…]

Successful 1.5.4 build log, Mac OS X 10.4.10 MacBook Pro

[frstan@…]

it seems appropriate to note this information from closed as duplicate ticket here:

#13275: cant upgrade doxygen to 1.5.4_0 on intel/leopard Same problem as v 1.5.3 had building under intel/leopard. Solution: uncomment patch patch-portable.cpp in portfile. This was the patch that fixed version 1.5.3 and I have confirmed that it fixes 1.5.4 also By frstan@… — 11/13/07 01:33:49

[css@…]

The patch is simple, but I ihaven't seen why it's needed. In fact, doxygen fails to build on my Mac with Tiger with the patch applied'. Why is that patch needed for some of you? Doxygen 1.5.4 builds for me without error. I cannot reproduce it. I'm trying to determine the discrepancy that results in the difference in behavior. I don't want to patch upstream source without a clear understanding of why the patch is needed. Is it an XCode incompatibility? Intel vs PPC? Some third party library? Just some anomaly that lets it build without the patch on my machine?

• XCode versions seem to match. doxygen builds without patching on XCode 2.4 and 2.5.
• libiconv versions are fine in both /usr/include and /opt/local/include.
• I do not have a /usr/local/include. (Do any of you with the error?)
• Does libiconv() have a different function signature on Leopard?
• Do you have another libiconv.h somewhere?

Here's what happens when I apply the patch:

portable.cpp: In function ‘size_t portable_iconv(void*, const char**, size_t*, char**, size_t*)’:
portable.cpp:385: error: invalid conversion from ‘char**’ to ‘const char**’
portable.cpp:385: error:   initializing argument 2 of ‘size_t libiconv(void*, const char**, size_t*, char**, size_t*)’
make[1]: *** [../objects/portable.o] Error 1

Note that the second argument to libiconv() is a const char. This is correct:

/usr/include/libiconv.h:82:

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

/opt/local/include/libiconv.h:83:

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

Therefore the patch should not be needed, as doxygen's portable_libiconv() shouldn't need to cast to a char**.

[ram@…]

build log from Leopard showing build failure

[ram@…]

I've attached the build log I get when trying to build on Intel Leopard

[css@…]

Thanks for the log. I'm still not clear on where the discrepancies may be. Can you include the output from the following command:

grep "extern size_t iconv" /usr/include/* /opt/local/include/*

[ram@…]

$ grep "extern size_t iconv" /usr/include/* /opt/local/include/*
/opt/local/include/iconv.h:extern size_t iconv (iconv_t cd,  char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
$ 

[css@…]

Hrm, now that's strange ...

$ grep "extern size_t iconv" /usr/include/* /opt/local/include/*/usr/include/iconv.h:extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
/opt/local/include/iconv.h:extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
$ port installed libiconv
The following ports are currently installed:
  libiconv @1.12_0+darwin_8 (active)

I have the latest version installed, but both my iconv.h headers have a const char** parameter. What's your port installed libiconv report?

[ram@…]

$ port installed libiconv
The following ports are currently installed:
  libiconv @1.12_0 (active)
$

[afb@…]

Replying to afb@macports.org:

Casting the function pointer over to void* would work with either constness...

Bug #13761 was reported as a duplicate of this.

[css@…]

I determined the origin of the const qualifier ... if a system already has libiconv installed (and every properly configured Mac OS X developer system should have /usr/include/iconv.h), then libiconv configures with the const char** parameter. This seems to match my system as well as that of doxygen's author.

Could those of you encountering this error post the output from:

lsbom /Library/Receipts/DevSDK.pkg/Contents/Archive.bom | grep 'iconv.h'

[ram@…]

I don't have DevSDK.pkg in /Library/Receipts on my Intel Leopard system, Xcode3 is installed - in fact I just reinstalled it again to make sure...

Could this be a similar problem to that in g95 in #13841, where it was linking against the libiconv from MacPorts yet using the system iconv.h header?

[css@…]

Do you have a /usr/include/iconv.h? If not, then I'm wondering if you're missing the component of the OS that includes it. That in turn appears to make the libiconv port configure differently. One of the comments noted this error on Tiger, something I have as yet been unable to reproduce.

[ram@…]

Yes, I have /usr/include/iconv.h

$ ls -l /usr/include/iconv.h
-rw-r--r--  1 root  wheel  8126 23 Sep 15:08 /usr/include/iconv.h
$ md5 /usr/include/iconv.h 
MD5 (/usr/include/iconv.h) = 9d23f75835d62fadb44b83b78170af41

[dclunie@…]

Hi

I also have the same error reported (Leopard).

I have a general question, which is why does port install libiconv in the first place, if the same version is already present in Leopard. I.e.:

% ls -l /usr/lib/libiconv*
lrwxr-xr-x  1 root  wheel       16 Dec 24 18:45 /usr/lib/libiconv.2.4.0.dylib -> libiconv.2.dylib
-rw-r--r--  1 root  wheel  4147008 Sep 23 18:08 /usr/lib/libiconv.2.dylib
lrwxr-xr-x  1 root  wheel       20 Dec 24 18:45 /usr/lib/libiconv.dylib -> libiconv.2.4.0.dylib
-rw-r--r--  1 root  wheel      795 Sep 23 18:08 /usr/lib/libiconv.la

% ls -l /opt/local/lib/libiconv*
-rw-r--r--  2 root  admin  1061556 Dec 30 08:40 /opt/local/lib/libiconv.2.4.0.dylib
lrwxr-xr-x  1 root  admin       20 Dec 30 08:40 /opt/local/lib/libiconv.2.dylib -> libiconv.2.4.0.dylib
-rw-r--r--  2 root  admin  1075320 Dec 30 08:40 /opt/local/lib/libiconv.a
lrwxr-xr-x  1 root  admin       20 Dec 30 08:40 /opt/local/lib/libiconv.dylib -> libiconv.2.4.0.dylib
-rw-r--r--  2 root  admin      828 Dec 30 08:40 /opt/local/lib/libiconv.la

Also, I saw the earlier comment to check that the iconv header version should be the same on the Apple version and the port installed version.

That is the case for me, but the contents of the iconv.h files are different in the two locations.

Specifically:

% diff /opt/local/include/iconv.h /usr/include/iconv.h
23a24,30
> #include <sys/cdefs.h>
> #include <_types.h>
> #ifndef _SIZE_T
> #define _SIZE_T
> typedef __darwin_size_t     size_t;
> #endif
> 
45,46c52,53
< #undef iconv_t
< #define iconv_t libiconv_t
---
> #ifndef _ICONV_T
> #define _ICONV_T
48,59d54
< 
< /* Get size_t declaration.
<    Get wchar_t declaration if it exists. */
< #include <stddef.h>
< 
< /* Get errno declaration and values. */
< #include <errno.h>
< /* Some systems, like SunOS 4, don't have EILSEQ. Some systems, like BSD/OS,
<    have EILSEQ in a different header.  On these systems, define EILSEQ
<    ourselves. */
< #ifndef EILSEQ
< #define EILSEQ 
70,73c65
< #ifndef LIBICONV_PLUG
< #define iconv_open libiconv_open
< #endif
< extern iconv_t iconv_open (const char* tocode, const char* fromcode);
---
> iconv_t iconv_open (const char* /*tocode*/, const char* /*fromcode*/);
80,83c72,74
< #ifndef LIBICONV_PLUG
< #define iconv libiconv
< #endif
< extern size_t iconv (iconv_t cd,  char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
---
> size_t iconv (iconv_t /*cd*/,
> 	char ** __restrict /*inbuf*/,  size_t * __restrict /*inbytesleft*/,
> 	char ** __restrict /*outbuf*/, size_t * __restrict /*outbytesleft*/);
86,90c77
< #ifndef LIBICONV_PLUG
< #define iconv_close libiconv_close
< #endif
< extern int iconv_close (iconv_t cd);
< 
---
> int iconv_close (iconv_t /*cd*/);
92c79
< #ifndef LIBICONV_PLUG
---
> #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)
95a83,89
> #ifndef __cplusplus
> #ifndef _WCHAR_T
> #define _WCHAR_T
> typedef __darwin_wchar_t	wchar_t;
> #endif /* _WCHAR_T */
> #endif /* __cplusplus */
> 
97,98c91
< #define iconvctl libiconvctl
< extern int iconvctl (iconv_t cd, int request, void* argument);
---
> int iconvctl (iconv_t /*cd*/, int /*request*/, void* /*argument*/);
177,181c170,173
< #define iconvlist libiconvlist
< extern void iconvlist (int (*do_one) (unsigned int namescount,
<                                       const char * const * names,
<                                       void* data),
<                        void* data);
---
> void iconvlist (int (* /*do_one*/) (unsigned int /*namescount*/,
>                                       const char * const * /*names*/,
>                                       void* /*data*/),
>                        void* /*data*/);
194,195c186,187
< extern void libiconv_set_relocation_prefix (const char *orig_prefix,
< 					    const char *curr_prefix);
---
> void libiconv_set_relocation_prefix (const char * /*orig_prefix*/,
> 					    const char * /*curr_prefix*/);
197c189
< #endif
---
> #endif /* (!_POSIX_C_SOURCE || _DARWIN_C_SOURCE) */

[coreymon77@…]

i have the same problem on leopard. is there a patch released for it yet?

[css@…]

Not yet ... I just got access back to my Mac again. This patch looks like it's a leopard-specific fix. I'll follow up tonight.

[css@…]

Apply a patch on Leopard systems

[css@…]

Could someone please test this patch on Leopard? It seems to leave things working fine on Tiger, as it only applies the patch for darwin 9.

[gui_dos@…]

I confirm that the patch makes doxygen build successfully on Leopard.

There's a problem, though: I had texlive_base installed which doesn't provide pdflatex, stopping the compilation.

The dependency on bin:tex:teTeX should therefore changed into port:teTeX

[ram@…]

That builds find for me.

The dependency shouldn't be changed to port:teTeX as teTeX is deprecated in favour of TeXLive - what port is pdflatex in, as that should be added as a dependency.

[coreymon77@…]

i too can confirm that this patch makes doxygen successfully build on 10.5.1 leopard. thanks for the patch

[css@…]

Fixed in r33551, thanks for the testing (and to afb for the original patch!) I'll address the texlive change in #13986.

[anonymous]

Milestone Port Bugs deleted