gcc: installation problem, cannot exec `stddef.h ' No such file or directory
 

I read carefully the similar threads about the similar question. But still have problem unsolved. I use another PC running Fedora14(32-bit).
I installed the gcc by 'yum install gcc', then the i686-redhat-linux/4.5.1 is mounted. At first I also met the problem to find out cc1, after I re-install gcc , this error has disappeared.But another
error appears when I do 'make'.

I type 'locate stddef.h', it clearly exists in
/usr/include/linux/stddef.h
/usr/lib/gcc/i686-redhat-linux/3.4.6/include/stddef.h
/usr/lib/gcc/i686-redhat-linux/4.5.1/include/stddef.h
/usr/local/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/include/stddef.h
/usr/local/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/install-tools/include/stddef.h
/usr/share/man/man0p/stddef.h.0p.gz

What should I do to solve this problem?
(because I want to run g77, so I also install 'compat-gcc-34-g77-3.4.6-20.fc14.i686' is it contradictory to others?)

Thanks in advance for help.

Which software are you trying to compile ? ?



And about g77 : Works perfectly together with the other compilers.

And what is the exact error message ? Copy-paste the full error message, starting from the command line executed by 'make', here.

The thread name, i.e. the "cannot exec `stddef.h ' No such file or directory" part of it, doesn't make sense to me - stddef.h is not an executable file in the first place.

