Stdio h not found windows

I have installed LLVM and Clang-3.9.0 on Win10. I have MinGW installed as well.

I have put my C code in ‘D:’ drive.

I can use gcc and g++ to compile my code. But when I use clang I get:

clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target x86_64-pc-windows-msvc
ignoring duplicate directory "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A"
ignoring duplicate directory "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A"
#include "..." search starts here:
#include <...> search starts here:
 C:\Program Files\LLVM\bin\..\lib\clang\3.9.0\include
 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include
 C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A
End of search list.
 hello.c:1:10: fatal error: 'stdio.h' file not found
 #include "stdio.h"
             ^
 1 error generated.

As I can use gcc and g++, my environment variable settings are right. But then I am not able to force clang to look into C:\MinGW.

I tried copy pasting the whole MinGW folder manually in C:\Program Files\LLVM\bin\ and \lib\clang\3.9.0\include separately, but it did not work. I wanted to try this, but in 3.9.0 I cannot find, clang/lib/Frontend/InitHeaderSearch.cpp.

Anyway, is there a work around?

Note: I have tried <stdio.h> and "stdio.h" both, and I still get the same error.

Источник

Hi. I downloaded the binary release instead of building from source (as was recommended by the terra guide) on Windows. I downloaded release-2016-03-25. When I try any example that makes use of terralib.includec, terra seems to be unable to find any C library files unless I put them in the same directory as the .t file I’m trying to run. Obviously, that’s a bad idea for things like stdio.h.

I saw in #92 and #120 that these system C files are supposed to somehow be included internally in the terra binary release, but it doesn’t seem to work for me.

If I run the terra test suite (in share/terra/tests), 442 pass and 70 fail. The failing tests all appear to be ones which use terralib.includec.

This happens when Visual Studio is installed in a different place from
where it was installed in the binary releases. The newest src releases have
a fix for it that uses the Window’s registry to find where Visual Studio is
installed, and I will try to rebuild the binaries soon so that it can be
used.

For C headers, right now the only C files that are included internally are
the Clang-specific header files (like stddef.h) that individual compilers
provide. Things like ‘stdio.h’ still come from the libc installed on the
machine.

To work around this now, you can set the terralib.includepath, e.g.:

terra.includepath = "/usr/local/include;..;"

Inside the application so that it searches more directories.

On Wed, Jun 1, 2016 at 5:03 PM, Andrew Richards notifications@github.com
wrote:

Hi. I downloaded the binary release instead of building from source (as
was recommended by the terra guide) on Windows. I downloaded
release-2016-03-25. When I try any example that makes use of
terralib.includec, terra seems to be unable to find any C library files
unless I put them in the same directory as the .t file I’m trying to run.
Obviously, that’s a bad idea for things like stdio.h.

I saw in #92 #92 and #120
#120 that these system C files
are supposed to somehow be included internally in the terra binary release,
but it doesn’t seem to work for me.

If I run the terra test suite (in share/terra/tests), 442 pass and 70
fail. The failing tests all appear to be ones which use terralib.includec.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#177, or mute the thread
https://github.com/notifications/unsubscribe/AAWmGuHfLklaKXMr00rNv8CUW_ZEmeqcks5qHh26gaJpZM4IsF0M
.

Thanks for the reply! Manually setting the includepath is letting me work with libc now.

Hi, where can I do the includepath? Visual studio? Or environment variable? Sorry. New to this? Moreover, What path should I include?

Thank you. Actually I tried to include C:\Program Files (x86)\Microsoft
Visual Studio 14.0\VC to environment variable, however, it doesn’t work. I
need to install opt based on terra. Thus, it would be better for me to find
a way to solve the problem globally, instead of defining in the script.

…

How can I add terralib.includepath to the script? Can you show me an
example? have no idea where to add it.

terralib.includepath = «/usr/local/include;..;»

local c = terralib.includec(«stdio.h»)

terra hello()
c.printf(«hello, world\n»)
end

