17.3.2011 16:13, David Paterson kirjoitti:
On Thu, Mar 17, 2011 at 12:47 PM, Kai Ruottu<kai.ruottu@xxxxxxxxxxx> wrote:
17.3.2011 12:58, David Paterson kirjoitti:
I'm currently rebuilding using the methods you recommended, and so far
it's working fine... :-)
It seems that preinstalling the target headers into the
'$prefix/$target/include' and putting them to be seen
also in '$prefix/$target/sys-include' (the GCC build
expects to see them there for investigation) is always
obligatory! If putting only the 'newlib' and 'libgloss'
among the GCC sources, the C library will be built but
for instance the GCC's own 'limits.h' will not be fixed
to include the newlib's 'limits.h'.
Odd. I don't seem to have a $prefix/$target/sys-include directory...
As was told, for some peculiar reason the GCC build expects
the target headers being seen in the 'sys-include'. So having
them there during the build is important! If we look at the
resulted '$BUILD/gcc/Makefile', there is :
# Default native SYSTEM_HEADER_DIR, to be overridden by targets.
NATIVE_SYSTEM_HEADER_DIR = /usr/include
# Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
CROSS_SYSTEM_HEADER_DIR = $(gcc_tooldir)/sys-include
Ie the '$prefix/$target/sys-include' was put to be the equivalent
to the native '/usr/include'. It definitely isn't that!
About some terms :
The '/usr/include' is not the place for the native "system headers",
the Linux kernel headers could belong to this group, it is the place
for the native "standard headers". The 'sys-include' then is the place
for the "system headers" for the $target, the 'include' is the place
for the "standard headers" for the $target. Someone mixed these two
places when people started to talk only about "system headers" :(
The "system headers" originally meaned something in the directory
which the old gcc-2.95 manual defined like :
"SYSTEM_INCLUDE_DIR is used only by native compilers. This macro
defi nes a C string constant which specifi es a system-specifi c
directory to search for header fi les before the standard choice
of `/usr/include'. SYSTEM_INCLUDE_DIR comes before STANDARD_INCLUDE_DIR
in the search order."
So the 'sys-include' is the equivalent to this usually unexisting
directory!
I have :-
$prefix/include
Usually (earlier) this was the place for the common (for all targets
besides the $target specific parts in their own subdirs) C++ headers
in subdirectory 'c++/$gcc-version'. When there is no $target component,
it would also be common for all GCCs built to use the same $prefix!
$prefix/$target/include
The "standard headers" for the $target should be here, nowadays also
the C++ headers will go there into the 'c++' subdirectory unless one
defines another place
$prefix/$target/lib/gcc/$target/4.5.2/include
$prefix/$target/lib/gcc/$target/4.5.2/include-fixed
$prefix/$target/lib/gcc/$target/4.5.2/install-tools/include
These are for the $target and GCC-version specific headers...
All of which contain different sets of files (and even different
versions of some files e.g. limits.h)
If the 'limits.h' is seen in the '$prefix/$target/sys-include' during
the GCC build, the GCC's own 'limits.h' will be edited to
'#include_next' (via 'syslimits.h') it... Hmmm, many 'limits.h's, must
be investigated in my installs... The 'install-tools/include/limits.h'
and 'include-fixed/limits.h' were identical. Only the second would be
found by GCC as default.
Should I be creating sys-include and copying the Newlib headers into
it?
In modern Unix and Linux systems a symlink, 'sys-include -> include',
is much better. I don't know Windoze, what to do there. After the GCC
build and install the 'sys-include' having identical headers or the
earlier generic newlib headers, has not much use. Only making it
possible to find the possible diffs between the generic and the final
headers. If there are differences then the generic headers stuff in
'sys-include' shouldn't be seen... So copying the newlib headers to
the 'include' and letting the newlib install to replace them is more
sane! A symlink causing the 'include' and 'sys-inlude' meaning the
same place would be nice...
When compiling using '-v' for GCC, the search order for the header
directories will be seen. There you can see 'sys-include' (if it
exists) to be searched before 'include', these two being the last.
I think that the original purpose for the 'sys-include' was for the
"(target) system specific" headers, those which don't belong to the
C library, neither to GCC. For instance headers from chip-makers for
the CPU, its I/O, IRQ-vectors etc. Keeping them separated from the
C library headers would be useful...
So: If you copy the generic headers into the 'sys-include', you must
decide what you will do with them after the GCC and newlib install!
When the headers there are seen earlier than the final ones in
'include', they should not be the wrong ones! My opinion is that
there is no sanity in the use of 'sys-include' during the GCC build!
How easy it then would be to edit the code which causes the earlier
shown rows, to appear instead as :
# Default native SYSTEM_HEADER_DIR, to be overridden by targets.
NATIVE_SYSTEM_HEADER_DIR = /usr/include
# Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
CROSS_SYSTEM_HEADER_DIR = $(gcc_tooldir)/include
nobody however has cared / has had enough courage to fix this code
during the 15+ years :( How many times for instance I have nagged
about this is hard to say...
I thought the directory structure in the install location was set
up by the configure and build system to keep the host and target
versions of things separate.
For the "system targets" there is nowadays the '--with-sysroot=$sysroot'
to point to the place where the "native" stuff for the $target system
is installed on the cross $host, in its "native" install scheme. For
instance:
$sysroot/etc
$sysroot/bin
$sysroot/lib
$sysroot/sbin
$sysroot/usr/bin
$sysroot/usr/include
$sysroot/usr/lib
$sysroot/usr/sbin
for some Linux distro. Imagining the "native install scheme" for an
embedded system may however be hard, so the traditional $tooldir
aka $prefix/$target install place is still used in these cases. So
the 'bin' there has executables for the $host and targeted to $target.
But 'include' and 'lib' have headers and library binaries for $target.
Only the last two are moved into the $sysroot in the new scheme...
The $prefix/bin then has those '$prefix-<tool>'s (with the default
names, these can be changes via the GCC configure options
'--program-suffix=something' and '--program-prefix=something').
For some it of course could be possible to imagine some "native GCC
installation" for the $target where the "native" C library headers
are in the '/usr/include' and the native libraries in '/usr/lib'.
One then wants to make "another incarnation" of this GCC on some
cross $host and copies its "native C library" into some suitable
$sysroot. Then there would not be that stupid 'sys-include' issue!
Something to try for some brave person :) I really cannot tell where
the newlib headers and libraries would be installed in the
'--with-sysroot=$sysroot' case, hopefully not to the '/usr/include'
and '/usr/lib' :( Does the newlib configure really understand and
use the $sysroot or does the main configury give right install
places for 'newlib' and 'libgloss'? One tries, one sees, there is
the bravery...
Looks like I'll need to do a bit more investigation to get it all
straight in my head...
If the insane things like that with the 'sys-include' could be
removed, these things would be much easier to understand...
