From: Hinko Kocevar <hinko.kocevar@cetrtapot.si>
To: buildroot@busybox.net
Subject: [Buildroot] uClibc missing limits.h
Date: Wed, 09 Jul 2008 09:54:43 +0200 [thread overview]
Message-ID: <48746EC3.2020008@cetrtapot.si> (raw)
In-Reply-To: <20080703080557.GA29943@mx.loc>
Bernhard Fischer wrote:
> On Thu, Jul 03, 2008 at 09:05:06AM +0200, Hinko Kocevar wrote:
>> Ulf Samuelsson wrote:
>>>
>>>> Hinko Kocevar wrote:
>>>>> Bernhard Fischer wrote:
>>>>>> On Mon, Jun 23, 2008 at 02:22:25PM +0200, Hinko Kocevar wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've found a way for uClibc to find headers that are not in the
>>>>>>> $(shell $CC -print-file-name=include), but in $(shell $CC
>>>>>>> -print-file-name=include)-fixed.
>>>>>>> According to
>>>>>>> http://sourceware.org/ml/libc-alpha/2007-03/msg00017.html LIBC
>>>>>>> should also look in other gcc provided header directories (eg.
>>>>>>> include-fixed) instead only relying on 'include' to contain all
>>>>>>> correct headers.
>>>>>>>
>>>>>>> Below is uClibc patch for this (tested on cris).
>>>>>> Well, that's not really correct since the default search path already
>>>>>> should to be
>>>>>> $target_triple/$ver/include \
>>>>>> $target_triple/$ver/include-fixed \
>>>>>>
>>> Removing "-nostdinc" from CFLAGS in "uClibc-0.9.29/Rules.mak"
>>> allows the ARM compilation to continue,
>> But is this OK?
>
> no.
Looking at the gcc manual "-nostdinc" causes compiler to omit the standard include directories:
-nostdinc
Do not search the standard system directories for header files. Only the directories you have specified with -I options (and the directory of the current file, if appropriate) are searched.
IMHO, only when compiling uClibc we need to worry about the "-nostdinc" flag hence we should add -I directive to the compiler flags as suggested by the manual and solve the missing limits.h problem.
Or we could use "-isystem" flag:
-isystem dir
Search dir for header files, after all directories specified by -I but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. If dir begins with =, then the = will be replaced by the sysroot prefix; see --sysroot and -isysroot.
Best regards,
Hinko
PS.: Now I know what -I=dir stands for :)
--
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si
next prev parent reply other threads:[~2008-07-09 7:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-23 12:22 [Buildroot] uClibc missing limits.h Hinko Kocevar
2008-06-23 13:16 ` Bernhard Fischer
2008-06-24 11:14 ` Hinko Kocevar
2008-07-02 8:59 ` Hinko Kocevar
2008-07-02 18:22 ` Ulf Samuelsson
2008-07-03 7:05 ` Hinko Kocevar
2008-07-03 8:05 ` Bernhard Fischer
2008-07-09 7:54 ` Hinko Kocevar [this message]
2008-07-09 11:38 ` Bernhard Fischer
2008-07-11 7:15 ` Hinko Kocevar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48746EC3.2020008@cetrtapot.si \
--to=hinko.kocevar@cetrtapot.si \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox