This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Porting GNU C Library
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at systemhalted dot org>
- Cc: "ABELS\, GARY" <ga1534 at att dot com>, "libc-help\@sourceware.org" <libc-help at sourceware dot org>
- Date: Sat, 01 Jun 2019 13:31:24 +0200
- Subject: Re: Porting GNU C Library
- References: <49D0BC30748D514597E1495CD4C8EB602D5C86EB@MISOUT7MSGUSRDE.ITServices.sbc.com> <CAE2sS1jHWmzQ--VFx18cNh9nu=O=TKWC+-fQQ7-wUy463DMKtA@mail.gmail.com>
* Carlos O'Donell:
> On Thu, May 30, 2019 at 12:02 PM ABELS, GARY <ga1534@att.com> wrote:
>> I am interested in porting to SunOS 5.10 Generic_150400-64 sun4v sparc SUNW,Sun-Fire-T200.
>
> Gary,
>
> Is there any reason you are interested in porting glibc to SunOS? Is
> there any reason you need to use SunOS?
>
> Depending on your requirements the simpler scenario is often to port
> the application that needs glibc to GNU/Linux and use an existing
> distribution like Debian, Ubunutu, Fedora, SUSE, etc.
Have any of these active sparc64 ports? There's a Debian non-release
port, but I'm not sure how viable that is.
Porting glibc to new kernels can be quite tricky. I'm not even sure if
Solaris has a stable kernel interface. Some systems change libc/kernel
interfaces all the time and only support applications dynamically linked
against the libc version that matches the kernel requirements.
If these problems can be solved, then the next matter is making sure
that the port can at least build, which means adding it to
build-many-glibcs.py. If the required kernel headers are proprietary,
then not many glibc contributors will be able to build the configuration
regularly.
Thanks,
Florian