From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 2 Sep 2013 20:28:52 -0400 To: mischief@9.offblast.org, 9fans@9fans.net Message-ID: <97bd08b770c2ccd6ee5d62ff072745f7@brasstown.quanstro.net> In-Reply-To: <20130902220856.GA6254@iota.offblast.org> References: <20130902181554.GD8567@iota.offblast.org> <20130902220856.GA6254@iota.offblast.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Building Go/386 Topicbox-Message-UUID: 7948b476-ead8-11e9-9d60-3106f5b1d025 > the trouble here is that go's src/libmach/8obj.c has '#include > "../cmd/8l/8.out.h"', and 8.out.h now has the newly added '#include > "../ld/textflag.h"'. >=20 > i see now that the kernel source has an instance of this, in > /sys/src/9/pc: 'fns.h:1: #include "../port/portfns.h"', but i'm not sur= e > how that is treated differently from this situation. it is different because -I../port is part of CFLAGS. i've just verified that the plan 9 c compilers interpret relative paths relative to the original source file, not any included files, but -p interprets relative to the file doing the including. imo the compilers should be fixed, but it might require a few fixes. the easiest (smallest delta) solution would be for 8.out.h to include "../../cmd/ld/textflag.h" instead of "../ld/textflag.h= ". i suppose this is just another reason not to include include files. =E2=98= =BA - erik