Question about clisp version naming

Question about clisp version naming

[Ken Brown]

I've succeeded in making dynamic loading of modules work in clisp on 
Cygwin, and I'll be issuing a new release soon.

My work was based on the tip of the upstream Mercurial repository, which 
shows a version number of 2.49+ and is at revision 15623.  So I was 
thinking of using 2.49+hg15623 as the version number.  Will upset be 
happy with that?  Or is there some other standard way of assigning 
version numbers in cases like this?

Ken

Re: Question about clisp version naming

[Yaakov Selkowitz]

On Wed, 2015-03-11 at 17:35 -0400, Ken Brown wrote:
> I've succeeded in making dynamic loading of modules work in clisp on 
> Cygwin, and I'll be issuing a new release soon.

Yeah!

> My work was based on the tip of the upstream Mercurial repository, which 
> shows a version number of 2.49+ and is at revision 15623.  So I was 
> thinking of using 2.49+hg15623 as the version number.  Will upset be 
> happy with that?  Or is there some other standard way of assigning 
> version numbers in cases like this?

With setup now being stricter about versions wrt upgrading, we need to
be as well.  Because this is a post-2.49 revision, it should be
VERSION=2.49 and RELEASE=2.YYYYMMDDhg15623 (since there was already a
-1).

--
Yaakov

Re: Question about clisp version naming

[Achim Gratz]

Yaakov Selkowitz writes:
>> My work was based on the tip of the upstream Mercurial repository, which 
>> shows a version number of 2.49+ and is at revision 15623.  So I was 
>> thinking of using 2.49+hg15623 as the version number.  Will upset be 
>> happy with that?  Or is there some other standard way of assigning 
>> version numbers in cases like this?
>
> With setup now being stricter about versions wrt upgrading, we need to
> be as well.  Because this is a post-2.49 revision, it should be
> VERSION=2.49 and RELEASE=2.YYYYMMDDhg15623 (since there was already a
> -1).

Version numbers like the one Ken has proposed are becoming common in
Linux distributions, so we'd rather check that setup handles them
correctly.  I think Jari already uses a bunch of them.  The thing here
is that for all versioning schemes that use hashes you need to prepend
an ISO date so things sort correctly, but I'd rather not append this to
the release number, so I'd suggest VERSION=2.49+YYYYMMDDhg15623 instead.
Also, I don't think it's a good idea to allow "."  in the release
number.  Alphas already work in that place (I use that for snapshots
since years) and are a lot less ambigous if you try to parse the release
out of a file name.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Question about clisp version naming

[Ken Brown]

On 3/11/2015 6:20 PM, Yaakov Selkowitz wrote:
> On Wed, 2015-03-11 at 17:35 -0400, Ken Brown wrote:
>> I've succeeded in making dynamic loading of modules work in clisp on
>> Cygwin, and I'll be issuing a new release soon.
>
> Yeah!
>
>> My work was based on the tip of the upstream Mercurial repository, which
>> shows a version number of 2.49+ and is at revision 15623.  So I was
>> thinking of using 2.49+hg15623 as the version number.  Will upset be
>> happy with that?  Or is there some other standard way of assigning
>> version numbers in cases like this?
>
> With setup now being stricter about versions wrt upgrading, we need to
> be as well.  Because this is a post-2.49 revision, it should be
> VERSION=2.49 and RELEASE=2.YYYYMMDDhg15623 (since there was already a
> -1).

That's fine with me, but I just want to make sure that there's no typo 
in what you wrote.  Are we really going to start having release numbers 
that aren't just integers?

Ken

Re: Question about clisp version naming

[Yaakov Selkowitz]

On Thu, 2015-03-12 at 07:32 -0400, Ken Brown wrote:
> On 3/11/2015 6:20 PM, Yaakov Selkowitz wrote:
> > On Wed, 2015-03-11 at 17:35 -0400, Ken Brown wrote:
> >> I've succeeded in making dynamic loading of modules work in clisp on
> >> Cygwin, and I'll be issuing a new release soon.
> >
> > Yeah!
> >
> >> My work was based on the tip of the upstream Mercurial repository, which
> >> shows a version number of 2.49+ and is at revision 15623.  So I was
> >> thinking of using 2.49+hg15623 as the version number.  Will upset be
> >> happy with that?  Or is there some other standard way of assigning
> >> version numbers in cases like this?
> >
> > With setup now being stricter about versions wrt upgrading, we need to
> > be as well.  Because this is a post-2.49 revision, it should be
> > VERSION=2.49 and RELEASE=2.YYYYMMDDhg15623 (since there was already a
> > -1).
> 
> That's fine with me, but I just want to make sure that there's no typo 
> in what you wrote.  Are we really going to start having release numbers 
> that aren't just integers?

We already started that with the Cygwin test prereleases.

--
Yaakov

Re: Question about clisp version naming

[Ken Brown]

On 3/12/2015 2:43 AM, Achim Gratz wrote:
> Yaakov Selkowitz writes:
>>> My work was based on the tip of the upstream Mercurial repository, which
>>> shows a version number of 2.49+ and is at revision 15623.  So I was
>>> thinking of using 2.49+hg15623 as the version number.  Will upset be
>>> happy with that?  Or is there some other standard way of assigning
>>> version numbers in cases like this?
>>
>> With setup now being stricter about versions wrt upgrading, we need to
>> be as well.  Because this is a post-2.49 revision, it should be
>> VERSION=2.49 and RELEASE=2.YYYYMMDDhg15623 (since there was already a
>> -1).
>
> Version numbers like the one Ken has proposed are becoming common in
> Linux distributions, so we'd rather check that setup handles them
> correctly.  I think Jari already uses a bunch of them.  The thing here
> is that for all versioning schemes that use hashes you need to prepend
> an ISO date so things sort correctly, but I'd rather not append this to
> the release number, so I'd suggest VERSION=2.49+YYYYMMDDhg15623 instead.
> Also, I don't think it's a good idea to allow "."  in the release
> number.  Alphas already work in that place (I use that for snapshots
> since years) and are a lot less ambigous if you try to parse the release
> out of a file name.

Sorry, but Yaakov says we already allow dots in the release number, and 
he's the distro czar.  So I'm going with his suggestion.

Ken

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
>> Version numbers like the one Ken has proposed are becoming common in
>> Linux distributions, so we'd rather check that setup handles them
>> correctly.  I think Jari already uses a bunch of them.  The thing here
>> is that for all versioning schemes that use hashes you need to prepend
>> an ISO date so things sort correctly, but I'd rather not append this to
>> the release number, so I'd suggest VERSION=2.49+YYYYMMDDhg15623 instead.
>> Also, I don't think it's a good idea to allow "."  in the release
>> number.  Alphas already work in that place (I use that for snapshots
>> since years) and are a lot less ambigous if you try to parse the release
>> out of a file name.
>
> Sorry, but Yaakov says we already allow dots in the release number,
> and he's the distro czar.  So I'm going with his suggestion.

As you wish.  I still think his view is somewhat unique looking at the
version numbers in several Linux distros that provide packages
in-between-official-releases from several VCS.  The only case that I
know where the VCS revision tag was used in the relase part of the
version string was when the release was made from a local branch in all
other cases they'd been appended to the latest release version string.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Question about clisp version naming

[Achim Gratz]

Achim Gratz writes:
> As you wish.  I still think his view is somewhat unique looking at the
> version numbers in several Linux distros that provide packages
> in-between-official-releases from several VCS.  The only case that I
> know where the VCS revision tag was used in the relase part of the
> version string was when the release was made from a local branch in all
> other cases they'd been appended to the latest release version string.

Here are a few examples from my Tumbleweed installation for illustration:

| grub2-x86_64-efi      | 2.02~beta2-33.1                    |
| libffi4-32bit         | 4.8.3+r218481-2.1                  |
| libiniparser0-32bit   | 3.1.0.git20140619_c5beb80a-3.1     |
| liblockdev1-32bit     | 1.0.3_git201003141408-29.2         |
| libspeex1-32bit       | 1.1.999_1.2rc2-1.1                 |
| shim                  | 0.7.318.81ee561d-9.1               |
| libx265-32            | 0.32hg20140928-2.10                |


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Question about clisp version naming

[Yaakov Selkowitz]

On Fri, 2015-03-13 at 20:27 +0100, Achim Gratz wrote:
> Ken Brown writes:
> >> Version numbers like the one Ken has proposed are becoming common in
> >> Linux distributions, so we'd rather check that setup handles them
> >> correctly.  I think Jari already uses a bunch of them.  The thing here
> >> is that for all versioning schemes that use hashes you need to prepend
> >> an ISO date so things sort correctly, but I'd rather not append this to
> >> the release number, so I'd suggest VERSION=2.49+YYYYMMDDhg15623 instead.
> >> Also, I don't think it's a good idea to allow "."  in the release
> >> number.  Alphas already work in that place (I use that for snapshots
> >> since years) and are a lot less ambigous if you try to parse the release
> >> out of a file name.
> >
> > Sorry, but Yaakov says we already allow dots in the release number,
> > and he's the distro czar.  So I'm going with his suggestion.
> 
> As you wish.  I still think his view is somewhat unique looking at the
> version numbers in several Linux distros that provide packages
> in-between-official-releases from several VCS.  The only case that I
> know where the VCS revision tag was used in the relase part of the
> version string was when the release was made from a local branch in all
> other cases they'd been appended to the latest release version string.

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning

Except we don't (yet) have Epoch (PTC).

--
Yaakov

Re: Question about clisp version naming

[Yaakov Selkowitz]

On Fri, 2015-03-13 at 14:42 -0500, Yaakov Selkowitz wrote:
> On Fri, 2015-03-13 at 20:27 +0100, Achim Gratz wrote:
> > Ken Brown writes:
> > >> Version numbers like the one Ken has proposed are becoming common in
> > >> Linux distributions, so we'd rather check that setup handles them
> > >> correctly.  I think Jari already uses a bunch of them.  The thing here
> > >> is that for all versioning schemes that use hashes you need to prepend
> > >> an ISO date so things sort correctly, but I'd rather not append this to
> > >> the release number, so I'd suggest VERSION=2.49+YYYYMMDDhg15623 instead.
> > >> Also, I don't think it's a good idea to allow "."  in the release
> > >> number.  Alphas already work in that place (I use that for snapshots
> > >> since years) and are a lot less ambigous if you try to parse the release
> > >> out of a file name.
> > >
> > > Sorry, but Yaakov says we already allow dots in the release number,
> > > and he's the distro czar.  So I'm going with his suggestion.
> > 
> > As you wish.  I still think his view is somewhat unique looking at the
> > version numbers in several Linux distros that provide packages
> > in-between-official-releases from several VCS.  The only case that I
> > know where the VCS revision tag was used in the relase part of the
> > version string was when the release was made from a local branch in all
> > other cases they'd been appended to the latest release version string.
> 
> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning
> 
> Except we don't (yet) have Epoch (PTC).

I should also point out that packages already using extended VERSIONs
may not be able to switch immediately to this scheme without a real
VERSION bump.

--
Yaakov

Re: Question about clisp version naming

[Achim Gratz]

Yaakov Selkowitz writes:
> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning

The way I read this, there is no suggestion of putting these extra
version parts in or after the %dist and/or build number, which is what
we use the release field for.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: Question about clisp version naming

[Yaakov Selkowitz]

On Fri, 2015-03-13 at 21:14 +0100, Achim Gratz wrote:
> Yaakov Selkowitz writes:
> > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning
> 
> The way I read this, there is no suggestion of putting these extra
> version parts in or after the %dist and/or build number, which is what
> we use the release field for.

Obviously we don't have %dist, but did you continue reading to the
"Non-Numeric Version in Release" section?

--
Yaakov

Re: Question about clisp version naming

[Achim Gratz]

Yaakov Selkowitz writes:
> Obviously we don't have %dist, but did you continue reading to the
> "Non-Numeric Version in Release" section?

Yes.  I can somewhat understand the rationale for putting this in the
release part, but I still like the openSUSE numbering better.  The
central question is how you introduce ordering and it's easily taken
care of by prepending the ISO data before any version monikers that
don't strictly increment.  We've got a bunch of those already in Cygwin
as well (most of them from Jari IIRC), so why should we change that now?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
> My work was based on the tip of the upstream Mercurial repository,
> which shows a version number of 2.49+ and is at revision 15623.  So I
> was thinking of using 2.49+hg15623 as the version number.  Will upset
> be happy with that?  Or is there some other standard way of assigning
> version numbers in cases like this?

Maxima needs to be rebuilt for the new clisp, but the clisp-exec build
errors out with

/mnt/share/maint/maxima.x86_64/build/src/binary-clisp/maxima.exe: error while loading shared libraries: lisp.dll: cannot open shared object file: No such file or directory

I'm not sure if that's a build error on the clisp side or something I
need to fix in maxima yet, but if you know what to do, please chime in.

If I link the lisp.dll from clisp into the binary-clisp directory _and_
start maxima with the cwd in that same directory I can start it.  But
not if I just add to PATH.  It also works if lisp.dll gets linked into
/usr/bin.  So how do I tell that executable where to look for libraries
at runtime?

The clisp mem-based build runs the tests (not finished yet).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Question about clisp version naming

[Ken Brown]

On 3/15/2015 12:40 PM, Achim Gratz wrote:
> Ken Brown writes:
>> My work was based on the tip of the upstream Mercurial repository,
>> which shows a version number of 2.49+ and is at revision 15623.  So I
>> was thinking of using 2.49+hg15623 as the version number.  Will upset
>> be happy with that?  Or is there some other standard way of assigning
>> version numbers in cases like this?
>
> Maxima needs to be rebuilt for the new clisp, but the clisp-exec build
> errors out with
>
> /mnt/share/maint/maxima.x86_64/build/src/binary-clisp/maxima.exe: error while loading shared libraries: lisp.dll: cannot open shared object file: No such file or directory
>
> I'm not sure if that's a build error on the clisp side or something I
> need to fix in maxima yet, but if you know what to do, please chime in.
>
> If I link the lisp.dll from clisp into the binary-clisp directory _and_
> start maxima with the cwd in that same directory I can start it.  But
> not if I just add to PATH.  It also works if lisp.dll gets linked into
> /usr/bin.  So how do I tell that executable where to look for libraries
> at runtime?
>
> The clisp mem-based build runs the tests (not finished yet).

This sounds like a packaging error on my part.  First of all, lisp.dll 
is new with the latest clisp; it was part of my solution to the dynamic 
loading problem.  But from what you say, it sounds like I should put it 
in /usr/bin.  In fact, I should rename it to cyglisp.dll, with a 
corresponding /usr/lib/liblisp.dll.a, so that applications can link 
against it with '-llisp'.  Would this solve the problem?

In retrospect, I should have made the new clisp a test release, to avoid 
breaking things.  Sorry about that.

Ken

Re: Question about clisp version naming

[Yaakov Selkowitz]

On Sun, 2015-03-15 at 13:37 -0400, Ken Brown wrote:
> This sounds like a packaging error on my part.  First of all, lisp.dll 
> is new with the latest clisp; it was part of my solution to the dynamic 
> loading problem.  But from what you say, it sounds like I should put it 
> in /usr/bin.  In fact, I should rename it to cyglisp.dll, with a 
> corresponding /usr/lib/liblisp.dll.a, so that applications can link 
> against it with '-llisp'.  Would this solve the problem?

I'm not all that familiar with clisp.  Is there a single binary that
loads these dynamic modules, or multiple binaries?

> In retrospect, I should have made the new clisp a test release, to avoid 
> breaking things.  Sorry about that.

No worries.

--
Yaakov

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
> This sounds like a packaging error on my part.  First of all, lisp.dll
> is new with the latest clisp; it was part of my solution to the
> dynamic loading problem.  But from what you say, it sounds like I
> should put it in /usr/bin.  In fact, I should rename it to
> cyglisp.dll, with a corresponding /usr/lib/liblisp.dll.a, so that
> applications can link against it with '-llisp'.  Would this solve the
> problem?

That would solve the problem, AFAICS (I'd go with cygclisp.dll, though).
I've meanwhile found out that if I put the clisp dir3ectory in PATH the
library is also found.  But I had to patch the scripts calling maxima
for that, so if this isn't necessary then this is even better.

> In retrospect, I should have made the new clisp a test release, to
> avoid breaking things.  Sorry about that.

No problem, I didn't know this would cause breakage either.  AT the
moment nobody else seems to use these things anyway.  :-)


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Question about clisp version naming

[Ken Brown]

On 3/15/2015 2:19 PM, Yaakov Selkowitz wrote:
> On Sun, 2015-03-15 at 13:37 -0400, Ken Brown wrote:
>> This sounds like a packaging error on my part.  First of all, lisp.dll
>> is new with the latest clisp; it was part of my solution to the dynamic
>> loading problem.  But from what you say, it sounds like I should put it
>> in /usr/bin.  In fact, I should rename it to cyglisp.dll, with a
>> corresponding /usr/lib/liblisp.dll.a, so that applications can link
>> against it with '-llisp'.  Would this solve the problem?
>
> I'm not all that familiar with clisp.  Is there a single binary that
> loads these dynamic modules, or multiple binaries?

The only user-visible binary is /usr/bin/clisp.exe.  This is essentially 
a wrapper that calls /usr/lib/clisp-2.49+/base/lisp.exe with suitable 
arguments.  The latter is linked against 
/usr/lib/clisp-2.49+/base/lisp.dll, as are all the modules.  The modules 
are simply DLLs that get loaded as needed via dlopen by the running 
lisp.exe process.  [Prior to the latest clisp release, there was no 
lisp.dll, so there was no way (AFAIK) to build the modules as DLLs.]

I thought this would all work fine because lisp.dll was in the same 
directory as lisp.exe.  And it does work fine for users of clisp.  But I 
didn't think about applications like Maxima that would need to link 
against lisp.dll.

I think my new proposal (with /usr/bin/cyglisp.dll and 
/usr/lib/liblisp.dll.a) will work better.  I don't know whether it's 
best to split off libclisp and clisp-devel subpackages.  Fedora has a 
separate clisp-devel package, but it contains a lot of files that are 
currently (and have always been) in the main clisp package on Cygwin. 
At the moment, it's probably a higher priority to get something in the 
distro that Achim can use to build Maxima.  But I'm open to suggestion 
on all of this.

Ken

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
> I thought this would all work fine because lisp.dll was in the same
> directory as lisp.exe.  And it does work fine for users of clisp.  But
> I didn't think about applications like Maxima that would need to link
> against lisp.dll.

Maxima doesn't link against this library, it uses clisp' capability of
dumping an executable that has the application pre-loaded.  In fact, if
you simply start the resulting EXE (not through the maxima wrapper)
you'll be greeted by a CLisp prompt.

> I think my new proposal (with /usr/bin/cyglisp.dll and
> /usr/lib/liblisp.dll.a) will work better.  I don't know whether it's
> best to split off libclisp and clisp-devel subpackages.  Fedora has a
> separate clisp-devel package, but it contains a lot of files that are
> currently (and have always been) in the main clisp package on
> Cygwin. At the moment, it's probably a higher priority to get
> something in the distro that Achim can use to build Maxima.  But I'm
> open to suggestion on all of this.

I have a workaround for maxima and building and testing the package as
we speak.  We can test the new clisp packaging more thoroughly later on.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Question about clisp version naming

[Ken Brown]

On 3/15/2015 3:14 PM, Achim Gratz wrote:
> Ken Brown writes:
>> I think my new proposal (with /usr/bin/cyglisp.dll and
>> /usr/lib/liblisp.dll.a) will work better.  I don't know whether it's
>> best to split off libclisp and clisp-devel subpackages.  Fedora has a
>> separate clisp-devel package, but it contains a lot of files that are
>> currently (and have always been) in the main clisp package on
>> Cygwin. At the moment, it's probably a higher priority to get
>> something in the distro that Achim can use to build Maxima.  But I'm
>> open to suggestion on all of this.
>
> I have a workaround for maxima and building and testing the package as
> we speak.  We can test the new clisp packaging more thoroughly later on.

Just for testing purposes, I've built a new clisp with 
/usr/bin/cyglisp.dll and /usr/lib/liblisp.dll.a, and I've uploaded it to 
my Cygwin repository:

   http://sanibeltranquility.com/cygwin/

When you get a chance, please test it and see if it allows you to avoid 
your workaround.  If so, I'll think about whether it's worth repackaging 
following Fedora.

There's no rush about this from my point of view.

Ken

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
> Just for testing purposes, I've built a new clisp with
> /usr/bin/cyglisp.dll and /usr/lib/liblisp.dll.a, and I've uploaded it
> to my Cygwin repository:
>
>   http://sanibeltranquility.com/cygwin/
>
> When you get a chance, please test it and see if it allows you to
> avoid your workaround.  If so, I'll think about whether it's worth
> repackaging following Fedora.

This has the same problem as the current release: any attempt to run
lisp.exe (or an executable dump) will produce this message:

...lib/clisp-2.49+/base (2120) ./lisp.exe 
module 'syscalls' requires package OS.
/mnt/share/maint (2125) /usr/lib/clisp-2.49+/base/lisp.exe
module 'syscalls' requires package OS.

The loading of memory images via clisp works, so I'll pull the
maxima-exec-clisp package until we get to the bottom of this.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: Question about clisp version naming

[Achim Gratz]

Achim Gratz writes:
> Ken Brown writes:
>> Just for testing purposes, I've built a new clisp with
>> /usr/bin/cyglisp.dll and /usr/lib/liblisp.dll.a, and I've uploaded it
>> to my Cygwin repository:
>>
>>   http://sanibeltranquility.com/cygwin/
>>
>> When you get a chance, please test it and see if it allows you to
>> avoid your workaround.  If so, I'll think about whether it's worth
>> repackaging following Fedora.
>
> This has the same problem as the current release: any attempt to run
> lisp.exe (or an executable dump) will produce this message:
>
> ...lib/clisp-2.49+/base (2120) ./lisp.exe 
> module 'syscalls' requires package OS.
> /mnt/share/maint (2125) /usr/lib/clisp-2.49+/base/lisp.exe
> module 'syscalls' requires package OS.
>
> The loading of memory images via clisp works, so I'll pull the
> maxima-exec-clisp package until we get to the bottom of this.

Hmm.  Scratch that, I think I got the maxima.exe (dumped image) to work.
Let's see if it survives installation.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Question about clisp version naming

[Achim Gratz]

Achim Gratz writes:
>> The loading of memory images via clisp works, so I'll pull the
>> maxima-exec-clisp package until we get to the bottom of this.
>
> Hmm.  Scratch that, I think I got the maxima.exe (dumped image) to work.
> Let's see if it survives installation.

No it doesn't.  Specifically, it doesn't like being stripped.  I'll
RESTRICT that, let's hope it works now…  Yup, it does.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Question about clisp version naming

[Yaakov Selkowitz]

On Mon, 2015-03-16 at 20:41 +0100, Achim Gratz wrote:
> Achim Gratz writes:
> >> The loading of memory images via clisp works, so I'll pull the
> >> maxima-exec-clisp package until we get to the bottom of this.
> >
> > Hmm.  Scratch that, I think I got the maxima.exe (dumped image) to work.
> > Let's see if it survives installation.
> 
> No it doesn't.  Specifically, it doesn't like being stripped.  I'll
> RESTRICT that, let's hope it works now…  Yup, it does.

Ken, Achim,

Is there an issue with stripping clisp executables?  Is there a magic
number we can use to detect these automatically?

--
Yaakov

Re: Question about clisp version naming

[Achim Gratz]

Yaakov Selkowitz writes:
> Is there an issue with stripping clisp executables?

Yes, with the executable dumps.

> Is there a magic
> number we can use to detect these automatically?

File identifies them as plain executables.  CLisp knows which runtime
they were rpdocued from, so there must by some symbols to pull this
information from.  Ken should have an answer, otherwise I can
investigate later.  In any case these are the only executables shipped
with maxima, so RESTRICT=strip doesn't do any harm at the moment.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Question about clisp version naming

[Ken Brown]

On 3/16/2015 4:07 PM, Achim Gratz wrote:
> Yaakov Selkowitz writes:
>> Is there an issue with stripping clisp executables?
>
> Yes, with the executable dumps.
>
>> Is there a magic
>> number we can use to detect these automatically?
>
> File identifies them as plain executables.  CLisp knows which runtime
> they were rpdocued from, so there must by some symbols to pull this
> information from.  Ken should have an answer, otherwise I can
> investigate later.  In any case these are the only executables shipped
> with maxima, so RESTRICT=strip doesn't do any harm at the moment.

The clisp executables are not stripped because apparently there's a 
disassemble command within clisp that doesn't work if the executables 
are stripped.  I don't actually know anything about this, but there was 
a comment about that in the .cygport file that I inherited from Reini. 
This may or may not explain why maxima.exe didn't like being stripped.

Ken

Re: Question about clisp version naming

[Ken Brown]

On 3/16/2015 3:41 PM, Achim Gratz wrote:
> Achim Gratz writes:
>>> The loading of memory images via clisp works, so I'll pull the
>>> maxima-exec-clisp package until we get to the bottom of this.
>>
>> Hmm.  Scratch that, I think I got the maxima.exe (dumped image) to work.
>> Let's see if it survives installation.
>
> No it doesn't.  Specifically, it doesn't like being stripped.  I'll
> RESTRICT that, let's hope it works now…  Yup, it does.

Great.  Thanks for testing.  There's probably no reason for me to upload 
a new clisp package right now (unless it would help you).  But I'll give 
you a heads up when I'm ready to do that.

Ken

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
>> No it doesn't.  Specifically, it doesn't like being stripped.  I'll
>> RESTRICT that, let's hope it works now…  Yup, it does.
>
> Great.  Thanks for testing.  There's probably no reason for me to
> upload a new clisp package right now (unless it would help you).  But
> I'll give you a heads up when I'm ready to do that.

I'll continue to use the workaround for this (hopefully final) iteration
of the maxima package.  I'll drop that part of the patch when it is no
longer necessary.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
> The clisp executables are not stripped because apparently there's a
> disassemble command within clisp that doesn't work if the executables
> are stripped.  I don't actually know anything about this, but there
> was a comment about that in the .cygport file that I inherited from
> Reini. This may or may not explain why maxima.exe didn't like being
> stripped.

Looking at the executable it seems that it is a very small (~66 kiB)
stub that then proceeds to load the rest of the file after having
started the runtime.  The memory image seems simply bolted on (as an
overlay?), and gets removed when the executable is stripped.


Regards
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Question about clisp version naming

[Yaakov Selkowitz]

On Mon, 2015-03-16 at 23:16 +0100, Achim Gratz wrote:
> Ken Brown writes:
> > The clisp executables are not stripped because apparently there's a
> > disassemble command within clisp that doesn't work if the executables
> > are stripped.  I don't actually know anything about this, but there
> > was a comment about that in the .cygport file that I inherited from
> > Reini. This may or may not explain why maxima.exe didn't like being
> > stripped.
> 
> Looking at the executable it seems that it is a very small (~66 kiB)
> stub that then proceeds to load the rest of the file after having
> started the runtime.  The memory image seems simply bolted on (as an
> overlay?), and gets removed when the executable is stripped.

That sounds very similar to OCaml; if so, I would expect there to be
some sort of magic number in the binary that can be used to identify
this type of executable (just because file(1) doesn't know about it
doesn't mean it doesn't exist).  If we can pinpoint that, cygport can be
patched to not strip them.

--
Yaakov

Re: Question about clisp version naming

[Achim Gratz]

Yaakov Selkowitz writes:
>> Looking at the executable it seems that it is a very small (~66 kiB)
>> stub that then proceeds to load the rest of the file after having
>> started the runtime.  The memory image seems simply bolted on (as an
>> overlay?), and gets removed when the executable is stripped.

UPX says it found an overlay and doesn't compress it.

> That sounds very similar to OCaml; if so, I would expect there to be
> some sort of magic number in the binary that can be used to identify
> this type of executable (just because file(1) doesn't know about it
> doesn't mean it doesn't exist).  If we can pinpoint that, cygport can be
> patched to not strip them.

That string is likely a good initial bet:

000107b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 63  |...............c|
000107c0  6c 69 73 70 00 69 31 38  6e 00 73 79 73 63 61 6c  |lisp.i18n.syscal|
000107d0  6c 73 00 00 00 00 00 b4  fc d7 e7 03 00 00 00 50  |ls.............P|

Or really, just check if the executable has an overlay and leave it
alone if so, like UPX does.  No magic required.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
> Great.  Thanks for testing.  There's probably no reason for me to
> upload a new clisp package right now (unless it would help you).  But
> I'll give you a heads up when I'm ready to do that.

I've now drilled to the bottom of what I had assumed were build/package
problems… it turns out that if you rebase the lisp.dll, then the dumped
executable that depends on it stops working.  The dumped executable as
well as clisp.exe is OK since rebase decides it can't touch it.  The
other interesting thing to note is that rebase has altered lisp.dll even
though it says it didn't.

--8<---------------cut here---------------start------------->8---
/mnt/share/maint (2015) objdump -h /usr/lib/clisp-2.49+/base/lisp.dll

/usr/lib/clisp-2.49+/base/lisp.dll:     file format pei-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00107794  69a81000  69a81000  00000600  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  1 .data         0001b3e4  69b89000  69b89000  00107e00  2**6
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rdata        000d4dbc  69ba5000  69ba5000  00123200  2**6
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .buildid      00000035  69c7a000  69c7a000  001f8000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .eh_frame     000241f4  69c7b000  69c7b000  001f8200  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .bss          00004fb8  69ca0000  69ca0000  00000000  2**6
                  ALLOC
  6 .edata        00014b0b  69ca5000  69ca5000  0021c400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .idata        00003914  69cba000  69cba000  00231000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .reloc        0002964c  69cbe000  69cbe000  00234a00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .debug_aranges 00000778  69ce8000  69ce8000  0025e200  2**3
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_info   004519d6  69ce9000  69ce9000  0025ea00  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_abbrev 0000c2e3  6a13b000  6a13b000  006b0400  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_line   0004088c  6a148000  6a148000  006bc800  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_frame  00000038  6a189000  6a189000  006fd200  2**2
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_str    0001f4a7  6a18a000  6a18a000  006fd400  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_loc    001113f0  6a1aa000  6a1aa000  0071ca00  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_ranges 0004deb0  6a2bc000  6a2bc000  0082de00  2**0
                  CONTENTS, READONLY, DEBUGGING
/mnt/share/maint (2016) maxima -v
+ '[' clisp = clisp ']'
+ '[' true = true ']'
+ '[' -x /usr/lib/maxima/5.35.1/binary-clisp/maxima ']'
+ exec /usr/lib/maxima/5.35.1/binary-clisp/maxima -q '' -- -v '' '' '' '' '' '' '' ''
Maxima 5.35.1 http://maxima.sourceforge.net
using Lisp CLISP 2.49+ (2010-07-17)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) 
/mnt/share/maint (2017) rebase -sO /usr/lib/clisp-2.49+/base/lisp.dll
rebase: oblivious file "/usr/lib/clisp-2.49+/base/lisp.dll" already found in rebase database (file and database kept unchanged).
/mnt/share/maint (2018) maxima -v
+ '[' clisp = clisp ']'
+ '[' true = true ']'
+ '[' -x /usr/lib/maxima/5.35.1/binary-clisp/maxima ']'
+ exec /usr/lib/maxima/5.35.1/binary-clisp/maxima -q '' -- -v '' '' '' '' '' '' '' ''
module 'syscalls' requires package OS.
/mnt/share/maint (2019) objdump -h /usr/lib/clisp-2.49+/base/lisp.dll

/usr/lib/clisp-2.49+/base/lisp.dll:     file format pei-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00107794  4d1b1000  4d1b1000  00000600  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  1 .data         0001b3e4  4d2b9000  4d2b9000  00107e00  2**6
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rdata        000d4dbc  4d2d5000  4d2d5000  00123200  2**6
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .buildid      00000035  4d3aa000  4d3aa000  001f8000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .eh_frame     000241f4  4d3ab000  4d3ab000  001f8200  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .bss          00004fb8  4d3d0000  4d3d0000  00000000  2**6
                  ALLOC
  6 .edata        00014b0b  4d3d5000  4d3d5000  0021c400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .idata        00003914  4d3ea000  4d3ea000  00231000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .reloc        0002964c  4d3ee000  4d3ee000  00234a00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .debug_aranges 00000778  4d418000  4d418000  0025e200  2**3
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_info   004519d6  4d419000  4d419000  0025ea00  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_abbrev 0000c2e3  4d86b000  4d86b000  006b0400  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_line   0004088c  4d878000  4d878000  006bc800  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_frame  00000038  4d8b9000  4d8b9000  006fd200  2**2
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_str    0001f4a7  4d8ba000  4d8ba000  006fd400  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_loc    001113f0  4d8da000  4d8da000  0071ca00  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_ranges 0004deb0  4d9ec000  4d9ec000  0082de00  2**0
                  CONTENTS, READONLY, DEBUGGING
--8<---------------cut here---------------end--------------->8---


I'll revoke the maxima-exec-clisp package until we can find a way to
make these things rebaseable.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Question about clisp version naming

[Ken Brown]

On 3/17/2015 3:20 PM, Achim Gratz wrote:
> Ken Brown writes:
>> Great.  Thanks for testing.  There's probably no reason for me to
>> upload a new clisp package right now (unless it would help you).  But
>> I'll give you a heads up when I'm ready to do that.
>
> I've now drilled to the bottom of what I had assumed were build/package
> problems… it turns out that if you rebase the lisp.dll, then the dumped
> executable that depends on it stops working.

I'll study the clisp code that creates dumped executables and see if I 
can figure out what's going on.

> rebase has altered lisp.dll even
> though it says it didn't.

This sounds like a bug in rebase, but it probably isn't related to the 
present problem.

Ken

Re: Question about clisp version naming

[Yaakov Selkowitz]

On Tue, 2015-03-17 at 17:15 -0400, Ken Brown wrote:
> On 3/17/2015 3:20 PM, Achim Gratz wrote:
> > Ken Brown writes:
> >> Great.  Thanks for testing.  There's probably no reason for me to
> >> upload a new clisp package right now (unless it would help you).  But
> >> I'll give you a heads up when I'm ready to do that.
> >
> > I've now drilled to the bottom of what I had assumed were build/package
> > problems… it turns out that if you rebase the lisp.dll, then the dumped
> > executable that depends on it stops working.
> 
> I'll study the clisp code that creates dumped executables and see if I 
> can figure out what's going on.
> 
> > rebase has altered lisp.dll even
> > though it says it didn't.
> 
> This sounds like a bug in rebase, but it probably isn't related to the 
> present problem.

Do I understand correctly that lisp.exe (AKA lisp.run on *NIX platforms)
is the only binary loading these modules, and that these modules depend
on the symbols in lisp.exe (if there were no lisp.dll)?  How does the
lisp.exe in clisp relate to the one that would be in maxima-exec-clisp?

--
Yaakov

Re: Question about clisp version naming

[Ken Brown]

On 3/17/2015 5:40 PM, Yaakov Selkowitz wrote:
> On Tue, 2015-03-17 at 17:15 -0400, Ken Brown wrote:
>> On 3/17/2015 3:20 PM, Achim Gratz wrote:
>>> Ken Brown writes:
>>>> Great.  Thanks for testing.  There's probably no reason for me to
>>>> upload a new clisp package right now (unless it would help you).  But
>>>> I'll give you a heads up when I'm ready to do that.
>>>
>>> I've now drilled to the bottom of what I had assumed were build/package
>>> problems… it turns out that if you rebase the lisp.dll, then the dumped
>>> executable that depends on it stops working.
>>
>> I'll study the clisp code that creates dumped executables and see if I
>> can figure out what's going on.
>>
>>> rebase has altered lisp.dll even
>>> though it says it didn't.
>>
>> This sounds like a bug in rebase, but it probably isn't related to the
>> present problem.
>
> Do I understand correctly that lisp.exe (AKA lisp.run on *NIX platforms)
> is the only binary loading these modules, and that these modules depend
> on the symbols in lisp.exe (if there were no lisp.dll)?

Yes.  But that makes me wonder if I made things too complicated and 
could have avoided building lisp.dll.  The native Windows build of clisp 
creates a lisp.def file, containing the symbols of lisp.exe, and it just 
adds "lisp.def" to the gcc command line when building the modules.  But 
that didn't work on Cygwin; the linker complained that it didn't know 
what lisp.def was, and it tried to interpret it as a linker script.  Is 
there a way to make this approach work?

> How does the
> lisp.exe in clisp relate to the one that would be in maxima-exec-clisp?

Achim will have to answer this one.

Ken

Re: Question about clisp version naming

[Jon TURNEY]

On 17/03/2015 22:40, Ken Brown wrote:
> Yes.  But that makes me wonder if I made things too complicated and
> could have avoided building lisp.dll.  The native Windows build of clisp
> creates a lisp.def file, containing the symbols of lisp.exe, and it just
> adds "lisp.def" to the gcc command line when building the modules.  But
> that didn't work on Cygwin; the linker complained that it didn't know
> what lisp.def was, and it tried to interpret it as a linker script.  Is
> there a way to make this approach work?

I seem to recall that you can't have any comments at the start of the 
module definition file for ld to recognize it as one.

Re: Question about clisp version naming

[Ken Brown]

On 3/17/2015 8:17 PM, Jon TURNEY wrote:
> On 17/03/2015 22:40, Ken Brown wrote:
>> Yes.  But that makes me wonder if I made things too complicated and
>> could have avoided building lisp.dll.  The native Windows build of clisp
>> creates a lisp.def file, containing the symbols of lisp.exe, and it just
>> adds "lisp.def" to the gcc command line when building the modules.  But
>> that didn't work on Cygwin; the linker complained that it didn't know
>> what lisp.def was, and it tried to interpret it as a linker script.  Is
>> there a way to make this approach work?
>
> I seem to recall that you can't have any comments at the start of the
> module definition file for ld to recognize it as one.

It didn't occur to me to check the syntax of the def file, although it 
should have (see below).  The one produced by the build (before I 
changed the approach) starts like this:

EXPORTS
IMPORTS
	lisp.exe.time_t_from_filetime
	lisp.exe.time_t_to_filetime
	lisp.exe.fd_read

And the gcc command line with error message is:

gcc -ggdb -O2 -pipe -Wimplicit-function-declaration -W -Wswitch 
-Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations 
-Wimplicit -Wno-sign-compare -Wno-format-nonliteral -O 
-falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_MODULES -DDLL_EXPORT 
-DPIC -Wl,--stack,0x800000 -Wl,--export-all-symbols modules.o calls.o 
bogomips.o -lcrypt -luser32 -lole32 -loleaut32 -L/usr/lib/w32api -luuid 
-lversion gettext.o lisp.a lisp.def libgnu.a /usr/lib/libintl.dll.a 
/usr/lib/libreadline.dll.a -lncurses /usr/lib/libiconv.dll.a -o lisp.exe
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/bin/ld: 
lisp.def:3: syntax error
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/bin/ld:lisp.def: 
file format not recognized; treating as linker script

Having just (!) noticed that this says there's a syntax error in line 3, 
  I tried deleting line 2.  This resulted in a slew of errors like this:

