Hi!
I've not build
true ;-)
or run tested the code, so if someone with an eglibc
build-tree around could test the attached patch (against the
glibc-ports tree) that would be pretty helpful
With slight modification in progress.
Petr
--
To UNSUBSCRIBE, email to
or run tested the code, so if someone with an eglibc
build-tree around could test the attached patch (against the
glibc-ports tree) that would be pretty helpful
With slight modification in progress.
There are failures in testsuite,
at least ptsname.c have to be updated too.
Other related
On Thu, 2011-06-09 at 11:05:28 +0200, Petr Salinger wrote:
or run tested the code, so if someone with an eglibc
build-tree around could test the attached patch (against the
glibc-ports tree) that would be pretty helpful
With slight modification in progress.
Thanks for the building and
There are failures in testsuite, at least ptsname.c have to be
updated too.
Ah right, had a small change for that one, but as there seemed to be
more changed needed there I didn't include it, was not suspecting it
would cause test suite failures. :) Attached now.
Although the line with:
p[0]
On Thu, 2011-06-09 at 11:05:28 +0200, Petr Salinger wrote:
There are failures in testsuite, at least ptsname.c have to be
updated too.
Other related functions are:
grantpt(), ptsname(), unlockpt()
Ok, I guess the obvious answer to this is:
There are failures in testsuite, at least ptsname.c have to be
updated too.
Other related functions are:
grantpt(), ptsname(), unlockpt()
The set of changes is in our glibc-bsd SVN.
It passes the testsuite, seems to work inside chroot.
I have not committed it into pkg-glibc SVN due to tie
Hi!
I just got annoyed enough with the kFreeBSD message on the console:
pid %d (%s) is using legacy pty devices%s\n
that I started digging around. This is due to applications using the
old BSD-style pseudo-terminal master device.
I've switched the eglibc getpt(3) and posix_openpt(3) to use
7 matches
Mail list logo
