[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] New user question - more explicit information concerning

From: Camm Maguire
Subject: Re: [Gcl-devel] New user question - more explicit information concerning shared library use
Date: 06 May 2005 10:06:57 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


Jordan Rosenthal <address@hidden> writes:

> Hi,
> Thanks for the quick response!
> > Its much better now, but hopefully will still improve further with
> > 2.7.0, hopefully out by summer's end.  There is a recent thread on
> > gcl-devel -- your ideas most welcome.
> Okay, if I get a chance I'll try and take a look.
> > I prefer locbfd
> > which will carry the bfd object modules around in libgcl, as if you
> > want to run compiler::link at some later date on a different machine
> > with different bfd version, you will definitely have problems.
> > dynsysbfd will fail to startup in such a case, as the bfd soname
> > policy is to make every point release binary incompatible.
> Point taken.  Fortunately, our system will only be used locally for
> the foreseeable future.
> >>2) How do I use the compiler::link command?  The syntax is
> >>straight-forward, but whenever I do it I get errors.  I have tried
> >>both using and not using the system-p key, but in either case I get
> >>some sort of error.  In one case (I can't remember which) I get a
> >>"cannot relocate" error.  In the other case I get a "multiple
> >>instances of init_code defined" error.
> >>
> > You must compile with :system-p t for compiler::link for the init
> > names to be unique as required by ld.  Cannot relocate likely
> > indicates that you forgot to link in your new shared library.
> Thanks, I'll look into it.
> We currently use a bookstrapping approach to our system creation:
> 1) Starting with GCL, we use compile-file to load in some useful
> definitions and create a slightly extended version.  This gets saved
> off to a new image.
> 2) This new image is then used to compile-file several packages.
> 3) Finally, all the packages (including the compiled files for our
> bootstrap extensions) are loaded into the bare GCL and saved off to
> our final system image.
> So now I'm trying to figure out where in this process I would be best
> off using a compiler::link to get some functions that use shared
> libraries.  It almost seems like I need to add a fourth step that
> performs this operation, which makes things a bit complicated.  Any
> better suggestions?

No need to add another layer -- indeed I don't see the need for your
third step as it is.  Say step one is accomplished by loading
"s1.lsp".  Then just replace this with

(compile-file "mysharedlibwrapper.lsp" :system-p t)
(compiler::link (list "mysharedlibwrapper.o") 

> An aside:  I think I'll look through our bootstrapping code and see if
> there is anything which could be useful to the main GCL build.  I
> imagine most of it is only locally useful, but there may be some code
> that is generally useful.

Please do -- we are always in the need for informed contributions from
users.  I don't suppose your application is open source?  I typically
use such applications as a regression suite for GCL releases using the
Debian packaging system and autobuilder network, and would be happy to
add your app if appropriate.

> > Hopefully this example will suffice:
>  > <example snipped>
> Yes!!!  That was very helpful.  Thank you.


Take care,

> Jordan

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]