From: Ralf Baechle <ralfb@cthulhu.engr.sgi.com>
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>,
Ulf Carlsson <ulfc@bun.falkenberg.se>
Cc: Alex deVries <adevries@engsoc.carleton.ca>,
SGI Linux <linux@cthulhu.engr.sgi.com>
Subject: Re: glibc 2.1
Date: Thu, 15 Apr 1999 15:07:18 -0700 [thread overview]
Message-ID: <19990415150718.B524@uni-koblenz.de> (raw)
In-Reply-To: <u84smi7x5q.fsf@arthur.rhein-neckar.de>; from Andreas Jaeger on Thu, Apr 15, 1999 at 04:53:21PM +0200
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
next prev parent reply other threads:[~1999-04-15 22:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-04-15 1:39 glibc 2.1 Alex deVries
1999-04-15 7:10 ` Ulf Carlsson
1999-04-15 14:53 ` Andreas Jaeger
1999-04-15 22:07 ` Ralf Baechle [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-11-21 18:25 Michael Quicquaro
[not found] ` <CAAD-K951DjgTWDXBKACxyimP6j_vM-XN7hh8pFqfU217-6J3bg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-22 9:42 ` Richardson, Bruce
[not found] ` <59AF69C657FD0841A61C55336867B5B01A975AA5-kPTMFJFq+rELt2AQoY/u9bfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2013-11-22 15:57 ` Michael Quicquaro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19990415150718.B524@uni-koblenz.de \
--to=ralfb@cthulhu.engr.sgi.com \
--cc=adevries@engsoc.carleton.ca \
--cc=aj@arthur.rhein-neckar.de \
--cc=linux@cthulhu.engr.sgi.com \
--cc=ulfc@bun.falkenberg.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.