[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Latest libc6?

>>>>> Michael Shuey writes:
> [...]
Michael> Okay, here's the deal: GNU's libc6 (glibc v2.0) does NOT support sparc boxes.
Michael> At all.  Because of this there is no RedHat 5.0 for sparc (they don't want to
Michael> hack out libc6 to make it work).  The folks at GNU have promised that glibc
Michael> v2.1 will have full sparc compatibility.  However, 2.1 is still in development.
Michael> The Debian people, being the smart, insane little programmers that they are,
Michael> are working with the glibc people on backporting sparc patches from glibc 2.1
Michael> to 2.0, thus making a sparc-capable libc6.

Michael>     A little while ago the GNU folks came out with a big set of changes to
Michael> v2.1, which (once applied to 2.0) produced a version of libc6 that was binary
Michael> _incompatible_ with previous releases (namely those prior to 980301).

That description is not entirly correct.  glibc 2.0.x does not support
sparc boxes - but glibc 2.1 will support sparc (and powerpc,...).  At
the moment glibc 2.1 is not released but development snapshots are
available.  Debian/Sparc uses those development snapshots (and don't
backport anything to glibc 2.0!) with some additional patches.  The
current glibc 2.1 development snapshot identifiy themselves as

In the lifetime of glibc 2.1 snapshots there were AFAIK two binary
incompatibilities with previous 2.1 snapshots introduced.  glibc 2.1
is and will be binary compatible to glibc 2.0.x on the platforms that
are supported for glibc 2.0.x.

The incompatibilities were the problem with _IO_2_1_std{out,err} and
change in exporting names (some new (!) functions are now exported as
version 2.1 and not 2.0 anymore).

Michael> [...]
Michael> 3) gcc:		Works, still a few unsolved bugs (like not being able to
Michael> 		initalize a global file descriptor to stdin or stdout, as is
Michael> 		done in several X programs)

Please read the glibc FAQ (I've appended the relevant section below).
This is not a bug in gcc but in the X program.  Instead of saying:

static FILE *InPtr = stdin;
you have to do initialize InPtr in main.


P.S. Glibc FAQ question 3.9:
3.9.	I get compiler messages "Initializer element not constant" with
	stdin/stdout/stderr. Why?

{RM,AJ} Constructs like:
static FILE *InPtr = stdin;

lead to this message. This is correct behaviour with glibc since stdin
is not a constant expression. Please note that a strict reading of ISO
C does not allow above constructs.

One of the advantages of this is that you can assign to stdin, stdout,
and stderr just like any other global variable (e.g. `stdout =
my_stream;'), which can be very useful with custom streams that you
can write with libio (but beware this is not necessarily
portable). The reason to implement it this way were versioning
problems with the size of the FILE structure.

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

To UNSUBSCRIBE, email to debian-sparc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: