Re: OSX Porting Problems

On 2007-03-13 at 16:35:05 [+0100], Morgan Howe <[email protected]> wrote:

A general hint beforehand: You seem to use gcc 4.1.2 as cross-compiler. While 
that should work in principle, due to binary compatibility reasons with BeOS 
our standard compiler is gcc 2.95.3 (in the legacy subdirectory) ATM. The gcc 
4 build is not very well tested and the resulting Haiku seems to have some 
problems (that is more than the version built with gcc 2.95.3 :-)).

> I've followed Ingo's advice on porting haiku to OSX, and have run into a few
> snags.  I've set it up to use the proper build target (instead of trying to
> cheat and using freebsd ;), and am still getting the following errors:
>
> generated/cross-tools/lib/gcc/i586-pc-haiku/4.1.2/../../../../include/c++/4.
> 1.2/new:84:
> error: 'operator new' takes type 'size_t' ('long unsigned int') as first
> parameter
> 
> This error actually occurs on each of the 6 definitions of operator new in
> the mentioned file.  (Lines 84, 85, 88, 89, 94, 95)  Simply deleting them
> does get rid of the problem, though I'm pretty sure that this is not the
> best course of action.

Agreed. I would rule out later build problems with this work-around.

> Is there a proper way to fix this?

You should really provide a bit more context, ideally the full output for the 
error (as mentioned in an earlier mail). I'm guessing that this error 
concerns a file compiled for the host platform (we have several specific 
build tools the build system generates). Namely a part of the bfs_shell 
(src/tests/add-ons/kernel/file_systems/{fs_shell,bfs/bfs_shell}), which uses 
a weird mix of the host and target build environment. This definitely needs 
to be fixed, but noone has gathered enough motivation to do that yet.

The problem the compiler complains about is that new's first parameter, which 
is size_t, is not compatible with the size_t definition that compiler has 
been built with. You can check, which type that is by running:

	echo __SIZE_TYPE__ | cpp -

size_t is defined in our header headers/posix/size_t.h. The comment on the 
hack there says that it actually tries to fix exactly the kind of problem you 
have encountered. That size_t is defined as "long unsigned int" is strange 
though, since that would mean, that the macro __BEOS__ is defined. Which 
shouldn't happen when building for the host platform though, not even in the 
convoluted case of bfs_shell. So maybe my assumption about what is built is 
not correct. Well, more context would help ...

Oh, and what host gcc version are you using anyway?

> The second error I'm getting is this:
> 
> headers/private/kernel/util/DoublyLinkedList.h:17: error: template with C
> linkage
> 
> This occurs in several places in DoublyLinkedList.h, as well as a number of
> other header files (if run without the -q switch).  Apparently what this
> means is that an `extern "C" {' block did not get closed prior to the
> compiler running into C++ code.  I've pulled the build command for the very
> first file built (Volume.o), and am manually running it to try and debug.  I
> used the gcc switch -E so that only the preprocessor gets run and I can skim
> through and try to find the missing closing bracket.  This is a pretty time
> consuming and painful process, but hopefully it will turn up some results.

The strategy is good. Skipping to the error line and searching backwards for 
'extern "C"' should actually turn up the problem quickly. Since an 'extern 
"C" { ... }' block should never contain #include directives, it should be 
relatively easy to spot the missing closing brace this way.

> If I'm lucky it will be one header file that gets included frequently and a
> single fix will take care of the problem throughout Haiku.

I suppose so.

> I suppose that does make me wonder -- why doesn't that problem occur on
> Linux?  Advice on either issue is appreciated.

Good question. I believe you're still building the build tools, which indeed 
depends heavily on the host platform environment. In principle basic POSIX 
compatibility of the host platform should suffice, but there are parts that 
are a bit, uh, esoteric. :-)

CU, Ingo

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV