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

eglibc done, too



Finn Thain dixit:

>> There are code generation differences, disabled optimisation passes, etc.
>
>I'm not aware of code generation differences. Can you be more specific?

Sadly, not by a number of quick greps. It’s something I remember from
some time ago, and I *think* I’ve seen cases in gcc’s source where
calls were explicitly not done for cross compilers, but cannot find
them right now. If this has changed in the meantime, even better,
but recently, people discussing pcc vs. gcc still said that pcc uses
the exact same code paths for native vs. cross (actually, that pcc
doesn’t care whether it’s a native or cross compiler), whereas gcc
makes big noise about it.

If this has indeed changed in gcc, I’d like pointers ☺ and will
apologise.

>No, it is like saying that MS Outlook works for most people (or they
>simply wouldn't pay for it). Linux cross-compilers are commercial
>products.

Hrm. Yes. But that still doesn’t make it good (per se), right? ;-)

>You are perhaps too young to remember EGCS, but I do. If it weren't for

I used gcc 2.7.2.3 on Linux 2.0 (before knowing about the LFS book,
I did something similar – before having internet access at home,
actually… I remember downloading a diff between 2.0.36 and .38 and
putting it on floppies, as well as other things missing from the
SuSE 6.1 and Debian slink source CDs which I wanted, and carrying
these home from school), heard about pgcc, seen egcs, and remember
when they said egcs is to become the new gcc.

>Cygnus and later CodeSourcery, the GNU toolchain would certainly not be
>what it is today.

I agree. Others, too (think Ada; wasn’t g++ also added by a third
party and only because of the GPL?). From what little I played with
gpc (which is part of MirBSD’s base gcc too), I think its develop-
ment is also often company-driven.

>All native compilers, cross compilers, emulators and silicon have bugs.

Aye!

>that all architectures started life from emulators and cross-compilers.

They know that, just they want to stop using them after the architecture
has been bootstrapped. I *think* they have been bitten by bugs. Another
of their arguments is that only by compiling natively the hardware is
exercised so that the (silicon) bugs show up, which can then be worked
around. (Maybe it’s also a we-are-better-than-you attitude… with those
guys you never know. They did burn a donated T-Shirt after all *and*
put the video of that into the net…)

>Probably they are also unaware of Plan 9.

I think these two have a love-hate relationship with each other :)

>This does not argue against emulation, it is argues against ONLY emulating
>(the context was the lack of a working physical buildd).

OK, sorry then.

I propose that I now (see below) get cowbuilder going with the packages
I have, then recompile everything needed for a buildd, make a sort of
bootstrap apt repo out of that, and then we can start running a real
buildd on real hardware again. I will make use of Ingo’s boxen during
the process, and upload things like gcc, binutils, etc. to d-p.o after
they pass their respective testsuites on real hardware, if possible.
(I want to upload packages needing a TLS capable kernel only after we
have one of them in the archive _anyway_, so the delay isn’t bad, be-
sides I’ll send appropriate sources.list lines here once it is set up.)
Is that agreeable with you?

Well, that said:
-rw-r--r--  1 root root    10514 Oct 23 12:15 eglibc_2.11.2-6+m68k.2_m68k.changes

I’m putting this up here:
http://www.freewrt.org/~tg/aradebs/dists/tlsdirty/unreleased/Pkgs/eglibc/

@all: Remember these packages are built in an environment with Finn’s
eglibc sysroot extracted, i.e. more than just unclean ☺ but they will
be used in compiling gcc-4.4 and eglibc that can in the end be uploaded
(although I’ll likely recompile (binNMU) everything, just to make sure
they are clean).

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.	-- Rob Pike in "Notes on Programming in C"


Reply to: