Date: Thu, 12 Dec 2002 17:10:26 -0800 From: "Drew Tomlinson" <drew@mykitchentable.net> To: "Andrew Gallatin" <gallatin@cs.duke.edu> Cc: <freebsd-alpha@FreeBSD.ORG> Subject: Re: OSF1 and Tru64 (Was Re: SOLVED - Linux_Base Port - Any Workarounds? Message-ID: <01ab01c2a244$6d6003c0$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> <15865.11498.408215.723128@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Andrew Gallatin" <gallatin@cs.duke.edu> To: "Drew Tomlinson" <drew@mykitchentable.net> Cc: <freebsd-alpha@FreeBSD.ORG> Sent: Thursday, December 12, 2002 4:42 PM Subject: Re: OSF1 and Tru64 (Was Re: SOLVED - Linux_Base Port - Any Workarounds? > > 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). Thank you for the explanation. This is way beyond my current knowledge but I will do a little reading and see if I can figure anything out. I don't have a Tru64 box to run odump but maybe I can find the info on Google. What I was trying to install was a binary from RealNetworks. The binary is a self extracting file that installs Helix Universal Server which is a media distribution server, i.e. RealMedia, Windows Media, QuickTime, etc. Helix server connects to the various encoder boxes and serves up the streams. It will also serve previously encoded streams from files. They have a version specific for FreeBSD but it is for the Intel Platform so I had given up. Then when I learned about the osf1 stuff from your previous post, my hopes of running the Helix Universal Server on FreeBSD Alpha were rekindled as they offer a Tru64 binary. Thanks again, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01ab01c2a244$6d6003c0$6e2a6ba5>