1.5.0 - showstopper?

[Charles Wilson]

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