Samium Gromoff | 4 Sep 16:08 2010
Picon

Poll: where do you get SBCL from on OS X?

Good day folks,

As some of you may know, I'm setting up a VM farm, with an end goal of
establishing automated build tests for most of the open-source lisp
software on main platform/lisp combinations.

I've deliberately chosen a policy of setting up "the easiest available"
versions of supported lisps in these platforms, so as to try to
ostensibly reproduce the way of the "common lisper"[1], which is,
supposedly, at odds with the #lisp wisdom of "getting everything
from CVS/git/...", and even with the more reasonable "getting binaries
from sourceforge".

This is deliberate, to put it again, to cater to the newcoming
people, and ultimately, in an attempt to lower the entry barrier.

So, with all this said (forgive me for stretching your patience,
but I thought that this point needed deliberation, for the virtue
of being an uncommon one), I'd like to address the non-bleeding-edge
Lispers running SBCL on Mac OS X -- how do you tend to obtain it?

Sourceforge? 

Unstable fink? 

--

-- 
regards,
  Samium Gromoff
--
1. Pun not intended, but was sort of unavoidable..
(Continue reading)

Troy Noble | 7 Sep 04:11 2010
Picon

1.0.42 build problem on Solaris Sparc... in make-target-2.sh

Apologies if I'm on the wrong list.  I saw some recent bug fixes on the list for Sparc Solaris build.  I manually fixed runtime.c to #include <limits.h> as recommended... I was able to get src/runtime/sbcl to build successfully.

I am trying to use 1.0.23 sparc solaris binaries to build 1.0.42 from source on Solaris 8 (sparcv9) with 32-bit GCC 3.4.3 and Sun 'as' assembler.

I am getting a "lose" during output/cold-sbcl.core load with message: "can't load .core for different runtime, sorry"

I'm not sure where to go from here...  Any help would be appreciated.

$ sh make.sh --xc-host='/proj-0/apps/sbcl-1.0.23/bin/sbcl --core /proj-0/apps/sbcl-1.0.23/lib/sbcl/sbcl.core --disable-debugger --no-userinit --no-sysinit' --prefix=/net/plaka/proj-0/apps/sbcl-1.0.42

....
beginning GENESIS, creating core "output/cold-sbcl.core"
WARNING: ignoring unrecognized line "" in src/runtime/sbcl.nm
WARNING: ignoring unrecognized line "" in src/runtime/sbcl.nm
WARNING: ignoring unrecognized line "sbcl:" in src/runtime/sbcl.nm
WARNING: ignoring unrecognized line "0x0003bc88 s" in src/runtime/sbcl.nm
WARNING: ignoring unrecognized line "0x0003bc94 s" in src/runtime/sbcl.nm
WARNING: ignoring unrecognized line "0x0003bc98 s" in src/runtime/sbcl.nm
...
WARNING: ignoring unrecognized line "0x0003b750 s" in src/runtime/sbcl.nm
WARNING: ignoring unrecognized line "0x0003bc80 s" in src/runtime/sbcl.nm
WARNING: redefining "force_to_data" from #X3BC7C to #X3B750
obj/from-xc/src/code/show.lisp-obj
obj/from-xc/src/code/early-source-location.lisp-obj
obj/from-xc/src/code/early-constants.lisp-obj
obj/from-xc/src/code/backq.lisp-obj
obj/from-xc/src/code/globals.lisp-obj
...
obj/from-xc/src/code/late-defbangmethod.lisp-obj
obj/from-xc/src/pcl/walk.lisp-obj
[building initial core file in "output/cold-sbcl.core":
writing 8192 bytes [1 page] from #<SB!FASL::GSPACE :READ-ONLY>
writing 8192 bytes [1 page] from #<SB!FASL::GSPACE :STATIC>
writing 29908992 bytes [3651 pages] from #<SB!FASL::GSPACE :DYNAMIC>
/(DESCRIPTOR-BITS INITIAL-FUN)=#X31B84B6D
done]
* //testing for consistency of first and second GENESIS passes
//header files match between first and second GENESIS -- good

