Greetings!
It would be nice to have pargcl as a configurable option in the
standard gcl distribution.
Gene Cooperman <[EMAIL PROTECTED]> writes:
> I noticed recently that with gcl-2.6.x, my ParGCL distribution doesn't
> seem to work any more. The issue is that I need to statically
> link a file (mpi_glue.o) and a static library (libmpi.a).
> In the past, I could do this with:
> rm -f raw_saved_gcl
> make EXTRAS="mpi_glue.o libmpi.a"
>
> It appears that this no longer works. If I read the documentation
> correctly, it's because gcl is now using bfd for linking. (Is this right?)
>
I thought this still worked. It would be great if you could post the
symptoms of the failure. It is true that I believe this method is
obsolete, perhaps even 'deprecated' :-).
> The documentation also seems to say that I need to now use
> compiler::link . I tried this, and while compiler::link successfully
> creates a new saved_gcl, my foreign functions are not available in
> the new saved_gcl.
>
OK, assuming mpi_glue.o was output by (compile-file ... :system-p t),
I think you need
(compiler::link (list "mpi_glue.o") "new_image" "" "libmpi.a" t)
First arg -- list of compiled lisp modules with :system-p t flag.
Second -- output image name
Third -- Any interpreted initialization code needed to be run in
new_image
Fourth -- C libs and objects not produced with GCL's compiler,
including dynamic libs (i.e. could just do -lmpi)
Fifth -- whether to initialize the lisp modules in the first arg
explicitly, or to do so by way of redirecting calls to load
invoked in the third argument. I.e. in acl2, we just run
their massive init sequence again, and all calls to load of modules
already linked in simply run the initialization sequence. In all
cases, this init process needs doing at some point for the functions
in the module to become accessible. You can crudely think of it as
allocating the function structure bodies and naming symbols and
pointing them at the right code address in the new_image.
If mpi_glue.o is pure C, then it belongs in the 4rth arg instead.
> As a test, I try to make a simple file, "foreign-fnc.lsp", according
> to the example in the "defentry" section of the GCL manual.
> I can create it, compile it, load it, and use it successfully.
>
> Then I try:
> cd gcl-2.6.6/unixport; gcl
> and:
> (compile-file "foreign-fnc.lsp" :system-p t)
> (compiler::link '("foreign-fnc.o") "saved_gcl")
> I see:
> Initializing foreign-fnc.o
> T
> >
> "saved_gcl"
>
> It creates a new saved_gcl, but the new one does not contain the
> foreign function that I defined.
>
OK, the fifth arg defaulted to t, so all should be initialized. I
don't know why this did not work -- could you please post your .lsp
file?
> I've also tried:
> (compiler::link '("foreign-fnc.o") "saved_gcl" "(load \"foreign-fnc.o\")")
> but it seems to have similar results.
I take it you are working on a systm with native relocation abilities,
such as x86. In this case, there is never a need for use of the first
argument, as GCL can just (load "foo.o") followed by (si::save-system
"foo") to the same effect. You can, but do not have to, link in
compiled lisp modules with compiler::link. YOu only absolutely need
it for pure C code and libraries. I would just
(compiler::link nil "new_image" "" "-lmpi my_C_module.o")
fire up new_image, and load your lisp interface from there. If this
works, you can then do all in one step via compiler::link's third arg.
If you point me at your files again, I might find some time to test too.
Take care,
>
> Do you have any suggestions?
> Thanks,
> - Gene
>
>
>
--
Camm Maguire [EMAIL PROTECTED]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
_______________________________________________
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
