Hi

I tried SunStudio Express 2 on RedHat Fedora 5 and got the following
test.cpp

#include <iostream>
using namespace std;
int main()
{
  cout << "Hello" << endl;
  return 0;
}

CC test.cpp

"/usr/include/string.h", line 272: Error: End of file encountered in macro arguments for "__nonnull".
"/usr/include/string.h", line 272: Error: ")" expected instead of "(".
"/usr/include/string.h", line 272: Error: Unexpected ")" -- Check for matching parenthesis.
"/usr/include/string.h", line 272: Error: Operand expected instead of ";".
"/usr/include/string.h", line 426: Error: "strerror_r(int, char*, unsigned long)" is expected to return a value.

Stlport4 works without any problem though. ei ( CC test.cpp -library=stlport4 )

/Lars

 

 

Perhaps an FC5 issue? It works OK on RHEL WS 4.

Paul

 

 

Strange workaround found...
CC -E test.cpp > _test.cpp
CC _test.cpp

No error and the program works...
Anyone care to explain ?

/Lars

 

 

W/o trying the initial error its hard to give a definite answer.
However it is a known fact that compiling preprocessed file can lead to subtle differences in compilation.

As for origin of the error itself - different Linux distributions have different header problems. We solve some of those problems by interposing on these headers and sort of applying a fix before including system header. While we try to make these fixes be as general and non-disruptive, still certain fix that worked for SuSE/RHEL might spoil FC or just expose another header problem that was not present before.
Its still speculations. Is there any place I can look at FC5 /usr/include/string.h online?

regards,
__Fedor.

 

 

Could be a glibc 2.4 problem.

http://rpm.pbone.net/index.php3?stat=26&dist=47&size=611513&name=glibc-headers-2.4-11.i386.rpm

or

http://lingonpaj.com/~erior/string.h

/Lars

 

 

The following looks suspicious:

/* Get size_t and NULL from <stddef.h>.  */
#define	__need_size_t
#define	__need_NULL
#include <stddef.h>

stddef.h is a compiler-specific include, and our compilers provide their own version. However this string.h implies certain functionality to be enabled by defining these __need thingies.
Seems to be a hardcoded gcc dependency.

regards,
__Fedor.

 

 

I tried with new project on FC6 (Fedora Core 6)...

#include <stdlib.h>
#include <iostream.h>
//
int main(int argc, char** argv) {
    cout << "Welcome ...\n";
    return (EXIT_SUCCESS);
}

Set Tools->Options->Default Compiler Collection ==> GNU Compiler Collection
Set Tools->Options->Make Command ==> make

Many warning but works fine.

 

 

No, it looks like a preprocessor bug. I just found this thread having hit the same issue on debian - the OPs problem basically is produced by this code

#define __Pragma(x) _Pragma(#x)
#define __nonnull(x)
int twolines() __Pragma(redefine_extname twolines my_twolines)
    __nonnull((1));
int oneline() __Pragma(redefine_extname oneline my_oneline) __nonnull((1));

though I guess this makes it clearer...

#define NOT_A_TOKEN
int oops() _Pragma("foo") NOT_A_TOKEN;
 
~etp% sunc++ oops.cpp
"oops.cpp", line 2: Error: "{" expected instead of "NOT_A_TOKEN".
"oops.cpp", line 2: Error: NOT_A_TOKEN is not defined.
"oops.cpp", line 2: Error: "}" expected instead of EOF.
3 Error(s) detected.

_Pragma is evidently breaking the preprocessing of the remainder of the line.

Anthony

 

 

Bug 6509190 has been filed for this problem. You can monitor progress at bugs.sun.com