This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
1.5.0 - showstopper?
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin-developers at cygwin dot com
- Date: Sun, 06 Jul 2003 18:24:58 -0400
- Subject: 1.5.0 - showstopper?
I just downloaded cygwin-1.5.0 [ sorry, Chris -- I cheated. :-) ] to try
to do a test build of zlib. While it compiles okay, and runs, there's
one teeny little problem.
It seems to be re-exporting certain cygwin1.dll symbols, which it
certainly did not do before. I'm wondering if the 32,64,undecorated
symbol magic is confusing binutils' "exclude symbols from" code...
With zlib, I'm getting this "extra" symbol re-exported:
[ 20] fopen
Note that cygwin1.dll (1.5.0) contains
[ 200] _fopen
[ 201] _fopen64
[ 812] fopen
I also tried to build popt, but ran into the same problem -- with
certain other symbols:
[ 1] geteuid
[ 2] getuid
[ 3] lseek
[ 4] open
What's weird is that other symbols, like 'close', that are imported from
cygwin1.dll are NOT re-exported. That's why I think that only the
symbols that had the 32/64 magic are causing a problem. But I could be
wrong -- are all of [ fopen geteuid getuid lseek open ] affected by the
32/64 changes?
Now, IF I am right the problem may ACTUALLY be in binutils.
pe-dll.c(auto_export) contains this code:
/* We should not re-export imported stuff. */
if (strncmp (n, "_imp__", 6) == 0)
return 0;
But, thanks to the new magic in the headers, is it possible that certain
symbols (like open, fopen, etc) do not get listed as "_imp__foo" in the
import lib, but are actually thunked to "foo" in the static portion of
the import lib?
That would really fool binutils -- and like all of the other symbols
that are in the static portion of libcygwin.a, we need to add them to
pe-dll.c's autofilter_symbollist.
--Chuck