[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] New user question - more explicit information concerning
Re: [Gcl-devel] New user question - more explicit information concerning shared library use
06 May 2005 10:06:57 -0400
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Jordan Rosenthal <address@hidden> writes:
> 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.
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah