From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Message-id: From: Pietro Gagliardi To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Date: Sat, 17 May 2008 22:56:43 -0400 References: Subject: [9fans] Linker weirdness? (was: Assembler weirdness?) Topicbox-Message-UUID: aaeb261c-ead3-11e9-9d60-3106f5b1d025 I fixed it by specifying in the mkfile to convert jamesmol.s to jmfixed.s or something. But now when I go to link I get these weird errors about undefined symbols in a function that they are not even related to. source: /n/sources/contrib/pietro/pgos.tar error list: /n/sources/contrib/pietro/pgos.err And yes, I plan to use the a.out(6). But now it just takes raw binary. On May 17, 2008, at 10:21 PM, Pietro Gagliardi wrote: > You mean ##? Okay, but since 8a doesn't have an option to issue the > standard C preprocessor (cpp(1) - 8c has -p), I'll see what I can do. > > On May 17, 2008, at 9:44 PM, erik quanstrom wrote: > >>> Hello. I'm trying to switch from GCC/NASM to the good old Plan 9 >>> tools >>> to get a simple kernel I'm writing compiled and working with 9load >>> (which fortunately is Multiboot-compliant). But there is one file >>> - an >>> 8a-ized hand-me-down interrupt service routine array - that is >>> causing >>> problems. Running >>> >>> 8a /n/sources/contrib/pietro/jamesmol.s >>> >>> yields the errors in /n/sources/contrib/pietro/jamesmol.out. But >>> if I >>> first preprocess with cpp(1), which produces /n/sources/contrib/ >>> pietro/ >>> jamesmol.fixed, everything works fine with 8a. What's wrong? >>> >>> - Pietro >>> >>> PS - This is when I hate macros. >> >> i believe 8c disapproves of string pasting. >> >> - erik >> >> > >