missing 64bit ports

Ken Brown kbrown@cornell.edu
Fri Jul 17 12:53:00 GMT 2015

On 7/17/2015 3:32 AM, Corinna Vinschen wrote:
> On Jul 15 16:12, Ken Brown wrote:
>> On 7/15/2015 2:28 PM, Corinna Vinschen wrote:
>>> On Jul 15 16:24, Marco Atzeri wrote:
>>>> Dear All,
>>>> I spent a bit of time checking the real situation of the packages
>>>> still missing as 64 bit port.
>>>> After xdelta, bsdiff and iperf porting, without counting the few mingw ones,
>>>> the duplicates we are down to ~44.
>>>> Please see here the analysis :
>>>> https://docs.google.com/spreadsheets/d/1Hn7Eaq6djEN9X0jS_AM8-DH_LvP43G9_DXnpTt09Asc/edit#gid=0
>>>> Feel free to insert comments on the cells.
>>>> For what I found :
>>>> - half of them are dead upstream so we can directly
>>>> obsolete and don't worry anynore.
>>>> - Few are Jary's scripts, so the only porting issue is Jary's time.
>>>> - Very few have real porting issue
>>>> The only one really interesting for me is Mathomatic and eventually catdoc
>>>> if works with latest word documents.
>>>> (of course I will port pure-ftpd)
>>> Thanks for looking into this.
>>> Two points:
>>> - Shall we remove all 32b-bit only orphaned packages for which we don't
>>>    get a maintainer until, say, end of August?
>> That seems reasonable, as long as there are exceptions for packages where
>> the lack of a 64-bit package is due to genuine porting difficulties.
>> libsigsegv was in that category until yesterday.  Another one I'm aware of
>> is ffcall.
> I understand, but they are unmaintained.  So, who's going to check
> if they are buildable as 64 bit packages?

Good point.  In that case, I volunteer to maintain ffcall, just to protect it. 
I have an interest in it because it's used by clisp (and probably nothing else). 
  I already looked into the possibility of a 64-bit port, starting here:


And Reini made a start (https://github.com/rurban/ffcall/tree/win64), but I 
don't know when/if he'll have time to finish it.


More information about the Cygwin-apps mailing list