* Issues with stdio.h
@ 2012-02-20 0:07 Chris Sutcliffe
2012-02-20 0:25 ` Christopher Faylor
0 siblings, 1 reply; 11+ messages in thread
From: Chris Sutcliffe @ 2012-02-20 0:07 UTC (permalink / raw)
To: The Cygwin Mailing List
I'm trying to compile vim now using the latest snapshot, and I'm
having an issue with stdio.h referencing stddef.h, which seems to be
missing. I checked my /usr/include directory and sure enough, it's
not there. According to vim's configure:
configure:3089: gcc -o conftest.exe conftest.c >&5
In file included from conftest.c:10:0:
/usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or directory
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with stdio.h
2012-02-20 0:07 Issues with stdio.h Chris Sutcliffe
@ 2012-02-20 0:25 ` Christopher Faylor
2012-02-20 21:40 ` Thomas Wolff
0 siblings, 1 reply; 11+ messages in thread
From: Christopher Faylor @ 2012-02-20 0:25 UTC (permalink / raw)
To: cygwin
On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
>I'm trying to compile vim now using the latest snapshot, and I'm
>having an issue with stdio.h referencing stddef.h, which seems to be
>missing. I checked my /usr/include directory and sure enough, it's
>not there. According to vim's configure:
>
>configure:3089: gcc -o conftest.exe conftest.c >&5
>In file included from conftest.c:10:0:
>/usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or directory
stddef.h comes from the gcc4-core package. It's located in:
usr/lib/gcc/i686-pc-cygwin/4.5.3/include/stddef.h
and should be found automatically by the compiler. I just tried a
simple test case and the inclusion of stdio.h seemed to work fine.
You could try checking to make sure that there are no environment
variables set which would impact the compiler.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with stdio.h
2012-02-20 0:25 ` Christopher Faylor
@ 2012-02-20 21:40 ` Thomas Wolff
2012-02-20 22:10 ` Eric Blake
2012-02-20 22:12 ` JonY
0 siblings, 2 replies; 11+ messages in thread
From: Thomas Wolff @ 2012-02-20 21:40 UTC (permalink / raw)
To: cygwin
Am 20.02.2012 01:25, schrieb Christopher Faylor:
> On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
>> ...
>> /usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or directory
> stddef.h comes from the gcc4-core package. It's located in:
>
> usr/lib/gcc/i686-pc-cygwin/4.5.3/include/stddef.h
>
> and should be found automatically by the compiler.
I think it's a weird setup that an include file referred from
/usr/include is not found in that location but well hidden in
installation-specific directories. Not the usual setup anyway. Also
uncomfortable for people who want to check include files manually.
Please consider to change this (gcc maintainer?).
Thomas
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with stdio.h
2012-02-20 21:40 ` Thomas Wolff
@ 2012-02-20 22:10 ` Eric Blake
2012-02-20 22:58 ` Thomas Wolff
2012-02-20 22:12 ` JonY
1 sibling, 1 reply; 11+ messages in thread
From: Eric Blake @ 2012-02-20 22:10 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]
On 02/20/2012 02:39 PM, Thomas Wolff wrote:
> Am 20.02.2012 01:25, schrieb Christopher Faylor:
>> On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
>>> ...
>>> /usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or
>>> directory
>> stddef.h comes from the gcc4-core package. It's located in:
>>
>> usr/lib/gcc/i686-pc-cygwin/4.5.3/include/stddef.h
>>
>> and should be found automatically by the compiler.
> I think it's a weird setup that an include file referred from
> /usr/include is not found in that location but well hidden in
> installation-specific directories. Not the usual setup anyway.
Wrong. GNU/Linux does this too. On my Fedora machine,
$ printf '#include <stddef.h>\n#include <stdio.h>\n' | gcc -E -\
|grep '^# 1 "/'
# 1 "/usr/lib/gcc/x86_64-redhat-linux/4.6.2/include/stddef.h" 1 3 4
# 1 "/usr/include/stdio.h" 1 3 4
# 1 "/usr/include/features.h" 1 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 1 "/usr/include/gnu/stubs-64.h" 1 3 4
# 1 "/usr/lib/gcc/x86_64-redhat-linux/4.6.2/include/stddef.h" 1 3 4
# 1 "/usr/include/bits/types.h" 1 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 1 "/usr/include/bits/typesizes.h" 1 3 4
# 1 "/usr/include/libio.h" 1 3 4
# 1 "/usr/include/_G_config.h" 1 3 4
# 1 "/usr/lib/gcc/x86_64-redhat-linux/4.6.2/include/stddef.h" 1 3 4
# 1 "/usr/include/wchar.h" 1 3 4
# 1 "/usr/lib/gcc/x86_64-redhat-linux/4.6.2/include/stdarg.h" 1 3 4
# 1 "/usr/include/bits/stdio_lim.h" 1 3 4
# 1 "/usr/include/bits/sys_errlist.h" 1 3 4
So it is quite a common practice, and cygwin is merely copying what you
get on a GNU/Linux box.
> Also
> uncomfortable for people who want to check include files manually.
How so? As far back as C89, and reiterated in newer documents such as
POSIX 2008, there is no guarantee that <stddef.h> is an actual file that
lives in any particular directory, only that the <> notation in the
#include directive tells the compiler to find whatever it needs to
provide that standard header.
> Please consider to change this (gcc maintainer?).
I don't see the need for any change.
--
Eric Blake eblake@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with stdio.h
2012-02-20 21:40 ` Thomas Wolff
2012-02-20 22:10 ` Eric Blake
@ 2012-02-20 22:12 ` JonY
2012-02-20 22:58 ` Robert Miles
1 sibling, 1 reply; 11+ messages in thread
From: JonY @ 2012-02-20 22:12 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
On 2/21/2012 05:39, Thomas Wolff wrote:
> Am 20.02.2012 01:25, schrieb Christopher Faylor:
>> On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
>>> ...
>>> /usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or
>>> directory
>> stddef.h comes from the gcc4-core package. It's located in:
>>
>> usr/lib/gcc/i686-pc-cygwin/4.5.3/include/stddef.h
>>
>> and should be found automatically by the compiler.
> I think it's a weird setup that an include file referred from
> /usr/include is not found in that location but well hidden in
> installation-specific directories. Not the usual setup anyway. Also
> uncomfortable for people who want to check include files manually.
> Please consider to change this (gcc maintainer?).
> Thomas
>
So how are you supposed to use headers provided by the compiler anyway
without going into that compiler specific directory?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with stdio.h
2012-02-20 22:12 ` JonY
@ 2012-02-20 22:58 ` Robert Miles
2012-02-20 23:08 ` Eric Blake
2012-02-21 1:10 ` Christopher Faylor
0 siblings, 2 replies; 11+ messages in thread
From: Robert Miles @ 2012-02-20 22:58 UTC (permalink / raw)
To: cygwin; +Cc: JonY
On 2/20/2012 4:12 PM, JonY wrote:
> On 2/21/2012 05:39, Thomas Wolff wrote:
>> Am 20.02.2012 01:25, schrieb Christopher Faylor:
>>> On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
>>>> ...
>>>> /usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or
>>>> directory
>>> stddef.h comes from the gcc4-core package. It's located in:
>>>
>>> usr/lib/gcc/i686-pc-cygwin/4.5.3/include/stddef.h
>>>
>>> and should be found automatically by the compiler.
>> I think it's a weird setup that an include file referred from
>> /usr/include is not found in that location but well hidden in
>> installation-specific directories. Not the usual setup anyway. Also
>> uncomfortable for people who want to check include files manually.
>> Please consider to change this (gcc maintainer?).
>> Thomas
>>
> So how are you supposed to use headers provided by the compiler anyway
> without going into that compiler specific directory?
>
Why not put a stddef.h file into /user/include that includes comments
showing
where to find the compiler-specific stddef.h files? And if putting it
there makes
the compiler try to use it instead of the compiler-specific one, also
add the code
needed to tell the compiler to include the compiler-specific one, after
checking
which compiler is currently in use.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with stdio.h
2012-02-20 22:10 ` Eric Blake
@ 2012-02-20 22:58 ` Thomas Wolff
2012-02-20 23:05 ` Eric Blake
0 siblings, 1 reply; 11+ messages in thread
From: Thomas Wolff @ 2012-02-20 22:58 UTC (permalink / raw)
To: cygwin
Am 20.02.2012 23:10, schrieb Eric Blake:
> On 02/20/2012 02:39 PM, Thomas Wolff wrote:
>> Am 20.02.2012 01:25, schrieb Christopher Faylor:
>>> On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
>>>> ...
>>>> /usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or
>>>> directory
>>> stddef.h comes from the gcc4-core package. It's located in:
>>>
>>> usr/lib/gcc/i686-pc-cygwin/4.5.3/include/stddef.h
>>>
>>> and should be found automatically by the compiler.
>> I think it's a weird setup that an include file referred from
>> /usr/include is not found in that location but well hidden in
>> installation-specific directories. Not the usual setup anyway.
> Wrong. GNU/Linux does this too. On my Fedora machine,
>
> $ printf '#include<stddef.h>\n#include<stdio.h>\n' | gcc -E -\
> |grep '^# 1 "/'
> # 1 "/usr/lib/gcc/x86_64-redhat-linux/4.6.2/include/stddef.h" 1 3 4
> # 1 "/usr/include/stdio.h" 1 3 4
> # 1 "/usr/include/features.h" 1 3 4
> # 1 "/usr/include/sys/cdefs.h" 1 3 4
> # 1 "/usr/include/bits/wordsize.h" 1 3 4
> # 1 "/usr/include/gnu/stubs.h" 1 3 4
> # 1 "/usr/include/bits/wordsize.h" 1 3 4
> # 1 "/usr/include/gnu/stubs-64.h" 1 3 4
> # 1 "/usr/lib/gcc/x86_64-redhat-linux/4.6.2/include/stddef.h" 1 3 4
> # 1 "/usr/include/bits/types.h" 1 3 4
> # 1 "/usr/include/bits/wordsize.h" 1 3 4
> # 1 "/usr/include/bits/typesizes.h" 1 3 4
> # 1 "/usr/include/libio.h" 1 3 4
> # 1 "/usr/include/_G_config.h" 1 3 4
> # 1 "/usr/lib/gcc/x86_64-redhat-linux/4.6.2/include/stddef.h" 1 3 4
> # 1 "/usr/include/wchar.h" 1 3 4
> # 1 "/usr/lib/gcc/x86_64-redhat-linux/4.6.2/include/stdarg.h" 1 3 4
> # 1 "/usr/include/bits/stdio_lim.h" 1 3 4
> # 1 "/usr/include/bits/sys_errlist.h" 1 3 4
>
> So it is quite a common practice, and cygwin is merely copying what you
> get on a GNU/Linux box.
>
>> Also
>> uncomfortable for people who want to check include files manually.
> How so? As far back as C89, and reiterated in newer documents such as
> POSIX 2008, there is no guarantee that<stddef.h> is an actual file that
> lives in any particular directory, only that the<> notation in the
> #include directive tells the compiler to find whatever it needs to
> provide that standard header.
JonY wrote:
> So how are you supposed to use headers provided by the compiler anyway
> without going into that compiler specific directory?
As I interpret this, stddef.h - containing those constants - is the only
file with this setup, so be it.
(I had actually checked on a SunOS system.)
Thomas
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with stdio.h
2012-02-20 22:58 ` Thomas Wolff
@ 2012-02-20 23:05 ` Eric Blake
0 siblings, 0 replies; 11+ messages in thread
From: Eric Blake @ 2012-02-20 23:05 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]
On 02/20/2012 03:58 PM, Thomas Wolff wrote:
>> Wrong. GNU/Linux does this too. On my Fedora machine,
>>
>> $ printf '#include<stddef.h>\n#include<stdio.h>\n' | gcc -E -\
>> |grep '^# 1 "/'
...
>> # 1 "/usr/lib/gcc/x86_64-redhat-linux/4.6.2/include/stddef.h" 1 3 4
>> # 1 "/usr/include/wchar.h" 1 3 4
>> # 1 "/usr/lib/gcc/x86_64-redhat-linux/4.6.2/include/stdarg.h" 1 3 4
>
> As I interpret this, stddef.h - containing those constants - is the only
> file with this setup, so be it.
Reading the trace I posted above, it is not just <stddef.h>, but also at
least <stdarg.h>, and probably others, too.
> (I had actually checked on a SunOS system.)
SunOS isn't GNU/Linux, so it is less relevant to how cygwin behaves
(since cygwin is striving to be a Linux emulation, not a POSIX
emulation). Not to mention that using gcc on SunOS _also_ prefers to
translate <stddef.h> to a gcc-specific directory, rather than
/usr/include/stddef.h, since gcc relies on aspects that are specific to
the gcc compiler, while /usr/include/stddef.h is tied to the system's
own 'cc' that doesn't understand gcc extensions.
--
Eric Blake eblake@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with stdio.h
2012-02-20 22:58 ` Robert Miles
@ 2012-02-20 23:08 ` Eric Blake
2012-02-21 1:10 ` Christopher Faylor
1 sibling, 0 replies; 11+ messages in thread
From: Eric Blake @ 2012-02-20 23:08 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
On 02/20/2012 03:57 PM, Robert Miles wrote:
> Why not put a stddef.h file into /user/include that includes comments
> showing
> where to find the compiler-specific stddef.h files?
Why not ask the upstream gcc list? This is not a situation specific to
Cygwin, so asking on this list won't get it changed.
--
Eric Blake eblake@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with stdio.h
2012-02-20 22:58 ` Robert Miles
2012-02-20 23:08 ` Eric Blake
@ 2012-02-21 1:10 ` Christopher Faylor
2012-02-21 13:01 ` Earnie Boyd
1 sibling, 1 reply; 11+ messages in thread
From: Christopher Faylor @ 2012-02-21 1:10 UTC (permalink / raw)
To: cygwin
On Mon, Feb 20, 2012 at 04:57:20PM -0600, Robert Miles wrote:
>On 2/20/2012 4:12 PM, JonY wrote:
>> On 2/21/2012 05:39, Thomas Wolff wrote:
>>> Am 20.02.2012 01:25, schrieb Christopher Faylor:
>>>> On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
>>>>> ...
>>>>> /usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or
>>>>> directory
>>>> stddef.h comes from the gcc4-core package. It's located in:
>>>>
>>>> usr/lib/gcc/i686-pc-cygwin/4.5.3/include/stddef.h
>>>>
>>>> and should be found automatically by the compiler.
>>> I think it's a weird setup that an include file referred from
>>> /usr/include is not found in that location but well hidden in
>>> installation-specific directories. Not the usual setup anyway. Also
>>> uncomfortable for people who want to check include files manually.
>>> Please consider to change this (gcc maintainer?).
>>> Thomas
>>>
>> So how are you supposed to use headers provided by the compiler anyway
>> without going into that compiler specific directory?
>>
>Why not put a stddef.h file into /user/include that includes comments
>showing where to find the compiler-specific stddef.h files? And if
>putting it there makes the compiler try to use it instead of the
>compiler-specific one, also add the code needed to tell the compiler to
>include the compiler-specific one, after checking which compiler is
>currently in use.
It appears that we have a few here who are not familiar with Linux
and/or gcc. That's not terribly surprising but if you're not familiar
with the way gcc lays things out then this is really not the place to
express consternation. If we *didn't* set things up like Linux that
would actually be a bug.
So, no, we're not going to include versions of gcc's header files in
/usr/include because that's where you want to look for things. You can
see the directories that gcc searches by adding a '-v' to your compile
line. The include search path that is then printed will be your clue
for where to look for header files.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Issues with stdio.h
2012-02-21 1:10 ` Christopher Faylor
@ 2012-02-21 13:01 ` Earnie Boyd
0 siblings, 0 replies; 11+ messages in thread
From: Earnie Boyd @ 2012-02-21 13:01 UTC (permalink / raw)
To: cygwin
And FWIW, MinGW's native gcc also doesn't include the GCC specific
headers in the /mingw/include directory.
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-02-21 13:01 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-20 0:07 Issues with stdio.h Chris Sutcliffe
2012-02-20 0:25 ` Christopher Faylor
2012-02-20 21:40 ` Thomas Wolff
2012-02-20 22:10 ` Eric Blake
2012-02-20 22:58 ` Thomas Wolff
2012-02-20 23:05 ` Eric Blake
2012-02-20 22:12 ` JonY
2012-02-20 22:58 ` Robert Miles
2012-02-20 23:08 ` Eric Blake
2012-02-21 1:10 ` Christopher Faylor
2012-02-21 13:01 ` Earnie Boyd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).