ld -execute -macosxversionmin 10.11 -lSystem -o testcprogram testcprogram.o
Does not work. You get the error that the system library can not be found.
You are using ld directly to link an executable? Why? I've never seen anyone do that.
Instead you have to use this linker command:
ld -execute -macosxversionmin 10.11 -lSystem -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -o testcprogram testcprogram.o
OK. So? You are doing something totally unique and you found a workaround - for today at least.
It is a known issue in Big Sur and is in the release notes.
I haven't see anything in the release notes about using ld. Maybe you are referring to the dynamic library cache issue. That is only incidentally related to ld.
I only found out about the work around because a lot of others on the internet already figured it out and posted about it.
Don't take advice from the internet. They don't know what they are talking about. Just use Xcode. If you absolutely must develop your apps just one level above using a hex editor, what's the difference if you have to specify the path?
If that's true, then you can't use ld to link .o files that have calls to the system library for production software anymore because the libraries will not be able to be found when xcode and the command line tools are not installed.
The ld tool is only installed as part of either Xcode or the command line tools. Ergo, Xcode or the command line tools would have to be already installed if you are using ld. But that's not the point. At best, you are talking about a small implementation detail on a low-level tool that virtually no one uses, and obviously few of those should be using it.
As you can see, I'm not using a crazy cross-platform development tool to compile this code. I'm only using the XCode command line tools cc and ld. And yes, there is a problem. I was hoping to hear Apple has say. Like if this will be fixed in the next release, or if support for ld is dropped, or if somehow using -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib with ld will work for production software. But from what you are saying, it looks like -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib is not a good solution.
I'll accept that you aren't doing anything cross-platform, but I won't go any further than that. I'm not sure what you are doing here, in more ways than one. Generally speaking, the command line tools are for building and running software on your own machine. They shouldn't be used for distributing software. That's what Xcode is for. I don't know if the command line tools would create universal binaries, for example.
But regardless, there isn't anything wrong with using "-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib", just as there isn't anything wrong with using "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib". Neither path is going to show up in the executable. That's why I suggested using "otool -L" to see how it works. It is going to say "/usr/lib/libSystem.B.dylib" using "otool -L". And you can even change that if you want, but that wouldn't be appropriate in this case.