ffcall

ffcall

[Ken Brown]

I've been trying to adopt Reini's packages that have not yet been ported to 
64-bit Cygwin and that have some connection to packages I already maintain.  The 
next one on my list is ffcall.

Unfortunately, the source has a lot of assembler code in it, so I will almost 
certainly need help from someone well versed in x86_64 assembly language.  And 
the libffcall project appears to be dead upstream, so I'm not going to get help 
there.

I have no idea how hard this will be.  The code has been ported to x86_64 Linux, 
so there's at least a starting point.

Does anyone here have the interest and expertise to help with this?

Ken

Re: ffcall

[Yaakov Selkowitz]

On Wed, 2015-02-18 at 13:49 -0500, Ken Brown wrote:
> I've been trying to adopt Reini's packages that have not yet been ported to 
> 64-bit Cygwin and that have some connection to packages I already maintain.  The 
> next one on my list is ffcall.

I'm guessing this is for clisp?  (In Fedora, clisp is the only package
which BR: ffcall).

> Unfortunately, the source has a lot of assembler code in it, so I will almost 
> certainly need help from someone well versed in x86_64 assembly language.  And 
> the libffcall project appears to be dead upstream, so I'm not going to get help 
> there. 

Unless you can find a patch somewhere for Win64 support.

> I have no idea how hard this will be.  The code has been ported to x86_64 Linux, 
> so there's at least a starting point.

Only to a point, there are significant differences:

https://sourceforge.net/p/mingw-w64/wiki2/MinGW%20x64%20Software%
20convention/

--
Yaakov

Re: ffcall

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

On Feb 18 13:28, Yaakov Selkowitz wrote:
> On Wed, 2015-02-18 at 13:49 -0500, Ken Brown wrote:
> > I've been trying to adopt Reini's packages that have not yet been ported to 
> > 64-bit Cygwin and that have some connection to packages I already maintain.  The 
> > next one on my list is ffcall.
> 
> I'm guessing this is for clisp?  (In Fedora, clisp is the only package
> which BR: ffcall).
> 
> > Unfortunately, the source has a lot of assembler code in it, so I will almost 
> > certainly need help from someone well versed in x86_64 assembly language.  And 
> > the libffcall project appears to be dead upstream, so I'm not going to get help 
> > there. 
> 
> Unless you can find a patch somewhere for Win64 support.
> 
> > I have no idea how hard this will be.  The code has been ported to x86_64 Linux, 
> > so there's at least a starting point.

What is ffcall doing?  What functions does it call?

Help with basic x86_64 assembler is ok, I did it for Cygwin with help
from Kai Tietz.

The main difference to Linux you have to look out for is the different
calling convention and how the registers are used:
http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention

So the job is typically to rearrange the register usage and to
account for the only four registers used for the first arguments
to a function, rather than the 6 registers in the SYSV ABI.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: ffcall

[Ken Brown]

On 2/18/2015 3:08 PM, Corinna Vinschen wrote:
> On Feb 18 13:28, Yaakov Selkowitz wrote:
>> On Wed, 2015-02-18 at 13:49 -0500, Ken Brown wrote:
>>> I've been trying to adopt Reini's packages that have not yet been ported to
>>> 64-bit Cygwin and that have some connection to packages I already maintain.  The
>>> next one on my list is ffcall.
>>
>> I'm guessing this is for clisp?  (In Fedora, clisp is the only package
>> which BR: ffcall).
>>
>>> Unfortunately, the source has a lot of assembler code in it, so I will almost
>>> certainly need help from someone well versed in x86_64 assembly language.  And
>>> the libffcall project appears to be dead upstream, so I'm not going to get help
>>> there.
>>
>> Unless you can find a patch somewhere for Win64 support.
>>
>>> I have no idea how hard this will be.  The code has been ported to x86_64 Linux,
>>> so there's at least a starting point.
>
> What is ffcall doing?  What functions does it call?

I don't know much about it yet.  Here's an overview:

ffcall - foreign function call libraries

This is a collection of four libraries which can be used to build
foreign function call interfaces in embedded interpreters.

The four packages are:

     avcall - calling C functions with variable arguments

     vacall - C functions accepting variable argument prototypes

     trampoline - closures as first-class C functions

     callback - closures with variable arguments as first-class C functions
                (a reentrant combination of vacall and trampoline)

All except callback are written in assembler.

> Help with basic x86_64 assembler is ok, I did it for Cygwin with help
> from Kai Tietz.
>
> The main difference to Linux you have to look out for is the different
> calling convention and how the registers are used:
> http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention
>
> So the job is typically to rearrange the register usage and to
> account for the only four registers used for the first arguments
> to a function, rather than the 6 registers in the SYSV ABI.

I might give it a try at some point, but I'm not highly motivated unless someone 
who really cares about clisp steps forward to help.  I'll concentrate first on 
seeing if I can get some 64-bit version of clisp built without ffcall.

Ken

Re: ffcall

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2794 bytes --]

On Feb 18 17:41, Ken Brown wrote:
> On 2/18/2015 3:08 PM, Corinna Vinschen wrote:
> >On Feb 18 13:28, Yaakov Selkowitz wrote:
> >>On Wed, 2015-02-18 at 13:49 -0500, Ken Brown wrote:
> >>>I've been trying to adopt Reini's packages that have not yet been ported to
> >>>64-bit Cygwin and that have some connection to packages I already maintain.  The
> >>>next one on my list is ffcall.
> >>
> >>I'm guessing this is for clisp?  (In Fedora, clisp is the only package
> >>which BR: ffcall).
> >>
> >>>Unfortunately, the source has a lot of assembler code in it, so I will almost
> >>>certainly need help from someone well versed in x86_64 assembly language.  And
> >>>the libffcall project appears to be dead upstream, so I'm not going to get help
> >>>there.
> >>
> >>Unless you can find a patch somewhere for Win64 support.
> >>
> >>>I have no idea how hard this will be.  The code has been ported to x86_64 Linux,
> >>>so there's at least a starting point.
> >
> >What is ffcall doing?  What functions does it call?
> 
> I don't know much about it yet.  Here's an overview:
> 
> ffcall - foreign function call libraries
> 
> This is a collection of four libraries which can be used to build
> foreign function call interfaces in embedded interpreters.
> 
> The four packages are:
> 
>     avcall - calling C functions with variable arguments
> 
>     vacall - C functions accepting variable argument prototypes
> 
>     trampoline - closures as first-class C functions
> 
>     callback - closures with variable arguments as first-class C functions
>                (a reentrant combination of vacall and trampoline)
> 
> All except callback are written in assembler.

Dunno about trampoline, but avcall and vacall shouldn't be too hard.
It's just juggling around register and stack usage a bit, probably.

> >Help with basic x86_64 assembler is ok, I did it for Cygwin with help
> >from Kai Tietz.
> >
> >The main difference to Linux you have to look out for is the different
> >calling convention and how the registers are used:
> >http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention
> >
> >So the job is typically to rearrange the register usage and to
> >account for the only four registers used for the first arguments
> >to a function, rather than the 6 registers in the SYSV ABI.
> 
> I might give it a try at some point, but I'm not highly motivated unless
> someone who really cares about clisp steps forward to help.  I'll
> concentrate first on seeing if I can get some 64-bit version of clisp built
> without ffcall.

Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: ffcall

[Reini Urban]

On 02/19/2015 10:38 AM, Corinna Vinschen wrote:
> On Feb 18 17:41, Ken Brown wrote:
> Help with basic x86_64 assembler is ok, I did it for Cygwin with help
> from Kai Tietz.
>
> The main difference to Linux you have to look out for is the different
> calling convention and how the registers are used:
> http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention
>
> So the job is typically to rearrange the register usage and to
> account for the only four registers used for the first arguments
> to a function, rather than the 6 registers in the SYSV ABI.
>> I might give it a try at some point, but I'm not highly motivated unless
>> someone who really cares about clisp steps forward to help.  I'll
>> concentrate first on seeing if I can get some 64-bit version of clisp built
>> without ffcall.
Should be doable without. In the meantime I started here:
https://github.com/rurban/ffcall/tree/win64 with a win64 port, time permits.

win64 also needs 32byte shadow stack space to spill rcx, rdx, r8 and r9.
libffi added win64 and cygwin64 support recently, but ffcall is easier to
understand, and faster.

Re: ffcall

[Ken Brown]

On 2/19/2015 10:43 AM, Reini Urban wrote:
> On 02/19/2015 10:38 AM, Corinna Vinschen wrote:
>> On Feb 18 17:41, Ken Brown wrote:
>> Help with basic x86_64 assembler is ok, I did it for Cygwin with help
>> from Kai Tietz.
>>
>> The main difference to Linux you have to look out for is the different
>> calling convention and how the registers are used:
>> http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention
>>
>> So the job is typically to rearrange the register usage and to
>> account for the only four registers used for the first arguments
>> to a function, rather than the 6 registers in the SYSV ABI.
>>> I might give it a try at some point, but I'm not highly motivated unless
>>> someone who really cares about clisp steps forward to help.  I'll
>>> concentrate first on seeing if I can get some 64-bit version of clisp built
>>> without ffcall.
> Should be doable without.

Yes, it seems to be.  So far I've built and am testing a version with no 
non-default modules, and with the default regexp module disabled.  I had 
to do the latter because of the gcc problem I encountered while trying 
to compile regexi.c:

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939

The same sort of error occurs with several other modules.

> In the meantime I started here:
> https://github.com/rurban/ffcall/tree/win64 with a win64 port, time permits.

Thanks!!

> win64 also needs 32byte shadow stack space to spill rcx, rdx, r8 and r9.
> libffi added win64 and cygwin64 support recently, but ffcall is easier to
> understand, and faster.

Ken

Re: ffcall

[Ken Brown]

On 2/19/2015 11:46 AM, Ken Brown wrote:
> On 2/19/2015 10:43 AM, Reini Urban wrote:
>> On 02/19/2015 10:38 AM, Corinna Vinschen wrote:
>>> On Feb 18 17:41, Ken Brown wrote:
>>> Help with basic x86_64 assembler is ok, I did it for Cygwin with help
>>> from Kai Tietz.
>>>
>>> The main difference to Linux you have to look out for is the different
>>> calling convention and how the registers are used:
>>> http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention
>>>
>>>
>>> So the job is typically to rearrange the register usage and to
>>> account for the only four registers used for the first arguments
>>> to a function, rather than the 6 registers in the SYSV ABI.
>>>> I might give it a try at some point, but I'm not highly motivated
>>>> unless
>>>> someone who really cares about clisp steps forward to help.  I'll
>>>> concentrate first on seeing if I can get some 64-bit version of
>>>> clisp built
>>>> without ffcall.
>> Should be doable without.
>
> Yes, it seems to be.  So far I've built and am testing a version with no
> non-default modules, and with the default regexp module disabled.  I had
> to do the latter because of the gcc problem I encountered while trying
> to compile regexi.c:
>
>     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939
>
> The same sort of error occurs with several other modules.

I tried to test my build by using it to build xindy.  It appeared to 
work, as far as it went, but it didn't go too far because xindy requires 
the regexp module.  So I think I'm stuck until the gcc problem is resolved.

I don't whether it's worth uploading my crippled clisp at this point to 
let it get some testing.  Reini, is clisp without regexp at all useful?

Ken

Re: ffcall

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

On Feb 19 12:19, Ken Brown wrote:
> On 2/19/2015 11:46 AM, Ken Brown wrote:
> >On 2/19/2015 10:43 AM, Reini Urban wrote:
> >>On 02/19/2015 10:38 AM, Corinna Vinschen wrote:
> >>>On Feb 18 17:41, Ken Brown wrote:
> >>>Help with basic x86_64 assembler is ok, I did it for Cygwin with help
> >>>from Kai Tietz.
> >>>
> >>>The main difference to Linux you have to look out for is the different
> >>>calling convention and how the registers are used:
> >>>http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention
> >>>
> >>>
> >>>So the job is typically to rearrange the register usage and to
> >>>account for the only four registers used for the first arguments
> >>>to a function, rather than the 6 registers in the SYSV ABI.
> >>>>I might give it a try at some point, but I'm not highly motivated
> >>>>unless
> >>>>someone who really cares about clisp steps forward to help.  I'll
> >>>>concentrate first on seeing if I can get some 64-bit version of
> >>>>clisp built
> >>>>without ffcall.
> >>Should be doable without.
> >
> >Yes, it seems to be.  So far I've built and am testing a version with no
> >non-default modules, and with the default regexp module disabled.  I had
> >to do the latter because of the gcc problem I encountered while trying
> >to compile regexi.c:
> >
> >    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939
> >
> >The same sort of error occurs with several other modules.
> 
> I tried to test my build by using it to build xindy.  It appeared to work,
> as far as it went, but it didn't go too far because xindy requires the
> regexp module.  So I think I'm stuck until the gcc problem is resolved.

Does it build with the former gcc 4.8.3, by any chance?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: ffcall

[Ken Brown]

On 2/19/2015 12:44 PM, Corinna Vinschen wrote:
> On Feb 19 12:19, Ken Brown wrote:
>> On 2/19/2015 11:46 AM, Ken Brown wrote:
>>> On 2/19/2015 10:43 AM, Reini Urban wrote:
>>>> On 02/19/2015 10:38 AM, Corinna Vinschen wrote:
>>>>> On Feb 18 17:41, Ken Brown wrote:
>>>>> Help with basic x86_64 assembler is ok, I did it for Cygwin with help
>>>> >from Kai Tietz.
>>>>>
>>>>> The main difference to Linux you have to look out for is the different
>>>>> calling convention and how the registers are used:
>>>>> http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention
>>>>>
>>>>>
>>>>> So the job is typically to rearrange the register usage and to
>>>>> account for the only four registers used for the first arguments
>>>>> to a function, rather than the 6 registers in the SYSV ABI.
>>>>>> I might give it a try at some point, but I'm not highly motivated
>>>>>> unless
>>>>>> someone who really cares about clisp steps forward to help.  I'll
>>>>>> concentrate first on seeing if I can get some 64-bit version of
>>>>>> clisp built
>>>>>> without ffcall.
>>>> Should be doable without.
>>>
>>> Yes, it seems to be.  So far I've built and am testing a version with no
>>> non-default modules, and with the default regexp module disabled.  I had
>>> to do the latter because of the gcc problem I encountered while trying
>>> to compile regexi.c:
>>>
>>>     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939
>>>
>>> The same sort of error occurs with several other modules.
>>
>> I tried to test my build by using it to build xindy.  It appeared to work,
>> as far as it went, but it didn't go too far because xindy requires the
>> regexp module.  So I think I'm stuck until the gcc problem is resolved.
>
> Does it build with the former gcc 4.8.3, by any chance?

