* 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 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 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 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 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
* 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-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 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-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
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).