"stdio.h: No such file or directory" despite presence and correct search paths

LFKaupert wrote:

These are the instructions I’m following: https://github.com/gpdm/tinycore-targetdisplaymode

Does building a simple C hello app work, as shown above?

If so, this again would appear an issue with the Docker container, and you will want to ask the folks supporting this bootable Linux installer Docker for assistance.

I’d guess that the container is messing with the local include path, or there is some other incompatibility with recent macOS or recent Xcode, or the Docker doesn’t know from Apple silicon if that hardware is in use here.

And again, if this is Apple silicon, Linux is just acquiring support for Apple silicon, with Asahi Linux being probably the leading edge of that.

etresoft wrote:

LFKaupert wrote:

I'm trying to run a docker build

What does this mean?

It usually means there’s an immense amount of cross-platform baggage involved here, and the OP would like our help sorting out issues potentially deep within the cross-platform build they’re trying to use.

I’d suggest asking folks that know Docker better, or (better) whoever provided this container, as—if a command-line clang compilation works—the part of this whole stack that I know about is working.

I’d guess that the container is messing with the local include path.

I presume you mean "compile" a C file that requires stdio.h, and not execute it.

Showing my work, here's a typical install of Xcode 14.3.1 on Ventura, invoked from the shell:

$ cc x.c -o x
$ chmod o+x x
$ ./x
Kilroy was here!
$ cat x.c
#include <stdio.h>
#include <stdlib.h>
int main( int argc, char **argv ) {
  printf("Kilroy was here!\n");
  exit( EXIT_SUCCESS );
}
$ cc --version
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ sw_vers
ProductName:		macOS
ProductVersion:		13.6.1
BuildVersion:		22G313
$

Maybe this is a warning that got promoted to a full-on error somewhere in your environment or in your settings or in that Docker container? (I'd still suspect the involvement of that Docker container, too.) The default Xcode install is missing a couple of directories, but that omission doesn't trigger an error with the Xcode 14.3.1 installation:

ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks"

I'm trying to elicit from the OP what they think it means. I spent a few months out of my life that I'll never get back learning all about Docker. It's another one of those tools that are pushed on people as an "easy" way for them to build some complex system architecture. Invariably, people believe what they've been told. That leaves us here in the forums to be the bearers of bad news.

My guess is that there actually aren't any cross-platform issues here. I seem to remember something about Docker now supporting macOS Apple Silicon guests. I think the OP is trying to do that, but doesn't understand how Docker works, as evidenced by the quote, "When I go into the directory here...". In Docker, that's usually flat-out impossible. I think it would probably be easier in a macOS guest due to the monolithic nature of a default macOS installation with respect to Linux. Linux Docker containers often don't contain any unnecessary binaries like fileserver, web servers, shells, etc. But even so, there would be work on the guest side to configure remote access and on the client side to use it. ssh alone tends to throw the internet-reading crowd for a loop.

But that's all just a guess. If the OP can explain in more detail what instructions they are trying to follow, and what they are trying to accomplish, we could give more useful advice.

LFKaupert wrote:

I can see why mentioning Docker was a distracting bit of information.

I'm pretty sure that Docker is the core of your problem, not a distraction.

The error happens whenever I try to execute a .c file that requires stdio.h.

You would be compiling the .c file, not executing it.

I haven't tested other headers, I should, but I've been assuming it can't find any of them.

A better use of your time would be to explain exactly what you are trying to do, which operating system you are trying to do it on, and, ideally, what lead you to the rabbit hole that you are currently stuck in.

After reading through many forums on the topic, I've found that they all address the issue

Let's be clear. There's no issue. Those header files are in the same place they have been for a long time. You have followed some poor advice and now you're stuck. I understand that. But we can't help you until you meet us halfway. For example, you are using the "cc" command. Why? The only reason I can think that someone would suggest that would be if they were following some instructions from 1983. Now that command might still work. It's just an alias to clang, but sometimes those aliases include some legacy behaviour. But even that doesn't matter because everything that you've described works perfectly. Whatever your problem is, it's not there.

I'm wondering if this is a mac OS bug

I can assure you that it is not.

if I'm just being stupid and these search paths which I found in the method I described above are not what's being used when I'm attempting to run my commands.

You're not being stupid, you're being obstinate. There's a difference.

What commands are you trying to run? In what context and environment? That's the important part, not a distraction.

/tmp $ cat test.c
#include <stdio.h>

int main()
  {
  printf("Hello, world!\n");

  return 0;
  }
/tmp $ cc -o runit test.c
/tmp $ ./runit
Hello, world!
/tmp $ 

LFKaupert wrote:

These are the instructions I’m following: https://github.com/gpdm/tinycore-targetdisplaymode

Those instructions have nothing to do with the Mac. It is 100% Linux, and 100% Intel for that matter. It’s never going to work on your M2 Air.

Are you saying that you have an old Intel iMac and want to use it for Target Display Mode, while running Linux, while booted from USB? The only way you could do that would be to install Docker on the iMac itself and do the build there.

You would be running a standard, Mac-hosted version of Docker. Your guest OS would be Linux. When Docker is running, if it needs to build anything, it would do it with standard Linux tool chains like gcc. You would not need the Mac Command Line developer tools at all. Other than running the Docker host, you only use macOS to construct the bootable USB. Then, when you boot from that, you’re running Linux.

LFKaupert wrote:

I'm trying to run a docker build

What does this mean?