doxygen @1.8.10: Could NOT find ICONV (missing: ICONV_COMPILES)

[ballapete (Peter "Pete" Dyballa)]

The log only shows:

-- Found Threads: TRUE  
-- Looking for iconv_open
-- Looking for iconv_open - not found
-- Performing Test ICONV_COMPILES
-- Performing Test ICONV_COMPILES - Failed
-- Could NOT find ICONV (missing:  ICONV_COMPILES) 
CMake Error at cmake/FindIconv.cmake:121 (MESSAGE):
  Unable to determine iconv() signature
Call Stack (most recent call first):
  CMakeLists.txt:64 (find_package)


-- Configuring incomplete, errors occurred!
See also "/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeOutput.log".
See also "/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeError.log".
Command failed:  cd "/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10" && /opt/local/bin/cmake -DCMAKE_INSTALL_PREFIX=/opt/local -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON -DCMAKE_INSTALL_RPATH=/opt/local/lib -DCMAKE_INSTALL_NAME_DIR=/opt/local/lib -DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr" -DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules -DCMAKE_FIND_FRAMEWORK=LAST -Wno-dev -DCMAKE_C_FLAGS_RELEASE="-DNDEBUG" -DCMAKE_CXX_FLAGS_RELEASE="-DNDEBUG" -DCMAKE_OSX_ARCHITECTURES="ppc" -DCMAKE_OSX_DEPLOYMENT_TARGET="10.5" -DCMAKE_OSX_SYSROOT="/" /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10 
Exit code: 1
Error: Failed to configure doxygen: configure failure: command execution failed
DEBUG: Error code: NONE

but CMakeFiles/CMakeError.log exhibits (complete):

Determining if the function iconv_open exists failed with the following output:
Change Dir: /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_a46a9/fast"
/usr/bin/make -f CMakeFiles/cmTC_a46a9.dir/build.make CMakeFiles/cmTC_a46a9.dir/build
Building C object CMakeFiles/cmTC_a46a9.dir/CheckFunctionExists.c.o
/Developer/usr/bin/gcc-4.2   -I/opt/local/include  -pipe -Os -arch ppc  -DCHECK_FUNCTION_EXISTS=iconv_open -arch ppc -mmacosx-version-min=10.5   -o CMakeFiles/cmTC_a46a9.dir/CheckFunctionExists.c.o   -c /opt/local/share/cmake-3.4/Modules/CheckFunctionExists.c
Linking C executable cmTC_a46a9
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_a46a9.dir/link.txt --verbose=1
/Developer/usr/bin/gcc-4.2  -pipe -Os -arch ppc  -DCHECK_FUNCTION_EXISTS=iconv_open -arch ppc -mmacosx-version-min=10.5 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc  CMakeFiles/cmTC_a46a9.dir/CheckFunctionExists.c.o  -o cmTC_a46a9  
Undefined symbols:
  "_iconv_open", referenced from:
      _main in CheckFunctionExists.c.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [cmTC_a46a9] Error 1
make: *** [cmTC_a46a9/fast] Error 2


Performing C++ SOURCE FILE Test ICONV_COMPILES failed with the following output:
Change Dir: /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_3bd84/fast"
/usr/bin/make -f CMakeFiles/cmTC_3bd84.dir/build.make CMakeFiles/cmTC_3bd84.dir/build
Building CXX object CMakeFiles/cmTC_3bd84.dir/src.cxx.o
/Developer/usr/bin/g++-4.2    -I/opt/local/include  -Wno-deprecated-register -mmacosx-version-min=10.5 -pipe -Os -arch ppc  -DICONV_COMPILES -arch ppc -mmacosx-version-min=10.5   -o CMakeFiles/cmTC_3bd84.dir/src.cxx.o -c /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp/src.cxx
cc1plus: error: unrecognized command line option "-Wno-deprecated-register"
make[1]: *** [CMakeFiles/cmTC_3bd84.dir/src.cxx.o] Error 1
make: *** [cmTC_3bd84/fast] Error 2

Source file was:
#include <iconv.h>
     int main() {
        iconv(iconv_t(-1), 0, 0, 0, 0);
     }

[ballapete (Peter "Pete" Dyballa)]

main.log

[udbraumann]

Cc Me!

[udbraumann]

I can report the same problem on 10.6.8

[ballapete (Peter "Pete" Dyballa)]

Replying to braumann@…:

I can report the same problem on 10.6.8

Me too. CMakeFiles/CMakeError.log has (complete):

Change Dir: /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp

Run Build Command:"/opt/local/bin/gmake" "cmTC_afb5e/fast"
/opt/local/bin/gmake -f CMakeFiles/cmTC_afb5e.dir/build.make CMakeFiles/cmTC_afb5e.dir/build
gmake[1]: Entering directory '/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_afb5e.dir/CheckFunctionExists.c.o
/Developer/usr/bin/llvm-gcc-4.2   -I/opt/local/include  -pipe -Os -arch x86_64  -DCHECK_FUNCTION_EXISTS=iconv_open -arch x86_64 -mmacosx-version-min=10.6   -o CMakeFiles/cmTC_afb5e.dir/CheckFunctionExists.c.o   -c /opt/local/share/cmake-3.4/Modules/CheckFunctionExists.c
Linking C executable cmTC_afb5e
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_afb5e.dir/link.txt --verbose=1
/Developer/usr/bin/llvm-gcc-4.2  -pipe -Os -arch x86_64  -DCHECK_FUNCTION_EXISTS=iconv_open -arch x86_64 -mmacosx-version-min=10.6 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64  CMakeFiles/cmTC_afb5e.dir/CheckFunctionExists.c.o  -o cmTC_afb5e  
Undefined symbols for architecture x86_64:
  "_iconv_open", referenced from:
      _main in CheckFunctionExists.c.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
CMakeFiles/cmTC_afb5e.dir/build.make:97: recipe for target 'cmTC_afb5e' failed
gmake[1]: *** [cmTC_afb5e] Error 1
gmake[1]: Leaving directory '/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_afb5e/fast' failed
gmake: *** [cmTC_afb5e/fast] Error 2


Performing C++ SOURCE FILE Test ICONV_COMPILES failed with the following output:
Change Dir: /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp

Run Build Command:"/opt/local/bin/gmake" "cmTC_7efce/fast"
/opt/local/bin/gmake -f CMakeFiles/cmTC_7efce.dir/build.make CMakeFiles/cmTC_7efce.dir/build
gmake[1]: Entering directory '/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_7efce.dir/src.cxx.o
/Developer/usr/bin/llvm-g++-4.2    -I/opt/local/include  -Wno-deprecated-register -mmacosx-version-min=10.5 -pipe -Os -arch x86_64  -DICONV_COMPILES -arch x86_64 -mmacosx-version-min=10.6   -o CMakeFiles/cmTC_7efce.dir/src.cxx.o -c /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp/src.cxx
cc1plus: error: unrecognized command line option "-Wno-deprecated-register"
CMakeFiles/cmTC_7efce.dir/build.make:65: recipe for target 'CMakeFiles/cmTC_7efce.dir/src.cxx.o' failed
gmake[1]: *** [CMakeFiles/cmTC_7efce.dir/src.cxx.o] Error 1
gmake[1]: Leaving directory '/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_7efce/fast' failed
gmake: *** [cmTC_7efce/fast] Error 2

Source file was:
#include <iconv.h>
     int main() {
        iconv(iconv_t(-1), 0, 0, 0, 0);
     }

[gnw3]

Cc Me!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Cc Me!

[gnw3]

A possible workaround on 10.6.8:

$ sudo port -s install doxygen +wizard +docs configure.compiler=macports-clang-3.6
[...]
$ otool -L $(which doxygen)
/opt/local/bin/doxygen:
	/opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 44.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

The CMake configuration still failed to find "_iconv_open", which I think is provided by the macports' version of libiconv. I assume it linked to the system library during the configuration stage, but otool shows that it ends up using macports' version.

[neverpanic (Clemens Lang)]

I think the problem here may be how libiconv names its symbols. The MacPorts version does not deviate from the upstream default and names its symbols libiconv, but adds a define in the header file that transparently renames iconv to libiconv.

The test source code file correctly includes iconv.h, so it should benefit from that. However since it seems to fail on link because it looks for the symbol iconv_open, my assumption is that the test is actually not done using the correct include path, and the system iconv.h is used.

[udbraumann]

Even

sudo port -s upgrade doxygen configure.compiler=macports-gcc-4.7

has worked for me on 10.6.8 (not yet tested on 10.5.8) to upgrade from doxygen @1.8.9.1_0 to doxygen @1.8.10_1.

It is beyond my scope to analyze what is gong wrong using gcc-4.2 or llvm-gcc4.2, as well as when using gcc-mp-4.5 and gcc-mp-4.6.

[ivl1705]

Cc Me!

[nneonneo (Robert Xiao)]

I'm encountering the exact same problem on OS X 10.10.5 with +universal - the build fails during configuration with "iconv" and "_iconv_open" not found.

[ballapete (Peter "Pete" Dyballa)]

Replying to braumann@…:

sudo port -s upgrade doxygen configure.compiler=macports-gcc-4.7

On PPC Mac OS X 10.5.8 for me this fails like that:

-- The C compiler identification is GNU 4.7.4
-- The CXX compiler identification is GNU 4.7.4
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /opt/local/bin/gcc-mp-4.7
-- Check for working C compiler: /opt/local/bin/gcc-mp-4.7 -- broken
CMake Error at /opt/local/share/cmake-3.4/Modules/CMakeTestCCompiler.cmake:61 (message):
  The C compiler "/opt/local/bin/gcc-mp-4.7" is not able to compile a simple
  test program.

  It fails with the following output:

   Change Dir: /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp

  

  Run Build Command:"/usr/bin/make" "cmTC_2e70e/fast"

  /usr/bin/make -f CMakeFiles/cmTC_2e70e.dir/build.make
  CMakeFiles/cmTC_2e70e.dir/build

  Building C object CMakeFiles/cmTC_2e70e.dir/testCCompiler.c.o

  /opt/local/bin/gcc-mp-4.7 -pipe -Os -m32 -arch ppc
  -mmacosx-version-min=10.5 -o CMakeFiles/cmTC_2e70e.dir/testCCompiler.c.o -c
  /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/CMakeFiles/CMakeTmp/testCCompiler.c


  gcc-mp-4.7: error: unrecognized option '-arch'

  make[1]: *** [CMakeFiles/cmTC_2e70e.dir/testCCompiler.c.o] Error 1

  make: *** [cmTC_2e70e/fast] Error 2

[ballapete (Peter "Pete" Dyballa)]

main.log from port -s upgrade doxygen configure.compiler=macports-gcc-4.7

[ballapete (Peter "Pete" Dyballa)]

Replying to gnwiii@…:

A possible workaround on 10.6.8:

$ sudo port -s install doxygen +wizard +docs configure.compiler=macports-clang-3.6

Trying to use the installed clang-3.3 @3.3_8+analyzer+python27 the compilation seems to indicate a faulty installation:

make[2]: Entering directory `/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10'
[ 21%] Building CXX object vhdlparser/CMakeFiles/vhdlparser.dir/CharStream.cc.o
cd /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/vhdlparser && /opt/local/bin/clang++-mp-3.3    -I/opt/local/include -I/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/src -I/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/qtools  -Wno-deprecated-register -mmacosx-version-min=10.5 -pipe -Os -stdlib=libstdc++ -arch ppc  -DNDEBUG -arch ppc -mmacosx-version-min=10.5   -o CMakeFiles/vhdlparser.dir/CharStream.cc.o -c /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/vhdlparser/CharStream.cc
warning: unknown warning option '-Wno-deprecated-register'; did you mean '-Wno-deprecated'? [-Wunknown-warning-option]
In file included from /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/vhdlparser/CharStream.cc:3:
In file included from /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/vhdlparser/CharStream.h:5:
In file included from /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10/vhdlparser/JavaCC.h:6:
/usr/include/c++/4.0.0/string:44:10: fatal error: 'bits/c++config.h' file not found
#include <bits/c++config.h>
         ^
1 warning and 1 error generated.
make[2]: *** [vhdlparser/CMakeFiles/vhdlparser.dir/CharStream.cc.o] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10'
make[1]: *** [vhdlparser/CMakeFiles/vhdlparser.dir/all] Error 2
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10'
make: *** [all] Error 2
make: Leaving directory `/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10'
Command failed:  cd "/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/doxygen/work/doxygen-1.8.10" && /usr/bin/make -w all VERBOSE=ON 

[udbraumann]

Replying to Peter_Dyballa@…:

Replying to braumann@…:

sudo port -s upgrade doxygen configure.compiler=macports-gcc-4.7

On PPC Mac OS X 10.5.8 for me this fails like that:

...

Yes, I get the same error under 10.5.8 (also when using gcc-mp-5, btw):

gcc-mp-4.7: error: unrecognized option '-arch'

I really wonder why this does not happen under 10.6.8?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

As noted in comment:12, +universal variant fails with an error with iconv.
On OS X 10.11, at least, CMakeError.log records the error: The C compiler identification could not be found in ..., which is similar to #48331.
Following the ​upstream discussion, r143737 fixed the universal problem for me.

By any chance, did r143737 fix the non-universal iconv problem as well?

[udbraumann]

Thanks, but unfortunately r143737 did not fix the problem described in comment:13, I could not build doxygen @1.8.10 on 10.5.8 PPC using gcc-mp-4.9.

[udbraumann]

I need to tell that I did not find a way to build doxygen @1.8.10 on 10.5.8 PPC.

Replying to cal@…:

I think the problem here may be how libiconv names its symbols. The MacPorts version does not deviate from the upstream default and names its symbols libiconv, but adds a define in the header file that transparently renames iconv to libiconv.

The test source code file correctly includes iconv.h, so it should benefit from that. However since it seems to fail on link because it looks for the symbol iconv_open, my assumption is that the test is actually not done using the correct include path, and the system iconv.h is used.

doxygen @1.8.10 brings a copy of iconv.h which is put under /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_doxygen/doxygen/work/doxygen-1.8.10/winbuild after extraction. Under the same folder there are also iconv.lib and iconv64.lib. The two latter are ar-packed object files. I assume both were not built for ppc, but for i386 and x86_64, respectively (and both contain a definition for iconv_open). I wonder why doxygen i) apparently is not using libiconv from MacPorts, and ii) why it is not using glibc which should also provide an iconv implementation?

[ryandesign (Ryan Carsten Schmidt)]

I assume the winbuild folder is for building on Windows and is not used on OS X.

[ryandesign (Ryan Carsten Schmidt)]

And there is no glibc on OS X.

[dstrubbe (David Strubbe)]

Cc Me!

[udbraumann]

Replying to ryandesign@…:

I assume the winbuild folder is for building on Windows and is not used on OS X.

Sorry, you are certainly right.

[udbraumann]

Replying to ryandesign@…:

And there is no glibc on OS X.

My mistake, sorry.

[udbraumann]

Replying to cal@…:

I think the problem here may be how libiconv names its symbols. The MacPorts version does not deviate from the upstream default and names its symbols libiconv, but adds a define in the header file that transparently renames iconv to libiconv.

The test source code file correctly includes iconv.h, so it should benefit from that. However since it seems to fail on link because it looks for the symbol iconv_open, my assumption is that the test is actually not done using the correct include path, and the system iconv.h is used.

I think you are quite right. However, I doubt that the test which fails during the configure phase is using iconv.h at all.

I made some small on foot tests on my 10.5.8 PPC (that test which presently fails during the configure phase):

$ /Developer/usr/bin/gcc-4.2   -I/opt/local/include  -pipe -Os  -DCHECK_FUNCTION_EXISTS=iconv_open -arch ppc -mmacosx-version-min=10.5  -o CheckFunctionExists.c.o   -c /opt/local/share/cmake-3.4/Modules/CheckFunctionExists.c

followed by

$ /Developer/usr/bin/gcc-4.2  -pipe -Os  -DCHECK_FUNCTION_EXISTS=iconv_open -arch ppc -mmacosx-version-min=10.5 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names  CheckFunctionExists.c.o  -o cmTC_c612f
Undefined symbols:
  "_iconv_open", referenced from:
      _main in CheckFunctionExists.c.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Only, if I replace the -L/opt/local/lib with -liconv the compilation is successful:

 /Developer/usr/bin/gcc-4.2  -pipe -Os  -DCHECK_FUNCTION_EXISTS=iconv_open -arch ppc -mmacosx-version-min=10.5 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -liconv -Wl,-headerpad_max_install_names  CheckFunctionExists.c.o  -o cmTC_c612f

I also looked using nm inside /opt/local/lib/libiconv.a and have seen that only _libiconv_open is defined therein. However, inside /usr/lib/libiconv.a I found both _iconv_open and _libiconv_open.

Simply addin -liconv was not sufficient:

$ /Developer/usr/bin/gcc-4.2  -pipe -Os  -DCHECK_FUNCTION_EXISTS=iconv_open -arch ppc -mmacosx-version-min=10.5 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -liconv -L/opt/local/lib -Wl,-headerpad_max_install_names  CheckFunctionExists.c.o  -o cmTC_c612f
Undefined symbols:
  "_iconv_open", referenced from:
      _main in CheckFunctionExists.c.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

That emphasizes that _iconv_open is not included in the /opt/local/lib/libiconv.a.

Note that without -liconv the linker does not find /usr/lib/libiconv.a, and even with -liconv, if -L/opt/local/lib/ is included prior to -L/usr/lib it will find an inappropriate libiconv.a without _iconv_open defined inside. I have not idea what happens if iconv.h is really included, but as far as I can see, this is not done using /opt/local/share/cmake-3.4/Modules/CheckFunctionExists.c.

BTW, in /opt/local/include/iconv.h I find this line:

#ifndef LIBICONV_PLUG
#define iconv_open libiconv_open
#endif

Is this what you mentioned? Do you understand the condition? Would it mean that if LIBICONV_PLUG is undefined all occurences of iconv_open would be treated as if libiconv_open was called?

Can we assume that if doxygen is referring to functions from libiconv everything should be fine? E.g., I have tried to check what happens if I make the test with the libiconv_open symbol:

$ /Developer/usr/bin/gcc-4.2 -DLIBICONV_PLUG -I/opt/local/include  -pipe -Os  -DCHECK_FUNCTION_EXISTS=libiconv_open -arch ppc -mmacosx-version-min=10.5  -o CheckFunctionExists.c.o   -c /opt/local/share/cmake-3.4/Modules/CheckFunctionExists.c

followed by

$ /Developer/usr/bin/gcc-4.2  -pipe -Os  -DCHECK_FUNCTION_EXISTS=iconv_open -arch ppc -mmacosx-version-min=10.5 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -liconv -L/opt/local/lib -Wl,-headerpad_max_install_names  CheckFunctionExists.c.o  -o cmTC_c612f

This works. Of course only, if I tell to use -liconv explicitly. I really wonder how this test ever could be successful without any -liconv.

[neverpanic (Clemens Lang)]

The define you quoted in /opt/local/include/iconv.h is exactly the line that would make this rename transparent for applications. If the configure check did include this header before testing for iconv_open, like it should, then everything would work as expected. Modifying the test to check for the libiconv_open symbol is the wrong approach to fixing this, because it would in turn break linking against Linux' and OS X' system iconv.

The test is successful on other systems because their copy of libiconv has LIBICONV_PLUG defined in its headers (Apple does this for the system copy of it), or iconv is integrated into libc, where the symbol is named iconv_open.

The correct fix is to modify the check to compile a piece of software that correctly includes iconv.h. Patches on this are very welcome and would probably also be accepted upstream.

[udbraumann]

I have tried to explicitly specify MacPort's iconv.h:

$ /Developer/usr/bin/gcc-4.2  -include /opt/local/include/iconv.h  -pipe -Os  -DCHECK_FUNCTION_EXISTS=iconv_open -arch ppc -mmacosx-version-min=10.5  -o CheckFunctionExists.c.o   -c /opt/local/share/cmake-3.4/Modules/CheckFunctionExists.c
/opt/local/share/cmake-3.4/Modules/CheckFunctionExists.c:6: error: conflicting types for ‘libiconv_open’
/opt/local/include/iconv.h:73: error: previous declaration of ‘libiconv_open’ was here

I have no idea where this conflicting libiconv_open has been defined before.

I've also tried to define LIBICONV_PLUG. Note that now it complains about a previously defined iconv_open:

$ /Developer/usr/bin/gcc-4.2 -DLIBICONV_PLUG  -include /opt/local/include/iconv.h  -pipe -Os  -DCHECK_FUNCTION_EXISTS=iconv_open -arch ppc -mmacosx-version-min=10.5  -o CheckFunctionExists.c.o   -c /opt/local/share/cmake-3.4/Modules/CheckFunctionExists.c
/opt/local/share/cmake-3.4/Modules/CheckFunctionExists.c:6: error: conflicting types for ‘iconv_open’
/opt/local/include/iconv.h:73: error: previous declaration of ‘iconv_open’ was here

What to do now?

[neverpanic (Clemens Lang)]

The second definition is probably added by CMake's symbol check mechanism to avoid causing a warning (that could turn into an error depending on compiler settings). You'll have to roll your own compile check instead of re-using what CMake provides to get this right.

[neverpanic (Clemens Lang)]

Actually, we were following the wrong lead here. The check_function_exists(iconv_open) test is supposed to fail on OS X, which gives cmake/FindIconv.cmake the possibility to continue to search for a dedicated libiconv.dylib. It then finds that and tries to compile it, which is what fails in your case. See the second part of your test output, where the compiler throws an error message:

cc1plus: error: unrecognized command line option "-Wno-deprecated-register"

This was fixed by Jeremy in r144650.

[ballapete (Peter "Pete" Dyballa)]

It built on PPC Leopard, Mac OS X 10.5.8, and on Leopard, Mac OS X 10.6.8.