No, same error.

Ken

Re: ffcall

[Reini Urban]

On 02/19/2015 06:19 PM, Ken Brown wrote:
> On 2/19/2015 11:46 AM, Ken Brown wrote:
>> On 2/19/2015 10:43 AM, Reini Urban wrote:
>>> On 02/19/2015 10:38 AM, Corinna Vinschen wrote:
>>>> On Feb 18 17:41, Ken Brown wrote:
>>>> Help with basic x86_64 assembler is ok, I did it for Cygwin with help
>>>> from Kai Tietz.
>>>>
>>>> The main difference to Linux you have to look out for is the different
>>>> calling convention and how the registers are used:
>>>> http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention
>>>>
>>>>
>>>>
>>>> So the job is typically to rearrange the register usage and to
>>>> account for the only four registers used for the first arguments
>>>> to a function, rather than the 6 registers in the SYSV ABI.
>>>>> I might give it a try at some point, but I'm not highly motivated
>>>>> unless
>>>>> someone who really cares about clisp steps forward to help.  I'll
>>>>> concentrate first on seeing if I can get some 64-bit version of
>>>>> clisp built
>>>>> without ffcall.
>>> Should be doable without.
>>
>> Yes, it seems to be.  So far I've built and am testing a version with no
>> non-default modules, and with the default regexp module disabled.  I had
>> to do the latter because of the gcc problem I encountered while trying
>> to compile regexi.c:
>>
>>     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939
>>
>> The same sort of error occurs with several other modules.
Huh, that's a good one! Something for Kai.

> I tried to test my build by using it to build xindy.  It appeared to
work, as far as it went, but it didn't go too far because xindy requires
the regexp module.  So I think I'm stuck until the gcc problem is resolved.
>
> I don't whether it's worth uploading my crippled clisp at this point
> to let it get some testing.  Reini, is clisp without regexp at all
> useful?

Usually clisp users don't need the regexp module, they usually have
better matchers.
But xindy needs it, so... :)

And the deal with the latest clisp 2.49 was that modules can be dynaloaded.
If the gnulib steps would work. I never did for me. And I fixed most of
the other
module compilation problems before.

Re: ffcall

[Ken Brown]

On 2/19/2015 2:46 PM, Reini Urban wrote:
> On 02/19/2015 06:19 PM, Ken Brown wrote:
>> On 2/19/2015 11:46 AM, Ken Brown wrote:
>>> On 2/19/2015 10:43 AM, Reini Urban wrote:
>>>> On 02/19/2015 10:38 AM, Corinna Vinschen wrote:
>>>>> On Feb 18 17:41, Ken Brown wrote:
>>>>> Help with basic x86_64 assembler is ok, I did it for Cygwin with help
>>>>> from Kai Tietz.
>>>>>
>>>>> The main difference to Linux you have to look out for is the different
>>>>> calling convention and how the registers are used:
>>>>> http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention
>>>>>
>>>>>
>>>>>
>>>>> So the job is typically to rearrange the register usage and to
>>>>> account for the only four registers used for the first arguments
>>>>> to a function, rather than the 6 registers in the SYSV ABI.
>>>>>> I might give it a try at some point, but I'm not highly motivated
>>>>>> unless
>>>>>> someone who really cares about clisp steps forward to help.  I'll
>>>>>> concentrate first on seeing if I can get some 64-bit version of
>>>>>> clisp built
>>>>>> without ffcall.
>>>> Should be doable without.
>>>
>>> Yes, it seems to be.  So far I've built and am testing a version with no
>>> non-default modules, and with the default regexp module disabled.  I had
>>> to do the latter because of the gcc problem I encountered while trying
>>> to compile regexi.c:
>>>
>>>      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939
>>>
>>> The same sort of error occurs with several other modules.
> Huh, that's a good one! Something for Kai.
>
>> I tried to test my build by using it to build xindy.  It appeared to
> work, as far as it went, but it didn't go too far because xindy requires
> the regexp module.  So I think I'm stuck until the gcc problem is resolved.
>>
>> I don't whether it's worth uploading my crippled clisp at this point
>> to let it get some testing.  Reini, is clisp without regexp at all
>> useful?
>
> Usually clisp users don't need the regexp module, they usually have
> better matchers.

In that case, I think I'll go ahead and release what I have and see if 
it's of use to anyone.

Ken

Re: ffcall

[David Billinghurst]

On 20/02/2015 9:30 AM, Ken Brown wrote:
> In that case, I think I'll go ahead and release what I have and see if 
> it's of use to anyone.
>
> Ken 

I have built and tested maxima-5.43.1 with your clisp release on 
cygwin64.  Perfect test results.    I find clisp slow for routine work, 
but it is good to have it available.

David

Re: ffcall

[Ken Brown]

On 2/21/2015 5:03 AM, David Billinghurst wrote:
>
> On 20/02/2015 9:30 AM, Ken Brown wrote:
>> In that case, I think I'll go ahead and release what I have and see if it's of
>> use to anyone.
>>
>> Ken
>
> I have built and tested maxima-5.43.1 with your clisp release on cygwin64.
> Perfect test results.    I find clisp slow for routine work, but it is good to
> have it available.

Thanks for testing.

Ken

Re: ffcall

[Achim Gratz]

David Billinghurst writes:
> I have built and tested maxima-5.43.1 with your clisp release on
> cygwin64.  Perfect test results.    I find clisp slow for routine
> work, but it is good to have it available.

I've built maxima-5.35.1 for both architectures.  The makefiles don't
really want to cooperate with cygport, you'll have to link the sourcedir
and then it still looks for some files that configure produces in
sourcedire while testing… but other than that, everything looks OK, all
tests are pass.

--8<---------------cut here---------------start------------->8---
NAME="maxima"
VERSION="5.35.1"
RELEASE="1"
HOMEPAGE="http://maxima.sourceforge.net/index.html"
SRC_URI="mirror://sourceforge/${P}.tar.gz"

CATEGORY="Science"
SUMMARY="Maxima Computer Algebra System"
DESCRIPTION="${SUMMARY}

Maxima is a system for the manipulation of symbolic and numerical
expressions, including differentiation, integration, Taylor series,
Laplace transforms, ordinary differential equations, systems of linear
equations, polynomials, sets, lists, vectors, matrices and
tensors. Maxima yields high precision numerical results by using exact
fractions, arbitrary-precision integers and variable-precision
floating-point numbers. Maxima can plot functions and data in two and
three dimensions.

Maxima is written in CommonLisp and based on the DOE Macsyma that was
developed at MIT."

CYGCONF_ARGS="--enable-clisp-exec --enable-gettext"

src_compile() {
    cd ${S}
    cygautoreconf
    lndirs
    cd ${B}
    cygconf
    cygmake
}
src_test() {
    cd ${B}
    # need to patch test/Makefile here or fix configury
    cygtest
}
--8<---------------cut here---------------end--------------->8---

I also tried building gcl (with the intention of running maxima on gcl);
again you'll have to lndirs and the configure script doesn't check how
to include the xdr headers.  It also doesn't find the bfd and liberty
libraries that are static only on Cygwin, not sure if it needs them.
The include hiccup out of the way things start to compile, but then
raw_pre_gcl segfaults.

--8<---------------cut here---------------start------------->8---
NAME="gcl"
VERSION="2.6.12"
RELEASE="1"
HOMEPAGE="http://www.gnu.org/software/${PN}/"
SRC_URI="mirror://gnu/${PN}/${P}.tar.gz"
SRC_DIR="${PN}"

CATEGORY="Text"
SUMMARY="GNU Common Lisp"
DESCRIPTION="${SUMMARY}

GCL is the official Common Lisp for the GNU project. Its design makes
use of the system's C compiler to compile to native object code,
providing for both good performance and facile portability."

CYGCONF_ARGS="--enable-notify=no --enable-readline --enable-ansi"
MAKEOPTS+=" -j1 -k"
CFLAGS+=" -I/usr/include/tirpc"

src_compile() {
    cd ${S}
    cygautoreconf
    lndirs
    cd ${B}
    cygconf
    cygmake
}
--8<---------------cut here---------------end--------------->8---


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: ffcall

[Achim Gratz]

Achim Gratz writes:
> The include hiccup out of the way things start to compile, but then
> raw_pre_gcl segfaults.

Something for Corinna it seems… :-)

--8<---------------cut here---------------start------------->8---
...gcl.x86/build/unixport (1673) strace /mnt/share/maint/gcl.x86/build/unixport/raw_pre_gcl.exe /mnt/share/maint/gcl.x86/build/unixport/ -libdir /mnt/share/maint/gcl.x86/build/ < foo
    2       2 [main] raw_pre_gcl (2616) **********************************************
  112     114 [main] raw_pre_gcl (2616) Program name: D:\Freeware\CygShare\maint\gcl.x86\build\unixport\raw_pre_gcl.exe (windows pid 2616)
   56     170 [main] raw_pre_gcl (2616) OS version:   Windows NT-6.3
   49     219 [main] raw_pre_gcl (2616) **********************************************
  123     342 [main] raw_pre_gcl (2616) sigprocmask: 0 = sigprocmask (0, 0x0, 0x61292748)
  339     681 [main] raw_pre_gcl 2616 open_shared: name shared.5, n 5, shared 0x60FF0000 (wanted 0x60FF0000), h 0x78, *m 6
   70     751 [main] raw_pre_gcl 2616 user_heap_info::init: heap base 0x80000000, heap top 0x80000000, heap size 0x18000000 (402653184)
   72     823 [main] raw_pre_gcl 2616 open_shared: name S-1-5-21-3709744764-2796632336-1210317817-1001.1, n 1, shared 0x60FE0000 (wanted 0x60FE0000), h 0x74, *m 6
   51     874 [main] raw_pre_gcl 2616 user_info::create: opening user shared for 'S-1-5-21-3709744764-2796632336-1210317817-1001' at 0x60FE0000
   59     933 [main] raw_pre_gcl 2616 user_info::create: user shared version AB1FCCE8
   81    1014 [main] raw_pre_gcl 2616 fhandler_pipe::create: name \\.\pipe\cygwin-08dae4ebc0ee1e22-2616-sigwait, size 5412, mode PIPE_TYPE_MESSAGE
  105    1119 [main] raw_pre_gcl 2616 fhandler_pipe::create: pipe read handle 0x8C
   50    1169 [main] raw_pre_gcl 2616 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-08dae4ebc0ee1e22-2616-sigwait
   60    1229 [main] raw_pre_gcl 2616 fhandler_pipe::create: pipe write handle 0x90
   41    1270 [main] raw_pre_gcl 2616 dll_crt0_0: finished dll_crt0_0 initialization
  591    1861 [sig] raw_pre_gcl 2616 wait_sig: entering ReadFile loop, my_readsig 0x8C, my_sendsig 0x90
   66    1927 [main] raw_pre_gcl 2616 set_signal_mask: setmask 0, newmask 0, mask_bits 0
   47    1974 [main] raw_pre_gcl 2616 sigprocmask: 0 = sigprocmask (2, 0x10ECAA8, 0x10ECAAC)
   34    2008 [main] raw_pre_gcl 2616 set_signal_mask: setmask 0, newmask 0, mask_bits 0
   29    2037 [main] raw_pre_gcl 2616 sigprocmask: 0 = sigprocmask (2, 0x10ECAA8, 0x10ECAAC)
   32    2069 [main] raw_pre_gcl 2616 sigaction_worker: signal 11, newact 0x10ECAB4 (handler 0x409200), oa 0x0
   29    2098 [main] raw_pre_gcl 2616 sigaction: 0 = sigaction(11, 0x10ECAB4, 0x0)
   29    2127 [main] raw_pre_gcl 2616 sigaction_worker: signal 10, newact 0x10ECAB4 (handler 0x409200), oa 0x0
   28    2155 [main] raw_pre_gcl 2616 sigaction: 0 = sigaction(10, 0x10ECAB4, 0x0)
14680   16835 [main] raw_pre_gcl 2616 mount_info::conv_to_posix_path: conv_to_posix_path (D:\Freeware\CygShare\maint\gcl.x86\build\unixport, no-keep-rel, no-add-slash)
  134   16969 [main] raw_pre_gcl 2616 normalize_win32_path: D:\Freeware\CygShare\maint\gcl.x86\build\unixport = normalize_win32_path (D:\Freeware\CygShare\maint\gcl.x86\build\unixport)
   53   17022 [main] raw_pre_gcl 2616 mount_info::conv_to_posix_path: /mnt/share/maint/gcl.x86/build/unixport = conv_to_posix_path (D:\Freeware\CygShare\maint\gcl.x86\build\unixport)
  125   17147 [main] raw_pre_gcl 2616 sigprocmask: 0 = sigprocmask (0, 0x0, 0x980DD510)
  205   17352 [main] raw_pre_gcl 2616 _cygwin_istext_for_stdio: fd 0: not open
   67   17419 [main] raw_pre_gcl 2616 _cygwin_istext_for_stdio: fd 1: not open
   51   17470 [main] raw_pre_gcl 2616 _cygwin_istext_for_stdio: fd 2: not open
  226   17696 [main] raw_pre_gcl (2616) open_shared: name cygpid.2616, n 2616, shared 0x60FD0000 (wanted 0x60FD0000), h 0xBC, *m 2
   90   17786 [main] ? (2616) time: 1424552435 = time(0x0)
   48   17834 [main] raw_pre_gcl 2616 pinfo::thisproc: myself dwProcessId 2616
  188   18022 [main] raw_pre_gcl 2616 environ_init: GetEnvironmentStrings returned 0x2056D8
  120   18142 [main] raw_pre_gcl 2616 environ_init: 0x980EEA28: ALLUSERSPROFILE=C:\ProgramData
   77   18219 [main] raw_pre_gcl 2616 environ_init: 0x980EEA48: APPDATA=C:\Users\ASSI\AppData\Roaming
  121   18340 [main] raw_pre_gcl 2616 environ_init: 0x980EEA70: COMPUTERNAME=CYGWIN
  103   18443 [main] raw_pre_gcl 2616 environ_init: 0x980EEA88: COMSPEC=C:\Windows\system32\cmd.exe
  102   18545 [main] raw_pre_gcl 2616 parse_options: glob (called func)
   96   18641 [main] raw_pre_gcl 2616 parse_options: returning
   47   18688 [main] raw_pre_gcl 2616 environ_init: 0x980EEAB0: CYGWIN=noglob
   81   18769 [main] raw_pre_gcl 2616 environ_init: 0x980EEAC8: CYGWIN32_ROOT=D:\Freeware\Cygwin32\
   62   18831 [main] raw_pre_gcl 2616 environ_init: 0x980EEAF0: CYGWIN64_ROOT=D:\Freeware\Cygwin64\
   54   18885 [main] raw_pre_gcl 2616 environ_init: 0x980EEB18: CYGWIN_NOWINPATH=true
   54   18939 [main] raw_pre_gcl 2616 environ_init: 0x980EEB30: CYGWIN_ROOT=D:\Freeware\Cygwin64\
   54   18993 [main] raw_pre_gcl 2616 environ_init: 0x980EEB58: CYGWIN_UPLOAD=D:\Freeware\Upload\
   55   19048 [main] raw_pre_gcl 2616 environ_init: 0x980EEB80: CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
   55   19103 [main] raw_pre_gcl 2616 environ_init: 0x980EEBC0: COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files
   55   19158 [main] raw_pre_gcl 2616 environ_init: 0x980EEBF8: CommonProgramW6432=C:\Program Files\Common Files
   53   19211 [main] raw_pre_gcl 2616 environ_init: 0x980EEC30: FP_NO_HOST_CHECK=NO
   52   19263 [main] raw_pre_gcl 2616 environ_init: 0x980EEC48: GROUP=Kein
   53   19316 [main] raw_pre_gcl 2616 getwinenv: can't set native for HOME= since no environ yet
   31   19347 [main] raw_pre_gcl 2616 mount_info::conv_to_posix_path: conv_to_posix_path (C:\Users\ASSI\CygwinHome, no-keep-rel, no-add-slash)
   30   19377 [main] raw_pre_gcl 2616 normalize_win32_path: C:\Users\ASSI\CygwinHome = normalize_win32_path (C:\Users\ASSI\CygwinHome)
   29   19406 [main] raw_pre_gcl 2616 mount_info::conv_to_posix_path: /home/ASSI = conv_to_posix_path (C:\Users\ASSI\CygwinHome)
   79   19485 [main] raw_pre_gcl 2616 win_env::add_cache: posix /home/ASSI
   27   19512 [main] raw_pre_gcl 2616 win_env::add_cache: native HOME=C:\Users\ASSI\CygwinHome
   27   19539 [main] raw_pre_gcl 2616 posify_maybe: env var converted to HOME=/home/ASSI
  19763 [main] raw_pre_gcl 2616 D:\Freeware\CygShare\maint\gcl.x86\build\unixport\raw_pre_gcl.exe: *** fatal error - internal error reading the windows environment - too many environment variables?
--- Process 2616, exception c0000005 at 00420D43
  224   19763 [main] raw_pre_gcl 2616 D:\Freeware\CygShare\maint\gcl.x86\build\unixport\raw_pre_gcl.exe: *** fatal error - internal error reading the windows environment - too many environment variables?
  20213 [main] raw_pre_gcl 2616 cygwin_exception::open_stackdumpfile: Dumping stack trace to raw_pre_gcl.exe.stackdump
  450   20213 [main] raw_pre_gcl 2616 cygwin_exception::open_stackdumpfile: Dumping stack trace to raw_pre_gcl.exe.stackdump
118020  138233 [main] raw_pre_gcl 2616 proc_terminate: nprocs 0
  147  138380 [main] raw_pre_gcl 2616 proc_terminate: leaving
  167  138547 [main] raw_pre_gcl 2616 pinfo::exit: Calling ExitProcess n 0x1, exitcode 0x100
--8<---------------cut here---------------end--------------->8---


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: ffcall

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

On Feb 21 22:04, Achim Gratz wrote:
> Achim Gratz writes:
> > The include hiccup out of the way things start to compile, but then
> > raw_pre_gcl segfaults.
> 
> Something for Corinna it seems… :-)

Well, I'm not so sure...

> --8<---------------cut here---------------start------------->8---
>    52   19263 [main] raw_pre_gcl 2616 environ_init: 0x980EEC48: GROUP=Kein
>    53   19316 [main] raw_pre_gcl 2616 getwinenv: can't set native for HOME= since no environ yet
>    31   19347 [main] raw_pre_gcl 2616 mount_info::conv_to_posix_path: conv_to_posix_path (C:\Users\ASSI\CygwinHome, no-keep-rel, no-add-slash)
>    30   19377 [main] raw_pre_gcl 2616 normalize_win32_path: C:\Users\ASSI\CygwinHome = normalize_win32_path (C:\Users\ASSI\CygwinHome)
>    29   19406 [main] raw_pre_gcl 2616 mount_info::conv_to_posix_path: /home/ASSI = conv_to_posix_path (C:\Users\ASSI\CygwinHome)
>    79   19485 [main] raw_pre_gcl 2616 win_env::add_cache: posix /home/ASSI
>    27   19512 [main] raw_pre_gcl 2616 win_env::add_cache: native HOME=C:\Users\ASSI\CygwinHome
>    27   19539 [main] raw_pre_gcl 2616 posify_maybe: env var converted to HOME=/home/ASSI
>   19763 [main] raw_pre_gcl 2616 D:\Freeware\CygShare\maint\gcl.x86\build\unixport\raw_pre_gcl.exe: *** fatal error - internal error reading the windows environment - too many environment variables?
> --- Process 2616, exception c0000005 at 00420D43
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The crash occurs *during* envionment variable processing, but *in* the
application address space.  Does the application come with its own
malloc?