calls.o: In function `error_OS_stream':
/home/kbrown/src/cygclisp/clisp-2.49-4.20150312hg15611.x86_64/src/clisp/modules/syscalls/calls.c:183: 
undefined reference to `__imp_OS_error'
/home/kbrown/src/cygclisp/clisp-2.49-4.20150312hg15611.x86_64/src/clisp/modules/syscalls/calls.c:183:(.text+0x11d): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`__imp_OS_error'

Next I tried deleting line 1 instead.  This time the linking completed. 
  But when I ran the resulting executable, I got this:

$ ./lisp.exe --version
module 'syscalls' requires package OS.

That's the same error Achim reported.

I'm stumped.  There must be a way around this, but I don't know enough 
about .def files to know what else to try.

Ken

Re: Question about clisp version naming

[Ken Brown]

On 3/17/2015 8:54 PM, Ken Brown wrote:
> On 3/17/2015 8:17 PM, Jon TURNEY wrote:
>> On 17/03/2015 22:40, Ken Brown wrote:
>>> Yes.  But that makes me wonder if I made things too complicated and
>>> could have avoided building lisp.dll.  The native Windows build of clisp
>>> creates a lisp.def file, containing the symbols of lisp.exe, and it just
>>> adds "lisp.def" to the gcc command line when building the modules.  But
>>> that didn't work on Cygwin; the linker complained that it didn't know
>>> what lisp.def was, and it tried to interpret it as a linker script.  Is
>>> there a way to make this approach work?
>>
>> I seem to recall that you can't have any comments at the start of the
>> module definition file for ld to recognize it as one.
>
> It didn't occur to me to check the syntax of the def file, although it
> should have (see below).  The one produced by the build (before I
> changed the approach) starts like this:
>
> EXPORTS
> IMPORTS
>      lisp.exe.time_t_from_filetime
>      lisp.exe.time_t_to_filetime
>      lisp.exe.fd_read
>
> And the gcc command line with error message is:
>
> gcc -ggdb -O2 -pipe -Wimplicit-function-declaration -W -Wswitch
> -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations
> -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -O
> -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_MODULES -DDLL_EXPORT
> -DPIC -Wl,--stack,0x800000 -Wl,--export-all-symbols modules.o calls.o
> bogomips.o -lcrypt -luser32 -lole32 -loleaut32 -L/usr/lib/w32api -luuid
> -lversion gettext.o lisp.a lisp.def libgnu.a /usr/lib/libintl.dll.a
> /usr/lib/libreadline.dll.a -lncurses /usr/lib/libiconv.dll.a -o lisp.exe
> /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/bin/ld:
> lisp.def:3: syntax error
> /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/bin/ld:lisp.def:
> file format not recognized; treating as linker script
>
> Having just (!) noticed that this says there's a syntax error in line 3,
>   I tried deleting line 2.  This resulted in a slew of errors like this:
>
> calls.o: In function `error_OS_stream':
> /home/kbrown/src/cygclisp/clisp-2.49-4.20150312hg15611.x86_64/src/clisp/modules/syscalls/calls.c:183:
> undefined reference to `__imp_OS_error'
> /home/kbrown/src/cygclisp/clisp-2.49-4.20150312hg15611.x86_64/src/clisp/modules/syscalls/calls.c:183:(.text+0x11d):
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `__imp_OS_error'
>
> Next I tried deleting line 1 instead.  This time the linking completed.
>   But when I ran the resulting executable, I got this:
>
> $ ./lisp.exe --version
> module 'syscalls' requires package OS.
>
> That's the same error Achim reported.
>
> I'm stumped.  There must be a way around this, but I don't know enough
> about .def files to know what else to try.

Maybe this will work after all.  I continued the build process with the 
modified lisp.def (line 1 removed), and the resulting clisp.exe (which 
is a wrapper that calls lisp.exe with suitable arguments) seems to work.

I'll keep playing with this, but if anyone can explain to me what's 
going on, I'd appreciate it.  I'm not happy just randomly modifying 
lisp.def without really knowing what I'm doing.

Ken

Re: Question about clisp version naming

[Yaakov Selkowitz]

On Tue, 2015-03-17 at 21:09 -0400, Ken Brown wrote:
> On 3/17/2015 8:54 PM, Ken Brown wrote:
> > It didn't occur to me to check the syntax of the def file, although it
> > should have (see below).  The one produced by the build (before I
> > changed the approach) starts like this:
> >
> > EXPORTS
> > IMPORTS
> >      lisp.exe.time_t_from_filetime
> >      lisp.exe.time_t_to_filetime
> >      lisp.exe.fd_read
> >
> > And the gcc command line with error message is:
> >
> > gcc -ggdb -O2 -pipe -Wimplicit-function-declaration -W -Wswitch
> > -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations
> > -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -O
> > -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_MODULES -DDLL_EXPORT
> > -DPIC -Wl,--stack,0x800000 -Wl,--export-all-symbols modules.o calls.o
> > bogomips.o -lcrypt -luser32 -lole32 -loleaut32 -L/usr/lib/w32api -luuid
> > -lversion gettext.o lisp.a lisp.def libgnu.a /usr/lib/libintl.dll.a
> > /usr/lib/libreadline.dll.a -lncurses /usr/lib/libiconv.dll.a -o lisp.exe
> > /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/bin/ld:
> > lisp.def:3: syntax error
> > /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/bin/ld:lisp.def:
> > file format not recognized; treating as linker script
> >
> > Having just (!) noticed that this says there's a syntax error in line 3,
> >   I tried deleting line 2.  This resulted in a slew of errors like this:
> >
> > calls.o: In function `error_OS_stream':
> > /home/kbrown/src/cygclisp/clisp-2.49-4.20150312hg15611.x86_64/src/clisp/modules/syscalls/calls.c:183:
> > undefined reference to `__imp_OS_error'
> > /home/kbrown/src/cygclisp/clisp-2.49-4.20150312hg15611.x86_64/src/clisp/modules/syscalls/calls.c:183:(.text+0x11d):
> > relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> > `__imp_OS_error'
> >
> > Next I tried deleting line 1 instead.  This time the linking completed.
> >   But when I ran the resulting executable, I got this:
> >
> > $ ./lisp.exe --version
> > module 'syscalls' requires package OS.
> >
> > That's the same error Achim reported.
> >
> > I'm stumped.  There must be a way around this, but I don't know enough
> > about .def files to know what else to try.
> 
> Maybe this will work after all.  I continued the build process with the 
> modified lisp.def (line 1 removed), and the resulting clisp.exe (which 
> is a wrapper that calls lisp.exe with suitable arguments) seems to work.
> 
> I'll keep playing with this, but if anyone can explain to me what's 
> going on, I'd appreciate it.  I'm not happy just randomly modifying 
> lisp.def without really knowing what I'm doing.

A .def file can be used for two purposes:

1) to specify which symbols to export in a DLL/EXE, in place of
dllexport or -Wl,--export-all-symbols (EXPORTS)

2) to resolve symbols by declaring them in other DLL/EXE(s), in place of
a .dll.a (IMPORTS)

It appears that they were trying to use the same .def file for both
linking lisp.exe (EXPORTS) and the dynmods (IMPORTS), and that is
invalid syntax.  However, according to your paste, lisp.exe is already
linked with -Wl,--export-all-symbols, so lisp.def EXPORTS isn't needed
when linking lisp.exe, only when linking the dynmods.  So removing
EXPORTS and leaving in IMPORTS should work.

--
Yaakov

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
>> How does the
>> lisp.exe in clisp relate to the one that would be in maxima-exec-clisp?
>
> Achim will have to answer this one.

I don't really know either.  The executable dump is provided by clisp
and you can name the resulting exe any which way you want.  For maxima,
it's maxima.exe.  This file is (looking at both the non-executable
memory image and the executable one) an exe stub with the non-executable
image as an overlay.  I don't really know where the stub comes from, but
I don't see it directly relating to lisp.exe at the moment.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Question about clisp version naming

[Ken Brown]

On 3/17/2015 9:47 PM, Yaakov Selkowitz wrote:
> A .def file can be used for two purposes:
>
> 1) to specify which symbols to export in a DLL/EXE, in place of
> dllexport or -Wl,--export-all-symbols (EXPORTS)
>
> 2) to resolve symbols by declaring them in other DLL/EXE(s), in place of
> a .dll.a (IMPORTS)

Thanks.  That's very clear.

> It appears that they were trying to use the same .def file for both
> linking lisp.exe (EXPORTS) and the dynmods (IMPORTS), and that is
> invalid syntax.  However, according to your paste, lisp.exe is already
> linked with -Wl,--export-all-symbols, so lisp.def EXPORTS isn't needed
> when linking lisp.exe, only when linking the dynmods.  So removing
> EXPORTS and leaving in IMPORTS should work.

And indeed it does.  I've still got a couple of things to clean up, but 
I expect to upload a new clisp soon that no longer uses lisp.dll.  I 
hope that will solve the Maxima problem

Ken

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
> And indeed it does.  I've still got a couple of things to clean up,
> but I expect to upload a new clisp soon that no longer uses lisp.dll.
> I hope that will solve the Maxima problem

It doesn't… Instead of lisp.dll it now requires lisp.exe to be in $PATH
and it produces an executable that immediately segfaults.  This has
nothing to do with maxima, you can produce the same abort more simply
with:

clisp -norc -q -x '(progn (ext:saveinitmem "test.exe" :init-function (function exit) :EXECUTABLE t))'
env PATH=${PATH}:/usr/lib/clisp-2.49+/base ./test.exe


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Question about clisp version naming

[Ken Brown]

On 3/22/2015 4:50 PM, Achim Gratz wrote:
> Ken Brown writes:
>> And indeed it does.  I've still got a couple of things to clean up,
>> but I expect to upload a new clisp soon that no longer uses lisp.dll.
>> I hope that will solve the Maxima problem
>
> It doesn't… Instead of lisp.dll it now requires lisp.exe to be in $PATH
> and it produces an executable that immediately segfaults.  This has
> nothing to do with maxima, you can produce the same abort more simply
> with:
>
> clisp -norc -q -x '(progn (ext:saveinitmem "test.exe" :init-function (function exit) :EXECUTABLE t))'
> env PATH=${PATH}:/usr/lib/clisp-2.49+/base ./test.exe

But saving non-executable memory images seems to work fine:

$ clisp -norc -q -x '(progn (ext:saveinitmem "test.mem" :init-function 
(function exit)))'

[output deleted]

$ clisp -M test.mem
   i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
   I I I I I I I      8     8   8           8     8     o  8    8
   I  \ `+' /  I      8         8           8     8        8    8
    \  `-+-'  /       8         8           8      ooooo   8oooo
     `-__|__-'        8         8           8           8  8
         |            8     o   8           8     o     8  8
   ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49+ (2010-07-17) <http://clisp.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

Bye.

So maybe you could dump a memory image maxima.mem and start it with a 
script that calls 'clisp -M maxima.mem'.

Ken

Re: Question about clisp version naming

[Ken Brown]

On 3/22/2015 6:33 PM, Ken Brown wrote:
> On 3/22/2015 4:50 PM, Achim Gratz wrote:
>> Ken Brown writes:
>>> And indeed it does.  I've still got a couple of things to clean up,
>>> but I expect to upload a new clisp soon that no longer uses lisp.dll.
>>> I hope that will solve the Maxima problem
>>
>> It doesn't… Instead of lisp.dll it now requires lisp.exe to be in $PATH
>> and it produces an executable that immediately segfaults.  This has
>> nothing to do with maxima, you can produce the same abort more simply
>> with:
>>
>> clisp -norc -q -x '(progn (ext:saveinitmem "test.exe" :init-function
>> (function exit) :EXECUTABLE t))'
>> env PATH=${PATH}:/usr/lib/clisp-2.49+/base ./test.exe
>
> But saving non-executable memory images seems to work fine:
>
> $ clisp -norc -q -x '(progn (ext:saveinitmem "test.mem" :init-function
> (function exit)))'
>
> [output deleted]
>
> $ clisp -M test.mem
>    i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
>    I I I I I I I      8     8   8           8     8     o  8    8
>    I  \ `+' /  I      8         8           8     8        8    8
>     \  `-+-'  /       8         8           8      ooooo   8oooo
>      `-__|__-'        8         8           8           8  8
>          |            8     o   8           8     o     8  8
>    ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8
>
> Welcome to GNU CLISP 2.49+ (2010-07-17) <http://clisp.org/>
>
> Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
> Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
> Copyright (c) Bruno Haible, Sam Steingold 1999-2000
> Copyright (c) Sam Steingold, Bruno Haible 2001-2010
>
> Type :h and hit Enter for context help.
>
> Bye.
>
> So maybe you could dump a memory image maxima.mem and start it with a
> script that calls 'clisp -M maxima.mem'.

I just took a look at the maxima package, and it seems that you already 
use a script that does something like this in the absence of a maxima 
executable.  Is it really much slower to start maxima that way?  I tried 
'clisp -M maxima.mem', and it started up instantly.  Whatever other 
overhead there is in the maxima script seems to be the same whether 
there's a maxima executable or not.  But maybe I'm missing something.

Ken

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
>> So maybe you could dump a memory image maxima.mem and start it with a
>> script that calls 'clisp -M maxima.mem'.

I'm already doing that.  :-)

> I just took a look at the maxima package, and it seems that you
> already use a script that does something like this in the absence of a
> maxima executable.  Is it really much slower to start maxima that way?

Not for me, but I'm using an SSD.  I haven't yet tested on spinning rust
or over slow network.  But I don't really think it makes much of a
difference, it seems it just has to open one more file than it would
otherwise.  I'm not sure if there are other platforms for clisp that
can't dump executables, if so you might look at whether they remove the
corresponding code and/or warn or error out on an attempt to dump an
executable.

> I tried 'clisp -M maxima.mem', and it started up instantly.  Whatever
> other overhead there is in the maxima script seems to be the same
> whether there's a maxima executable or not.  But maybe I'm missing
> something.

As I said, I've revoked the maxima-exec-clisp package for now, so
whether you either come up with a solution for that problem or conclude
that dumping of executables isn't going to be supported on Cygwin, I'm
fine.  For whatever reason, the exec stuff is the default for clisp and
building the non-exec had required some jumping through hoops (building
them both in one go wasn't even supported).  But I've fixed that now.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Question about clisp version naming

[Ken Brown]

On 3/23/2015 2:45 AM, Achim Gratz wrote:
> As I said, I've revoked the maxima-exec-clisp package for now, so
> whether you either come up with a solution for that problem or conclude
> that dumping of executables isn't going to be supported on Cygwin, I'm
> fine.

OK, that's good.  I'd still like to get it to work, but I'm stumped at 
the moment.  I've tried tweaking the build in various ways, but I can't 
get dumping of executables and dynamic modules to work simultaneously.

The earlier approach of using a lisp DLL came the closest to working, 
but that's not viable if the resulting DLL can't be rebased.

Ken

Re: Question about clisp version naming

[Achim Gratz]

Ken Brown writes:
> OK, that's good.  I'd still like to get it to work, but I'm stumped at
> the moment.  I've tried tweaking the build in various ways, but I
> can't get dumping of executables and dynamic modules to work
> simultaneously.
>
> The earlier approach of using a lisp DLL came the closest to working,
> but that's not viable if the resulting DLL can't be rebased.

I *think* the problem in both cases is that the executable is not
properly linked and thus can't be relocated.  It seems that having a
lisp.o, the memory dump and some linker script should get the desired
dump.exe without the breakage.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves