GCC hiding standard C header files

[WIckedWitch]

Just tried to compile this to check order of evaluation of + in C:

Code: Select all

#include <stdio.h>

int main(void)
{	
	char* 	ordeval		=	"RR";
	int 	i 			=	1;	
	
	ordeval[(--i) + i)]	=	'L';
	
	return printf("+ evaluated %c%c\n", ordeval[0], ordeval[1]);
}

but gcc-4.8.2 complains with:

Code: Select all

ordeval-plus.c:3:20: fatal error: stddef.h: No such file or directory
 #include <stddef.h>
                    ^
compilation terminated.

So, it can find <stdio.h>, but can't find <stddef.h>.

WTF?

Ideas anyone?

[6502coder]

Does this help?
https://stackoverflow.com/questions/371 ... sr-include

[jafadmin]

do you have the devx sfs loaded for that puppy version?

[WIckedWitch]

@ 6502coder: alas no - AFAI can tell there's no stddef.h anywhere on my HDD

@ jafadmin: can't find devx.sfs anywhere on the HDD either - do I need it?

@ both: thx for replies - as a workaround, I rolled back to gcc 4.6.4, which *does* come with a stddef.h in a place where it looks for it - but I'm a bit freaked out that gcc 4.8.x seems not to come with its own stddef.h.

While I'll happily dive into to any number of problems that require me to devise efficient algorithms, configuration settings have always been the part of software engineering that p!sses me off. Whatever is systematic I can cope with but illogical configuration constraints just drive me nuts.

[jafadmin]

Standard puppy does not have a compiler or dev env in the initrd. Each puppy has a downloadable "devx" sfs file that you load in via the sfs loader that merges gcc, headers, and all the other essential goodies for compiling, etc.

So go to where you downloaded the initial livecd iso and download the matching "devx" sfs file and put it in the same dir as your puppy sfs, then after booting, use the sfs loader in your distro to load the devx.

Now you can R&R ..

[WIckedWitch]

So go to where you downloaded the initial livecd iso and download the matching "devx" sfs file and put it in the same dir as your puppy sfs, then after booting, use the sfs loader in your distro to load the devx.

Now you can R&R ..

Yep - that fixed it - murky buckets

[jafadmin]

So go to where you downloaded the initial livecd iso and download the matching "devx" sfs file and put it in the same dir as your puppy sfs, then after booting, use the sfs loader in your distro to load the devx.

Now you can R&R ..

Yep - that fixed it - murky buckets

Pas de quoi

[WIckedWitch]

@jafadmin - beats me why any gcc package should ship without its own stddef.c - but ours, sans doute, is not to reason why.

thanks again

[jafadmin]

.. beats me why any gcc package should ship without its own stddef.c ..

stddefs.h belongs to the OS, not the compiler.

[rcrsn51]

In Debian Stretch, the file stddef.h is in the package libgcc-6-dev. It is a dependency of gcc-6, which is a dependency of gcc, which is a dependency of build-essential.

So in Debian, you can get a compiler environment with just one package - build-essential.

A Puppy devx will have all the equivalent stuff from its parent distro. But if all you download is a single gcc package, you won't get stddef.h.

[WIckedWitch]

A Puppy devx will have all the equivalent stuff from its parent distro. But if all you download is a single gcc package, you won't get stddef.h.

Given that stddef.h is a standard header defined by the ISO C standards, I find it bizarre that a gcc package may not itself come with it.

Perhaps I should explain the basis for this concern. One of my professional activities is on-target C compiler validation using either the Perennial or SolidSands test suite. For proprietary embedded C compilers such as IAR, Tasking, Keil, etc. you get a *complete* C implementation with their distribution images. Running the installer gives a readily reproducible implementation, so the compiler validator can know exactly what it is that is being tested.

Contrast this with gcc-based embedded C compilers. I have yet to satisfy myself that the installation from distribution images of any such compiler is actually reproducible. Consequently, I can never know for sure exactly what it is that I have tested. I cannot confidently say that I have tested gcc-x.y because I have no reference installation against which to compare any particular installation I have made.

So much, then for compliance with the C standards. Yes, what you are testing might pass every conformance test in a validation suite - but you still cannot say unambiguously what the implementation under test actually was.

BnMMER!

[rcrsn51]

Given that stddef.h is a standard header defined by the ISO C standards, I find it bizarre that a gcc package may not itself come with it.

I expect that jafadmin is correct about this. The gcc compiler is meant to be multi-OS. So the OS-specific stuff has been split off into a separate package.

Even then, Debian gcc is not one single package. There are a number of sub-packages that also need loading.

If you install the compiler via apt, this is all transparent.

It's only when you try to install it piece-meal that problems arise.

Consequently, I can never know for sure exactly what it is that I have tested. I cannot confidently say that I have tested gcc-x.y because I have no reference installation against which to compare any particular installation I have made.

I don't understand this. Are you trying to load multiple gcc's into the same environment?