For the time being, I declare Cygwin's innocence.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: ffcall

[Achim Gratz]

Corinna Vinschen writes:
> The crash occurs *during* envionment variable processing, but *in* the
> application address space.  Does the application come with its own
> malloc?

Probably, I'll have to check.  It comes with it's own GC at least.

> For the time being, I declare Cygwin's innocence.

Fair enough.


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: ffcall

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

On Feb 23 18:48, Achim Gratz wrote:
> Corinna Vinschen writes:
> > The crash occurs *during* envionment variable processing, but *in* the
> > application address space.  Does the application come with its own
> > malloc?
> 
> Probably, I'll have to check.  It comes with it's own GC at least.

Own malloc and own GC?  WHat if it misses the fact that the C library
(aka Cygwin) uses malloc, too?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: ffcall

[Achim Gratz]

Corinna Vinschen writes:
> Own malloc and own GC?  WHat if it misses the fact that the C library
> (aka Cygwin) uses malloc, too?

I didn't really follow through after that fail.  I did successfully
compile ecl and it seems to work with maxima, but ecl doesn't produce
executables.  But really, what's the matter with those Lisp folks and
their wierd build systems? (don't answer, rhetorical question)


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: ffcall

[Ken Brown]

On 2/19/2015 2:46 PM, Reini Urban wrote:
> And the deal with the latest clisp 2.49 was that modules can be dynaloaded.
> If the gnulib steps would work. I never did for me. And I fixed most of
> the other
> module compilation problems before.

But I just discovered that clisp-2.49 builds fine with the configure option 
--without-dynamic-modules.  Is there any reason not to do that?  After all, 
clisp-2.48 is built without dynamic modules, so what's the harm in doing the 
same for 2.49?

Ken

Re: ffcall

[Reini Urban]

On 02/21/2015 04:44 AM, Ken Brown wrote:
> On 2/19/2015 2:46 PM, Reini Urban wrote:
>> And the deal with the latest clisp 2.49 was that modules can be
>> dynaloaded.
>> If the gnulib steps would work. I never did for me. And I fixed most of
>> the other
>> module compilation problems before.
>
> But I just discovered that clisp-2.49 builds fine with the configure
> option --without-dynamic-modules.  Is there any reason not to do
> that?  After all, clisp-2.48 is built without dynamic modules, so
> what's the harm in doing the same for 2.49?

Technically this is the best.
But I never published 2.49 with this option, because there were not many
other changes.
So it's almost the same as 2.48 and my version was not as confusing.

Re: ffcall

[Ken Brown]

On 2/21/2015 7:59 AM, Reini Urban wrote:
> On 02/21/2015 04:44 AM, Ken Brown wrote:
>> On 2/19/2015 2:46 PM, Reini Urban wrote:
>>> And the deal with the latest clisp 2.49 was that modules can be
>>> dynaloaded.
>>> If the gnulib steps would work. I never did for me. And I fixed most of
>>> the other
>>> module compilation problems before.
>>
>> But I just discovered that clisp-2.49 builds fine with the configure
>> option --without-dynamic-modules.  Is there any reason not to do
>> that?  After all, clisp-2.48 is built without dynamic modules, so
>> what's the harm in doing the same for 2.49?
>
> Technically this is the best.
> But I never published 2.49 with this option, because there were not many
> other changes.
> So it's almost the same as 2.48 and my version was not as confusing.

OK, that makes sense.  On the other hand, I think users are confused by not 
having the latest release in the distro, so I'll probably update to 2.49.

Ken

Re: ffcall

[Ken Brown]

On 2/18/2015 2:28 PM, Yaakov Selkowitz wrote:
> On Wed, 2015-02-18 at 13:49 -0500, Ken Brown wrote:
>> I've been trying to adopt Reini's packages that have not yet been ported to
>> 64-bit Cygwin and that have some connection to packages I already maintain.  The
>> next one on my list is ffcall.
>
> I'm guessing this is for clisp?

Right.  It might be possible to build a rudimentary version of clisp on x86_64 
without ffcall, but I don't know yet.

>> Unfortunately, the source has a lot of assembler code in it, so I will almost
>> certainly need help from someone well versed in x86_64 assembly language.  And
>> the libffcall project appears to be dead upstream, so I'm not going to get help
>> there.
>
> Unless you can find a patch somewhere for Win64 support.

Not that I've been able to find.

>> I have no idea how hard this will be.  The code has been ported to x86_64 Linux,
>> so there's at least a starting point.
>
> Only to a point, there are significant differences:
>
> https://sourceforge.net/p/mingw-w64/wiki2/MinGW%20x64%20Software%
> 20convention/

Ken