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

[Camm Maguire]

Greetings!

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") 
                "new_image" 
                "(load\"s1.lsp\")" 
                "-lmysharedlib"
                t)


> 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.
> 

Great!

Take care,

> Jordan
> 
> 
> 
> 

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