glibc 2.1

glibc 2.1

[Alex deVries]

Has anyone started work on glibc 2.1 for mips{eb|el}?  I'd like to start
on a port of Red Hat 6.0 ofor mipseb and mipsel.

- A

-- 
Alex deVries, puffin on LinuxNet.
Linux on HP PA RISC. The final frontier.

Re: glibc 2.1

[Ulf Carlsson]

Hi Alex,

> Has anyone started work on glibc 2.1 for mips{eb|el}?  I'd like to start
> on a port of Red Hat 6.0 ofor mipseb and mipsel.

I tried to do this some time ago, but I never finished it. I have heard that
Ralf has done some work here, maybe he can share his work with us. I've tried
to persuade him to do this before without any success. I'd like to have these
patches as well so that I may continue working with the D word. :-)

Well, if we can't get these patches I'd like to help you with the porting work
for glibc 2.1.

- Ulf

Re: glibc 2.1

[Andreas Jaeger]

>>>>> Ulf Carlsson writes:

Ulf> Hi Alex,
>> Has anyone started work on glibc 2.1 for mips{eb|el}?  I'd like to start
>> on a port of Red Hat 6.0 ofor mipseb and mipsel.

Ulf> I tried to do this some time ago, but I never finished it. I have heard that
Ulf> Ralf has done some work here, maybe he can share his work with us. I've tried
Ulf> to persuade him to do this before without any success. I'd like to have these
Ulf> patches as well so that I may continue working with the D word. :-)

Ulf> Well, if we can't get these patches I'd like to help you with the porting work
Ulf> for glibc 2.1.

At the end of last year I tried to integrate Ralf's patches into
glibc 2.1.  A number of patches went into the glibc tree but some
problems are still open.  Ralf can certainly better comment this from
the mips side, I'm just a glibc developer without access to any mips
machine who used a cross compiler:
- glibc 2.1 needs symbol versioning but there're no binutils for mips
  that support symbol versioning
- there're some problems with the way glibc handles PIC which leads to 
  problems on mips.
- the system (mips) dependend part of the dynamic linker has to be
  updated.
- some minor discrepancies between the kernel headers in the official
  kernel and the glibc headers.  Ralf and I updated most (all?) but
  somebody should recheck this.

IMO the first two problems to tackle is to get it running at all,
meaning to fix the PIC problems (that's already planned by the glibc
folks for 2.2) and the dynamic linker.  Without symbol versioning you
loose binary compatibility with older and newer versions of glibc.
Therefore the binutils have to be fixed to use glibc 2.1.

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: glibc 2.1

[Ralf Baechle]

On Thu, Apr 15, 1999 at 04:53:21PM +0200, Andreas Jaeger wrote:

> At the end of last year I tried to integrate Ralf's patches into
> glibc 2.1.  A number of patches went into the glibc tree but some
> problems are still open.  Ralf can certainly better comment this from
> the mips side, I'm just a glibc developer without access to any mips
> machine who used a cross compiler:
> - glibc 2.1 needs symbol versioning but there're no binutils for mips
>   that support symbol versioning
> - there're some problems with the way glibc handles PIC which leads to 
>   problems on mips.

Fixed in my patches.

> - the system (mips) dependend part of the dynamic linker has to be
>   updated.

Done in my patches modulo debugging.

I've fixed several problems in H.J. Lu's binutils 2.9.1.0.15.  Symbol
version is still not working and building GNU libc still results in
amazing amounts of assertion messages in bfd/elf32-mips.c; building
kernels is broken as well.

> - some minor discrepancies between the kernel headers in the official
>   kernel and the glibc headers.  Ralf and I updated most (all?) but
>   somebody should recheck this.
> 
> IMO the first two problems to tackle is to get it running at all,
> meaning to fix the PIC problems (that's already planned by the glibc
> folks for 2.2) and the dynamic linker.  Without symbol versioning you
> loose binary compatibility with older and newer versions of glibc.
> Therefore the binutils have to be fixed to use glibc 2.1.

While that is correct for a production version we probably can temporarily
bump the major version number for development purposes and work on
both binutils and GNU binutils in parallel.

The latest versions I've worked on are GNU libc version 2.0.109 and
binutils 2.9.1.0.15.  I've put my patches on linus.linux.sgi.com into
/pub/linux/mips/test/{binutils-2.9.1.0.15.diff.gz,glibc-2.0.109.diff.gz}.

Have fun ;-)

  Ralf

glibc 2.1

[Michael Quicquaro]

Hello all,

I have built dpdk (and pktgen-dpdk) on a couple RHEL 6.4 servers.  This
distribution comes with glibc 2.12

I have read that glibc 2.7 is needed for coreset() functionality.  My
testing, at the moment, only requires one cpu core.

I assume that upgrading to glibc 2.7 would probably break many of the
executables on this system.

The build seemed to work fine.

Do you think that there are any adverse effects of using a dpdk that was
built with glibc 2.1 in this case?

- Mike

Re: glibc 2.1

[Richardson, Bruce]

The Intel DPDK should work fine on RHEL 6.4. There should be no need to update your glibc, since this is subversion 12 (> 7), rather than 1.2.
Regards,
/Bruce 

> -----Original Message-----
> From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Michael Quicquaro
> Sent: Thursday, November 21, 2013 6:26 PM
> To: dev-VfR2kkLFssw@public.gmane.org
> Subject: [dpdk-dev] glibc 2.1
> 
> Hello all,
> 
> I have built dpdk (and pktgen-dpdk) on a couple RHEL 6.4 servers.  This
> distribution comes with glibc 2.12
> 
> I have read that glibc 2.7 is needed for coreset() functionality.  My testing,
> at the moment, only requires one cpu core.
> 
> I assume that upgrading to glibc 2.7 would probably break many of the
> executables on this system.
> 
> The build seemed to work fine.
> 
> Do you think that there are any adverse effects of using a dpdk that was
> built with glibc 2.1 in this case?
> 
> - Mike

Re: glibc 2.1

[Michael Quicquaro]

Right, thanks.  I had a little brain fart.


On Fri, Nov 22, 2013 at 4:42 AM, Richardson, Bruce <
bruce.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

> The Intel DPDK should work fine on RHEL 6.4. There should be no need to
> update your glibc, since this is subversion 12 (> 7), rather than 1.2.
> Regards,
> /Bruce
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Michael Quicquaro
> > Sent: Thursday, November 21, 2013 6:26 PM
> > To: dev-VfR2kkLFssw@public.gmane.org
> > Subject: [dpdk-dev] glibc 2.1
> >
> > Hello all,
> >
> > I have built dpdk (and pktgen-dpdk) on a couple RHEL 6.4 servers.  This
> > distribution comes with glibc 2.12
> >
> > I have read that glibc 2.7 is needed for coreset() functionality.  My
> testing,
> > at the moment, only requires one cpu core.
> >
> > I assume that upgrading to glibc 2.7 would probably break many of the
> > executables on this system.
> >
> > The build seemed to work fine.
> >
> > Do you think that there are any adverse effects of using a dpdk that was
> > built with glibc 2.1 in this case?
> >
> > - Mike
>