real    18:42.4
user    17:14.8
sys      1:18.0
//entering make-target-2.sh
//doing warm init - compilation phase
This is SBCL 1.0.42, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
fatal error encountered in SBCL pid 5601:
can't load .core for different runtime, sorry

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>  <CTRL-D>

$ file src/runtime/sbcl
src/runtime/sbcl:       ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
$ file output/cold-sbcl.core
output/cold-sbcl.core:  data


I tried running the command manually with truss to see if it would reveal anything.  It appears that it is at least trying to load output/cold-sbcl.core:

$ truss ./src/runtime/sbcl --core output/cold-sbcl.core --lose-on-corruption --no-sysinit --no-userinit <make-target-2.lisp
...
This is SBCL 1.0.42, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
write(1, " T h i s   i s   S B C L".., 362)     = 362
time()                                          = 1283823477
open("/usr/share/lib/zoneinfo/US/Mountain", O_RDONLY) = 3
read(3, " T Z i f\0\0\0\0\0\0\0\0".., 8192)     = 877
close(3)                                        = 0
open("output/cold-sbcl.core", O_RDONLY)         = 3
lseek(3, 0, SEEK_SET)                           = 0
brk(0x00040FB0)                                 = 0
brk(0x00042FB0)                                 = 0
read(3, " S B C L\0\00F14\0\0\003".., 8192)     = 8192
sigprocmask(SIG_BLOCK, 0x0003CF80, 0x00000000)  = 0
fatal error encounteredwrite(2, " f a t a l   e r r o r  ".., 23)       = 23
getpid()                                        = 5611 [5610]
 in SBCL pid write(2, "   i n   S B C L   p i d".., 13) = 13
5611write(2, " 5 6 1 1", 4)                             = 4
:
write(2, " :\n", 2)                             = 2
can't load .core for different runtime, sorry
write(2, " c a n ' t   l o a d   .".., 46)      = 46

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Sbcl-help mailing list
Sbcl-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help
Didier Verna | 13 Sep 13:54 2010
X-Face
Face
Picon
Picon
Picon
Picon

[CfP] 4th European Lisp Symposium, Hamburg, March 31 - April 1st, 2011


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

		     4th European Lisp Symposium
	      Special Focus on Parallelism & Efficiency

		      March 31 - April 1st, 2011
		TUHH, Hamburg University of Technology
			   Hamburg, Germany

	       http://www.european-lisp-symposium.org/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Important Dates
~~~~~~~~~~~~~~~~
+ Submission Deadline: January  09, 2011
+ Author Notification: February 06, 2011
+ Final Paper Due:     February 28, 2011
+ Symposium:           March 31 - April 1st, 2011

Authors of accepted research contributions will be invited to submit
an extended version of their papers for journal publication.

Scope
~~~~~~
The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp dialects, including
Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure,
ACL2, ECMAScript, Racket and so on. We encourage everyone interested
in Lisp to participate.

The European Lisp Symposium 2011 invites high quality papers about
novel research results, insights and lessons learned from practical
applications, and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

This year's focus will be directed towards "Parallelism & Efficiency".
We especially invite submissions in the following areas:

+ Parallel and distributed computing
+ Code generation for multi-core architectures
+ Code generation for HTM
+ Large and ultra-large systems
+ Optimization techniques
+ Embedded applications

Contributions are also welcome in other areas, including but not
limited to:

+ Context-, aspect-, domain-oriented and generative programming
+ Macro-, reflective-, meta- and/or rule-based development approaches
+ Language design and implementation
+ Language integration, inter-operation and deployment
+ Development methodologies, support and environments
+ Educational approaches and perspectives
+ Experience reports and case studies

Technical Program:
~~~~~~~~~~~~~~~~~~
We invite submissions in the following forms:

* Papers: Technical papers of up to 15 pages that describe original
  results or explain known ideas in new and elegant ways.

* Demonstrations: Abstracts of up to 4 pages for demonstrations of
  tools, libraries, and applications.

* Tutorials: Abstracts of up to 4 pages for in-depth presentations
  about topics of special interest for at least 90 minutes and up to
  180 minutes.

* Lightning talks: Abstracts of up to one page for talks to last for
  no more than 5 minutes.

All submissions should be formatted following the ACM SIGS guidelines
and include ACM classification categories and terms. For more
information on the submission guidelines and the ACM keywords, see:
http://www.acm.org/sigs/publications/proceedings-templates
http://www.acm.org/about/class/1998

Submissions should be uploaded to Easy Chair, at the following address:
http://www.easychair.org/conferences/?conf=els2011

Programme Chair
~~~~~~~~~~~~~~~~
Didier Verna - EPITA Research and Development Laboratory, France

Local Chair
~~~~~~~~~~~~
Ralf Moeller - Hamburg University of Technology, Germany

Programme Committee
~~~~~~~~~~~~~~~~~~~~
Antonio Leitao - Instituto Superior Tecnico/INESC-ID, Portugal
Christophe Rhodes - Goldsmiths College, University of London, UK
David Edgar Liebke - Relevance Inc., USA
Didier Verna - EPITA Research and Development Laboratory, France
Henry Lieberman - MIT Media Laboratory, USA
Jay McCarthy - Brigham Young University, USA
Jose Luis Ruiz Reina - Universidad de Sevilla, Spain
Marco Antoniotti - Universita Milano Bicocca, Italy
Manuel Serrano - INRIA, France
Michael Sperber - DeinProgramm, Germany
Pascal Costanza - Vrije Universiteit of Brussel, Belgium
Scott McKay - ITA Software, USA

--

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
Peter Keller | 15 Sep 05:11 2010
Picon

Shared objects

Hello,

How can I find the absolute paths of all the loaded shared libraries
in a running lisp image? I'm writing an application which, before it
calls save-lisp-and-die, needs to copy all loaded shared libraries to
the current working directory of the lisp image. This is so the shared
objects it needs can be moved along with the executable to another machine
for execution. A constraint is that I'm not going to know a priori the
set of loaded shared objects until just before I call save-lisp-and-die
and those libraries may have been loaded via cffi or some other means.

Also, how do I adjust the lisp image to find said libraries (suppose in
the same path as the executable) when the executable restarts? I can
use LD_LIBRARY_PATH, but I'd prefer if I could somehow tell the image
just before it dies a new set of paths to search whenever a request to
load a library shows up.

How would I reliably do these things?  I'm happy to live with an SBCL
only solution.

Thank you.

-pete

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
Nikodemus Siivola | 15 Sep 10:19 2010
Picon

Re: Shared objects

On 15 September 2010 06:11, Peter Keller <psilord <at> cs.wisc.edu> wrote:

> How can I find the absolute paths of all the loaded shared libraries
> in a running lisp image? I'm writing an application which, before it
> calls save-lisp-and-die, needs to copy all loaded shared libraries to
> the current working directory of the lisp image. This is so the shared
> objects it needs can be moved along with the executable to another
> machine for execution. A constraint is that I'm not going to know a
> priori the set of loaded shared objects until just before I call
> save-lisp-and-die and those libraries may have been loaded via cffi
> or some other means.

This is going to be ugly, and is technically unsupported right now.
Sorry about that.

SB-SYS:*SHARED-OBJECTS* holds a list of all shared objects loaded.
This includes stuff loaded bu CFFI.

SB-ALIEN::SHARED-OBJECT-PATHNAME is the result of calling (PATHNAME
...) on the argument to LOAD-SHARED-OBJECT.

SB-ALIEN::SHARED-OBJECT-NAMESTRING is the native namestring that
dlopen() was called with to load that so. (If you want the lisp
pathname, use NATIVE-PATHNAME to parse it.)

SHARED-OBJECT-PATHNAME is only informational. S-O-NAMESTRING is what
is actually used by dlopen() when an image is reinitialized.

That's not too bad. Now comes the nasty bit.

