POSIX Compilance- #2966, GSoC Project 2019

Vaibhav Gupta vaibhavgupta40 at gmail.com
Mon Mar 18 15:07:09 UTC 2019


On Mon, Mar 18, 2019 at 4:40 AM Gedare Bloom <gedare at rtems.org> wrote:

> On Sun, Mar 17, 2019 at 2:24 PM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Sun, Mar 17, 2019, 12:45 PM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
> wrote:
> >>
> >> I did cloned RTEM source, newlib and rtems-libbsd.
> >> Kept them in same folder so as to get easy with 'grep' and 'find'.
> >>
> >> $ ls
> >> newlib-cygwin  rtems  rtems-libbsd
> >>
> >> $ grep -r grantpt ./
> >> ./newlib-cygwin/winsup/doc/posix.xml:    grantpt
> >> ./newlib-cygwin/winsup/doc/posix.xml:return -1 and set errno to
> ENOSYS.  <function>grantpt</function> and
> >> ./newlib-cygwin/winsup/cygwin/tty.cc:grantpt (int fd)
> >> ./newlib-cygwin/winsup/cygwin/libc/bsdlib.cc:      grantpt (master);
> >> ./newlib-cygwin/winsup/cygwin/common.din:grantpt NOSIGFE
> >> ./newlib-cygwin/winsup/cygwin/include/cygwin/stdlib.h:int grantpt (int);
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-1997:    *
> cygwin.din: srandom, ptsname, grantpt, unlockpt - new exports.
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-1997:
> (grantpt): new
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-2001:    *
> tty.cc (grantpt): Fix definition.
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-2011:    *
> tty.cc (grantpt): Check for valid fd.
> >> ./newlib-cygwin/newlib/ChangeLog-2015:    * libc/include/stdlib.h: add
> ptsname, grantpt, unlockpt to cygwin
> >> ./rtems/testsuites/psxtests/Makefile.am:## lib_a_SOURCES +=
> psxhdrs/stdlib/grantpt.c              See ticket #3645
> >> ./rtems/testsuites/psxtests/psxhdrs/stdlib/grantpt.c: *  @brief
> grantpt() API Conformance Test
> >> ./rtems/testsuites/psxtests/psxhdrs/stdlib/grantpt.c:    return_value =
> grantpt(fildes);
> >> .
> >> .
> >> As I analyzed the output, I find no file that contains implementation
> of 'grantpt()', means ticket #3645(https://devel.rtems.org/ticket/3645)
> still needs to be addressed.
> >> But then how this method is used in rtems testsuites?. (refer last two
> lines of output for grep command).
> >> .
> >> Am I doing something wrong? or I am missing something.
> >
> >
> > You haven't done anything wrong.
> >
> > The grantpt() method is in a winsup subdirectory which indicates it is a
> Cygwin specific implementation.
> >
> > The psxhdrs test just checks that the prototype us right in the header
> file.
> >
> > All said, I don't know if grantpt makes sense on RTEMS or not. That's a
> different discussion.
> >
> >>
> >> Thanks
> >> Vaibhav Gupta
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Mar 8, 2019 at 5:31 AM Joel Sherrill <joel at rtems.org> wrote:
> >>>
> >>> I'm about to head home so not going to dig into each of those but I
> >>> will point out for GSoC, we need to get you where you can answer
> >>> these questions yourself.
> >>>
> >>> 1) clone the newlib (sourceware.org/newlib) source, RTEMS source, and
> >>>     rtems-libbsd source. rtems-libbsd is the source for networking
> APIs.
> >>> 2) use "grep -r" (recursive grep) and find (ex: find . -name "XXX") to
> help you
> >>>     find implementations.
> >>>
> >>> For #3676, RTEMS supports aio but aio.h is one of only a handful of
> POSIX
> >>> .h files in RTEMS and not in newlib. That's why the Google Code-In
> student
> >>> couldn't find it in newlib. Just scanning the cpukit/include, I see 3
> POSIX .h
> >>> files which could be moved to newlib. This is worth discussing on
> devel@
> >>>
> >>> For the rest, I think they are still open to be implemented. Now
> whether the
> >>> method makes sense or not on RTEMS or requires more infrastructure than
> >>> a simple method to be added is something to determine on a case by case
> >>> basis.
> >>>
> >>> --joel
> >>>
> >>> On Thu, Mar 7, 2019 at 5:51 PM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
> wrote:
> >>>>
> >>>> It will be very helpful to know the current status of the following
> tickets, and if I can choose sub-tasks from them, for GSoC project.
> >>>>
> >>>> .
> >>>> #3676 - Add support for aio.h
> >>>> .
> >>>> #3642 - Add iswalnum(), iswalpha() ... (and 18 others) to <wchar.h>
> header
> >>>> .
> >>>> #3371 - Add dirfd() and fdopendir() methods in dirent.h
> >>>> .
> >>>> #3656 - Function prototypes for posix_fadvise() and posix_fallocate()
> missing in <fcntl.h> header file
> >>>> .
> >>>> #3652- Add support for sys/resource.h method - getpriority
> >>>> .
> >>>> #3653 - Add support for sys/resource.h method - getrlimit
> >>>> .
> >>>> #3654 - Add support for sys/resource.h method - setpriority
> >>>> .
> >>>> #3655 - Add support for sys/resource.h method - setrlimit
> >>>> .
> >>>> #3644 - Add support for stdlib.h method - getsubopt
> >>>> .
> >>>> #3645 - Add support for stdlib.h method - grantpt
> >>>> .
> >>>> #3646 - Add support for stdlib.h method - posix_openpt
> >>>> .
> >>>> #3647 - Add support for stdlib.h method - ptsname
> >>>> .
> >>>> #3648 - Add support for stdlib.h method - unlockpt
> >>>> .
> >>>> #3643 - Add support for uchar.h header
> >>>> .
> >>>> #3633 - add getdelim() and getline() to stdio.h
> >>>>
> >>>>
> >>>> Vaibhav Gupta
> >>>>
> >>>>
> >>>>
> >>>> On Thu, 7 Mar, 2019, 9:57 PM Vaibhav Gupta <vaibhavgupta40 at gmail.com
> wrote:
> >>>>>
> >>>>> Hello,
> >>>>> I was exploring open projects and got very much intrested in the
> following ticket:
> >>>>>
> >>>>> #2966 - POSIX Compilance : https://devel.rtems.org/ticket/2966
> >>>>> .
> >>>>> As on the page, the project is divided into multiple sub-tasks. For
> many of them I am not able to find their current status and if enough work
> is left on them to be included as a GSoC project.
> >>>>> .
> >>>>> I would like to know the good combinations of sub-tasks which can
> compile into a good GSoC project under the "POSIX" ticket. I am very much
> interested to take this project. It would be great if someone mentors this
> project, I want to discuss further on this.
> >>>>> .
> >>>>> Also if there are new any new projects which are not mentioned on
> open-projects page? That can be taken up as GSoC project, I would love to
> explore them as well.
> >>>>>
> >>>>> Thankyou
> >>>>> Vaibhav Gupta
> >
>
> I also just wanted to follow-up that for this particular project, you
> will need to be able to build newlib and produce patches for it. I
> suggest you do that during the proposal-writing period. Also, make
> sure your mentor approves all patches that are intended for newlib
> BEFORE you post to their mailing list. We had some issues in the past
> when student patches were not in a great shape, and the newlib folks
> got a little upset about having to do a lot of work that was really
> the responsibility of an RTEMS Mentor.
>
I was trying to build newlib. Even, I had some off-list talk with Aditya
and he
provided me with the link to his blog https://adityupa.wordpress.com/
to help me out.
after runnig the following command, as mentioned in his blog, I got error:

$  autoreconf -fvi
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
configure.ac:33: error: Please use exactly Autoconf 2.64 instead of 2.69.
config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:33: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: /home/varodek/development/rtems/5/bin/autom4te failed with
exit status: 1
autoreconf: aclocal failed with exit status: 1
.
realized, that I should use "Autoconf 2.64" which is not in official
package of my Arch Linux, so i got it build from AUR.
It is inside "/opt/autoconf/2.64/bin" folder.
.
.
But the path for binaries, in newlib-cygwin, is set to rtems:
$  which autoconf
/home/varodek/development/rtems/5/bin/autoconf
.
.
So how I should tackle with this?
-- Should i use ./configure -prefix=/opt/autoconf/2.64/bin ?
                     But then I read the blog further, we need to set the
prefix to {rtems root}/5/bin.
--Or should i replace the "autoconf" in {rtems root}/5/bin, with "2.64"
version?

Thanks Vaibhav Gupta

>
> Gedare
>
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190318/e4088bae/attachment-0002.html>


More information about the devel mailing list