Subject: Re: xemacs on alpha
To: None <port-alpha@NetBSD.ORG>
From: Ross Harvey <ross@teraflop.com>
List: port-alpha
Date: 05/18/1998 14:42:33
> From port-alpha-owner-ross=teraflop.com@NetBSD.ORG Mon May 18 14:18:31 1998
> To: nm <nmanisca@vt.edu>
> Cc: port-alpha@NetBSD.ORG, cgd@pa.dec.com, yba@polytronics.com
> Subject: Re: xemacs on alpha
> From: Jason Thorpe <thorpej@nas.nasa.gov>
> Date: Mon, 18 May 1998 14:02:05 -0700
>
> On Sun, 17 May 1998 16:30:03 -0400
> nm <nmanisca@vt.edu> wrote:
>
> > thanks for the info... ill just comment out those missing
> > headers and see if i can include enough other headers
> > so that it compiles :)
>
> That's not sufficient... basically, you need to port the alpha stuff
> to NetBSD ... it's currently Digital UNIX (formerly DEC OSF/1)-centric.
>
Right!
Perhaps the piece of information he needs to know is that NetBSD/alpha
(like Linux) no longer uses ecoff, but now uses the more modern
ELF format. In general, ELF is a lot more friendly to dynamic
loading (is that what xemacs wants to do?), but it is going to be
different.
The _good_ news is that many of these programs run on linux,
and our toolchain is very similar to the linux one. In general,
you can use as examples the linux alpha configuration for the program
you are porting. Otherwise, pick any other ELF platform and configure
for NetBSD/alpha in a similar way.
Also, I don't recall NM's question on shared libraries getting answered.
This is another ELF thing that comes up frequently. The right way to
make a shared library on any NetBSD port is to use bsd.lib.mk.
Here is an example Makefile that will make all the different types of
libraries from two c++ files:
LIB=Ross
SRCS=gsl.cc gsl2.cc
.include <bsd.lib.mk>
That's all there is to it!
To _link_ with one you can use <bsd.prog.mk> in a similar, trivial
fashion. But if you really want to do it yourself, here is the long
explanation:
You will have to know about -rpath. This is a linker directive that
buries one or more strings in in the executable that tells it where
to find the shared libraries at run time. If you think the shared
library might exist in a couple of different places you can give
multiple -rpath directives. You also need a -soname also to tell
it the name of the library it is going to look for in those rpath
directories.
It's usually convienient to go through cc(1), so you need to do:
cc -Wl,-rpath,/usr/local/lib,-soname,libxyz.so.3 ...
Actually, it automatically searches in /usr/local/lib, but I wouldn't
count on it always doing that.
>From within make:
cc -Wl,-rpath,$(USRLIBDIR),-soname,lib$(LIB).so.$(SHLIB_SOVERSION) ...
Look at the X11 Makefiles for the generally cannonical form for all this stuff.
-----------
Ross Harvey