Re: ANDROID
On Wed, Oct 30, 2013 at 07:17:41PM +0100, berenger.morel@neutralite.org wrote:
>
>
> Le 30.10.2013 18:44, Curt a écrit :
>
> Good. You did not forgot the "GNU" before "make". It simply means
> that there are a lot of "make" tools. And you know what?
>
> Wikipedia
> >POSIX includes standardization of the basic features and operation
> >of the Make utility
>
> Yes! It is part of POSIX standard! It happens that GNU implemented
> one. That's all.
You're welcome to try to replace GNU Make with inferior BSD Make and
use it to build Linux kernel. See, GNU Make not only implements POSIX,
it extends it. And surely, Linux kernel project is using such
extensions.
> > * GNU Compiler Collection (GCC): Suite of compilers for several
> >programming languages;
>
> Linux is written in C. C has a lot of compilers, and GCC currently
> is not really the best compiler suite I know. It is a gigantic
> memory eater. Use clang instead, and you will understand what I
> mean.
> You can argue that clang is a new compiler, and it's true. But C is
> far older than GNU, too.
Yet, Linux kernel is not written in pure K&R C. Linux kernel is written
with GCC in mind, and actively uses GCC's extensions to C89 (or C99,
memory fails me) standard.
LLVM (surprise!) doesn't implements all GCC-isms fully and correctly (if
such word can be applied to a custom extension of a standard). Using
clang to build Linux kernel will lead you to non-building kernel modules
(best case), or FTBS the kernel itself (usual case).
Same goes for ICC.
> > * GNU Binutils: Suite of tools including linker, assembler and
> >other tools;
>
> Well, as for GCC, that suite is quite a standard, when you use C.
> There are plenty of them. Without them, you can not use things you
> made in C.
Yet, using anything other than GNU Binutils may produce segfaulting
binaries and panicking kernels. Again, you're welcome to replace GNU
Binutils with anything else and try to build working Linux kernel.
> > * GNU build system (autotools):
> > o Autoconf
> > o Autoheader
> > o Automake
> > o Libtool
>
> Do not make me laugh. Those tools are just dirty.
> Every time I have to compile something with autotools, it gave me
> problems and problems and yet another problems!
>
> They are slow, produces unreadable logs, are hard to maintain... (I
> mean, it is hard to maintain the scripts they need to work)
That's only shows that you do not want or able to use these tools
properly. Because, you see, Linux kernel uses them just fine.
> >Amongst others, apparently (list taken from wikipedia). Is it
> >possible
> >(feasible) to bypass these "vital" tools with another set of tools,
> >that you'll
> >be writing shortly after responding to this post?
>
> Linux kernel is written in C. C owns nothing to GNU. Nothing.
>
> It may happen that Linux's developers used some GNU implementations
> for a C compiler, an assembler, a debugger, etc... but it could have
> be made with other tools too.
Given that:
a) Linux kernel has to function on multiple processor architectures.
b) Maintaining and developing is easier if you test for one compiler
only.
c) Nothing beats GCC in being cross-platform.
d) Linus motto was (and is) 'use that works'.
no, it can not been done with tools other than GNU provides.
> GNU means "Gnu is Not Unix", and it is because it was meant to be a
> complete OS ( I have never seen a working hurd ) different than
> Unix, but keeping the same behavior.
> In other word: the goal have never be to invent something, only to
> copy what exists somewhere else, but with the interest of being
> open-source, and that stuff depending on (linked with) their tools
> would stay open-source.
Nope. The goal was to enhance low quality userland AT&T and Berkley
gave the user. That goal was reached successfully. Copying functionality
is a byproduct of that goal. Next goal was to make GNU OS. That goal
wasn't reached yet.
Reco
Reply to: