[MacPorts] #50044: doxygen @1.8.10: Could NOT find ICONV (missing: ICONV_COMPILES)

[MacPorts]

#50044: doxygen @1.8.10: Could NOT find ICONV (missing:  ICONV_COMPILES)
------------------------------+---------------------------------
  Reporter:  Peter_Dyballa@…  |      Owner:  css@…
      Type:  defect           |     Status:  new
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:  2.3.4
Resolution:                   |   Keywords:  leopard snowleopard
      Port:  doxygen          |
------------------------------+---------------------------------

Comment (by braumann@…):

 Replying to [comment:9 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`.

-- 
Ticket URL: <https://trac.macports.org/ticket/50044#comment:24>
MacPorts <https://www.macports.org/>
Ports system for OS X