1.5.0 - showstopper?

[Charles Wilson]

> On Sun, Jul 06, 2003 at 06:24:58PM -0400, Charles Wilson wrote:
>>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?
> 
> I think I've fixed the cygwin magic that creates the aliased functions
> such that replaced objects like "open" and "fopen" now look like other,
> normal import objects.  It seems to fix this problem in a simple test
> case, anyway.
> 
> I'm generating a new snapshot.  Could you try the DLL and import library
> from the snapshot when it shows up and see if it rectifies this behavior?

Yes, that corrected the problem.

But it shouldn't, darnit.

New import lib:

          U __imp___fopen64
00000000 I __imp__fopen
00000000 T _fopen
00000000 T __fopen
00000000 I __imp___fopen
00000000 T __fopen64
00000000 I __imp___fopen64

Old import lib:

          U __imp___fopen64
00000000 T _fopen
00000000 T __fopen
00000000 I __imp___fopen
00000000 T __fopen64
00000000 I __imp___fopen64

The only difference is that the new implib contains an __imp__ symbol 
for the redirected symbol...

wait...

That means that when linking, the first "match" will be __imp__fopen, 
and that of course is excluded from re-export by the "__imp__" filter. 
It's still a little fragile(*) since the original _fopen symbol is still 
there and COULD be re-exported if anyone ever tried to link directly to it.

(*) but, the same is true for EVERY symbol in an import lib, so.. no 
harm, no foul.

So, okay...

But I still think libcygwin.a should be added to the exlude libs list.  :-)

--Chuck

Now I'm going to bed...