Hello Ryan, 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. 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? Regards, Takeshi
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.
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
I can ask the developers of iconv why those functions are not present.
Man pages are iconv_* rather than libiconv_*. If LIBICONV_PLUG is defined, iconv_* are used. (See include/iconv.h.in) It must be introduce to avoid some conflicts... But if so gcc source should be using libiconv_*. Please ask the developers if you can. Thanks. Takeshi
I will upload the patch after Trac is back.
I submitted the patch of g95 package. Could someone take a look? <http://trac.macosforge.org/projects/macports/attachment/ticket/13841> Takeshi
participants (3)
-
Peter O'Gorman
-
Ryan Schmidt
-
Takeshi Enomoto