SUNPRO 4.0.1
/opt/SUNWspro/bin/pc Pascal compiler
/opt/SUNWspro/bin/f77 Fortran compiler
/opt/SUNWspro/bin/f90 Fortran90 compiler
/opt/SUNWspro/bin/cc C compiler
/opt/SUNWspro/bin/CC C++ compiler
GNU
/usr/local/gnu/bin/g++ C++ compiler
/usr/local/gnu/bin/gcc C compiler
These two areas are in the default path, so you should not
have to give full pathnames unless you have changed your default path.
You can do this by typing
set path = (/opt/SUNWspro/bin $path)
... you can add this to your .login if you wish; be sure
you use the line as-written -- include the "$path".
gcc -o foo foo.c -lm
echo $path
There are two fixes:
1) Use directory context - since the current directory
is ".", you can run a program in the current directory by typing
"./programname". For example, if your C program was "thing.c",
and you compiled it with "cc -o thing thing.c", then you could
run it with "./thing".
2) Adjust your path - this one is a little more complicated,
since how you do it depends on what shell you're using. This should
work on just about every type:
set path = ( $path . )
One more thing: using "test" as an executable name will drive you crazy. There is a system command called "test" -- it's generally for shell programming. If you name your compiled program "test", you will be unhappy. What happens is, if you forget to use "./test", and just type "test", the system will just give you a prompt back, as if your program had run, but generated no output. I know of a number of students who inserted numerous print statements into their code and recompiled over and over again, trying to figure out what was wrong, when what was wrong was they weren't running their program at all. The safest thing is to not name your program "test".
gcc -o foo foo.c -lsocket -lnsl -lresolv