Have GCC link to system zlib

[Jeremy Huntwork]

GCC 4.5.0 now uses zlib in its build. It ships with a copy of zlib that it will build and use even if you have zlib installed in the system as is done in chapter 6. One can avoid compiling zlib again and use the system's zlib by passing --with-system-zlib to gcc's configure line.

[bdubbs@…]

I am not in favor of changing the tool chain in this way.

1. It creates another potential way to break gcc.

   $ ldd `which gcc`
           linux-vdso.so.1 =>  (0x00007fff21fff000)
           libc.so.6 => /lib/libc.so.6 (0x00007f7860660000)
           /lib64/ld-linux-x86-64.so.2 (0x00007f78609b3000)
   

is simple.

2. On my system:

   			[zlib]
   
   Build time is:			0 minutes and 5 seconds
   Build time in seconds is:	5
   Approximate SBU time is:	0.1
   

That time is hardly is worth saving.

3. It would require moving zlib to a position before gcc in Chapter 6.

I don't see other distros doing this and the potential to do harm is greater than what appears to be a negligible benefit.

[Jeremy Huntwork]

Replying to bdubbs@…:

1. It creates another potential way to break gcc.

   $ ldd `which gcc`
           linux-vdso.so.1 =>  (0x00007fff21fff000)
           libc.so.6 => /lib/libc.so.6 (0x00007f7860660000)
           /lib64/ld-linux-x86-64.so.2 (0x00007f78609b3000)
   

Incorrect, at least per this example. On my system that has been built with the --with-system-zlib switch:

 # ldd /usr/bin/gcc                                                                                                                                            
	linux-vdso.so.1 =>  (0x00007fffcedc2000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f38f505b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f38f53b2000)

It's using -lz within the build, so I believe all uses are of the static library.

is simple.

2. On my system:

   			[zlib]
   
   Build time is:			0 minutes and 5 seconds
   Build time in seconds is:	5
   Approximate SBU time is:	0.1
   

That time is hardly is worth saving.

Any time that can be saved is worth considering saving. In any case, the version of zlib that comes with gcc is an older one and for some reason it takes much longer than 5 seconds. Run through a build, you'll see what I mean.

3. It would require moving zlib to a position before gcc in Chapter 6.

Zlib already is before GCC in chapter 6.

I don't see other distros doing this and the potential to do harm is greater than what appears to be a negligible benefit.

I would accept this as a potentially valid argument if you applied that same principle to the other libraries that gcc uses and could be built in statically, namely, gmp and mpfr. As it is, since you install those to the system in chapter 6 solely for the sake of GCC, then you're already setting a precedent.

[bdubbs@…]

Replying to jhuntwork:

Replying to bdubbs@…:

It's using -lz within the build, so I believe all uses are of the static library.

OK.

Any time that can be saved is worth considering saving. In any case, the version of zlib that comes with gcc is an older one and for some reason it takes much longer than 5 seconds. Run through a build, you'll see what I mean.

Define 'much longer'. I'd still be nervous about it.

Zlib already is before GCC in chapter 6.

Yes. For some reason I was thinking of glibc.

I don't see other distros doing this and the potential to do harm is greater than what appears to be a negligible benefit.

I would accept this as a potentially valid argument if you applied that same principle to the other libraries that gcc uses and could be built in statically, namely, gmp and mpfr. As it is, since you install those to the system in chapter 6 solely for the sake of GCC, then you're already setting a precedent.

We build gmp and mpfr separately so other programs have them available. I have no idea why gcc needs libz anyway. It doesn't make sense to me.

[Jeremy Huntwork]

Replying to bdubbs@…:

Define 'much longer'. I'd still be nervous about it.

To be honest, I didn't capture the time. I halted it after I saw it building zlib and started looking for the switch to use, but it had already been going for at least twice that amount. Trivial, I know, but to me, the reason for doing this is less about saving time and more about using the build method to our advantage.

Why nervous? It's not like we're hacking the GCC code (a feat we've done more than I'd like in chapter 5). We're using a switch that they put there for that purpose.

We build gmp and mpfr separately so other programs have them available. I have no idea why gcc needs libz anyway. It doesn't make sense to me.

I do know why we build gmp and mpfr separately, and for the same reasons we've already built zlib and put it way up in the build order. Actually, when including BLFS packages, zlib is one of the most used libraries. All throughout BLFS there are switches used to link to the system installed zlib instead of included versions. My suggestion for the doing this here is just the same as what we've done elsewhere.

In any case, this is really a trivial issue. I leave it up to you active devs...

[houhongxun]

According to gcc documentation, the '--with-system-zlib' option is java specific option, it is only used by building libgcj. Does it have effect on other targets?

[Jeremy Huntwork]

Replying to hohoxu_hao115:

According to gcc documentation, the '--with-system-zlib' option is java specific option, it is only used by building libgcj. Does it have effect on other targets?

Where exactly are you seeing that? Anyway, it's definitely using zlib in the build without libgcj and it tries to build zlib internally without that switch. Check recent build logs from LFS, you should see what I mean.

[Matthew Burgess]

Replying to jhuntwork:

 # ldd /usr/bin/gcc                                                                                                                                            
	linux-vdso.so.1 =>  (0x00007fffcedc2000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f38f505b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f38f53b2000)

It's using -lz within the build, so I believe all uses are of the static library.

Hmm, I'd be prone to avoid using that switch then, as I'd prefer to avoid using static libraries if possible.

According to my build logs, it's 'cc1' and 'cc1plus' that use libz. Jeremy, could you check whether or not those 2 binaries (in /usr/lib/gcc/i686-pc-linux-gnu/4.5.0 on my box) are linked to a dynamic zlib library on your '--with-system-zlib' build please?

Thanks,

Matt.

[Jeremy Huntwork]

Replying to matthew@…:

Hmm, I'd be prone to avoid using that switch then, as I'd prefer to avoid using static libraries if possible.

I'm not sure I understand your reasoning here. If it builds an internal copy of zlib and uses that, then it's definitely using static anyway.

According to my build logs, it's 'cc1' and 'cc1plus' that use libz. Jeremy, could you check whether or not those 2 binaries (in /usr/lib/gcc/i686-pc-linux-gnu/4.5.0 on my box) are linked to a dynamic zlib library on your '--with-system-zlib' build please?

Good call. As it turns out, it is dynamically linking to zlib:

 ldd /usr/lib64/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1
	linux-vdso.so.1 =>  (0x00007fff4dbad000)
	libcloog.so.0 => /usr/lib64/libcloog.so.0 (0x00007f0e7e9a0000)
	libppl_c.so.2 => /usr/lib64/libppl_c.so.2 (0x00007f0e7e45a000)
	libppl.so.7 => /usr/lib64/libppl.so.7 (0x00007f0e7e196000)
	libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x00007f0e7df92000)
	libmpc.so.2 => /usr/lib64/libmpc.so.2 (0x00007f0e7dd7f000)
	libmpfr.so.4 => /usr/lib64/libmpfr.so.4 (0x00007f0e7db28000)
	libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f0e7d8bd000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f0e7d6b9000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f0e7d4a1000)
	libelf.so.1 => /usr/lib64/libelf.so.1 (0x00007f0e7d28c000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f0e7cf30000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f0e7cc2b000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f0e7c9a9000)
	libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f0e7c794000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f0e7ebc2000)

So it appears that it uses zlib statically in some spots through the build and then dynamically for some installed binaries.

[Matthew Burgess]

Replying to jhuntwork:

Replying to matthew@…:

Hmm, I'd be prone to avoid using that switch then, as I'd prefer to avoid using static libraries if possible.

I'm not sure I understand your reasoning here. If it builds an internal copy of zlib and uses that, then it's definitely using static anyway.

Maybe "I'd prefer to avoid using static system libraries if possible." i.e. if we're going to use a system library we'd benefit most by using the dynamic libraries. That way, if there's a security issue with zlib, in this case, we'd be able to fix that vulnerability system-wide by upgrading/patching Zlib. If GCC uses its internal zlib, or the system's static zlib, we'd have to recompile GCC after fixing the relevant copy of zlib.

Good call. As it turns out, it is dynamically linking to zlib:

Great, in which case I think this is pretty much a no-brainer then!

So it appears that it uses zlib statically in some spots through the build and then dynamically for some installed binaries.

Not sure what you mean here. I only found 4 references to '-lz' in my build logs, referring to the binaries 'cc1-dummy', 'cc1', 'cc1plus-dummy', 'cc1plus'.

[Jeremy Huntwork]

Replying to matthew@…:

Maybe "I'd prefer to avoid using static system libraries if possible." i.e. if we're going to use a system library we'd benefit most by using the dynamic libraries. That way, if there's a security issue with zlib, in this case, we'd be able to fix that vulnerability system-wide by upgrading/patching Zlib. If GCC uses its internal zlib, or the system's static zlib, we'd have to recompile GCC after fixing the relevant copy of zlib.

Yes, thanks for clarifying. And yes, that all sounds reasonable.

Not sure what you mean here. I only found 4 references to '-lz' in my build logs, referring to the binaries 'cc1-dummy', 'cc1', 'cc1plus-dummy', 'cc1plus'.

Hmm. I'll need to check my logs again then... Unfortunately, seems I'll actually have to produce some new logs... will do so in a bit.

[bdubbs@…]

My version according to the book right now is:

 ldd /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1
        linux-vdso.so.1 =>  (0x00007ffff23ff000)
        libmpc.so.2 => /usr/lib/libmpc.so.2 (0x00007fe41362b000)
        libmpfr.so.4 => /usr/lib/libmpfr.so.4 (0x00007fe4133d3000)
        libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007fe413167000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007fe412f63000)
        libc.so.6 => /lib/libc.so.6 (0x00007fe412c07000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe41383e000)

Looking through the source for zlib.h and eliminating things like the zlib directory itself and makefiles, I have:

• gcc/lto-compress.c
• cc/java/jcf-io.c
• libjava/java/util/zip/natDeflater.cc

That's it. Looking at gcc/lto-compress.c, it calls deflateInit, deflate, deflateEnd, inflateInit, inflate, inflateEnd one time each.

To me using the current version within gcc (1.2.3) or an external version doesn't make any difference. I'll go along with whatever Matt prefers.

[houhongxun]

Replying to jhuntwork:

Replying to hohoxu_hao115:

According to gcc documentation, the '--with-system-zlib' option is java specific option, it is only used by building libgcj. Does it have effect on other targets?

Where exactly are you seeing that? Anyway, it's definitely using zlib in the build without libgcj and it tries to build zlib internally without that switch. Check recent build logs from LFS, you should see what I mean.

I read this:​http://gcc.gnu.org/install/configure.html And according to bruce's investigation, zlib is only used by java and lto(gcc's link runtime optimization, a new feature added in gcc-4.5, depends on libelf). we don't use java and lto in lfs.

[Matthew Burgess]

Fixed in r9344.