Re: Building a cross compiler, and unsure about the use of --without-headers

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

 



21.3.2011 12:10, David Paterson kirjoitti:

Documentation, particularly on cross-compilers, is
sparse, hard to find, and often contradictory.  Several sites, and
mailing list threads, indicated that "--with-sysroot" should be used,
so it seemed best to follow their recommendations.

Things like this are so usual :(  People think that the only
possible opsys on a x86 system is Windows or if not that, then
Linux... Or that people need cross GCCs for originally totally
unexisting Linuces and that there really isn't anything just for
them. Although people have already "ported" Linuces for almost
all the suitable CPUs and there are many "implementations" for
these Linux ports, called "distros", the instructions still say
that people should not use anything existing in any phase.
"It doesn't matter if a cat is black or white, so long as it
catches mice" (Deng Xiaoping) is a clause which is totally
forgotten :(

So there are always alternative ways to do everything but people
don't tell the alternatives or don't even know what they are and
what is wrong with them if they don't want to suggest people to
use them...

I surely would like to see what on earth is wrong in using the
25 or more years old cross GCC model with a newlib-based embedded
target! And with building it in only one stage, including newlib!

That 'sys-include' nuisance was told just like what it means to
use the '--with-headers=' to copy the generic newlib headers
there and then leave them there after the GCC and newlib installations.
That the copied headers will be found before the final installed
newlib headers :(  If one tolerates this feature/bug and makes
the necessary workarounds :

 - copies or symlinks the generic headers to be seen in 'sys-include'
   during the GCC build
 - removes the headers from the 'sys-include' after the 'make install'
   if they were copied there before the GCC build

then the 1-stage build process should work nicely!

As was told, just provide the 'newlib' and 'libgloss' subdirs in the
main GCC source dir, for instance as 'gcc-4.5.2/newlib' and
'gcc-4.5.2/libgloss' and then they should be built just like
the 'libiberty', 'libstdc++-v3' and 'libssp' for the target with the
built 'xgcc', 'cc1' etc.

OK, I'll try that, but what about the rest of the stuff in the
Newlib-1.19.0 directory?  There are 3 other directories and 39 files,
several of which conflict with files and directories already in the
GCC directory.  (For now I'll just ignore them and try to build
without them.  I'll let you know if it succeeds.)

It should succeed! I looked those other directories and saw that :

- the 'etc' has texinfo src docs for 'configure' etc.

- the 'texinfo' has a 'texinfo.tex' "macro" file for the 'makeinfo'
  application

- the 'config' has host ('mh-') and target ('mt-') files for some
  "non-embedded" hosts/targets like Unix SVR3 (SCO), Darwin, WinCE,
  Interix, DJGPP,...

- didn't look much what on earth the files in the main newlib-z.y.0
  source directory were
I myself remember building newlib for SCO Unix 3.2, SVR4/ELF and
DJGPP 1.x on DOS...

These "system ports" of newlib don't belong to the embedded world
at all, and whether they now work and someone really maintains them
is really unclear, just like how well the Zilog's Z8000 CPU support
in 'newlib/libc/machine/z8k' is maintained nowadays... So there is
quite a lot "seldom used stuff" in the newlib sources too. Waiting
someone some day maybe needing it for something.

I tried to look any instructions for building GCC and newlib together
(search words "newlib libgloss GCC sources") in the net and the
following were some of them :

http://sourceware.org/newlib/faq.html#q3
http://blackfin.uclinux.org/gf/project/toolchain/forum/?_forum_action=ForumMessageBrowse&thread_id=379&action=ForumBrowse

The latter told that this idea isn't so rare : "I'm just used to always
to cross-compiler builds with newlib/libgloss linked into gcc sources (o;"


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux