[MacPorts] #50044: doxygen @1.8.10: Could NOT find ICONV (missing: ICONV_COMPILES)
MacPorts
noreply at macports.org
Tue Jan 5 16:03:50 PST 2016
#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@…):
I need to tell that I did not find a way to build `doxygen @1.8.10` on
10.5.8 PPC.
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.
`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?
--
Ticket URL: <https://trac.macports.org/ticket/50044#comment:18>
MacPorts <https://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list