This is the mail archive of the cygwin-apps@cygwin.com 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)


On Fri, 25 Jul 2003, Nicholas Wourms wrote:

> cgf@redhat.com 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.

> 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...

> Cheers,
> Nicholas

Hope the above is not misleading.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton


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