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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.