This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TEST: patch-2.5.8-4 (package maintainers, please note)

Igor Pechtchanski wrote:
> On Fri, 25 Jul 2003, Nicholas Wourms wrote:
> > wrote:
> >
> > > On Thu, Jul 24, 2003 at 06:53:59PM -0700, David Rothenberger wrote:
> > >
> > >>Christopher Faylor wrote:
> > >>
> > >>>[snip]
> > >>>I appreciate the research *very* much but this is not the appropriate
> > >>>mailing list for this.
> > >>>
> > >>>I wouldn't bother to comment but I would hate to see a bunch of "This is
> > >>>just for Corinna for when she gets back" messages here in the next N
> > >>>weeks.
> > >>
> > >>Sorry about the mistake.  I just wanted to tie the thread started here,
> > >>which
> > >>reported the problem and to which Corinna responded, with my research on
> > >>the main list.
> > >>
> > >>I do understand that problem reports go to the main list, even for apps.
> > >
> > >
> > > Actually, now that I've generated a fix for the problem, as it turns
> > > out, this *is* an issue for cygwin-apps.
> > >
> > > Fixing the problem requires generating a new DLL with a new export --
> > > fdopen64.  If there are any packages built which use fdopen they could
> > > conceivably fail in the same manner as patch.  Sigh.
> > >
> > > This means that we may have to go through the "rebuild packages" exercise
> > > again for cygwin 1.5.1.  I will release a 1.5.1 version of cygwin shortly
> > > after generating a snapshot.
> > >
> >
> > I'm still working on understing how you are handling the 64 bit exports,
> Nicholas,
> My guess is you're not asking about how the 64-bit symbols are exported
> (as that's pretty obvious), but, rather, how the backward compatibility is
> maintained.  If I may attempt an explanation...  AFAIU, the newlib headers
> redefine the standard names to point to their 64-bit counterparts, so when
> your program calls fdopen, it will be linked to fdopen64 instead, and
> that's what it's going to look for in the DLL when it's loaded.  The DLL
> still exports the old fdopen under the original name, so old applications
> looking for fdopen get the original version.

I don't think it's done through newlib headers.  That was my thought
initially, too, when I was investigating the patch problem, but I did
run gcc -E on some source and the result still called fdopen.

I think the magic is in libcygwin.a.  It contains an indirect reference,
so when code is linked against it, fdopen references get redirected to
fdopen64.  cygwin1.dll still contains the original fdopen, so apps that
have not been recompiled will continue to use it (since the indirect
reference is in the library, not the dll).
> > but that's my problem.  In the meantime, if we want to apply your newlib
> > patch locally, how are you planning to export fdopen64() and
> > fdopen64_r() from cygwin.din?  Are the any further modifications needed
> > to the winsup/cygwin source to support your implimentation?
> At a guess, you patch the headers, and add an "_fdopen64 = fdopen64" line
> in cygwin.din after "^fdopen$".  This is the "obvious" part mentioned
> above.  Can't think of anything else you'd need to do...

Update NEW_FUNCTIONS in to add the indirect reference.

> > Cheers,
> > Nicholas
> Hope the above is not misleading.
>         Igor


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]