Mail Archives: cygwin/2002/11/09/22:02:32
--=-OvMIatnXgAK0MaLzI03D
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Sun, 2002-11-10 at 12:34, Charles Wilson wrote:
> I don't know if we have enough information in the auto_export() context.=20
> Here's what I found doing a simple link [ printing=20
> abfd->my->archive->filename when in auto_export() ]. Each line=20
> corresponds to a given symbol under consideration for auto-export (not=20
> shown)
>=20
> abfd->my_arc->filename=3D/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
ok, so it is /usr/lib, and has no '..''s in the path.
> abfd->my_arc->filename=3D/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../lib=
cygwin.a
And this one, as you say, would need normalising.
=20
> First, how does ld know about gcc's built in path=20
> /usr/lib/gcc-lib/i686-pc-cygwin/3.2/ ?.
That would be an optional issue. It is in /usr/lib though. So, I'd
consider it a sub-path match.
> Second, we'd have to=20
> canonicalize /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../ to determine=20
> if it corresponded to the "system path" /usr/lib/ (which would be a nice=20
> trick on a cross-compiler setup)
We could simply not match paths with '..' as an initial trial.
> The good news is that almost everything in /usr/lib/w32api/ is an import=20
> lib, so those symbols are not re-exported anyway...exceptions:
>=20
> /usr/lib/w32api/libdxguid.a: x86 archive static
> /usr/lib/w32api/liblargeint.a: x86 archive static
> /usr/lib/w32api/libscrnsave.a: x86 archive static
> /usr/lib/w32api/libscrnsavw.a: x86 archive static
>=20
> So at least we needn't worry overmuch about ../w32api/..
>=20
> But, I think it's overkill to define "system libs that should not be=20
> re-exported" as "anything in /usr/lib" or something similarly broad.
Why? *anything* in /usr/lib is able to be linked to from multiple
packages. If one package creates a dll from there, then we will get this
problem. We're currently *manually* excluding *how many* libs? fortran.
gcc. stdc++. cygwin. And thats from memory. Do we want to hack ld when a
test g++-3.3 is released? IMO No.
> Perhaps the "regular" gcc-supplied system libs (libgcc, libstdc++,=20
> libsupc++, etc) can be explicitly rejected by name from within the=20
> ld.exe code, but additional **platform** dependent static runtime=20
> libraries like libmingwex, etc should actually be controlled by the=20
> platform-specific gcc spec file, using
>=20
> --exclude-libs libmingwex.a,libcygwin.a,...
I think that nothing specific to gcc should be handled by ld. If gcc
knows about file foo, be that mingw specific, or c++ specific, it should
tell ld to do the right thing. This centralises the knowledge about the
exceptions.
> -----------------------------------------------------------------
>=20
> On the other hand, we're really arguing about a problem that hasn't bit=20
> anyone yet. By excluding the main (gcc) static runtime libs from=20
> re-export, and the main (platform) static runtime libs like libmingw32=20
> libmingwex from re-export -- we pretty much cover all the important bases=
.
True. My suspicion though is that as folk find .dll's easier to build,
with the libtool dll support hitting mainstream as of(?1.4?) it will be
more common to link against something. Let me give you another contrived
example:
I create a static lib foo (say readline for arguments sake). It gets
installed into /usr/local/lib.
Someone else makes a library bar depending on foo. This library is a
.dll. It gets installed into /usr/local/lib.
Every app that links against both foo and bar (and if bar is a libtool
library, it will suck in foo for us) will get duplicate symbols.
> Anything else is obviously a corner case, since it hasn't bit anyone yet=20
> -- and the fix is for that person to specifically exclude the static lib=20
> that "bit" them by using --exclude-libs.
That is *a* fix. Why doesn't it bite folk on linux or BSD? Why should it
bite anyone here when *we can make ld do the right thing*.
We only want to export static archive symbols when=20
a) it's a convenience library,=20
b) we are creating a forwarding library for the archive.
In a) the library won't be in /usr/lib unless you are building from a
subdir of that (unlikely!).
In b) the library *may* be in /usr/lib, so we can allow a --include-libs
flag to override the heuristic (and I think we already have one, no?)
> The problem here, is that because of our packaging of gcc-2, we're=20
> missing the names of the (gcc) static runtime libs for that "package".=20
> Plus, libmingwex is another (platform) static runtime lib that we're=20
> missing -- but it was only recently added to the mingw "platform".
The problem is that dll's are non intuitive, and our automagic support
is incomplete :}. There's a refactoring smell, uhmm, 'Shotgun Surgery'.
When we change the names of common system libraries, we have to change
ld as well. That's plain wrong.
> (I raised the issue of libtextmode & friends, but since the only=20
> "re-exportable" symbol in them is _cygwin_premain0 which is already=20
> excluded by autofilter_symbolprefixlist, there's no problem there.)
>=20
> I think the (newly revised) attached patch is sufficient, and is general=20
> enough to be submitted for inclusion in the mainline binutils CVS.
I think that the revised patch is fine, along the existing approach, but
the existing approach is much less than optimal.
Rob
--=20
---
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
---
--=-OvMIatnXgAK0MaLzI03D
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQA9zcw7I5+kQ8LJcoIRAm5HAJ0QYJo4ZuPQM00SRQbu2R0Re9s1WQCfWFU5
NJlcpUtz4pbA2jTnjsQVOOk=
=Ti5r
-----END PGP SIGNATURE-----
--=-OvMIatnXgAK0MaLzI03D--
- Raw text -