No include path in which to find stdio h windows - Доктор Windows

I used to be able to compile C programs, but now I can’t:

$ cat helloworld.c
#include <stdio.h>

int main(void)
{
    printf("Hello, world!n");
    return 0;
}

$ gcc helloworld.c
helloworld.c:1:19: error: no include path in which to search for stdio.h

Yes, I do have /usr/include/stdio.h . Yes, build-essentials is installed.

This problem began after I modified my ~/.bashrc to run a program installed in my user directory. I know this is what’s wrong because if I remove ~/.bashrc, it works.

What environment variable would be shadowing /usr/include as an include path?

asked Nov 21, 2010 at 7:10

Joey AdamsJoey Adams

41.2k18 gold badges84 silver badges115 bronze badges

The problem was that I had another GCC in my PATH:

$ which gcc
/home/joey/gcc4ti/bin/gcc

When I was trying to compile «Hello World», it was running a compiler for a 68000, not my system compiler

I had this in my ~/.bashrc:

export PATH="/home/joey/gcc4ti/bin:$PATH"

Because paths are scanned in order, the gcc in /home/joey/gcc4ti/bin is seen first. I changed it to:

export PATH="$PATH:/home/joey/gcc4ti/bin"

answered Nov 21, 2010 at 7:15

Joey AdamsJoey Adams

41.2k18 gold badges84 silver badges115 bronze badges

Источник

Remove From My Forums

Question
Hey,

I’m using VSCode for a small C project.

Been trying to compile with gcc.exe from Mingw but it doesn’t have <winternl.h> whice I need for my code (although it has <windows.h> and other headers… but these things are beyond my understanding).

So, I tried compiling with cl.exe but apparently it has it’s own problems.

I get the error message:

fatal error C1034: stdio.h: no include path set

Any Ideas where <stdio.h> has gone? Can’t people code in C with peace?

Thanks
- Moved by
  
  Monday, January 20, 2020 6:56 AM

Источник

3645 / 1377 / 243

Регистрация: 16.04.2009

Сообщений: 4,526

24.01.2012, 22:23. Показов 8764. Ответов 7

Все привет! Столкнулся с проблемой. Установил MinGW c подписи niXman mingw-4.6.2+boost-1.48.0. Пытаюсь откомпилировать просто файл z.c хеловорлд. но выскакивает ошибка

Код

$ gcc -o z z.c
z.c:1: No include path in which to find stdio.h
z.c:2: No include path in which to find stdlib.h
 
‘‚@ANDREY-PC /c/mingw
$ g++ -o z z.c

g++ компилирует его нормально. В чем может быть проблема?
(При установке в Path указал путь к bin, переустанавливал все, без успешно)

3211 / 1459 / 73

Регистрация: 09.08.2009

Сообщений: 3,441

Записей в блоге: 2

25.01.2012, 01:37

попробуй переименовать z.c во что-то более съестное

3645 / 1377 / 243

Регистрация: 16.04.2009

Сообщений: 4,526

25.01.2012, 10:33

[ТС]

niXman, так?

Код

‘‚@ANDREY-PC /c/mingw
$ cat > hello.c
#include <stdio.h>

int main(void){
        printf("Hello worldn");
        return 0;
}

[1]+  Stopped                 cat >hello.c

‘‚@ANDREY-PC /c/mingw
$ gcc -o hello hello.c
hello.c:1: No include path in which to find stdio.h

‘‚@ANDREY-PC /c/mingw
$ g++ -o hello hello.c

‘‚@ANDREY-PC /c/mingw
$ hello.exe
Hello world

Не помогло, gcc не компилит

Добавлено через 11 минут
niXman, кстити, если не подключать никакие хедеры, то вот такие ошибки

Код

‘‚@ANDREY-PC /c/mingw
$ cat > ex.c
int main(void){
        return 1;
}

[1]+  Stopped                 cat >ex.c

‘‚@ANDREY-PC /c/mingw
$ gcc =o ex ex.c

‘‚@ANDREY-PC /c/mingw
$ gcc -o ex ex.c
gcc.exe: installation problem, cannot exec `cc1': No such file or directo

3211 / 1459 / 73

Регистрация: 09.08.2009

Сообщений: 3,441

Записей в блоге: 2

25.01.2012, 11:07

какая ОС?
куда установил MinGW?
как установил MinGW?

Добавлено через 2 минуты
попробуй без MSYS.

3645 / 1377 / 243

Регистрация: 16.04.2009

Сообщений: 4,526

25.01.2012, 11:14

[ТС]

Сообщение от niXman

попробуй без MSYS.

Из cmd запускал. Тоже самое. Или нужно msys удалить?

Сообщение от niXman

какая ОС?

Windows 7 x64

Сообщение от niXman

куда установил MinGW?

Когда распаковывал архив, указал c:mingw
Итоговый путь к bin получился C:MinGWmingwbin

Сообщение от niXman

как установил MinGW?

Затрудняюсь ответить. В path было дописано c:mingwmingwbin;c:msys1.0bin;c:msys1.0loc albin

3211 / 1459 / 73

Регистрация: 09.08.2009

Сообщений: 3,441

Записей в блоге: 2

25.01.2012, 12:14

в архиве и так лежит директория mingw.

кроме с: диска есть другие разделы? d:, e: ?
распакуй архив в корень любого из них. предварительно удалив из c: диска.
и PATH измени соответствующим образом.

MSYS для mingw`а не нужен.

3645 / 1377 / 243

Регистрация: 16.04.2009

Сообщений: 4,526

25.01.2012, 12:48

[ТС]

Сообщение от niXman

MSYS для mingw`а не нужен.

Удалил его.
Переустановил. Все также

Добавлено через 9 минут
Как бы уже решил проблему…

Добавлено через 10 минут
Был установлен еще один gcc. В общем его удалил, все заработало. Сборка Ваша работает. Спасибо Вам.

3211 / 1459 / 73

Регистрация: 09.08.2009

Сообщений: 3,441

Записей в блоге: 2

25.01.2012, 12:49

удачи

Источник

07-08-2011

#1
Registered User
Gcc compiler not finding header files
I dont know if this is the right place to post this but…

Basicaly, i cant compile a simple program like:

Code:

#include <stdio.h> int main() { printf("Hello world"); }

using the Mingws gcc c compiler, it just says that:
main.c:1: No include path in which to find stdio.h

i even tried to reinstall mingw with only the gcc compiler, but same error.

i can use a c++ compiler to compile it, but i really need the c compiler atm :
any sugestions?
07-08-2011

#2

Registered User

You likely have an bad MinGW GCC installation.
What folder/path is the MinGW installation in?
Does the file «stdio.h» exist under that path in a sub-folder?

NOTE: If you have multiple MinGW GCC installed; you MUST not have one installed in X:mingw for any drive letter in place of X.

Tim S.
07-08-2011

#3

Registered User

Originally Posted by stahta01

You likely have an bad MinGW GCC installation.
What folder/path is the MinGW installation in?
Does the file «stdio.h» exist under that path in a sub-folder?

NOTE: If you have multiple MinGW GCC installed; you MUST not have one installed in X:mingw for any drive letter in place of X.

My path is D:utilsmingw32
Its unlikely that i have a bad install of mingw, as i tried reinstaling it 2 times already ( and i also tried on the d:mingw path)
and yes, stdio.h exists in the mingw/include folder :

07-08-2011

Registered User

Open an Command prompt (cmd.exe)
Type in the following command; what version do you have?
Mine is

Code:

gcc version 4.4.1 (TDM-2 mingw32)

What does this return?

Code:

gcc -print-search-dirs

My result is this; the mingw base folder is «c:greenappsmingw_gcc4_4x_sjlj_tdm»

Code:

install: c:greenappsmingw_gcc4_4x_sjlj_tdmbin../lib/gcc/mingw32/4.4.1/
programs: =c:/greenapps/mingw_gcc4_4x_sjlj_tdm/bin/../libexec/gcc/mingw32/4.4.1/;c:/greenapps/mingw_gcc4_4x_sjlj_tdm/bin/../libexec/gcc/;/usr/libexec/gcc/mingw32/4.4.1/;/usr/libexec/gcc/mingw32/;/usr/lib/gcc/mingw32/4.4.1/;/usr/lib/gcc/mingw32/;c:/greenapps/mingw_gcc4_4x_sjlj_tdm/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/mingw32/4.4.1/;c:/greenapps/mingw_gcc4_4x_sjlj_tdm/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/
libraries: =c:/greenapps/mingw_gcc4_4x_sjlj_tdm/bin/../lib/gcc/mingw32/4.4.1/;c:/greenapps/mingw_gcc4_4x_sjlj_tdm/bin/../lib/gcc/;/usr/lib/gcc/mingw32/4.4.1/;c:/greenapps/mingw_gcc4_4x_sjlj_tdm/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/lib/mingw32/4.4.1/;c:/greenapps/mingw_gcc4_4x_sjlj_tdm/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/lib/;c:/greenapps/mingw_gcc4_4x_sjlj_tdm/bin/../lib/gcc/mingw32/4.4.1/../../../mingw32/4.4.1/;c:/greenapps/mingw_gcc4_4x_sjlj_tdm/bin/../lib/gcc/mingw32/4.4.1/../../../;/mingw/lib/mingw32/4.4.1/;/mingw/lib/

Note: The «install:» part is the important part for solving this problem.

Tim S.

Last edited by stahta01; 07-08-2011 at 10:24 AM.

07-08-2011

#5

Registered User

Originally Posted by shiroaisu

( and i also tried on the d:mingw path)

Delete or rename the folder MinGW on the D drive or delete all other MinGW installations.

Tim S.
07-08-2011

#6

Registered User

Try adding the include search path to directory. You could do this by
This will be included to the list of search paths which the compiler will look for.

ssharish

Life is like riding a bicycle. To keep your balance you must keep moving — Einstein
07-08-2011

#7

Banned

Gee… did anyone happen to notice all those «wrong way» slashes in there?

Unless MinGw does something internally to fix them, that’s not going to work on any windows install…

(Since I know this will come up… Yes, Win Vista and 7 will correct slashes for the UI elements of it’s own browsers, but no version will fix broken environment variables)
07-08-2011

#8

‘Allo, ‘Allo, Allo

Except of course, every Windows version (including MS-DOS) will correct forwards to backwards when passed to any file opening functions. Until they get there, it’s just aesthetics. The only time it matters is if you call the Nt* file functions yourself, and no sane person not writing a driver does that.

Источник

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.0VC 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, worldn»)
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.0VC 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.0VC but if the link I posted above is right then it needs to be C:Program Files (x86)Microsoft Visual Studio 14.0VCcrtsrc. 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 crtsrc 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.0VC but if the link I posted
above is right then it needs to be C:Program Files (x86)Microsoft
Visual Studio 14.0VCcrtsrc. 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. terrabin>terra ..shareterratestshello.t
llvm: program not executable

stack traceback:
[C]: in function ‘saveobj’
C:Userszdevitoterrasrcterralib.lua:3979: in function ‘saveobj’
..shareterratestshello.t:8: in main chunk

II. terralib.includepath = [[C:Program Files (x86)Windows
Kits10Include10.0.16299.0ucrt;C:Program Files (x86)Microsoft Visual
Studio 14.0VCinclude;C:UsersdengyaDocumentsOptlangterrabin]]
local c = terralib.includec(«stdio.h»)

terra hello()
c.printf(«hello, worldn»)
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:Userszdevitoterrasrcterralib.lua:3979: in function ‘saveobj’
..shareterratestshello.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:Userszdevitoterrasrcterralib.lua:3979: in function
‘saveobj’
..shareterratestshello.t:8: in main chunk

terra hello()
c.printf(«hello, worldn»)
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:Userszdevitoterrasrcterralib.lua:3979: in function
‘saveobj’
..shareterratestshello.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. terrabin>terra ..shareterratestshello.t
> llvm: program not executable
>
> stack traceback:
> [C]: in function ‘saveobj’
> C:Userszdevitoterrasrcterralib.lua:3979: in function
> ‘saveobj’
> ..shareterratestshello.t:8: in main chunk
>
>
> II. terralib.includepath = [[C:Program Files (x86)Windows
> Kits10Include10.0.16299.0ucrt;C:Program Files (x86)Microsoft
> Visual Studio 14.0VCinclude;C:Usersdengy
> aDocumentsOptlangterrabin]]
> local c = terralib.includec(«stdio.h»)
>
> terra hello()
> c.printf(«hello, worldn»)
> 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:Userszdevitoterrasrcterralib.lua:3979: in function ‘saveobj’
..shareterratestshello.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:Userszdevitoterrasrcterralib.lua:3979: in function
‘saveobj’
..shareterratestshello.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>
> .
>

Источник

F:
"C:Program Files (x86)Microsoft Visual Studio2017CommunityVCToolsMSVC14.10.25017binHostX64x64cl.exe" chrAprMax_byAdd.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25019 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

chrAprMax_byAdd.c
chrAprMax_byAdd.c(1): fatal error C1034: stdio.h: no include path set

— Please make sure you run «Developer Command Prompt for VS 20xx» or set Path variable includes «C:Program Files (x86)Microsoft Visual Studio2017CommunityVCToolsMSVC14.10.25017binHostX64x64» before that and run cl.exe in the window opened by «Developer Command Prompt for VS 20xx».

-> So now you can compile C/C++ source file without error: «fatal error C1034: stdio.h: no include path set»

F:>cl chrAprMax.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25019 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

chrAprMax.c
Microsoft (R) Incremental Linker Version 14.10.25019.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:chrAprMax.exe
chrAprMax.obj

F:>chrAprMax
Enter a string: just for fun
The character that appears the most frequently is "u" with 2 matched.

F:>cl chrAprMax.cpp -o chrAprMaxpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25019 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9035 : option 'o' has been deprecated and will be rem
oved in a future release
chrAprMax.cpp
Microsoft (R) Incremental Linker Version 14.10.25019.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:chrAprMax.exe
/out:chrAprMaxpp.exe
chrAprMax.obj

F:>chrAprMaxpp
Enter a string: just for fun
The character that appears the most frequently is "u" with 2 matched.

Источник

using gcc.exe
i dont understand how to correct this, these files are located in the same directory as gcc.exe

pl.c:65: No include path in which to find stdio.h
pl.c:66: No include path in which to find stdlib.h
pl.c:67: No include path in which to find string.h
pl.c:71: No include path in which to find winsock2.h
pl.c:72: No include path in which to find windows.h

Web Languages and StandardsC++

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.

View this solution by signing up for a free trial.

Members can start a

7-Day free trial

and enjoy unlimited access to the platform.

cool that worked for the first 4, but i guess i dont have winsock2.h or windows.h
any idea where i can get those?

ok i think i found those 2 files and a few more it was askin for, some came from microsoft and some came from the «wine» project, i dunno what that is but i hope thoes will work.

since i got all the files this is the error i now get
btw in the source it says to use the -lws2_32.lib on the end of the gcc statement

C:gcc>gcc -I C:gcc pl.c -lws2_32.lib
In file included from C:gccwinsock2.h:7299,
from HOD-ms04032-emf-expl.c:71:
C:gccpoppack.h:14: #error «Popping alignment isn’t possible since no alignment
has been pushed»

C:gcc>

ok this is getn worse, i keep finding more and more of these .h files, every version comes with its own errors.
im now getn about 100 lines of errors with winsock2.h
i dunno what to do plz help

well looks like this wont be answered here, im gonna have to find local help i think.

Источник

Раньше я мог компилировать программы на C, но теперь не могу:

$ cat helloworld.c
#include <stdio.h>

int main(void)
{
    printf("Hello, world!n");
    return 0;
}

$ gcc helloworld.c
helloworld.c:1:19: error: no include path in which to search for stdio.h

Да, у меня есть /usr/include/stdio.h . Да, build-essentials установлен.

Эта проблема началась после того, как я изменил свой ~/.bashrc для запуска программы, установленной в моем пользовательском каталоге. Я знаю, что это не так, потому что если я удалю ~/.bashrc, оно работает.

Какая переменная среды будет затенять /usr/include как включаемый путь?

1 ответы

Проблема заключалась в том, что у меня в PATH был еще один GCC:

$ which gcc
/home/joey/gcc4ti/bin/gcc

Когда я пытался скомпилировать «Hello World», он запускал компилятор для 68000, а не мой системный компилятор: D

У меня было это в моем ~/.bashrc:

export PATH="/home/joey/gcc4ti/bin:$PATH"

Поскольку пути сканируются по порядку, gcc in /home/joey/gcc4ti/bin видно первым. Я изменил его на:

export PATH="$PATH:/home/joey/gcc4ti/bin"

Создан 21 ноя.

Не тот ответ, который вы ищете? Просмотрите другие вопросы с метками

c
linux
gcc
bash

or задайте свой вопрос.

Источник

Question

Gcc compiler not finding header files

1 ответы