Creating standalone executables
Vincent Foley
this might have been asked before, in which case I should be flamed
(and possibly given a link to the original thread ;)), but which
Common Lisp implementation allow the creation of standalone executables?
I know both SBCL and CMUCL produce native code, but you need their
run-time files to execute those files. I'm think more something like
GCC would give? I would prefer free versions, but commercial might
be okay.
Thank you.
--
Vincent Foley-Bourgon
Email: vinf...@iquebec.com
Blog: http://www.livejournal.com/~gnuvince/
Erik Naggum
| this might have been asked before, in which case I should be flamed
| (and possibly given a link to the original thread ;)), but which
| Common Lisp implementation allow the creation of standalone
| executables?
Why do you want to build boot-loaders in Common Lisp?
--
Erik Naggum | Oslo, Norway 2004-032
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Henrik Motakef
> this might have been asked before
Only a few thousand times, as a quick search at groups.google.com
would almost certainly reveal. The last thread on this topic was
titled "compile", less than a week ago.
> in which case I should be flamed
The flames are more likely not about you bot bothering to inform
yourself about the available solutions, but because of your feeling
that there is much of a problem in the first place.
Generally, it is /very/ uncommon to really need to build "standalone"
executables. It seems that most people who ask for that want their
users to double-click some icon, or type some simple command in a
shell, and the app is started. This can almost always be done with a
simple starter shell-script like.
#!/bin/sh
my-lisp-implementation --load library-implementing-my-program --eval '(start-my-program)
Not to mention that "standalone" is almost never as standalone as you
might think, as Erik implied. They usually require a runtime
environment, the most popular ones being called "Unix" and "Windows",
and in most cases they need some dynamic libraries (and hence a linker
at run-time) like libc and libstdc++.
> (and possibly given a link to the original thread ;)), but which
> Common Lisp implementation allow the creation of standalone
> executables? I know both SBCL and CMUCL produce native code, but
> you need their run-time files to execute those files. I'm think
> more something like GCC would give? I would prefer free versions,
> but commercial might be okay.
CMUCL can create executables that are as standalone as what gcc
produces. They include the runtime, so you won't see any significant
decrease in size. SBCL can build something that pretends to be in a
way that no user is likely to care about the difference (see the
sb-executable contrib). ECL and GCL can (as far as I understand, I
never used them for that) build executables, indeed using GCC. The
non-trial versions of Lispworks and Allegro CL can also build
executables and include tree shakers that can make these executables
almost as small and unflexible as those you get with worse languages
(but they can also be used to create useful, flexible applications).
These are the most common choices for Unix, which I guess you use
given that you mention CMUCL and SBCL. There are other solutions for
Windows and (AFAIK) Mac OS X.
André Thieme
> Generally, it is /very/ uncommon to really need to build "standalone"
> executables. It seems that most people who ask for that want their
> users to double-click some icon, or type some simple command in a
> shell, and the app is started. This can almost always be done with a
> simple starter shell-script
If you want to deliver an application under Windows there usualy is no
Lisp installed. Delivering a .exe file (with some .dll's) comes handy.
Edi Weitz
> If you want to deliver an application under Windows there usualy is
> no Lisp installed. Delivering a .exe file (with some .dll's) comes
> handy.
All commercial Lisps on Windows can create .EXE files.
If you're using a "free" Lisp like CLISP you can deliver it together
with your app. If this packaged into a typical Windows installer
what's the difference between installing a couple of .DLLs and
installing a Lisp runtime? Most users won't notice anyway.
I cannot see the problem.
Edi.
André Thieme
> All commercial Lisps on Windows can create .EXE files.
>
> If you're using a "free" Lisp like CLISP you can deliver it together
> with your app. If this packaged into a typical Windows installer
> what's the difference between installing a couple of .DLLs and
> installing a Lisp runtime? Most users won't notice anyway.
>
> I cannot see the problem.
You cannot see the problem cause there is no problem.
It is just a question of comfort and safety.
If I develop with a commercial IDE like LispWorks, why shouldn't
I use its ability to create .dll and .exe files?
This way no curious user could configure some startup scripts.
It's probably a psychological thing - some people feel "better"
if they know their app is packed into a .exe file. It's more C'ish
and everyone knows this concept.
André
Pascal Bourguignon
On NeXTSTEP/OPENSTEP/MacOSX, the applications are "packed" in what's
called a file package, that is, a directory named with a .app
extension, containing the executable and all the needed files,
"resources" and other meta files. The important point is that the
Workspace Manager, or the Finder, present to the (naive) user these
file packages as a single atomic item, with its icon, and does not
allow (but the power users) to see what's inside. Actually, looking
inside such a file package directory is like looking what's inside a
resource fork on MacOS. Only Macintosh power users would use ResEdit
to look and manipulate the "embeded files" that are the resources.
Clearly, it's not only a psychological thing, it's also a question of
the tools that maintain the unity of all the elements composing the
application.
On ancient unix, an "application" spread it's components all over the
file system (some stuff in /usr/bin, some in /usr/lib, some in
/usr/shared, some in /usr/man, etc). That was Ok at a time when 5 MB
was a big hard drive and when there was no more than 2000 files in a
file system. But clearly this way poses problems, when you want to
uninstall an application with thousand of "resources", or when you
want to maintain it's integrity and ensure that none of these
components is missing or alterated.
Macintosh solved this issue with forked files and resources.
NeXT solved it more elegantly, and on a unix substrate, with file
packages, and with support from the GUI.
AFAIK, in MS-Windows an installer program can spread the .dll and .exe
on the disk, but it can provide the user with a single icon.
Note for example that on Linux, the way you'd encapsulate an
application to provide the user with an atomic icon for it depends on
the desktop GUI used. With GNUstep, it's the same as (compatible with)
what's done on NeXT/MacOSX. With Gnome or with KDE, I assume the
packaging is different.
How could a lisp implementation know what kind of packaging it should
provide? It depends on the desktop environment choosed by the user, so
it's best done by the programmer who will write scripts to encapsulate
its programs as required for his users' target desktop environment
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Joe Marshall
> * Vincent Foley
> | this might have been asked before, in which case I should be flamed
> | (and possibly given a link to the original thread ;)), but which
> | Common Lisp implementation allow the creation of standalone
> | executables?
>
> Why do you want to build boot-loaders in Common Lisp?
Boot-loaders usually assume a BIOS....
Erik Naggum
| Boot-loaders usually assume a BIOS....
Touché. It would be kind of cool with a Common Lisp BIOS, though. :)
--
Erik Naggum | Oslo, Norway 2004-033
Pascal Bourguignon
> * Joe Marshall
> | Boot-loaders usually assume a BIOS....
>
> Touché. It would be kind of cool with a Common Lisp BIOS, though. :)
Nowadays they program BIOS in FORTH.
OpenFirmware on Sun an Macintosh, and I think Intel wants to do the
new BIOS this way too. Should we suggest them to do it in Lisp rather?
Alexander Schreiber
But there aren't that many people who use sufficiently ancient version
of UNIX as their desktop environment and those tend to be able to deal
with it.
In case you haven't noticed, there are these newfangled things called
"package managers" on most _current_ version of Unix. Executables still
land in (leaning on Linux Filesystem Hierarchy Standard):
- /bin (non-privileged stuff used on startup),
- /sbin (privileged stuff used on startup),
- /usr/bin (non-privileged stuff for normal operations),
- /usr/sbin (privileged stuff for normal operations),
- /usr/X11R6/bin (X11 stuff)
and everything else in their appropriate place (like the manual pages
in the /usr/share/man hierarchy), but are under control of the package
management (be it RPM, Debian, emerge, Software Distributor (although
the commercial Unices tend to have rather messy filesystems), ...)
allowing for clean install and removal of packages.
So, all the executables are in a very limited number of places which is
comfortably stuffed into the PATH environment variable, keeping one from
hunting down the executables of whatever program one wants to run. Of
course, commercial software vendors, never being overly fond of
conforming to the standards of somebody else, have a tendency to ignore
that, but there are simple ways to fix that.
There are other places in the filesystem, usually /usr/local and /opt,
which have the "Danger! Crododiles lurking in the water!" character for
usually being not under package manager control and tending to decay
into a ugly mess when not tended carefully.
>Macintosh solved this issue with forked files and resources.
>
>NeXT solved it more elegantly, and on a unix substrate, with file
>packages, and with support from the GUI.
>
>AFAIK, in MS-Windows an installer program can spread the .dll and .exe
>on the disk, but it can provide the user with a single icon.
>
>
>Note for example that on Linux, the way you'd encapsulate an
>application to provide the user with an atomic icon for it depends on
>the desktop GUI used. With GNUstep, it's the same as (compatible with)
>what's done on NeXT/MacOSX. With Gnome or with KDE, I assume the
>packaging is different.
>
>
>How could a lisp implementation know what kind of packaging it should
>provide? It depends on the desktop environment choosed by the user, so
>it's best done by the programmer who will write scripts to encapsulate
>its programs as required for his users' target desktop environment
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Ingvar Mattsson
> * Joe Marshall
> | Boot-loaders usually assume a BIOS....
>
> Touché. It would be kind of cool with a Common Lisp BIOS, though. :)
CommonBoot? IIRC, the Forth BIOS is called openBoot or OpenFirmware.
//Ingvar
--
((lambda (x) `(,x ',x)) '(lambda (x) `(,x ',x)))
Probably KMP
Ng Pheng Siong
> If I develop with a commercial IDE like LispWorks, why shouldn't
> I use its ability to create .dll and .exe files?
> This way no curious user could configure some startup scripts.
On Windows you may still need to store some stuff in the registry to
bootstrap the application.
--
Ng Pheng Siong <ng...@netmemetic.com>
http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL
Ng Pheng Siong
> In case you haven't noticed, there are these newfangled things called
> "package managers" on most _current_ version of Unix.
> There are other places in the filesystem, usually /usr/local and /opt,
> which have the "Danger! Crododiles lurking in the water!" character for
> usually being not under package manager control and tending to decay
> into a ugly mess when not tended carefully.
Check out Usenix proceedings from the early 90's. Plenty of oldfangled
package managers operating on /usr/local, /opt, whatever.
Cross-Unixen/CPU/architecture, too, instead of having this one for Debian,
that one for RedHat, this other one for Gentoo.
Hannah Schroeter
Ng Pheng Siong <ng...@netmemetic.com> wrote:
>According to Alexander Schreiber <a...@usenet.thangorodrim.de>:
>> In case you haven't noticed, there are these newfangled things called
>> "package managers" on most _current_ version of Unix.
>> [...]
>> There are other places in the filesystem, usually /usr/local and /opt,
>> which have the "Danger! Crododiles lurking in the water!" character for
>> usually being not under package manager control and tending to decay
>> into a ugly mess when not tended carefully.
>Check out Usenix proceedings from the early 90's. Plenty of oldfangled
>package managers operating on /usr/local, /opt, whatever.
OpenBSD uses /usr/local as default package installation prefix,
if you just look besides the Linux world.
>[...]
Kind regards,
Hannah.
Brian Downing
In article <slrnc1v0f...@thangorodrim.de>,
Alexander Schreiber <a...@usenet.thangorodrim.de> wrote:
> There are other places in the filesystem, usually /usr/local and /opt,
> which have the "Danger! Crododiles lurking in the water!" character for
> usually being not under package manager control and tending to decay
> into a ugly mess when not tended carefully.
You might try looking at http://www.encap.org/. It's a very easy to use
packager that I use to keep /usr/local from exploding into uselessness.
It's very handy to use for stuff you install by hand as it won't
conflict with the native package manager of your OS.
$ ls -l /usr/local/bin/sbcl
ls: /usr/local/bin/sbcl: No such file or directory
$ ls -l /usr/local/encap/sbcl-0.8.6/bin/sbcl
-rwxr-xr-x 1 root wheel 365364 15 Jan 14:19 /usr/local/encap/sbcl-0.8.6/bin/sbcl*
$ sudo epkg sbcl-0.8.6
epkg: installing package sbcl-0.8.6...
> reading Encap source directory...
> installing package sbcl-0.8.6
> installation successful
$ ls -l /usr/local/bin/sbcl
lrwxr-xr-x 1 root wheel 28 3 Feb 11:43 /usr/local/bin/sbcl@ -> ../encap/sbcl-0.8.6/bin/sbcl
$ sudo epkg -r sbcl-0.8.6
epkg: removing package sbcl-0.8.6...
> reading Encap source directory...
> removing package sbcl-0.8.6
> removal successful
$ ls -l /usr/local/bin/sbcl
ls: /usr/local/bin/sbcl: No such file or directory
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Thomas F. Burdick
> Pascal Bourguignon <sp...@thalassa.informatimago.com> wrote:
>
> >On ancient unix, an "application" spread it's components all over the
> >file system (some stuff in /usr/bin, some in /usr/lib, some in
> >/usr/shared, some in /usr/man, etc). That was Ok at a time when 5 MB
> >was a big hard drive and when there was no more than 2000 files in a
> >file system. But clearly this way poses problems, when you want to
> >uninstall an application with thousand of "resources", or when you
> >want to maintain it's integrity and ensure that none of these
> >components is missing or alterated.
>
> But there aren't that many people who use sufficiently ancient version
> of UNIX as their desktop environment and those tend to be able to deal
> with it.
No kidding. It doesn't take a genius to figure out how symlinks work.
Once you see a /usr/local/packages/ directory somewhere, and notice
the symlinks pointing into it, you're home free. I assume that every
halfway reasonable Unix sysadmin know how to do this. Not everything
comes packaged, after all.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Alexander Schreiber
>a...@usenet.thangorodrim.de (Alexander Schreiber) writes:
>
>> Pascal Bourguignon <sp...@thalassa.informatimago.com> wrote:
>>
>> >On ancient unix, an "application" spread it's components all over the
>> >file system (some stuff in /usr/bin, some in /usr/lib, some in
>> >/usr/shared, some in /usr/man, etc). That was Ok at a time when 5 MB
>> >was a big hard drive and when there was no more than 2000 files in a
>> >file system. But clearly this way poses problems, when you want to
>> >uninstall an application with thousand of "resources", or when you
>> >want to maintain it's integrity and ensure that none of these
>> >components is missing or alterated.
>>
>> But there aren't that many people who use sufficiently ancient version
>> of UNIX as their desktop environment and those tend to be able to deal
>> with it.
>
>No kidding. It doesn't take a genius to figure out how symlinks work.
>Once you see a /usr/local/packages/ directory somewhere, and notice
>the symlinks pointing into it, you're home free. I assume that every
>halfway reasonable Unix sysadmin know how to do this. Not everything
>comes packaged, after all.
Of course. Thats why /usr/local in boxes I managed tends to be a bunch
of directories and symlinks farm with almost no files there. Stuff gets
installed as /opt/foobar-3.23, then a symlink is set up as /opt/foobar
pointing to /opt/foobar-3.23, and finally a cluster of symlinks is
cretaed:
- /opt/foobar/bin/* -> /usr/local/bin,
- /opt/foobar/lib/* -> /usr/local/lib,
- /opt/foobar/man*/* -> /usr/local/man*
Makes live a lot easier. Keeps /usr/local from decaying into a smelly
minefield, allows one to install and test foobar-$new while keeping
$foobar-$current around.
Of course, instead of /opt one might choose to use /usr/local/packages
or something similar.
And if I need the foobar package on more than one or two machines, I can
go and build a native package for whatever package manager the system in
question uses.
Alexander Schreiber
Which I think is not a good decision, because /usr/local is historically
the place for "site installed" stuff that was not covered by the set
available with the installed system. NetBSD uses /usr/pkg for this - an
IMHO better decision.
>if you just look besides the Linux world.
I do, working with and admining on Solaris, HP-UX, FreeBSD, NetBSD,
and several flavours of Linux regularly.
David Golden
Rahul Jain
> Not everything comes packaged, after all.
It does after I want to install it. :)
--
Rahul Jain
rj...@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Thomas F. Burdick
> t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Not everything comes packaged, after all.
>
> It does after I want to install it. :)
You're a better man^[^Hsysadmin than I. I do have a horrid shell
script named "package" that creates symlinks, which I think makes me at
least some sort of sysadmin :-)
szymon
> Clearly, it's not only a psychological thing, it's also a question of
> the tools that maintain the unity of all the elements composing the
> application.
>
> On ancient unix, an "application" spread it's components all over the
> file system (some stuff in /usr/bin, some in /usr/lib, some in
> /usr/shared, some in /usr/man, etc). That was Ok at a time when 5 MB
> was a big hard drive and when there was no more than 2000 files in a
> file system. But clearly this way poses problems, when you want to
> uninstall an application with thousand of "resources", or when you
> want to maintain it's integrity and ensure that none of these
> components is missing or alterated.
I found *very* nice solution:
------------------------------------------------------------------------------
TITLE: More control and package management using package users (v0.8)
LFS VERSION: 3.1 (should work with later versions with minor changes)
AUTHOR: Matthias S. Benkmann
SYNOPSIS:
-You want to know which packages your files belong to ?
-You want to deinstall software that doesn't have make uninstall ?
-You are bothered by programs installed setuid root behind your back ?
-You don't want packages to overwrite files from other packages ?
-You don't like package managers like RPM ?
-YOU WANT TOTAL CONTROL USING ONLY UNIX BUILTINS ?
..........
..........
this file has 53501 bytes, i think it's too large to post it (and
it's not about CL)
..........
------------------------------------------------------------------------------
regards, szymon.