To get the actual absolute pathname of the .so you have to duplicate
the searching behaviour of dlopen(), which is somewhat platform
dependent, and also depends on the current working directory at the
time the library was loaded.

For 90% of cases just searching LD_LIBRARY_PATH likely sufficient and
correct -- if that works for your case, good. If not, read the dlopen
docs carefully, and see what other environment variables or hardcoded
locations are involved.

If you find you have something loaded using current working directory,
you're really out of luck right now -- either you have to alter SBCL
to save the that information when the .so is loaded, or perhaps
preferably, alter the code that does so to do something else (eg. use
an absolute path.)

> Also, how do I adjust the lisp image to find said libraries (suppose
> in the same path as the executable) when the executable restarts? I
> can use LD_LIBRARY_PATH, but I'd prefer if I could somehow tell the
> image just before it dies a new set of paths to search whenever a
> request to load a library shows up.

Something like this, (untested):

(defun fix-shared-object (obj new-pathname)
  (declare (pathname new-pathname))
  (setf (sb-alien::shared-object-pathname obj) new-pathname)
  (setf (sb-alien::shared-object-namestring obj)
	(native-namestring (translate-logical-pathname new-pathname)
			   :as-file t))
  obj)

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
Michael Livshin | 15 Sep 11:16 2010
Picon

Re: Shared objects

Peter Keller <psilord <at> cs.wisc.edu> writes:

> How can I find the absolute paths of all the loaded shared libraries
> in a running lisp image?
>
> ...
>
> How would I reliably do these things?  I'm happy to live with an SBCL
> only solution.

if a linux-only solution is acceptable, you can just parse
/proc/≤PID>/maps to get the precise info, no need to second-guess
dlopen() and friends.

cheers,
--m

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
Jim Wise | 15 Sep 15:28 2010

Re: Shared objects

Michael Livshin <gmane <at> cmm.kakpryg.net> writes:

> Peter Keller <psilord <at> cs.wisc.edu> writes:
>
>> How can I find the absolute paths of all the loaded shared libraries
>> in a running lisp image?
>>
>> ...
>>
>> How would I reliably do these things?  I'm happy to live with an SBCL
>> only solution.
>
> if a linux-only solution is acceptable, you can just parse
> /proc/≤PID>/maps to get the precise info, no need to second-guess
> dlopen() and friends.

Likewise, on Solaris, the pldd(1) command can be used to list the paths
of all shared objects loaded into a running process.

--

-- 
				Jim Wise
				jwise <at> draga.com
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Sbcl-help mailing list
Sbcl-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help
Peter Keller | 15 Sep 17:02 2010
Picon

Re: Shared objects

On Wed, Sep 15, 2010 at 11:16:56AM +0200, Michael Livshin wrote:
> Peter Keller <psilord <at> cs.wisc.edu> writes:
> 
> > How can I find the absolute paths of all the loaded shared libraries
> > in a running lisp image?
> >
> > ...
> >
> > How would I reliably do these things?  I'm happy to live with an SBCL
> > only solution.
> 
> if a linux-only solution is acceptable, you can just parse
> /proc/≤PID>/maps to get the precise info, no need to second-guess
> dlopen() and friends.

There is somewhat of an impedance mismatch between the information found in 
/proc/PID/maps, and that known by SBCL.

Suppose we take librt.so as an example.

SBCL (via sb-sys:*shared-objects*) knows the name of that library
as "librt.so" and that's how it will try to load it. However, the
/proc/PID/maps entry for it is "/usr/lib/librt-2.5.so". So while I'd be
able to get the actual contents of the file by searching /proc/PID/maps, I
wouldn't get the logical symlink name for it, only the physical filename.
Due to this, if I copy /usr/lib/librt-2.5.so to the current working directory
it won't matter since the lisp image will look for librt.so.

Thank you.

-pete

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
Nikodemus Siivola | 15 Sep 17:11 2010
Picon

Re: Shared objects

On 15 September 2010 18:02, Peter Keller <psilord <at> cs.wisc.edu> wrote:

> There is somewhat of an impedance mismatch between the information found in
> /proc/PID/maps, and that known by SBCL.
>
> Suppose we take librt.so as an example.
>
> SBCL (via sb-sys:*shared-objects*) knows the name of that library
> as "librt.so" and that's how it will try to load it. However, the
> /proc/PID/maps entry for it is "/usr/lib/librt-2.5.so". So while I'd be
> able to get the actual contents of the file by searching /proc/PID/maps, I
> wouldn't get the logical symlink name for it, only the physical filename.
> Due to this, if I copy /usr/lib/librt-2.5.so to the current working directory
> it won't matter since the lisp image will look for librt.so.

It's whack-a-mole.

I think you can get by by considering only those objects whose map
names have a subsequence matching the pathname-name.pathname-type of
stuff in sb-sys:*shared-objects*, and passing the resolved name (in
the new location) to fix-shared-object.

Of couse, if you have libfoo.so resolving to libbar-1.0.so, then the
maps approach is pretty useless for your purposes.

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
Peter Keller | 15 Sep 18:08 2010
Picon

Re: Shared objects

On Wed, Sep 15, 2010 at 11:19:16AM +0300, Nikodemus Siivola wrote:
> On 15 September 2010 06:11, Peter Keller <psilord <at> cs.wisc.edu> wrote:
> 
> > How can I find the absolute paths of all the loaded shared libraries
> > in a running lisp image? I'm writing an application which, before it
> > calls save-lisp-and-die, needs to copy all loaded shared libraries to
> > the current working directory of the lisp image. This is so the shared
> > objects it needs can be moved along with the executable to another
> > machine for execution. A constraint is that I'm not going to know a
> > priori the set of loaded shared objects until just before I call
> > save-lisp-and-die and those libraries may have been loaded via cffi
> > or some other means.
> 
> This is going to be ugly, and is technically unsupported right now.
> Sorry about that.

Thank you for the help! I appreciate it very much. The purpose of my
query is that I've written a master/slave library meant for distributed
computing and I want to make the production of the application binary
(and associated libraries) as simple and complete as possible for the
developer.

> To get the actual absolute pathname of the .so you have to duplicate
> the searching behaviour of dlopen(), which is somewhat platform
> dependent, and also depends on the current working directory at the
> time the library was loaded.

> For 90% of cases just searching LD_LIBRARY_PATH likely sufficient and
> correct -- if that works for your case, good. If not, read the dlopen
> docs carefully, and see what other environment variables or hardcoded
> locations are involved.

This is the hard part if only because there isn't a premade library
to parse ELF executables and I'd have to use (which I presume exists
though I don't see it in the SBCL manual) a native interface for reading
environment variables in SBCL.

I could write enough of an ELF file format parser to get what I need
out of the SBCL executable itself. I'm not too worried about that. The
ELF portion I really have to pay attention to is DT_RPATH, since that is
a pretty commonly used feature.

Hmm... loading the /etc/ld.so.cache file would probably go pretty far in
giving me the information I need concerning mapping bare library names
to pathnames. I will explore this one first since it seems so promising.
Google seems strangely silent on the file format for that file....

> If you find you have something loaded using current working directory,
> you're really out of luck right now -- either you have to alter SBCL
> to save the that information when the .so is loaded, or perhaps
> preferably, alter the code that does so to do something else (eg. use
> an absolute path.)

I'm going to bail on this problem since it doesn't come up that much in
practice. Once the executable has been saved, it is very unlikely in my
use cases that save-lisp-and-die will be called in the binary.

> Something like this, (untested):
> 
> (defun fix-shared-object (obj new-pathname)
>   (declare (pathname new-pathname))
>   (setf (sb-alien::shared-object-pathname obj) new-pathname)
>   (setf (sb-alien::shared-object-namestring obj)
> 	(native-namestring (translate-logical-pathname new-pathname)
> 			   :as-file t))
>   obj)

I was doing something similar, but not as correct. :)

Thanks!

-pete

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Gmane