From owner-freebsd-hackers Fri Sep 26 01:20:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA20208 for hackers-outgoing; Fri, 26 Sep 1997 01:20:57 -0700 (PDT) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA20201 for ; Fri, 26 Sep 1997 01:20:53 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id RAA00553; Fri, 26 Sep 1997 17:48:02 +0930 (CST) Message-Id: <199709260818.RAA00553@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), bartol@salk.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: problem compiling for linux under compat_linux In-reply-to: Your message of "Fri, 26 Sep 1997 08:01:09 GMT." <199709260801.BAA17357@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 1997 17:48:01 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > If I use /compat/linux/usr/bin/gcc to compile anything other that very > > > trivial c program sources located on an NFS mounted filesystem I get > > > broken executables which seg fault. This same source code compiles > > > correctly when located on a local filesystem. This problem does not occur > > > when compiling trivial sources such as "Hello World". > > How do you make the compiler invoke the right linker in this case? You don't "make" it. It just does. > Do > you hack your path? No. > I've never thought running a Linux compiler in > a compat directory would work because it would invoke FreeBSD pieces > for hidden components. It doesn't. About the only time you trip up is when something like autoconf goes looking for things (most especially ranlib) and finds the FreeBSD version because there isn't a Linux one. > Are they really all referenced off the user's > path?!? Are they all branded Linux executables so the will go through > compat first on their path lookups? Any exec() call made by a linux-mode process will attempt to locate the target in /compat/linux first. The compiler driver is no exception. > > It's not clear to me how this could be an emulation-related problem > > just yet. (Possibly an mmap() incompatability?) > > Maybe. Do they mmap() the objects in ld now? I have no idea. I'm attempting to envision something in the ABI emulation that could be sensitive to the underlying filesystem type. About all that comes to mind is mmap() and maybe the directory lookup code. I can't see how the latter could cause this effect though, so mmap() is about all that's left. > Editorial on cache thrashing by mmap() in ld: Elide! Elide! mike