Ryan Schmidt wrote:
On Jan 5, 2008, at 17:23, Takeshi Enomoto wrote:
I have received an error report on g95. <http://trac.macosforge.org/projects/macports/ticket/13841>
It is related to MacPorts' libiconv. MacPorts' libiconv does not have symbols iconv_*. There are libiconv_* instead.
System's libiconv have both.
A quick google search tells me that it is a cause of build failure of a few other packages.
I do recall seeing this error reported before.
Could you tell me if 1) iconv_* are deprecated and I should rewrite them to libiconv_*, 2) system's libiconv should be used, or 3) I should wait an update of libiconv package?
I don't know the answer to any of those questions. Well, except for question 2, where I think the answer is "no" because of the reasons stated in the MacPorts FAQ (reasons for why MacPorts uses its own libraries and not the system libraries). I can ask the developers of iconv why those functions are not present.
Problem is related to a port finding the systems iconv.h but using the macports libiconv. Exapmle: /usr/bin/gcc-4.0 -O2 -DIN_GCC -Wall -Wmissing-prototypes -no-cpp-precomp -c version.c Does not have -I/opt/local/include but /usr/bin/gcc-4.0 -O2 -DIN_GCC -Wall -Wmissing-prototypes -no-cpp-precomp -L/opt/local/lib -o g95 g95-g95spec.o /opt/local/var/macports/build/_Users_ram_opt_macports_lang_g95/work/gcc-4.0.3/g95/gcc/prefix.o gcc.o version.o /opt/local/var/macports/build/_Users_ram_opt_macports_lang_g95/work/gcc-4.0.3/g95/gcc/intl.o /opt/local/var/macports/build/_Users_ram_opt_macports_lang_g95/work/gcc-4.0.3/g95/libiberty/libiberty.a /opt/local/var/macports/build/_Users_ram_opt_macports_lang_g95/work/gcc-4.0.3/g95/intl/libintl.a -liconv Does have -L/opt/local/lib Peter -- Peter O'Gorman http://pogma.com