From owner-freebsd-alpha Thu Dec 12 16:42:26 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E0FD37B401 for ; Thu, 12 Dec 2002 16:42:25 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5308F43EDA for ; Thu, 12 Dec 2002 16:42:24 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.6/8.12.6) with ESMTP id gBD0gN82014596 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 Dec 2002 19:42:23 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id gBD0gIq08034; Thu, 12 Dec 2002 19:42:18 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15865.11498.408215.723128@grasshopper.cs.duke.edu> Date: Thu, 12 Dec 2002 19:42:18 -0500 (EST) To: "Drew Tomlinson" Cc: Subject: Re: OSF1 and Tru64 (Was Re: SOLVED - Linux_Base Port - Any Workarounds? In-Reply-To: <016f01c2a235$beaeac40$6e2a6ba5@tagalong> References: <013801c2a216$5daca150$6e2a6ba5@tagalong> <15864.59185.414664.544704@grasshopper.cs.duke.edu> <015b01c2a22e$7705cf60$6e2a6ba5@tagalong> <15865.5392.284364.522752@grasshopper.cs.duke.edu> <016f01c2a235$beaeac40$6e2a6ba5@tagalong> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Drew Tomlinson writes: > ----- Original Message ----- > > > > Most things without threads, yes. Tru64 uses Mach IPC in their > > threads lib, and we don't emulate that. > > Thank you for the info. I'm no programmer and I don't mean to keep > taking up your time but would the following error fall into this > category? > > zombie# ./rs900-osf51-alpha.bin > 18710:./rs900-osf51-alpha.bin: /sbin/loader: Error: Unresolved symbol in > ./rs900-osf51-alpha.bin: __cxx_call_static_dtors > 18710:./rs900-osf51-alpha.bin: /sbin/loader: Error: Unresolved symbol in > ./rs900-osf51-alpha.bin: _F64_stat > 18710:./rs900-osf51-alpha.bin: /sbin/loader: Fatal Error: this > executable has unresolvable symbols > /sbin/loader is the OSF1 dynamic linker/loader thing. What's happening is its complaining about shared libs not being found. You want to run odump -Dl on a Tru64 box and see what libs this binary needs and make sure to install them on the FreeBSD box (potentially under pain of license violation if the box in question is not licensed for Tru64) Linking statically works too, and gets you a faster binary, as the Tru64 ld is able to perform some interfile optimizations only when you link statically. BTW, I targeted the Tru64 4.0 ABI as that was all that was available when I did the OSF ABI layer, and that's what the freely available libs from Compaq are from. I've never made any effort to support 5.0 since all commercial bins still support 4.0. I don't think 5.x changed much, but if you run into problems with unimplemented syscalls, let me know. If you're rolling your own binaries, and are using purely C, you can make a native binary using the compaq ccc compiler. There's a port for it (compaq-cc). Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message