Re: Building gcc 4.6 without libiconv

[John Marino <gnugcc at marino dot st>]

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