Last year I had problem in mounting 'pgplot' in my own PC (running Fedora14(32-bit), and I got many helps from 'linuxquestions.org'. At last I mounted g77 and solved it because I must run my many programs using 'pgplot' written with g77. After mounting g77, all the old steps in the instructions of installation of 'pgplot' need not to change.
This time I want to help my colleague to mount 'pgplot' in his PC (also run Fedora 14 (32-bit)), but failed. The process are as follows:
1.Follow the instructions of mounting 'pgplot' step by step, and then in directory '/usr/local/pgplot' to type:
/usr/local/src/pgplot/makemake /usr/local/src/pgplot linux g77_gcc'
2.The PC run smoothly, then type
'make'
3.It run smoothly at first, then stoped at some step, as shown below:
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grrec0.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grrect.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grsci.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grscr.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grscrl.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grsetc.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grsets.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grsfnt.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grsize.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grskpb.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grslct.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grsls.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grslw.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grsyds.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grsymk.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grsyxd.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grterm.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grtext.f
g77 -g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grtoup.f
c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grtrim.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grtrn0.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grtxy0.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grvct0.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grwarn.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grxhls.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/src/grxrgb.f
g77 -c -u -Wall -fPIC -O grexec.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/drivers/nudriv.f
g77 -c -u -Wall -fPIC -O /usr/local/src/pgplot/drivers/psdriv.f
gcc -c -Wall -fPIC -DPG_PPU -O -I. -I/usr/X11R6/include /usr/local/src/pgplot/drivers/xwdriv.c
In file included from /usr/local/src/pgplot/drivers/xwdriv.c:89:0:
/usr/include/stdlib.h:33:20: fatal error: stddef.h: No such file or directory
compilation terminated.
make: *** [xwdriv.o] Error 1
-------------------
Please note that I do the same steps as I did in my own PC.
As an old man, I do not understand why?
Thanks for reading and help

How about the usual # yum install pgplot
http://www.linuxquestions.org/questi...ra13-827192/#5
.. which is about the rpmfusion version, built with f95 :
pgplot-5.2.2-31.fc11


The Fedora pgplot source + the 5 patches: pgplot-5.2.2-31.fc11.src.rpm
http://download1.rpmfusion.org/nonfr...1.fc11.src.rpm

..

As an old man I learn a lot from all of you about how to use PC and linux. But my problem of pgplot still exists. I asked the author of pgplot (Prof.Pearson). He said it is not the pgplot itself, he wanted me to check other common C programs. I did it and found what he said imay be true.
(I never use C language in my work),Now I compile a simple C program copied from textbook and get the same error message as below:
------------------------
gcc -Wall simple.c -o simple.o
In file included from simple.c:5:0:
/usr/include/stdio.h:34:21: fatal error: stddef.h: No such file or directory
compilation terminated.
----------------------------
Therefore, could you please tell me the detailed steps about how to install gcc correctly in the PC? Should I delete the mounted old gcc first?

Many thanks for reading and help

Well, if gcc can't find its own stddef.h, I guess you can do something like:

GCC 4.5.1 :
gcc -I/usr/lib/gcc/i686-redhat-linux/4.5.1/include/ -I/usr/include

GCC 3.4.6 :
gcc34 -I/usr/lib/gcc/i686-redhat-linux/3.4.6/include/ -I/usr/include


( I don't remember the order of the options, input, output file for
"gcc -Wall simple.c -o simple.o" when -I (upper case i) is used.)

I have reinstalled gcc, and I already installed g77, now I can run all my previous programs using pgplot written in g77 again.
Thank you very much.

Bug not resolved
 

GCC and GLIBC both have <stdlib.h>

neither install them

this isn't a temporary problem they are both doing it for several years now

PROBLEM NOT SOLVED

usr/lib/gcc-lib/i386-slackware-linux/stddef.h

(old but good, actually the same file but old has NO COPYRIGHT notice !)

so the tradition for (gcc/glibc) has been it was not in /usr/include

also the "linux one" that defines true - your not supposed to install /usr/src/linux/include - rtfm linux readme you'll be happy you did

------------------------
a good question. did old linux find <stddef.h> as part of (libexec) part of it's own files as it would, say,

WHY ISNT IT FINDING IT TODAY ??

i know one thing: i read the "newly hacked" "header install script". and it doesn't look right. i refuse to run it - looks like it does allot of guessing, is badly coded, and will do more harm than good.

then another question: why has new GCC and GLIBC teams opted to make "remote phone home debugging libs" default and when you use --disable-foo they do not disable ? or install somthing that tampers with stacks putting "canaries" (breaks anything that uses stacks) ? or are hacking in new functions that cause a need to upgrade compiler to be able to compile code ? (__builtins) that do little: an nothing a little .c or .h couldn't have done ?

there is definitely some suspicious activity

but as to whether <stddef.h> is supposed to "just work" on past linux distro's - i have a problem remembering if it did - but i dont remember that specific problem (there were many)

often instead of fixing a problem they hacked. for example? is strlcpy in BSD but not in linux ? they would hack things that didn't work instead of adding strlcpy.c

but they aren't doing that anymore - you'll find things like "bcopy.c" ready and available

but not stddef.h ... and it's years now no one left any reason or answered allot of people asking the question

and my problem is i see a continual flow of edits that break things that work and favor softwares that didn't work (thus need new support built-in to cover up not working)

a continual flow of things broken and what's the offered replacement: improvement yes (and some well intended). but also forced use of allot of things that are HIGHLY questionable both in code and in intent

we then ALSO see certain people holding what isn't broken while others struggle to get the basics working - that should be easy and clockwork

Not solved - oops
 

come to think of it i have broken code asking for something simple bailing out:

#include <stddef.h>

but i get NULL defined i use it in my programs and never include <stddef.h> which defines NULL if i am correct

this MIGHT mean they hacked away the file but it is read (in libexec) but not found - but that old programs which need it the line can be removed. (problem - that's a B(*#TH and a waste of time)

i have the problem the program doesn't work anyway - and maybe that is due to actual broken code

i'm not liking the new headers. they use FOO##fob(dink)

to define FOOA1 FOOA2 . but only a short list. then when i have broken code and try to find some FOO define: i can't find it. it's hidden. and only whoever removed it has "the key" to what was removed. was it to save 200 bytes ? or to confuse me?

that was done long ago though - nothing new

one thing is for sure: it breaks old software and costs time in many ways. these "improvements"

Sorry, I cannot follow you. Do you have a concrete question regarding stddef.h?

Edit: I've checked stddef.h in two of my systems:

1. debian6-linux (dpkg):
gcc-4.4: /usr/lib/gcc/i486-linux-gnu/4.4/include/stddef.h

2. AIX-6.1 (rpm):
gcc-4.4.5-1: /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.5/include/stddef.h

of course gcc knows how to finds its own headers, no additional -I tags are needed. (On the other hand, when I use Oracle precompiler, I usually create a symlink to make precompilation less platform-dependent:

well it would not be and never would be on
RHEL4.5 ( end of life)
Fedora 14 ( end of life)

so if one is using UNSUPPORTED os's then they would not and never be fixed

this thread is from 2011 after all