On Thu, Mar 17, 2011 at 6:15 PM, Kai Ruottu <kai.ruottu@xxxxxxxxxxx> wrote:
> 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
I wonder if things have changed in the GCC build. I'm building using
version 4.5.2, and the same section in my makefile 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 =
$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)
which would give a path ending in ".../usr/include" I think. (?)
Although later in your post you propose a different definition :-
> CROSS_SYSTEM_HEADER_DIR = $(gcc_tooldir)/include
so perhaps somebody has listened to you, and made some changes in the
right direction?
There are a couple of uses of "sys-include" in the makefile,
specifically one used in defining "GCC_FOR_TARGET". However, it's
prefixed with $(build_tooldir), which I think is equal to
$PREFIX/$TARGET. I'm guessing this might be where I should create the
additional copy of the include directory.
> ... 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...
Unfortunately I'm having to use Windows, so I'll make a copy of the directory.
> 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.
No, there's no reference to sys-include in the search list...
> 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!
If sys-include isn't part of the normal compiler search path, then it
may not cause any problems to leave the directory there.
> 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...
See above - this may be fixed now.
>> 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...
It is, I agree, quite hard to understand. My attempts so far at
putting Newlib into the GCC directory haven't had much success :{
I'll keep trying...
David
