Subject: Re: Request for help: GCC guru answers to GCC 3.3 internals question/problem (try #2)
To: Todd Vierling <tv@pobox.com>
From: Joel Baker <lucifer@lightbearer.com>
List: tech-toolchain
Date: 05/20/2003 00:53:27
--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 20, 2003 at 12:16:16AM -0400, Todd Vierling wrote:
> On Fri, 16 May 2003, Joel Baker wrote:
>=20
> : For various reasons (not really related to NetBSD), I need to make sure
> : that dynamically linked binaries get an explicit NEEDED statement in the
> : ELF object for libc, in all cases
>=20
> : (IE, I can't ensure that I just add -lc explicitly to all compiles).
>=20
> This will make other things blow chunks, such as crt0.  If you're invoking
> "ld" directly, the correct solution is "don't do that" (or at least tell =
us
> why you are doing that 8-).
>=20
> But in any case....

Because later automated systems that detect library dependancies look for
it (for various reasons, just using 'ldd' isn't feasible, unfortunately).
I'm not invoking ld directly, only through gcc (and, to be more specific,
gcc 3.3).

The actual requirement is "'gcc -o foo foo.c' must produce an ELF binary
with a NEEDED entry of 'libc.so.12' or equivalent" for values of 'foo'
involving reasonably normal binaries.

As far as I can tell, anything explicitly linked with -l<bar> will show
up, including libc; the problem is that since the tools were developed on
Linux, originally, and are quite extensive, it isn't feasible to just say
"well, pass -lc to the compiler call".

> : Trying to change LIB_SPEC in gcc/config/netbsd*.h to have a stanza for
> : '%{shared:-lc}' builds the compiler fine, but causes the testsuite to s=
tart
> : blowing massive chunks;
>=20
> First verify that you can do "cc -v -shared -o libfoo.so ... -lc" without
> blowking chunks.  Save the -c output, if it works, because you'll need to
> compare it to the below.
>=20
> Then try removing the %{!shared:...} wrapper around -lc in LIB_SPEC and s=
ee
> how the output of "cc -v -shared -o libfoo.so ..." (note no -lc) compares=
 to
> the output saved above.  The positioning of -lc in the ld link line may be
> of importance here.

I'll try this.

> : in 3.2, this happened in basic_string template instantiation;
>=20
> Are you using a shared libstdc++?  (This is important to know, as it may
> indicate problems elsewhere, possibly related to crtbeginS/crtendS.)

Shared libstdc++, and possibly a shared libgcc1 (I'm still not entirely
sure that's relevant, or used, in this case; I know that it's generated on
all of the other platforms).
--=20
***************************************************************************
Joel Baker                           System Administrator - lightbearer.com
lucifer@lightbearer.com              http://users.lightbearer.com/lucifer/

--tKW2IUtsqtDRztdT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+ydDn13sEBdj5qMURAmA1AJ0SXHA6ql0kjNPiOC7VC5Q4VyB/ggCgt7x1
n4zbo8bc+nWvfkGMmXSX4CU=
=9Gzj
-----END PGP SIGNATURE-----

--tKW2IUtsqtDRztdT--