[9front] Linking error while porting

[9front] Linking error while porting

[sirjofri]

Hey all,

I'm trying to port the simon tatham portable puzzle collection using npe and I get incompatible type signatures while linking the files.

For npe, I had to #undef PI after #including <libc.h> (in npe.h), because puzzles #defines its own PI. Other than that, I didn't change the source repo or npe.

My sources are here: http://sirjofri.de/oat/tmp/puzzles/

repo.url contains the url to the source repo for puzzles. To get started, clone that url to your local filesystem and copy the remaining files into the same directory.

The other files are an mkfile and plan9.c (for the plan 9 frontend, which is mostly a stub I still have to fill).

b.rc is a short build script for building the blackbox program. Literally `mk install 6.blackbox`. It's not about that program specifically, it's just the first game in the list.

The linking errors are all roughly the same, like:

new_window: incompatible type signatures 71a60b79(blackbox.6) and 846c216a(plan9.6) for thegame

In this specific case, I double checked the type and the only difference is that one is declared as the struct itself, the other as the typedef'd struct (struct game vs game). I also changed that temporarily, without a difference. The compiler handles typedef's like it should.

I can't imagine any other reason why it shouldn't work. Thanks to npe, it's the same compiler (6c) for both source files. The compilers/linkers should be up to date (sysupdated yesterday).

If anyone has any idea what could be wrong, that would be very helpful. Also if I should give you more data, just let me know.

sirjofri

Re: [9front] Linking error while porting

[qwx]

On Wed May  8 13:23:38 +0200 2024, sirjofri+ml-9front@sirjofri.de wrote:
> Hey all,
> 
> I'm trying to port the simon tatham portable puzzle collection using npe and I get incompatible type signatures while linking the files.
> 
> For npe, I had to #undef PI after #including <libc.h> (in npe.h), because puzzles #defines its own PI. Other than that, I didn't change the source repo or npe.
> 
> My sources are here: http://sirjofri.de/oat/tmp/puzzles/
> 
> repo.url contains the url to the source repo for puzzles. To get started, clone that url to your local filesystem and copy the remaining files into the same directory.
> 
> The other files are an mkfile and plan9.c (for the plan 9 frontend, which is mostly a stub I still have to fill).
> 
> b.rc is a short build script for building the blackbox program. Literally `mk install 6.blackbox`. It's not about that program specifically, it's just the first game in the list.
> 
> The linking errors are all roughly the same, like:
> 
> new_window: incompatible type signatures 71a60b79(blackbox.6) and 846c216a(plan9.6) for thegame
> 
> In this specific case, I double checked the type and the only difference is that one is declared as the struct itself, the other as the typedef'd struct (struct game vs game). I also changed that temporarily, without a difference. The compiler handles typedef's like it should.
> 
> I can't imagine any other reason why it shouldn't work. Thanks to npe, it's the same compiler (6c) for both source files. The compilers/linkers should be up to date (sysupdated yesterday).
> 
> If anyone has any idea what could be wrong, that would be very helpful. Also if I should give you more data, just let me know.
> 
> sirjofri

 From what I saw, some of these structs are actually not defined in the
header but in individual c files.  Putting `#pragma incomplete' for a
few of them in puzzles.h fixes most linking errors:

#pragma incomplete midend
#pragma incomplete drawing
#pragma incomplete frontend
#pragma incomplete random_state

One error still remains for a big and complex struct, you might have
to go through all type declarations and make sure whatever isn't
defined in puzzles.h is marked incomplete.

Cheers,
qwx

Re: [9front] Linking error while porting

[sirjofri]

Hi,

08.05.2024 16:24:34 qwx@sciops.net:
> From what I saw, some of these structs are actually not defined in the
> header but in individual c files.  Putting `#pragma incomplete' for a
> few of them in puzzles.h fixes most linking errors:
>
> #pragma incomplete midend
> #pragma incomplete drawing
> #pragma incomplete frontend
> #pragma incomplete random_state

I tried that and that fixed most errors.

> One error still remains for a big and complex struct, you might have
> to go through all type declarations and make sure whatever isn't
> defined in puzzles.h is marked incomplete.

I tried to find the culprit, and in the end I was so frustrated I started to copy stuff to a separate project to troubleshoot. I was able to build some minimum failing example, the bare minimum that fails.

In that example, I still can't understand why it fails, but see for yourself:

https://sirjofri.de/oat/tmp/linkerr

In the puzzles project, it is noticable that nullgame.6, blackbox.6 and cube.6 all have different type signatures for basically the same piece of code (using the same type from the same include file).

Not sure if that's a compiler bug, maybe.

sirjofri

Re: [9front] Linking error while porting

[sirjofri]

Hi all,

probably the last follow-up on this thread, and you are a great help.

For those following this: it seems to be related to the const type specifier.

The simple "solution" is: #define const

In my code I did (puzzles.h):

#ifdef __plan9__
#define const
#endif

And I get a fully linked program.

Now I can start porting.

sirjofri