Fatal error stdio h file not found

macOS Sierra 10.12.6 with Xcode 8.3.3
Followed building instructions, I get gum/meson-private/sanitycheckobjc.m:1:8: fatal error: 'stdio.h' file not found

Checking the isysroot path, stdio.h is present in /usr/include/.

Macbook:frida macbook$ make core-macos
FRIDA_HOST=macos-x86_64 
		FRIDA_OPTIMIZATION_FLAGS="-Os" 
		FRIDA_DEBUG_FLAGS="-g3" 
		FRIDA_ASAN=no 
		./releng/setup-env.sh
Environment created. To enter:
# source /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-env-macos-x86_64.rc
. build/frida-env-macos-x86_64.rc && cd frida-gum/bindings/gumjs && npm install

> fsevents@1.1.2 install /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/frida-gum/bindings/gumjs/node_modules/fsevents
> node install

[fsevents] Success: "/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/frida-gum/bindings/gumjs/node_modules/fsevents/lib/binding/Release/node-v57-darwin-x64/fse.node" already installed
Pass --update-binary to reinstall or --build-from-source to recompile
npm notice created a lockfile as package-lock.json. You should commit this file.
added 450 packages in 10.03s
FRIDA_HOST=macos-x86 
		FRIDA_OPTIMIZATION_FLAGS="-Os" 
		FRIDA_DEBUG_FLAGS="-g3" 
		FRIDA_ASAN=no 
		./releng/setup-env.sh
Environment created. To enter:
# source /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-env-macos-x86.rc
. build/frida-env-macos-x86.rc 
		&& export PACKAGE_TARNAME=capstone 
		&& . $CONFIG_SITE 
		&& case macos-x86 in 
			*-x86)    capstone_archs="x86"         ;; 
			*-x86_64) capstone_archs="x86"         ;; 
			*-arm)    capstone_archs="arm"         ;; 
			*-arm64)  capstone_archs="aarch64 arm" ;; 
		esac 
		&& make -C capstone 
			PREFIX=$frida_prefix 
			BUILDDIR=../build/tmp-macos-x86/capstone 
			CAPSTONE_BUILD_CORE_ONLY=yes 
			CAPSTONE_ARCHS="$capstone_archs" 
			CAPSTONE_SHARED=$enable_shared 
			CAPSTONE_STATIC=$enable_static 
			install
  GEN     capstone.pc
  CC      cs.o
  CC      utils.o
  CC      SStream.o
  CC      MCInstrDesc.o
  CC      MCRegisterInfo.o
  CC      arch/X86/X86DisassemblerDecoder.o
  CC      arch/X86/X86Disassembler.o
  CC      arch/X86/X86IntelInstPrinter.o
  CC      arch/X86/X86ATTInstPrinter.o
  CC      arch/X86/X86Mapping.o
  CC      arch/X86/X86Module.o
  CC      MCInst.o
  AR      libcapstone.a
