Go to the FreeLists Home Page Home Signup Help Login
 



[haiku-development] || [Date Prev] [08-2007 Date Index] [Date Next] || [Thread Prev] [08-2007 Thread Index] [Thread Next]

[haiku-development] GCC 2.95 and certain #define macros

  • From: "Ryan Leavengood" <leavengood@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 18 Aug 2007 17:33:30 -0400
So, my WebKit saga continues. As I implied in my last email, I've
switched to GCC 2.95 to see if I can use it to compile a
JavaScriptCore which will work with my BeOS compiled ICU.

Unfortunately it chokes almost immediately because of some macro
definitions in JavaScriptCore's Platform.h:

#define PLATFORM(WTF_FEATURE) (defined( WTF_PLATFORM_##WTF_FEATURE )
&& WTF_PLATFORM_##WTF_FEATURE)

The above definition (and 3 more like it) doesn't cause errors, but
using it (or the others) does:

#if PLATFORM(DARWIN)

The error is:

3rdparty/WebKit/JavaScriptCore/wtf/Platform.h:83: `defined' without an
identifier
3rdparty/WebKit/JavaScriptCore/wtf/Platform.h:83: parse error

Of course the error is repeated profusely wherever that macro or
similar ones are used. I know GCC 2.95 is kind of old, but this seems
like a pretty basic macro. I put together a different example to test
the use of ## and it works. It also works to manually write the
equivalent of what that macro creates, for example:

#if (defined( WTF_PLATFORM_DARWIN ) && WTF_PLATFORM_DARWIN)

Is there a solution to this or should I just give up and try to
compile everything with GCC 4.1?

The problem with the latter approach is the compiled WebKit won't ever
work with a backwards-compatible Haiku compiled with GCC 2.95. Since
that is the default for R1, that pretty much means this whole port is
practically pointless (which, um, I would rather not be the case.)
Unless there are plans to set up a special Haiku runtime_loader which
can load both GCC 2.95 and GCC 4.x binaries (which is the ideal
solution.)

If no one else does this, I may look into it. It seems like we could
compile the whole system with GCC 4.1 but also build GCC 2.95 versions
of libstdc++ and libbe.so, etc, which would be used for legacy
binaries. Whether the library or application references
libstdc++.r4.so or libstdc++.a will determine which version it is. Of
course mixing the two (like I was trying to do) wouldn't be supported.
Is this crazy or feasible?

This would be the best solution, as we would have backwards
compatibility but most of the system would have the faster GCC 4.x
binaries and newer programs (like WebKit) could be ported more easily.

Ryan, who has been reading about ELF and runtime loaders





[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.