terralib.saveobj(«hello»,{main = hello})
hello()

…

On Wed, Nov 29, 2017 at 4:48 PM, yan deng ***@***.***> wrote:
Thank you. Actually I tried to include C:\Program Files (x86)\Microsoft
Visual Studio 14.0\VC to environment variable, however, it doesn’t work. I
need to install opt based on terra. Thus, it would be better for me to find
a way to solve the problem globally, instead of defining in the script.

On Wed, Nov 29, 2017 at 4:11 PM, Elliott Slaughter <
***@***.***> wrote:

> @mxgbs <https://github.com/mxgbs> You can set the environment variable
> INCLUDE_PATH when you run Terra, or you can add a line to your Terra
> script to set terralib.includepath as shown above.
>
> The exact path is going to depend on what Visual Studio you have
> installed, and unfortunately I don’t have access to a machine with this
> installed so I can look myself. You might try looking here:
> https://stackoverflow.com/questions/13786112/where-can-i-
> find-the-implementation-of-stdio-h-in-visual-studio
>
> Hope that helps.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#177 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AH0KCxG-PA7mXooXsbIJrthq86ItXkGLks5s7fKegaJpZM4IsF0M>
> .
>

Yes, that’s exactly right, you just have to modify the value you assign to terralib.includepath to point to do the directory that contains stdio.h. Note in your previous email you said you set the value to C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC but if the link I posted above is right then it needs to be C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\crt\src. At any rate, the directory you point it to needs to literally contain the file stdio.h. (I.e. you can’t just point it to the top of the MSVC install, it’s not that smart.)

I tried both crt\src and sdk, both not work independently or combined.
Google and use some other suggestions, it’s still not work.

…

On Wed, Nov 29, 2017 at 7:52 PM Elliott Slaughter ***@***.***> wrote:
Yes, that’s exactly right, you just have to modify the value you assign to
terralib.includepath to point to do the directory that contains stdio.h.
Note in your previous email you said you set the value to C:\Program
Files (x86)\Microsoft Visual Studio 14.0\VC but if the link I posted
above is right then it needs to be C:\Program Files (x86)\Microsoft
Visual Studio 14.0\VC\crt\src. At any rate, the directory you point it to
needs to literally contain the file stdio.h. (I.e. you can’t just point
it to the top of the MSVC install, it’s not that smart.)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#177 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AH0KC_FXOjf9nncz_BA7gLIUUGpjtmyWks5s7iZfgaJpZM4IsF0M>
.

The problem has to be one of the following:

