* ffcall
@ 2015-02-18 18:49 Ken Brown
2015-02-18 19:28 ` ffcall Yaakov Selkowitz
0 siblings, 1 reply; 24+ messages in thread
From: Ken Brown @ 2015-02-18 18:49 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-18 18:49 ffcall Ken Brown
@ 2015-02-18 19:28 ` Yaakov Selkowitz
2015-02-18 20:08 ` ffcall Corinna Vinschen
2015-02-18 22:17 ` ffcall Ken Brown
0 siblings, 2 replies; 24+ messages in thread
From: Yaakov Selkowitz @ 2015-02-18 19:28 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-18 19:28 ` ffcall Yaakov Selkowitz
@ 2015-02-18 20:08 ` Corinna Vinschen
2015-02-18 22:41 ` ffcall Ken Brown
2015-02-18 22:17 ` ffcall Ken Brown
1 sibling, 1 reply; 24+ messages in thread
From: Corinna Vinschen @ 2015-02-18 20:08 UTC (permalink / raw)
To: cygwin-apps
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-18 19:28 ` ffcall Yaakov Selkowitz
2015-02-18 20:08 ` ffcall Corinna Vinschen
@ 2015-02-18 22:17 ` Ken Brown
1 sibling, 0 replies; 24+ messages in thread
From: Ken Brown @ 2015-02-18 22:17 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-18 20:08 ` ffcall Corinna Vinschen
@ 2015-02-18 22:41 ` Ken Brown
2015-02-19 9:38 ` ffcall Corinna Vinschen
0 siblings, 1 reply; 24+ messages in thread
From: Ken Brown @ 2015-02-18 22:41 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-18 22:41 ` ffcall Ken Brown
@ 2015-02-19 9:38 ` Corinna Vinschen
2015-02-19 15:43 ` ffcall Reini Urban
0 siblings, 1 reply; 24+ messages in thread
From: Corinna Vinschen @ 2015-02-19 9:38 UTC (permalink / raw)
To: cygwin-apps
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-19 9:38 ` ffcall Corinna Vinschen
@ 2015-02-19 15:43 ` Reini Urban
2015-02-19 16:45 ` ffcall Ken Brown
0 siblings, 1 reply; 24+ messages in thread
From: Reini Urban @ 2015-02-19 15:43 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-19 15:43 ` ffcall Reini Urban
@ 2015-02-19 16:45 ` Ken Brown
2015-02-19 17:18 ` ffcall Ken Brown
0 siblings, 1 reply; 24+ messages in thread
From: Ken Brown @ 2015-02-19 16:45 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-19 16:45 ` ffcall Ken Brown
@ 2015-02-19 17:18 ` Ken Brown
2015-02-19 17:44 ` ffcall Corinna Vinschen
2015-02-19 19:46 ` ffcall Reini Urban
0 siblings, 2 replies; 24+ messages in thread
From: Ken Brown @ 2015-02-19 17:18 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-19 17:18 ` ffcall Ken Brown
@ 2015-02-19 17:44 ` Corinna Vinschen
2015-02-19 18:47 ` ffcall Ken Brown
2015-02-19 19:46 ` ffcall Reini Urban
1 sibling, 1 reply; 24+ messages in thread
From: Corinna Vinschen @ 2015-02-19 17:44 UTC (permalink / raw)
To: cygwin-apps
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-19 17:44 ` ffcall Corinna Vinschen
@ 2015-02-19 18:47 ` Ken Brown
0 siblings, 0 replies; 24+ messages in thread
From: Ken Brown @ 2015-02-19 18:47 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-19 17:18 ` ffcall Ken Brown
2015-02-19 17:44 ` ffcall Corinna Vinschen
@ 2015-02-19 19:46 ` Reini Urban
2015-02-19 22:30 ` ffcall Ken Brown
2015-02-21 3:45 ` ffcall Ken Brown
1 sibling, 2 replies; 24+ messages in thread
From: Reini Urban @ 2015-02-19 19:46 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-19 19:46 ` ffcall Reini Urban
@ 2015-02-19 22:30 ` Ken Brown
2015-02-21 10:03 ` ffcall David Billinghurst
2015-02-21 3:45 ` ffcall Ken Brown
1 sibling, 1 reply; 24+ messages in thread
From: Ken Brown @ 2015-02-19 22:30 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-19 19:46 ` ffcall Reini Urban
2015-02-19 22:30 ` ffcall Ken Brown
@ 2015-02-21 3:45 ` Ken Brown
2015-02-21 12:59 ` ffcall Reini Urban
1 sibling, 1 reply; 24+ messages in thread
From: Ken Brown @ 2015-02-21 3:45 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-19 22:30 ` ffcall Ken Brown
@ 2015-02-21 10:03 ` David Billinghurst
2015-02-21 17:16 ` ffcall Ken Brown
2015-02-21 20:43 ` ffcall Achim Gratz
0 siblings, 2 replies; 24+ messages in thread
From: David Billinghurst @ 2015-02-21 10:03 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-21 3:45 ` ffcall Ken Brown
@ 2015-02-21 12:59 ` Reini Urban
2015-02-21 17:20 ` ffcall Ken Brown
0 siblings, 1 reply; 24+ messages in thread
From: Reini Urban @ 2015-02-21 12:59 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-21 10:03 ` ffcall David Billinghurst
@ 2015-02-21 17:16 ` Ken Brown
2015-02-21 20:43 ` ffcall Achim Gratz
1 sibling, 0 replies; 24+ messages in thread
From: Ken Brown @ 2015-02-21 17:16 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-21 12:59 ` ffcall Reini Urban
@ 2015-02-21 17:20 ` Ken Brown
0 siblings, 0 replies; 24+ messages in thread
From: Ken Brown @ 2015-02-21 17:20 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-21 10:03 ` ffcall David Billinghurst
2015-02-21 17:16 ` ffcall Ken Brown
@ 2015-02-21 20:43 ` Achim Gratz
2015-02-21 21:04 ` ffcall Achim Gratz
1 sibling, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2015-02-21 20:43 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-21 20:43 ` ffcall Achim Gratz
@ 2015-02-21 21:04 ` Achim Gratz
2015-02-23 11:38 ` ffcall Corinna Vinschen
0 siblings, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2015-02-21 21:04 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-21 21:04 ` ffcall Achim Gratz
@ 2015-02-23 11:38 ` Corinna Vinschen
2015-02-23 17:48 ` ffcall Achim Gratz
0 siblings, 1 reply; 24+ messages in thread
From: Corinna Vinschen @ 2015-02-23 11:38 UTC (permalink / raw)
To: cygwin-apps
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-23 11:38 ` ffcall Corinna Vinschen
@ 2015-02-23 17:48 ` Achim Gratz
2015-02-23 20:32 ` ffcall Corinna Vinschen
0 siblings, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2015-02-23 17:48 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-23 17:48 ` ffcall Achim Gratz
@ 2015-02-23 20:32 ` Corinna Vinschen
2015-02-23 20:56 ` ffcall Achim Gratz
0 siblings, 1 reply; 24+ messages in thread
From: Corinna Vinschen @ 2015-02-23 20:32 UTC (permalink / raw)
To: cygwin-apps
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ffcall
2015-02-23 20:32 ` ffcall Corinna Vinschen
@ 2015-02-23 20:56 ` Achim Gratz
0 siblings, 0 replies; 24+ messages in thread
From: Achim Gratz @ 2015-02-23 20:56 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2015-02-23 20:56 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-18 18:49 ffcall Ken Brown
2015-02-18 19:28 ` ffcall Yaakov Selkowitz
2015-02-18 20:08 ` ffcall Corinna Vinschen
2015-02-18 22:41 ` ffcall Ken Brown
2015-02-19 9:38 ` ffcall Corinna Vinschen
2015-02-19 15:43 ` ffcall Reini Urban
2015-02-19 16:45 ` ffcall Ken Brown
2015-02-19 17:18 ` ffcall Ken Brown
2015-02-19 17:44 ` ffcall Corinna Vinschen
2015-02-19 18:47 ` ffcall Ken Brown
2015-02-19 19:46 ` ffcall Reini Urban
2015-02-19 22:30 ` ffcall Ken Brown
2015-02-21 10:03 ` ffcall David Billinghurst
2015-02-21 17:16 ` ffcall Ken Brown
2015-02-21 20:43 ` ffcall Achim Gratz
2015-02-21 21:04 ` ffcall Achim Gratz
2015-02-23 11:38 ` ffcall Corinna Vinschen
2015-02-23 17:48 ` ffcall Achim Gratz
2015-02-23 20:32 ` ffcall Corinna Vinschen
2015-02-23 20:56 ` ffcall Achim Gratz
2015-02-21 3:45 ` ffcall Ken Brown
2015-02-21 12:59 ` ffcall Reini Urban
2015-02-21 17:20 ` ffcall Ken Brown
2015-02-18 22:17 ` ffcall Ken Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).