2.3 and gcc problems...
John Lockwood
Since the c compiler was unbundled with Solaris 2.x, I got
a copy of gcc for Solaris 2.x. I've been trying to compile
one of the sample source files which came with 2.3. I have
been getting the following messages, followed with a compilation
failed message:
/usr/include/sys/ucontext.h:24: parse error before `sigset_t'
/usr/include/sys/ucontext.h:24: warning: no semicolon at end of struct
or union
/usr/include/sys/ucontext.h:25: warning: data definition has no type or
storage class
/usr/include/sys/ucontext.h:28: parse error before `}'
/usr/include/sys/ucontext.h:28: warning: data definition has no type or
storage class
I was hoping that someone could tell me what is causing these
errors, and how I might correct the problem. I would really appreciate
it. Many thanks in advance.
Regards,
Jon Lockwood
--
EMAIL: lock...@teleport.com
Doug Anson
I've seen this very problem in EVERY release of Solaris (2.1, 2.1x86, 2.2, and 2.3). This problem
also occurs when using the SparcCompilers or ProWorks compilers (x86) with the
-Xc option (full ANSI-C mode). I've had to use the -Xa option for those files and they seem to
compile fine. I guess gcc is running into the same problem. Are you using the -ansi option?
The REAL question is when is SUN going to fix this? IMHO, we should be able to use the full ANSI
mode of our compilers and compile in these system include files. Isnt Solaris itself compiled in
full ANSI mode?? If not, then is Solaris really ANSI compliant? Comments SUN??
Doug
--
-------------------------------------------
Doug Anson
Internet: dan...@lgc.com
Phone: 713.560.1274
FAX: 713.560.1277
SNAIL: Landmark Graphics Corporation LGC
15150 Memorial Drive
Houston, TX 77079
-------------------------------------------
Casper H.S. Dik
>|> Since the c compiler was unbundled with Solaris 2.x, I got
>|> a copy of gcc for Solaris 2.x. I've been trying to compile
>|> one of the sample source files which came with 2.3. I have
>|> been getting the following messages, followed with a compilation
>|> failed message:
>|>
>|> /usr/include/sys/ucontext.h:24: parse error before `sigset_t'
>|>
>|> Jon Lockwood
>I've seen this very problem in EVERY release of Solaris (2.1, 2.1x86, 2.2, and 2.3). This problem
>also occurs when using the SparcCompilers or ProWorks compilers (x86) with the
>-Xc option (full ANSI-C mode). I've had to use the -Xa option for those files and they seem to
>compile fine. I guess gcc is running into the same problem. Are you using the -ansi option?
It is more likely that the original poster didn't run fixincludes, probably
because he started from a binary gcc distribution.
It is possible that he compiled with -ansi.
>The REAL question is when is SUN going to fix this? IMHO, we should be able to use the full ANSI
>mode of our compilers and compile in these system include files. Isnt Solaris itself compiled in
>full ANSI mode?? If not, then is Solaris really ANSI compliant? Comments SUN??
Why? You can't have an ANSI conformant program AND use system include
files. When compiling in full ANSI compilant mode, the system isn't
even allowed to define stuff in the user name space that isn't
in the ANSI standard, not are you allowed to include files other
than those part of your code and those mentioned in the
ANSI C standard.
An operating system can be ANSI complaint (i.e., all ANSI C programs
compile), but the source code of that operating system need
not necesarily be ANSI compliant.
However, an OS w/o any extensions to ANSI C is not useful. So, the
include files contain all kinds of extensions to ANSI C, many of which
historically existed in the same include files as ANSI C prescribes.
But ANSI C also has an opinion about identifiers which can safely
be used in your programs.
The following is a legal ANSI C fragment (not sure which signals
ANSI defines)
#include <signal.h>
kill(long *object)
{
if (object == 0)
raise(SIGINT);
}
It does compile in strict ANSI mode, it won't compile in any other mode
because of the redefinition of kill().
I hope this illustrates why strict ANSI mode and the use of Sun extensions
are mutually exclusive goals.
To program with POSIX extensions, you can define
_POSIX_SOURCE (Solaris 2.x)
or
_POSIX_C_SOURCE (1, 2, 1993xxL for 2.3 and later,
see <sys/feature_test.h>
To use Sun extensions, there is no define (there should be one).
The only solution is to compile with -Xa.
Casper