RE: Building gcc 4.6 without libiconv

RE: Building gcc 4.6 without libiconv

[Jay K]

> John I'm trying to build gcc 4.6 without libiconv.  My understanding is
> Ian Is it causing a problem?


I've repeatedly run into the problem where a private gcc 4.3 or? 4.5 frontend built on one Solaris machine and then run on another fails
because the second doesn't have libiconv but the first did. I have since carefully patched all the libiconv use out.
(not to mention the gmp/mpfr/mpc dependencies...)

It *appears* but I didn't confirm that all frontends pull in libcpp and libiconv, but I haven't fully looked into it.

 - Jay

 		 	   		  

Re: Building gcc 4.6 without libiconv

[John Marino]

For my part, I was able to build bootstrap compilers that pull in z, 
mpc, mpfr, gmp, and iconv statically.  That only left libc as a shared 
object, and that's acceptable for my use.  In case others are 
interested, the patch I used follows.  Maybe not the best, but it got 
the job done for me.
Thanks,
John


--- gcc/Makefile.in.orig    2011-01-09 00:44:20.000000000 +0100
+++ gcc/Makefile.in    2011-01-09 00:53:28.000000000 +0100
@@ -306,11 +306,11 @@
  # This is where we get zlib from.  zlibdir is -L../zlib and zlibinc is
  # -I../zlib, unless we were configured with --with-system-zlib, in which
  # case both are empty.
-ZLIB = @zlibdir@ -lz
+ZLIB = -Wl,-Bstatic @zlibdir@ -lz -Wl,-Bdynamic
  ZLIBINC = @zlibinc@

  # How to find GMP
-GMPLIBS = @GMPLIBS@
+GMPLIBS = -Wl,-Bstatic @GMPLIBS@ -Wl,-Bdynamic
  GMPINC = @GMPINC@

  # How to find PPL
@@ -626,8 +626,8 @@
  LIBINTL_DEP = @LIBINTL_DEP@

  # Character encoding conversion library.
-LIBICONV = @LIBICONV@
-LIBICONV_DEP = @LIBICONV_DEP@
+LIBICONV = -Wl,-Bstatic -L/usr/local/lib -liconv -Wl,-Bdynamic
+LIBICONV_DEP =

  # The GC method to be used on this system.
  GGC=@GGC@.o


On 1/9/2011 10:10 PM, Jay K wrote:
>> John I'm trying to build gcc 4.6 without libiconv.  My understanding is
>> Ian Is it causing a problem?
>
> I've repeatedly run into the problem where a private gcc 4.3 or? 4.5 frontend built on one Solaris machine and then run on another fails
> because the second doesn't have libiconv but the first did. I have since carefully patched all the libiconv use out.
> (not to mention the gmp/mpfr/mpc dependencies...)
>
> It *appears* but I didn't confirm that all frontends pull in libcpp and libiconv, but I haven't fully looked into it.
>
>   - Jay
>
>   		 	   		

Re: Building gcc 4.6 without libiconv

[John Marino]

On 1/8/2011 10:21 PM, Jonathan Wakely wrote:
> Do you mean the GCC makefile or the BSD ports makefile?
> You don't need to change the GCC makefile to link statically to gmp,
> mpfr and mpc.  If you put the gmp/mpfr/mpc sources in the gcc source
> tree then those sources will be used and statically linked to the gcc
> binaries.
> If you want to use an existing libgmp.a already installed on the
> system, then you might need to change the makefiles to force that to
> happen.
Yes, all the libraries are already built, so it's faster to apply a one 
line patch to the gcc makefile to produce the bootstrap compiler than to 
rebuild 3 libraries that I already have in .a format.

The port-produced gnat will feature the normal shared-object libraries.

Re: Building gcc 4.6 without libiconv

[Jonathan Wakely]

On 8 January 2011 19:26, John Marino wrote:
>
> 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.

Do you mean the GCC makefile or the BSD ports makefile?
You don't need to change the GCC makefile to link statically to gmp,
mpfr and mpc.  If you put the gmp/mpfr/mpc sources in the gcc source
tree then those sources will be used and statically linked to the gcc
binaries.

If you want to use an existing libgmp.a already installed on the
system, then you might need to change the makefiles to force that to
happen.

Re: Building gcc 4.6 without libiconv

[John Marino]

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

Re: Building gcc 4.6 without libiconv

[Ian Lance Taylor]

John Marino <gnugcc@marino.st> writes:

> I'm trying to build gcc 4.6 without libiconv.  My understanding is
> that this library is only required for nls support and the java
> frontend.  I'm configuring with --disable-nls and I'm not building the
> java language.
>
> I've tried --without-libiconv-prefix
> I've tried --with-libiconv-prefix=no
> I've tried setting with-libiconv-prefix to a directory where libiconv
> doesn't exist.
>
> Yet the gcc/configure script keeps picking up -liconv.  It exists in
> the same library directory as libmpc, libmpfr, libgmp.
>
> So my questions are simple:
>
> 1) can somebody confirm libiconv isn't needed beyond nls and java?
> 2) Is so, why is configure script still looking for it if those
> options are disabled?
> 3) if so, short of patching the configure script, how can gcc be told
> to not link libiconv.so even if it finds it in a standard location?

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

Building gcc 4.6 without libiconv

[John Marino]

I'm trying to build gcc 4.6 without libiconv.  My understanding is that 
this library is only required for nls support and the java frontend.  
I'm configuring with --disable-nls and I'm not building the java language.

I've tried --without-libiconv-prefix
I've tried --with-libiconv-prefix=no
I've tried setting with-libiconv-prefix to a directory where libiconv 
doesn't exist.

Yet the gcc/configure script keeps picking up -liconv.  It exists in the 
same library directory as libmpc, libmpfr, libgmp.

So my questions are simple:

1) can somebody confirm libiconv isn't needed beyond nls and java?
2) Is so, why is configure script still looking for it if those options 
are disabled?
3) if so, short of patching the configure script, how can gcc be told to 
not link libiconv.so even if it finds it in a standard location?

Thanks for any help provided!
John