gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Failure in configure


From: Camm Maguire
Subject: Re: [Gcl-devel] Failure in configure
Date: 29 Oct 2005 13:28:20 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Paul -- thanks for the heads up.  Should be fixed now.  BTW, have you
been receiving any of my other emails of late?

Gene!  Great to see your commit!  Will be exploring it and
integration possibilities in the next few days -- in the meantime it
appears that one of your older pargcl configure scripts overwrote the
main gcl configure script.  I've reverted this for now.  

My understanding is that at least to begin with, you would like us to
add an --enable-pargcl option in the main configure.in which would
trigger a subconfigure and subuild on top of whatever image the user
had selected.  I'm in total agreement on this as a first step.  What
I really would love to do is to isolate the -lmpi symbols used by
pargcl and put them into o/plttest.c when pargcl had been selected --
this way we can ship the default image and an autoloadable pargcl
module.  I'd also like to do this with xgcl for example.  The idea is
sort of simple -- write dummy C calls in o/plttest.c which will access
the same symbols you want to use in your module, #ifdefed by the
PARGCL c macro which would be set by configure.  configure would
likewise add -lmpi to LIBS.  Then all base images will have entry
points for every symbol you need in the module so that it will
relocate properly when loaded.  This should help cut down on the image
proliferation/confusion.  Ultimately, it wold be ideal for us to forgo
even the plttest step, have your module be a shared object linked to
-lmpi, and then munge unexec to rewrite the program header and symbol
tables in the disk image to get ld.so to reload the whole thing
properly again, but this will take some time and research.

My I please suggest we think about the name.  "Parallel GCL" at least
has 4 different meanings now -- mpi, socket based client/server,
traditional fork atop pipes, and threads in the future.  What do you
think about something with mpi in the name?

Take care,

"Paul F. Dietz" <address@hidden> writes:

> This is from the current cvs head:
> 
> bash-2.05b$ ./configure --enable-ansi --prefix=/home/dietz
> configure: error: cannot find sources (src/mpi_defglue.lsp) in . or ..
> 
>       Paul
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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