*BSD News Article 32110


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!gatech!nntp.msstate.edu!olivea!decwrl!pa.dec.com!usenet.pa.dec.com!jkh
From: jkh@nx.ilo.dec.com (Jordan Hubbard)
Newsgroups: comp.os.386bsd.questions
Subject: Re: FreeBSD1.1R Shared Libs q's
Date: 27 Jun 1994 14:39:58 GMT
Organization: Digital Equipment Corporation, Galway Ireland
Lines: 41
Message-ID: <JKH.94Jun27153959@nx.ilo.dec.com>
References: <9417814.4311@mulga.cs.mu.OZ.AU>
NNTP-Posting-Host: nx.ilo.dec.com
In-reply-to: summer@ee.mu.OZ.AU's message of Mon, 27 Jun 1994 04:34:58 GMT

In article <9417814.4311@mulga.cs.mu.OZ.AU> summer@ee.mu.OZ.AU (Mark Summerfield) writes:

   Specifically, I want to know:

   1 - How to build shared libs.  ld -Bshareable ... seems to do the job, as the
       ld man page suggests it should, however in the SunOS system it is necessary
       to compile the object files as position independent code.  Is this not
       necessary here?  (And why not?)

You should compile the objects with -fpic, yes.  If your shared lib
works without doing this then I am rather mystified (or the code in
question is very simple)!  It shouldn't be possible.

   2 - What's the problem with C++ libs?  I assume there is a problem, since
       shared versions are not supplied.

You just need a way of calling the global ctor/dtor lists for them.
In 1.1R we forgot (I forgot :-( ) to install the c++rt0.o file that
the C++ shared lib must be linked with to perform this, even though
it's in the sources (/usr/src/lib/csu.i386).  This is fixed in 1.1.5,
and if you set the keyword `CPLUSPLUSLIB' in your library's Makefile,
it will even pull it in automatically for you.  libg++ is also
supplied shared now, as a working example.

   3 - (May be related to 2, based on the contents of the symbol table...)
       What's the "libgcc_pic.a" library for?

It's just an intermediate version of the pic library (e.g. just the
-fpic compiled object files aggregated into a normal archive) provided
purely for the benefit of ld, which needs them to produce the run-time
loader (ld.so).  Why?  Because ld.so must itself use only relocatable
code (consider its job) but can't obviously reference the relocatable
shared libs since it's the one responsible for relocating them! :-)

In any case, shared libs were new in 1.1R and we left a couple of
small but annoying things out - I'm happy to say that many or all of
them were fixed in 1.1.5, and I expect the full release version of
1.1.5 to go out in less than 6 days (1.1.5 ALPHA is already out and on
freefall.cdrom.com:~ftp/pub/incoming/1.1.5A).

					Jordan