ar: creating archive /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/tmp-macos-x86/capstone/libcapstone.a
mkdir -p /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86/lib
install -m0644 /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/tmp-macos-x86/capstone/libcapstone.a /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86/lib
mkdir -p /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86/include/capstone
install -m0644 include/*.h /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86/include/capstone
mkdir -p /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86/lib/pkgconfig
install -m0644 /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/tmp-macos-x86/capstone/capstone.pc /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86/lib/pkgconfig/
. build/frida-meson-env-macos-x86_64.rc; 
	builddir=build/tmp-macos-x86/frida-gum; 
	if [ ! -f $builddir/build.ninja ]; then 
		mkdir -p $builddir; 
		python3 /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/releng/meson/meson.py 
			--prefix /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86 
			--cross-file build/frida-macos-x86.txt 
			--default-library static --buildtype minsize --strip -Denable_diet=auto 
			frida-gum $builddir || exit 1; 
	fi; 
	/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/releng/ninja-macos-x86_64 -C $builddir install || exit 1
The Meson build system
Version: 0.41.0.dev1
Source dir: /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/frida-gum
Build dir: /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/tmp-macos-x86/frida-gum
Build type: cross build
Project name: frida-gum
Native c compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang (clang 8.1.0)
Appending CFLAGS from environment: '-include /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-version.h -fPIC -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -mmacosx-version-min=10.9 -arch x86_64 -I/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86_64/include -I/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/sdk-macos-x86_64/include'
Appending LDFLAGS from environment: '-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -Wl,-macosx_version_min,10.9 -arch x86_64 -Wl,-dead_strip -Wl,-no_compact_unwind -L/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86_64/lib -L/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/sdk-macos-x86_64/lib'
Appending CPPFLAGS from environment: '-include /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-version.h -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -mmacosx-version-min=10.9 -arch x86_64 -I/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86_64/include -I/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/sdk-macos-x86_64/include'
Cross c compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang (clang 8.1.0)
Native cpp compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ (clang 8.1.0)
Appending CXXFLAGS from environment: '-fPIC -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -mmacosx-version-min=10.9 -arch x86_64 -I/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86_64/include -I/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/sdk-macos-x86_64/include -stdlib=libc++ -fno-rtti'
Appending LDFLAGS from environment: '-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -Wl,-macosx_version_min,10.9 -arch x86_64 -Wl,-dead_strip -Wl,-no_compact_unwind -L/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86_64/lib -L/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/sdk-macos-x86_64/lib'
Appending CPPFLAGS from environment: '-include /Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-version.h -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -mmacosx-version-min=10.9 -arch x86_64 -I/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/frida-macos-x86_64/include -I/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/sdk-macos-x86_64/include'
Cross cpp compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ (clang 8.1.0)
Host machine cpu family: x86
Host machine cpu: x86
Target machine cpu family: x86
Target machine cpu: x86
Build machine cpu family: x86_64
Build machine cpu: x86_64
/Users/macbook/Dev/Clones/ReversingTools/frida/source/frida/build/tmp-macos-x86/frida-gum/meson-private/sanitycheckobjc.m:1:8: fatal error: 'stdio.h' file not found
#import<stdio.h>
       ^
1 error generated.

Meson encountered an error in file meson.build, line 15, column 2:
ObjC compiler /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang can not compile programs.
make[1]: *** [build/frida-macos-x86/lib/pkgconfig/frida-gum-1.0.pc] Error 1
make: *** [core-macos] Error 2

GCC fatal error: stdio.h: No such file or directory

I’m trying to compile a program in C on OS X 10.9 with GCC 4.9 (experimental). For some reason, I’m getting the following error at compile time:

I then tried a simple Hello World program:

Again, upon running gcc -o

/hello.c , I got the same error. I’m using an experimental version of gcc , but it seems implausible that there would be a release which generated errors upon importing stdio . What could be causing this issue, and how can it be fixed?

5 Answers 5

macOS

I had this problem too (encountered through Macports compilers). Previous versions of Xcode would let you install command line tools through xcode/Preferences, but xcode5 doesn’t give a command line tools option in the GUI, that so I assumed it was automatically included now. Try running this command:

If you see an error message that developer tools are already installed (and still header files can’t be found), wipe out any existing one to do a fresh installation:

Ubuntu

Alpine Linux

Mac OS Mojave

The accepted answer no longer works. When running the command xcode-select —install it tells you to use «Software Update» to install updates.

In this link is the updated method:

Open a Terminal and then:

This will open an installation Wizard.

Update 12/2019

After updating to Mojave 10.15.1 it seems that using xcode-select —install works as intended.

Источник

fatal error: stdio.h: No such file or directory

I have a problem with #include on mac Mojave 10.14.1

I have a default gcc compiler together with other gcc compilers.

Now I am in the path : /Users/dorothy/Desktop

I have stdio.h in the lib

However when I compile the file under the current path /Users/dorothy/Desktop Terminal will give me an error:

2 Answers 2

I still have a problem linking gcc with stdio.h on my mac. However, I have found an alternative way to compile the program with gcc . I typed brew install gcc in my terminal, that means a new gcc8.0.2 will be installed.(which is my case, I don’t know what gcc you will get) Then I use gcc-8 instead of gcc to compile my program. In this way, the new gcc8.0.2 is invoked.

You can check the command name for gcc variants by going to /usr/local/bin All the names for gcc commands are listed there. As for me, those are

If you have further question, you can contact me and I will give more details.

@Jonathan Leffler is right. Apple made another big cake for us. Since /usr/include has been moved (now it in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include after you install commandline tools), old versions of gcc build cannot find the most bottom level include files. And this is a problem. (What are there in their head) So only you are developer you use /usr/include?

This is NOT Unix-like.

Here is what happened. For gcc-4.9(gcc-4.9 and gcc-9 below are all brew gcc.), the include search paths are:

There is system level file stdio.h, this is why stdio.h cannot be found.

is:

Refer to /usr/local/Cellar/gcc@4.9/4.9.4_1/lib/gcc/4.9/gcc/x86_64-apple-darwin17.3.0/4.9.4/include/ssp/stdio.h

#include_next means include next one name stdio.h, this one is just a guider.

Give a deprecated shot. cp all files in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include to /usr/local/Cellar/gcc@4.9/4.9.4_1/lib/gcc/4.9/gcc/x86_64-apple-darwin17.3.0/4.9.4/include-fixed, gcc-4.9 will work again.

But for gcc-9 the path problem is fine. See:

Actually this bug can be simply fixed by reinstall xcode commandline tools, after that gcc-4.9 will work again.

Источник

Cannot find stdio.h

I am using macOS.

I am trying to build the code of mozilla-central.

While running the command ./mach build , the build fails at the compile step. Here are the relevant stack traces:

According to me, the root cause is:

The solution listed online was to install xcode command line tools using:

I have already done this.

7 Answers 7

The root reason is due to a missing /usr/include directory.

Installing command-line tools ( xcode-select —install ), sometimes, will not automatically add it.

The Link shows the correct way: After installing command-line tools Install the package at:

you should have a directory /usr/include with header files

Try setting SDKROOT explicitly to the system SDK:

Doing it avoids the need for creating symlinks in /usr .

This error seem recurrent, for example, if you installed another compiler (e.g. gcc from brew). Setting SDKROOT became so common that it might be a good idea to add it to

I had the same problem for compiling R packages, and running xcode-select —install and macOS_SDK_headers_for_macOS_10.14.pkg did not solve the problem.

I discovered that there seems to be some confusion from Apples side between macOS 10.14 and 10.15, since I’m running Mojave (10.14) with the latest xcode 11.0 (11A420a), and when clang compiles it looks for the MacOSX10.14.sdk sysroot directory in

but there only MacOSX10.15.sdk is present (along with other stuff). I fixed this with

pushd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ sudo ln -s MacOSX.sdk MacOSX10.14.sdk popd

Now I can install packages in RStudio again.

This is a comment to Rick Li. It’s too long to fit into comment area.

The solution provided by Rick Li isn’t necessary the correct way. It’s only the easiest way. According to Xcode 10 release note:

…If you are the maintainer of such software, we encourage you to update your project to work with the SDK or file a bug report for issues that are preventing you from doing so. As a workaround, an extra package is provided which will install the headers to the base system. In a future release, this package will no longer be provided. …

So the right way is to contact Mozilla team that their application won’t build without hack. It will break eventually.

If you don’t take this seriously, it would bite you in future. I still recall that Apple deprecated 32-bit application on macOS 10.13 (High Sierra). Now they formally disabled it in macOS 10.15 (Catalina) and I hear about people crying everywhere. Be responsible of your choice.

Источник

Cannot find stdio.h

I am using macOS.

I am trying to build the code of mozilla-central.

While running the command ./mach build , the build fails at the compile step. Here are the relevant stack traces:

According to me, the root cause is:

The solution listed online was to install xcode command line tools using:

I have already done this.

7 Answers 7

The root reason is due to a missing /usr/include directory.

Installing command-line tools ( xcode-select —install ), sometimes, will not automatically add it.

The Link shows the correct way: After installing command-line tools Install the package at:

you should have a directory /usr/include with header files

Try setting SDKROOT explicitly to the system SDK:

Doing it avoids the need for creating symlinks in /usr .

This error seem recurrent, for example, if you installed another compiler (e.g. gcc from brew). Setting SDKROOT became so common that it might be a good idea to add it to

I had the same problem for compiling R packages, and running xcode-select —install and macOS_SDK_headers_for_macOS_10.14.pkg did not solve the problem.

I discovered that there seems to be some confusion from Apples side between macOS 10.14 and 10.15, since I’m running Mojave (10.14) with the latest xcode 11.0 (11A420a), and when clang compiles it looks for the MacOSX10.14.sdk sysroot directory in

but there only MacOSX10.15.sdk is present (along with other stuff). I fixed this with

pushd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ sudo ln -s MacOSX.sdk MacOSX10.14.sdk popd

Now I can install packages in RStudio again.

This is a comment to Rick Li. It’s too long to fit into comment area.

The solution provided by Rick Li isn’t necessary the correct way. It’s only the easiest way. According to Xcode 10 release note:

…If you are the maintainer of such software, we encourage you to update your project to work with the SDK or file a bug report for issues that are preventing you from doing so. As a workaround, an extra package is provided which will install the headers to the base system. In a future release, this package will no longer be provided. …

So the right way is to contact Mozilla team that their application won’t build without hack. It will break eventually.

If you don’t take this seriously, it would bite you in future. I still recall that Apple deprecated 32-bit application on macOS 10.13 (High Sierra). Now they formally disabled it in macOS 10.15 (Catalina) and I hear about people crying everywhere. Be responsible of your choice.

Источник

Cannot open include file: ‘stdio.h’ — Visual Studio Community 2017 — C++ Error

I am trying to build a solution on Visual Studio Community 2017, but I keep getting the error «Cannot open include file: ‘stdio.h’ «.

I’ve read through several similar questions, but I still can’t fix this problem. It looks like the stdio.h file is called in the stdafx.h file. Below are more details. Any suggestions?

System details:

• Windows 10
• Visual Studio Community 2017 v.15.2 (26430.6) — Installed Desktop Development with C++ (Screenshot: Installation list)

Step 1: I wrote the famous Hello, World! program in C++.

Step 2: I clicked on Build → Build Solution.

Problem: ‘stdio.h’: No such file or directory. Full Error:

Troubleshooting details and things I’ve tried:

Configuration Properties* → VC++ Directories Include Directories $(VC_IncludePath);$(WindowsSDK_IncludePath);

Code in stdafx.cpp file:

Code in stdafx.h file:

NOTE: the #include for and both have the red squiggle line underneath, and says «cannot open source file».

Tried: I tried removing the last two lines, but then I got more errors.

Tried: Since many suggested that stdafx.h is not required, I tried removing just the first line, #include «stdafx.h» . But in order for this to work I had to do a little more. See the answer below.

14 Answers 14

I got same problem with a project porting from Visual Studio 2013 to Visual Studio 2017.

Fix: change Properties → General → Windows SDK Version to 10

Faced the problem of missing stdlib.h and stdio.h (and maybe more) after installing VS2017 Community on a new computer and migrating a solution from VS2013 to VS2017.

Used @Maxim Akristiniy’s proposal, but still got error message regarding toolset compatibility. However VS itself suggested to do solution retarget by right-clicking on the solution in Solution Explorer, then selecting Retarget solution from the menu and the updated Windows SDK Version from the drop-down list.

Now my projects build w/o a problem.

Note that you may need to make the project your startup project for the retargeting to catch.

There are three ways to solve this issue.

1. Ignore Precompiled Headers #1
   Steps: Project > Properties > Configuration Properties > C/C++ > Command Line > in the Additional Options box add /Y-. (Screenshot of Property Pages) > Ok > Remove #include «stdafx.h»
2. Ignore Precompiled Headers #2
   Steps: File > New > Project > . > In the Application Wizard Window click Next > Uncheck the Precompiled Header box > Finish > Remove #include «stdafx.h»

Reinstall Visual Studio
This also worked for me, because I realized that maybe there was something wrong with my Windows SDK. I was using Windows 10, but with Windows SDK 8.1. You may have this problem as well.
Steps: Open Visual Studio Installer > Click on the three-lined Menu Bar > Uninstall > Restart your computer > Open Visual Studio Installer > Install what you want, but make sure you install only the latest Windows SDK 10, not multiple ones nor the 8.1.

The first time I installed Visual Studio, I would get an error stating that I needed to install Windows SDK 8.1. So I did, through Visual Studio Installer’s Modify option. Perhaps this was a problem because I was installed it after Visual Studio was already installed, or because I needed SDK 10 instead. Just to be safe I did a complete reinstall.

Источник