System dependent: http://pubs.opengroup.org/onlinepubs/00 ... def.h.htmlWIckedWitch wrote: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 wrote:stddefs.h belongs to the OS, not the compiler.WIckedWitch wrote:.. beats me why any gcc package should ship without its own stddef.c ..
GCC hiding standard C header files
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
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.jafadmin wrote:System dependent: http://pubs.opengroup.org/onlinepubs/00 ... def.h.htmlWIckedWitch wrote: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 wrote: stddefs.h belongs to the OS, not the compiler.
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.
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?
Like I said before, stddef.h is NOT excluded from the install. It is in a subpackage that would be automatically installed by apt.WIckedWitch wrote:... but their developers do not take that as a reason to exclude them from the compiler install package.
How is that different?
Even Debian tcc has extra header files in a separate package.
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
You can do it but it's fiddly.rcrsn51 wrote:Just out of curiosity: If your compiler install depends on things like libc6 and libc6-dev, how can you guarantee a 100% reproducible environment?
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.
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
That's fine if, when you install gcc, it hauls in all the other packages it needs to ensure that you have a complete useable compiler after the install has finished. But with tahrpup you can install a gcc from ubuntu/main and be left without a stddef,h until you manually insert it into one of the include directories or else install devx.rcrsn51 wrote:Like I said before, stddef.h is NOT excluded from the install. It is in a subpackage that would be automatically installed by apt.WIckedWitch wrote:... but their developers do not take that as a reason to exclude them from the compiler install package.
How is that different?
Even Debian tcc has extra header files in a separate package.
The critical thing there is that the installed gcc is not complete and that to set up the repeatable environment, you have to decide the order of installation of gcc and devx and then prove repeatability by checksumming.
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?
That's exactly how a package management system like dpkg/apt works.WIckedWitch wrote:That's fine if, when you install gcc, it hauls in all the other packages it needs to ensure that you have a complete useable compiler after the install has finished.
Exactly, as explained above.But with tahrpup you can install a gcc from ubuntu/main and be left without a stddef,h until you manually insert it into one of the include directories or else install devx.
So your thread title "GCC hiding standard C header files" is disingenuous. Your particular method of installing gcc was at fault.
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
But there was nothing that I saw that would have told me in advance that i needed both gcc and devx to end up with a functioning compiler. (Incidentally, it was only gcc-4.8 thst gave me the problem. gcc-4.6 installed with its own stddef.h and so didn't need devx.rcrsn51 wrote: So your thread title "GCC hiding standard C header files" is disingenuous. Your particular method of installing gcc was at fault.
Again, perhaps I should emphasise that I am talking about very high integrity testing. With all the commercial compilers I have used, the documentation explains clearly how to do the install so that you end up with a full working compiler when the install has finished. This is not the case with some versions of gcc. Installing gcc-4.6 from ubuntu/main *does* give me a complete working compiler. Installing gcc-4.8 from ubuntu/main does not.
How was I to know other than by trial and error?
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
Yes - but which complete C compiler? How could I identify it unambiguously?rcrsn51 wrote:Just to be clear, a devx contains a complete C compiler.
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?
That's true. The Ubuntu gcc-4.6 package contains stddef.h. In gcc-4.8, they split it off into a separate -dev sub-package, which would be auto-installed by the package manager.This is not the case with some versions of gcc. Installing gcc-4.6 from ubuntu/main *does* give me a complete working compiler. Installing gcc-4.8 from ubuntu/main does not.
That's why piece-meal software installation in Puppy is risky.
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
When I installed gcc-4.8, no such separate -dev subpackage was installed by PPM.rcrsn51 wrote:That's true. The Ubuntu gcc-4.6 package contains stddef.h. In gcc-4.8, they split it off into a separate -dev sub-package.This is not the case with some versions of gcc. Installing gcc-4.6 from ubuntu/main *does* give me a complete working compiler. Installing gcc-4.8 from ubuntu/main does not.
That's why piece-meal software installation in Puppy is risky.
From the point of view of a certification-level tester, I think the best maxim is never to install from a Linux respository but to get the required gcc install package direct from the relevant GNU site.
Paradoxically, though this kind of thing is nothing but obstructive when you are setting up a high-integrity test platform, it is actually very helpful when you are developing the kinds of tests that I am currently working on. It tells me, for example, what kinds of checks I need to perform to provide an assurance of the integrity of an installed compiler before I even get to running the tests proper.
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?
Or do the installation on the specific platform for which the packages were built.WIckedWitch wrote:From the point of view of a certification-level tester, I think the best maxim is never to install from a Linux respository
Tahrpup is NOT Ubuntu Trusty.
Exactly.When I installed gcc-4.8, no such separate -dev subpackage was installed by PPM.
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
Fair comment. I certainly wouldn't use tahrpup as a platform for high-integrity testing (although it's great for exposing you to problems that you may have to guard against).rcrsn51 wrote:Or do the installation on the specific platform for which the packages were built.WIckedWitch wrote:From the point of view of a certification-level tester, I think the best maxim is never to install from a Linux respository
Tahrpup is NOT Ubuntu Trusty.
I'm not sure that installing on the platform for which the package is built would necessarily steer me clear of all the problems that a high-integrity test platform has to guard against. On the other hand, once I've developed configuration integrity checks for gcc on tahrpup, I could certainly then go on to installing on a real ubuntu platform and see what else can go wrong there.
Thanks, anyway, for your engagement with this thread
*** MODS: Possibly better to retitle this thread "gcc 4.8 missing stddef.h header" ? ***
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
One last remark:rcrsn51 wrote:
Tahrpup is NOT Ubuntu Trusty.
Exactly.When I installed gcc-4.8, no such separate -dev subpackage was installed by PPM.
Interesting that you refer to what is essentially part of the IEEE 1003-1 standard for a definition of stddef.h. That definition in turn refers to the ANSI/ISO C language standard, which, at least in matters relating to C implementations, takes precedence over IEEE 1003-1.System dependent: http://pubs.opengroup.org/onlinepubs/00 ... def.h.html
Tahrpup may not be Ubuntu Trusty but neither is C POSIX, especially not when it's implemented in a cross-compiler running in a Windows environment, which is currently the case for a substantial proportion of critical embedded C applications.
Perhaps my perspective on this may seem a little narrow but I have worked in international standards for programming and formal description languages on and off for over 25 years. For matters of language definition and implementation, I always and exclusively refer to the relevant International Standard for the language. Indeed, never since 1976 have I used anything but national and international standards as my programmer's reference manuals for any language that has such a standard.
... and one last question:
What do Synaptic or apt-get do that PPM does not when it is installing packages from a ubuntu repository?
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?
C was designed to be a portable language, and as such, C compilers can be found for most architectures and Operating systems.
Examples of things that are system dependent are endianess, bytesize, integer size, and pointer size.
So while the contents of <stdio.h> will likely be the same across platforms and architectures, the content of those header files that define the hardware to the compiler will always vary.
Examples of things that are system dependent are endianess, bytesize, integer size, and pointer size.
So while the contents of <stdio.h> will likely be the same across platforms and architectures, the content of those header files that define the hardware to the compiler will always vary.
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
AFAI can see, after rummaging around more sets of header files than I care to recall over the years, architecture-specific adaptation of headers is readily, if not always entirely straightforwardly, effected by defining a (sometimes large) number of scalar parameters as macros and then conditionally compiling headers as chunks of code that are conditionally included according to the values of those parameters.jafadmin wrote:C was designed to be a portable language, and as such, C compilers can be found for most architectures and Operating systems.
Examples of things that are system dependent are endianess, bytesize, integer size, and pointer size.
So while the contents of <stdio.h> will likely be the same across platforms and architectures, the content of those header files that define the hardware to the compiler will always vary.
It is technically possible to do this without having to separate any standard headers from the compiler install package, as is routine practice in all commercially supported compilers that I have looked into. Indeed the typical practice for commercial, multi-targettable embedded C compilers, is to give a complete set of architecture-dependent standard headers for each supported target architecture - and often for different chip variants within a single architecture.
Given that there is no technical necessity for separation of standard headers from the rest of the compiler, I am at a loss to see why gcc seems to think it a good thing to do - unless as far as gcc is concerned, POSIX is the only platform they are concerned with. This, of course, makes it far harder than necessary to create verifiably repeatable installed compiler configurations, the absence of which is utter anathema in the development of critical systems.
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?
Run these two commands from a console to produce all the info about the linux gcc compiler environment:
Code: Select all
#touch a.c
#gcc -v -E a.c
Some symbolic links might help like I did here:
http://murga-linux.com/puppy/viewtopic. ... 688#992688
http://murga-linux.com/puppy/viewtopic. ... 688#992688
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
Thanks. This is helpful. Although it isn't acceptable for certification-level testing, it does tell me a lot about how I can design an environmental enquiry program to obtain the required configuration information by acceptable means (i.e. by running a conforming C test program that discovers what the config is rather than simply by asking gcc to say it).jafadmin wrote:Run these two commands from a console to produce all the info about the linux gcc compiler environment:Code: Select all
#touch a.c #gcc -v -E a.c
I'm currently putting together a prototype system written in Tcl that will generate the required conforming C test programs. More when I've got it up and running and have played with it a bit.
###### Added 23:54 GMT+1 2018-05-22
I've got the first results from my Tcl test system and have started a new thread entitled
Determining C compiler implementation characteristics #####
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?