This is the mail archive of the
mailing list for the Cygwin project.
Re: [HEADSUP] Dropping libopenssl098 from distro
- From: Reini Urban <rurban at x-ray dot at>
- To: cygwin-apps at cygwin dot com
- Date: Sun, 25 Jan 2015 13:09:44 -0600
- Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
- Authentication-results: sourceware.org; auth=none
- References: <20150114141344 dot GG15791 at calimero dot vinschen dot de> <87ppahz3kt dot fsf at Rainer dot invalid> <20150114172404 dot GN15791 at calimero dot vinschen dot de> <87h9vtz254 dot fsf at Rainer dot invalid> <54B6DD5D dot 4060705 at cornell dot edu>
On 01/14/2015 03:19 PM, Ken Brown wrote:
> On 1/14/2015 12:46 PM, Achim Gratz wrote:
>> Corinna Vinschen writes:
>>>> Clisp is not yet ported to 64bit and it has problems under 32bit as
>>>> (temporary file generation) that also affect Maxima from ports.
>>> If it's a problem with the Cygwin DLL, it would be nice to get a
>>> bug report and, preferredly, an STC, so we have a chance to fix this.
>> AFAIK it's the same problem that produced the same symptoms in sqlite:
>> using a non-Cygwin API. So no, I don't think the Cygwin DLL is to
>>> Apart from that, I was only talking about the 32 bitr version anyway.
>>> It requires the wrong libopenssl and needs a simple rebuild for now.
>>>> One of the things holding a port off is libsigsegv, IIRC.
>>> This is a bit annoying. Libsigsegv should be optional, not required.
>> I have no idea whether that's possible for clisp.
> It is. There's a configure option "--ignore-absence-of-libsigsegv".
> But there are more serious problems, affecting both the 32-bit and
> 64-bit versions. (So even just rebuilding clisp for 32-bit Cygwin will
> take some work.) The problem is that lisp.exe, which is built and used
> in the course of trying to build clisp.exe, crashes with a SEGV shortly
> after it's started.
> My reason for looking at this was that clisp is needed for building
> xindy, an optional component of TeX Live. I did successfully build
> clisp in the 32-bit case four years ago, but I can't any more. My guess
> (untested) is that this is because the location of the heap has changed
> since then, and maybe the source code makes unwarranted assumptions
> about memory layout.
> It's a shame that Reini isn't available to help with this.
64bit is not yet possible, yes.
on 32bit, just use 2.48, which should work ok.
but the build system is tricky.
2.49 never really worked. I've tried a few times to fix modules support.
Most of my fixes are upstream, but the last released version was not
fixable anymore. A gnulib problem.