[WIckedWitch]

Given that stddef.h is a standard header defined by the ISO C standards, I find it bizarre that a gcc package may not itself come with it.

I don't understand this. Are you trying to load multiple gcc's into the same environment?

I do have multiple gcc's in one environment, but that is not the problem with which I am concerned. In the UK I am qualified as an assessor for compiler testing for UKAS, the body that provides accreditation to ISO/IEC 17025 for measurement and test laboratories. To meet that standard, all assessed testing and measurement must be both repeatable and reproducible.

For compiler testing to be repeatable, it must be possible to set up a test system that has exactly the same compiler configuration as in a previous test and that matches the configuration in the user's development and build environments. If an installed gcc relies on picking up header files that it does not itself define, then how can I show that the gcc I am testing on one occasion is the same gcc that I test on a subsequent occasion? If I cannot be sure of or otherwise demonstrate this, then I have no hope of making testing repeatable.

If an installation image is complete in itself and is simply a directory structure subject to simple scalar parameterisation, then I can provide the necessary assurance of repeatability by recursively checksumming the directory tree. Otherwise I'm not sure how I can obtain such an assurance.

This is not academic quibbling. I have already had to pull out from validation assignments for gcc-based C compilers because the clients were not able to demonstrate that a cleanly installed gcc configuration is the same as they use in their development and build environments. It is because of these difficulties that I am currently developing a suite of test programs that attempt to determine by testing what the installed configuration actually is. This is also an essential precursor to configuring static analysis tools to verify C programs compiled with gcc.

[rcrsn51]

What if your compiler is self-contained in a single squashfs module like the Puppy devx? Does that guarantee reproducibility?

[WIckedWitch]

.. beats me why any gcc package should ship without its own stddef.c ..

stddefs.h belongs to the OS, not the compiler.

What do you mean by "belongs to the OS"? The stddef.h header is specified in the C language standards, C90, C99, etc. Certification-quality compiler testing must always be traceable to the language standard. If a compiler does not provide its own stddef.h, then that compiler cannot guarantee that it complies with the standard if it picks up a stddef.h from another source.

[jafadmin]

.. beats me why any gcc package should ship without its own stddef.c ..

stddefs.h belongs to the OS, not the compiler.

What do you mean by "belongs to the OS"? The stddef.h header is specified in the C language standards, C90, C99, etc. Certification-quality compiler testing must always be traceable to the language standard. If a compiler does not provide its own stddef.h, then that compiler cannot guarantee that it complies with the standard if it picks up a stddef.h from another source.

System dependent: http://pubs.opengroup.org/onlinepubs/00 ... def.h.html

[rcrsn51]

Just out of curiosity: If your compiler install depends on things like libc6 and libc6-dev, how can you guarantee a 100% reproducible environment?

[WIckedWitch]

stddefs.h belongs to the OS, not the compiler.

What do you mean by "belongs to the OS"? The stddef.h header is specified in the C language standards, C90, C99, etc. Certification-quality compiler testing must always be traceable to the language standard. If a compiler does not provide its own stddef.h, then that compiler cannot guarantee that it complies with the standard if it picks up a stddef.h from another source.

System dependent: http://pubs.opengroup.org/onlinepubs/00 ... def.h.html

Virtually all of the standard library headers that come with C cross-compilers for microcontrollers are system-dependent but their developers do not take that as a reason to exclude them from the compiler install package.

Honestly, some of the things gcc does are utterly insane from the point of view of an embedded systems developer working on critical systems.

Still, my suite of tests for implementation-defined and unspecified characteristics will at least be able to tell the user that he has a missing stddef.h and tell him where best to put one if he has to get one from elsewhere.

[rcrsn51]

... but their developers do not take that as a reason to exclude them from the compiler install package.

Like I said before, stddef.h is NOT excluded from the install. It is in a subpackage that would be automatically installed by apt.

How is that different?

Even Debian tcc has extra header files in a separate package.

[WIckedWitch]

Just out of curiosity: If your compiler install depends on things like libc6 and libc6-dev, how can you guarantee a 100% reproducible environment?

You can do it but it's fiddly.

On Linux platforms the best way to go about setting up a repeatable test system is to figure out what you need to install in what order from which repositories to get what you want. Then you install the preferred Linux on a bare machine and then install, in the right order, what you have determined will give you a repeatable environment. And you should checksum the relevant directory trees to prove that the installation is repeatable.

Much the same goes for Windows - provided that you install from DVD release media and never connect to the Internet for updates. There you are most likely to be installing a commercially supported gcc + MinGW compiler. That will give you all the standard headers you need but once again, you need to prove that it's repeatable by directory checksumming.

Either way, if the C implementation passes validation tests, this can be certified only for the given platform/version and the given installed compiler configuration/version. Certification does not carry over to other installations just because it's all gcc underneath - though the great unwashed of the C world rarely accept this until you demonstrate to them what can go wrong if you don't take all the right technical precautions.