It's causing a small problem. I'm adding a better port of GNAT to
FreeBSD and adding new packages in pkgsrc of GNAT for DragonFly BSD and
NetBSD (both i386 and AMD64), and I have the option to do the same for
OpenBSD. I'm only concerned with C + Ada languages for now.
The first issue is the bootstrap compiler. What's been happening to
previous ports is that as libgmp, libmpc, and libmpfr get version
upgrades, the binary bootstrap compiler stops working (e.g. libgmp.so.8
goes to libgmp.so.10 and previous shared library is removed by the port
system so it breaks the bootstrap). I'm going to fix this by modifying
the makefile to statically link as many libraries as possible to build
the boostrap compiler. LIBICONV is evaluated separately, although I can
just probably just modify the bootstrap compiler makefile again.
So that leaves the general case of having a dependency in the port
system that the port doesn't really need. So for the general case, I'd
classify it as "nice to have", but certainly not a show stopper. I'm
sure somebody would argue that the c compiler would be used for more
than building another GNAT and thus -finput-charset capability should be
maintained.
So what I'm talking from this: libiconv is needed beyond nls and java,
and there is no way to prevent it from getting linked in if it's
available on a search path.
Thanks,
John
On 1/8/2011 7:56 PM, Ian Lance Taylor wrote:
gcc will use iconv, if available, even if --disable-nls is used, to
support the -finput-charset option. So the behaviour is as expected.
Is it causing a problem?
Ian
