From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 700D824776 for ; Wed, 8 May 2024 13:24:32 +0200 (CEST) Received: from sirjofri.de ([5.45.105.127]) by 9front; Wed May 8 07:20:17 -0400 2024 Received: from dummy.faircode.eu ([95.90.217.91]) by sirjofri.de; Wed May 8 13:20:09 +0200 2024 Date: Wed, 8 May 2024 13:20:07 +0200 (GMT+02:00) From: sirjofri To: 9front@9front.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Correlation-ID: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: non-blocking RESTful SSL framework event NoSQL grid Subject: [9front] Linking error while porting Reply-To: 9front@9front.org Precedence: bulk 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 (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