stdio.h is not located in the directories you added to the include path.
One of the transitive dependencies of stdio.h (i.e. via an #include directive inside stdio.h) is not on the path.
Something is going wrong in terralib.includec or in your assignment of terralib.includepath.

I think we can rule out (3) by creating a dummy header file my_header.h (which can just be empty for this purpose), placing it in a directory somewhere, and testing the same program with stdio.h replaced by my_header.h. Note: for completeness you should make sure to set terralib.includepath to the absolute path to this file, and you should make sure the path has similar features (i.e. spaces and parens) to the other path you were using.

If that works, then you probably need to take a hard look at stdio.h and make sure (a) it’s actually where you think it is, and (b) you include the paths of any dependencies it includes via #include.

Minor correction: when doing the test for (3) above, you need to set the path to the directory that contains the dummy header file, not the file itself.

Hi Elliott,

Thank you. I found out the right way to include that is as following(II).
However, new error popped up as in I. Do you have any clue how to solve
that? Besides, I also tried to add those two folder to the environment
variable, and use «SET» to check if those are correctly included. However,
even with them included in the environment variable, the test case is still
not work. The only way I found out to let it work is to include that in the
script.
I. terra\bin>terra ..\share\terra\tests\hello.t
llvm: program not executable

stack traceback:
[C]: in function ‘saveobj’
C:\Users\zdevito\terra\src\terralib.lua:3979: in function ‘saveobj’
..\share\terra\tests\hello.t:8: in main chunk

II. terralib.includepath = [[C:\Program Files (x86)\Windows
Kits\10\Include\10.0.16299.0\ucrt;C:\Program Files (x86)\Microsoft Visual
Studio 14.0\VC\include;C:\Users\dengya\Documents\Optlang\terra\bin]]
local c = terralib.includec(«stdio.h»)

terra hello()
c.printf(«hello, world\n»)
end

terralib.saveobj(«hello»,{main = hello})
hello()

…

Hi, @elliott
Tried to modify terralib.saveobj(«hello»,{main = hello})
to terralib.saveobj(«hello.o»,{main = hello}), it worked. hello.o
generated. But when generating executable file .o with g++ hello.o -o
hello, error popped as:.
hello.o:(.text[printf]+0x28): undefined reference to `__acrt_iob_func’
hello.o:(.text[printf]+0x42): undefined reference to
`__stdio_common_vfprintf’
collect2.exe: error: ld returned 1 exit status

Without change «hello» to «hello.o», the same error occurs as before. Then
I googled a little bit, it seems that some intrinsic functions are defined
differently in VS2015.
https://groups.google.com/forum/#!topic/dislin-users/kagVl9LVFJA . Do you
know how to solve that? Thank you.
llvm: program not executable

stack traceback:
[C]: in function ‘saveobj’
C:\Users\zdevito\terra\src\terralib.lua:3979: in function ‘saveobj’
..\share\terra\tests\hello.t:8: in main chunk

…

On Thu, Nov 30, 2017 at 10:13 AM, yan deng ***@***.***> wrote:
Hi Elliott,

stack traceback:
[C]: in function ‘saveobj’
C:\Users\zdevito\terra\src\terralib.lua:3979: in function
‘saveobj’
..\share\terra\tests\hello.t:8: in main chunk

terra hello()
c.printf(«hello, world\n»)
end

terralib.saveobj(«hello»,{main = hello})
hello()

On Thu, Nov 30, 2017 at 9:36 AM, Elliott Slaughter <
***@***.***> wrote:

> Minor correction: when doing the test for (3) above, you need to set the
> path to the directory that contains the dummy header file, not the file
> itself.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#177 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AH0KC9Xv7tcmjeiOqTclm7z9GdqiyKb-ks5s7uezgaJpZM4IsF0M>
> .
>

…

On Thu, Nov 30, 2017 at 3:00 PM, yan deng ***@***.***> wrote:
Hi, @elliott
Tried to modify terralib.saveobj(«hello»,{main = hello})
to terralib.saveobj(«hello.o»,{main = hello}), it worked. hello.o
generated. But when generating executable file .o with g++ hello.o -o
hello, error popped as:.
hello.o:(.text[printf]+0x28): undefined reference to `__acrt_iob_func’
hello.o:(.text[printf]+0x42): undefined reference to
`__stdio_common_vfprintf’
collect2.exe: error: ld returned 1 exit status

Without change «hello» to «hello.o», the same error occurs as before. Then
I googled a little bit, it seems that some intrinsic functions are defined
differently in VS2015. https://groups.google.com/
forum/#!topic/dislin-users/kagVl9LVFJA . Do you know how to solve that?
Thank you.
llvm: program not executable

stack traceback:
[C]: in function ‘saveobj’
C:\Users\zdevito\terra\src\terralib.lua:3979: in function
‘saveobj’
..\share\terra\tests\hello.t:8: in main chunk

On Thu, Nov 30, 2017 at 10:13 AM, yan deng ***@***.***> wrote:

> Hi Elliott,
>
> Thank you. I found out the right way to include that is as following(II).
> However, new error popped up as in I. Do you have any clue how to solve
> that? Besides, I also tried to add those two folder to the environment
> variable, and use «SET» to check if those are correctly included. However,
> even with them included in the environment variable, the test case is still
> not work. The only way I found out to let it work is to include that in the
> script.
> I. terra\bin>terra ..\share\terra\tests\hello.t
> llvm: program not executable
>
> stack traceback:
> [C]: in function ‘saveobj’
> C:\Users\zdevito\terra\src\terralib.lua:3979: in function
> ‘saveobj’
> ..\share\terra\tests\hello.t:8: in main chunk
>
>
> II. terralib.includepath = [[C:\Program Files (x86)\Windows
> Kits\10\Include\10.0.16299.0\ucrt;C:\Program Files (x86)\Microsoft
> Visual Studio 14.0\VC\include;C:\Users\dengy
> a\Documents\Optlang\terra\bin]]
> local c = terralib.includec(«stdio.h»)
>
> terra hello()
> c.printf(«hello, world\n»)
> end
>
> terralib.saveobj(«hello»,{main = hello})
> hello()
>
> On Thu, Nov 30, 2017 at 9:36 AM, Elliott Slaughter <
> ***@***.***> wrote:
>
>> Minor correction: when doing the test for (3) above, you need to set the
>> path to the directory that contains the dummy header file, not the file
>> itself.
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <#177 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AH0KC9Xv7tcmjeiOqTclm7z9GdqiyKb-ks5s7uezgaJpZM4IsF0M>
>> .
>>
>
>

I think if you want to use saveobj to generate a .o file you will need to use the MSVC compiler to link the final executable, given that stdio.h came from that compiler. (You mentioned using g++ above.)

I unfortunately don’t know anything about running MSVC, but from the article you linked it sounds like there is a legacy version of the functions you can link to if necessary? It’s not completely clear if you need those or not.

No. I don’t want to generate .o by saveobj. The problem is if I just try
saveobj to generate executable file, I will ge the error as I prviously
attached:

llvm: program not executable

stack traceback:
[C]: in function ‘saveobj’
C:\Users\zdevito\terra\src\terralib.lua:3979: in function ‘saveobj’
..\share\terra\tests\hello.t:8: in main chunk.

I found out change executable to .o, will let hello.t execute without
error. But the .o still could not be used because of the undefined external
error.

I don’t know where I can link to that legacy version. I tried
terralib.linklibrary
or add them to environment variable, both not work. So I’m wondering if you
know where I should link to that .lib. Thank you.

Sincerely,

Yan

…

On Thu, Nov 30, 2017 at 7:58 PM Elliott Slaughter ***@***.***> wrote:
I think if you want to use saveobj to generate a .o file you will need to
use the MSVC compiler to link the final executable, given that stdio.h
came from that compiler. (You mentioned using g++ above.)

I unfortunately don’t know anything about running MSVC, but from the
article you linked it sounds like there is a legacy version of the
functions you can link to if necessary? It’s not completely clear if you
need those or not.

Update: solve the problem by running the terra at VS2015 x64 Native Tools
Command Prompt.

Sincerely,

Yan

…

On Thu, Nov 30, 2017 at 8:08 PM, yan deng ***@***.***> wrote:
No. I don’t want to generate .o by saveobj. The problem is if I just try
saveobj to generate executable file, I will ge the error as I prviously
attached:

llvm: program not executable

stack traceback:
[C]: in function ‘saveobj’
C:\Users\zdevito\terra\src\terralib.lua:3979: in function
‘saveobj’
..\share\terra\tests\hello.t:8: in main chunk.

I found out change executable to .o, will let hello.t execute without
error. But the .o still could not be used because of the undefined external
error.

I don’t know where I can link to that legacy version. I tried terralib.linklibrary
or add them to environment variable, both not work. So I’m wondering if
you know where I should link to that .lib. Thank you.

Sincerely,

Yan

On Thu, Nov 30, 2017 at 7:58 PM Elliott Slaughter <
***@***.***> wrote:

> I think if you want to use saveobj to generate a .o file you will need
> to use the MSVC compiler to link the final executable, given that stdio.h
> came from that compiler. (You mentioned using g++ above.)
>
> I unfortunately don’t know anything about running MSVC, but from the
> article you linked it sounds like there is a legacy version of the
> functions you can link to if necessary? It’s not completely clear if you
> need those or not.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#177 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AH0KC9JNOx54G0CwefUTGsNoApalXf4oks5s73l5gaJpZM4IsF0M>
> .
>

Источник

При компиляции выдает ошибку:
helloworld.c:1:19: fatal error: stdio.h: No such file or directory
#include

#include <stdio.h>

int main()
{
    printf("This is a native C program.\n");
    return 0;
}

Вопрос задан

более трёх лет назад
8398 просмотров

Пригласить эксперта

Как исправить ошибку «stdio.h: No such file or directory »?

Понять почему она возникает:
— запустить компиляцию с опцией -v: gcc -v helloworld.c -o helloworld
— найти в выводе строки

#include "..." search starts here:
#include <...> search starts here:

— посмотреть что за каталоги идут после них, есть ли эти каталоги в твоей системе
— посмотреть, есть ли в твоей системе stdio.h, и если есть, то где
— написать сюда результаты выполнения предыдущих шагов.

Показать ещё
Загружается…

09 окт. 2023, в 10:00

2500 руб./за проект

09 окт. 2023, в 09:40

6000 руб./за проект

08 окт. 2023, в 23:50

5000 руб./за проект

Минуточку внимания

Источник

sweeney: CodeLite Curious; Posts: 2; Joined: Mon Dec 09, 2019 1:36 pm; Genuine User: Yes; IDE Question: C++; Contact:

‘stdio.h’ not found

I have noticed in Codelite 13.0.x and 14.0.x on Windows 10, the code editor will complain the C standard headers files like stdio.h are cannot be found when working on a C program, but has no issues with C++ standard headers like iostream when working a C++ program.
It seems to make no difference which whether cygwin or mingw compiler is selected and the source code compiles fine without issues. On FreeBSD/clang setup I have, the issue is not present.
Any ideas why this would be the case?

You do not have the required permissions to view the files attached to this post.

sweeney: CodeLite Curious; Posts: 2; Joined: Mon Dec 09, 2019 1:36 pm; Genuine User: Yes; IDE Question: C++; Contact:

Re: ‘stdio.h’ not found

Post

by sweeney » Wed Nov 25, 2020 3:43 pm

I find it funny how codelite knows about the standard printf function and complains about stdio.h not being included, but cannot find the stdio.h file specified at the top of the file…

You do not have the required permissions to view the files attached to this post.

Источник

Remove From My Forums

Question
I searched and didn’t see anyone with my problem. I am taking «Intro to C» this quarter and they use Visual Studio, so to get a headstart I downloaded VS C++ 2005 Express edition. When I try to compile a standard C program I always get an error. I did a search and can’t find <stdio.h> anywhere even with part of that name. I get this error:

1>—— Build started: Project: test, Configuration: Debug Win32 ——
1>Compiling…
1>test.c
1>c:\documents and settings\administrator\my documents\visual studio 2005\projects\test\test\test.c(13) : fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add ‘#include «stdafx.h»‘ to your source?
1>Build log was saved at «file://c:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\test\test\Debug\BuildLog.htm»
1>test — 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Here’s the code:

#include <stdio.h>

int main()
{

printf(«hello world»);
return 0;
}

Is it possible the <stdio.h> header is missing and not installed?

Thanks.

Answers

The problem here has nothing to do with stdio.h — instead the problem is that your project settings are using precompiled headers but it is not set up correctly. The easiest way to resolve this is to turn off precompiled headers in your project settings.
Right-click your project in Solution Explorer, Properties, Configuration Properties, C/C++, Precompiled Headers, Create/Use Precompiled Header = «Not using…». Or if you used a project template to get started, just put #include «stdafx.h» at the top of your source code.

Источник

Минуточку внимания

‘stdio.h’ not found

Re: ‘stdio.h’ not found

Question

Answers