Jump to content
  • Advertisement
Sign in to follow this  
Mantear

Compiling with GNUC, __attribute__

This topic is 3475 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Greetings, This may be a bit out there and so specific that no one will know what I'm talking about, but I'll give it a short. I'm working on porting a pre-existing code base over to an updated build environment. Updated compiler and supporting libraries, etc. A portion of the project includes a sub-project that was built under GNUC (in other words, the sub-project defines __GNUC__ in order to enable the GNU C and C++ extensions). However, I get build errors that I can't figure out. Simply having '#include <iostream.h>' in a *.cpp source file, and nothing else, causes it to bomb out, complaining about a missing '{'. Looking at the preprocessor output, it seems to be dying on an __attribute__ line. The offending code is below with the corresponding preprocessor output below that.
bool uncaught_exception();
_NO_RETURN(terminate()); // <--- Line the compiler errors out on complaining about a missing "{"
_NO_RETURN(unexpected());

namespace std {
		
class exception;
typedef void (*_Prhand)(const exception&);
extern _Prhand _Raise_handler;
void _Throw(const exception&);
		
class exception
	{	
public:
	static _Prhand _Set_raise_handler(_Prhand _Pnew)
		{	
		const _Prhand _Pold = _Raise_handler;
		_Raise_handler = _Pnew;
		return (_Pold);
		}

	explicit exception(const char *_Message = "unknown") throw ()
		: _Ptr(_Message)
		{	
		}

	exception(const exception& _Right) throw ()
		: _Ptr(_Right._Ptr)
		{	
		}

	exception& operator=(const exception& _Right) throw ()
		{	
		_Ptr = _Right._Ptr;
		return (*this);
		}

	virtual ~exception()
		{	
		}

	virtual const char *what() const
		{	
		return (_Ptr);
		}

protected:

	const char *_Ptr;	
	};

class bad_exception
	: public exception
	{	
public:
	bad_exception(const char *_Message = "bad exception")
		throw ()
		: exception(_Message)
		{	
		}

	virtual ~bad_exception() throw ()
		{	
		}
	};
		
typedef void (*terminate_handler)();
typedef void (*unexpected_handler)();

terminate_handler set_terminate(terminate_handler) throw ();
unexpected_handler set_unexpected(unexpected_handler) throw ();
bool uncaught_exception();
void terminate() __attribute__((__noreturn__)); // <--- Corresponding line in preprocessor output
void unexpected() __attribute__((__noreturn__));
}


As you can see, the root problem could be the __attribute__ stuff (which I know nothing about) which my compiler documentation mentions in the ANSI C Extensions section (ANSI C extensions are enabled when GNUC extensions are). If I disable GNUC, stuff builds much further until it hits a header file that wants to know what compiler is being used in order to #include other specific header files. If GNUC is not defined, it halts building. The short version of my question is, what does "__attribute__" do? Why might it be choking the compiler? *EDIT: I am in contact with our compiler vendor and they are also working the issue.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Mantear
Simply having '#include <iostream.h>' in a *.cpp source file, and nothing else, causes it to bomb out, complaining about a missing '{'.


No clue if this could be the problem, but why are you including <iostream.h> in a .cpp file when you should be including <iostream> instead?

Is this a legacy app?

Share this post


Link to post
Share on other sites
Quote:
Original post by Mantear
The short version of my question is, what does "__attribute__" do? Why might it be choking the compiler?

The __attribute__(()) extension is the GCC way of specifying metadata about an object. For instance, the __noreturn__ attribute specifies that the function will never return to its caller.

My guess is that your compiler vendor has provided a subset of GCC functionality, and that particular attribute is not a part of that subset. My guess is that your solution will be to check some magic preprocessor variable to see if you're using a real GCC or something else, and not define the _NO_RETURN macro (among others) appropriately.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!