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 4AB9125298 for ; Wed, 8 May 2024 23:13:26 +0200 (CEST) Received: from sirjofri.de ([5.45.105.127]) by 9front; Wed May 8 17:10:25 -0400 2024 Received: from dummy.faircode.eu ([95.90.217.91]) by sirjofri.de; Wed May 8 23:10:20 +0200 2024 Date: Wed, 8 May 2024 23:10:17 +0200 (GMT+02:00) From: sirjofri To: 9front@9front.org Message-ID: In-Reply-To: <94909FDAB9454C00B8D7ECE0602C3978@wopr.sciops.net> References: <94909FDAB9454C00B8D7ECE0602C3978@wopr.sciops.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: leveraged encrypted scripting standard-aware layer Subject: Re: [9front] Linking error while porting Reply-To: 9front@9front.org Precedence: bulk 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.=C2=A0 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 t= o copy stuff to a separate project to troubleshoot. I was able to build som= e minimum failing example, the bare minimum that fails. In that example, I still can't understand why it fails, but see for yoursel= f: https://sirjofri.de/oat/tmp/linkerr In the puzzles project, it is noticable that nullgame.6, blackbox.6 and cub= e.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