Hi Brian,

On Jul 31 11:55, Corinna Vinschen wrote:
> On Jul 28 14:50, Brian Inglis wrote:
> > On 2017-07-26 13:34, Corinna Vinschen wrote:
> > > On Jul 26 11:27, Brian Inglis wrote:
> > >> On 2017-07-26 04:49, Corinna Vinschen wrote:
> > >>> On Jul 25 14:13, Brian Inglis wrote:
> > >>>> On 2017-07-25 12:52, Corinna Vinschen wrote:
> > >>>>> Well... on *third* thought, targets may redefine time_t via redefining
> > >>>>> _TIME_T_.  Targets not doing that will get long, so yeah, you're right.
> > >>>>> Maybe it is safer to use always strtoll_l and just break this down to
> > >>>>> time_t on the way.
> > >>>>
> > >>>> My concern has always been do all newlib RTEMS targets support long
> > >>>> long, even if same as long, and stroll_l?
> > >>>
> > >>> Yes.  The long long functions are not excluded like we do with long
> > >>> double stuff.
> > >>>
> > >>>> Trying to build standalone or combined STC for this with changed strptime.c
> > >>>> ld/collect2 fails to resolve ...global_locale.
> > >>>
> > >>> Yeah, it's an internal function to newlib.  You need to include
> > >>> libc/locale/setlocale.h somehow to accomplish that.  STC from Cygwin
> > >>> userspace will do.
> > >>
> > >> Not doing it for me: that's why I asked if there were undistributed locale
> > >> changes in the tree, and maybe in a dev snapshot?
> > > 
> > > No, it's an *internal* function, it doesn't get exported.  There's no
> > > (easy) way to build strptime.c outside the newlib tree as part of the
> > > lib.  That's why I said a userspace STC is enough.  Don't try to build
> > > strptime.c as standalone.  Just build it as part of newlib/Cygwin and
> > > test it from userspace by calling it.
> > 
> > Finally got all the prereqs installed and a clean build.
> > My configure uses the default prefix /usr/local, which is at the head of my
> > personal path.
> > Is that enough for a test build, and how do I do that, or do I have to replace
> > the current release, with configure --prefix=/, make install into /bin/?
> 
> The configured paths don't matter for the Cygwin DLL itself, and your
> patch doesn't change any headers or entry points of the lib.  So just exit
> from Cygwin, replace the DLL in Explorer, start a shell and go ahead.

any news on the patch?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat