[plt-scheme] v300 on OpenBSD

Hi,

Yeah, I tried using -fno-stack-protector, which seemed to compile and  
install okay, including running ./install. Some binaries (web-server)  
were missing, though, so I re-ran ./install, and the hang problem  
returned.

I tried deleting the old `configure', editing configure.ac to produce  
good code for OpenBSD, and re-creating the original `configure' with  
the supplied script, so the build was as clean as possible. This is  
also on top of editing the libffi `configure' to "support" OpenBSD'.  
I suspect that this might be problematic, even though it runs and  
installs okay.

Does parser-tools use the ffi much/at all?

(This duplicates some of what's in the web-server thread, I'll try  
and keep discussion here from now on, at least 'till this is resolved.)

Cheers,

-Patrick

On 27 Dec 2005, at 18:59, Matthew Flatt wrote:

> I think buffering is unlikely. But -fno-stack-protector (Evan's
> suggestion) seems a likely solution. Possibly something in
> "parser-tools" causes an internal stack overflow while compiling, and
> MzScheme's attempt to handle it is thwarted by stack protection.
> MzScheme threads should run into the same problem.
>
> So, if you configure with
>
>  env CFLAGS=-fno-stack-protector configure ...
>
> does that help?
>
> Matthew
>
> At Mon, 26 Dec 2005 22:03:39 +0000, Patrick Collison wrote:
>
>> Got this from Eli, he thinks it's probably a buffering issue:
>>
>> Begin forwarded message:
>>
>>
>>> From: Eli Barzilay <eli at barzilay.org>
>>> Date: 26 December 2005 21:23:34 GMT+00:00
>>> To: Patrick Collison <patrick at collison.ie>
>>> Subject: Re: [plt-scheme] v300 on OpenBSD
>>>
>>>
>>> On Dec 26, Patrick Collison wrote:
>>>
>>>
>>>> On 26 Dec 2005, at 19:58, Eli Barzilay wrote:
>>>>
>>>>
>>>>
>>>>> On Dec 26, Patrick Collison wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to compile v300 of mzscheme on OpenBSD-CURRENT. I ran
>>>>>> configure with --prefix=/usr/local and --disable-foreign, because
>>>>>> I don't know of any good libffi port for OpenBSD. configure and
>>>>>> make ran without any issue.
>>>>>>
>>>>>>
>>>>>
>>>>> I don't know of any problems libffi has on freebsd.
>>>>>
>>>>>
>>>>
>>>> OpenBSD isn't a supported platform according to the site.
>>>>
>>>>
>>>
>>> Ah, as usual, I always confuse the *BSDs.
>>>
>>>
>>>
>>>
>>>> I added
>>>>
>>>> i*86-*-openbsd*) TARGET=X86; TARGETDIR=x86;;
>>>>
>>>> to the libffi configure script and things seem to go okay with
>>>> it. It might be worth adding this permanently to whatever
>>>> development snapshot of libffi you're using. Still, I've heard  
>>>> there
>>>> are issues with libffi and the stack-manipulation stuff that  
>>>> OpenBSD
>>>> does, so caveat programmor.
>>>>
>>>>
>>>
>>> I'll leave it as is, until libffi changes.
>>>
>>>
>>>
>>>
>>>> The libffi change has also changed my problem (slightly):
>>>>
>>>> setup-plt:   in /usr/local/plt/collects/mzlib/private/
>>>> setup-plt: Compiling .zos used by MzLib
>>>> setup-plt:   in /usr/local/plt/collects/mzlib/
>>>> setup-plt: No more .zos to compile for MzScheme
>>>> setup-plt: Compiling .zos used by Net
>>>> setup-plt:   in /usr/local/plt/collects/net/
>>>> setup-plt:   in /usr/local/plt/collects/srfi/13/
>>>> setup-plt:   in /usr/local/plt/collects/srfi/14/
>>>> setup-plt:   in /usr/local/plt/collects/net/private/
>>>> setup-plt: Compiling .zos used by Parser-tools private-yacc
>>>> setup-plt:   in /usr/local/plt/collects/parser-tools/private-yacc/
>>>> setup-plt:   in /usr/local/plt/collects/parser-tools/private-lex/
>>>> setup-plt: Compiling .zos used by Parser-tools private-lex
>>>> setup-plt:   in /usr/local/plt/collects/parser-tools/private-lex/
>>>> setup-plt: Compiling .zos used by Parser-tools
>>>> setup-plt:   in /usr/local/plt/collects/parser-tools/
>>>> setup-plt:   in /usr/local/plt/collects/syntax/
>>>>
>>>> It seems to be getting a little bit further, now hanging on
>>>> compiling syntax. Is there any good way of diagnosing what might be
>>>> going?  Would I be right in assuming that the change in problem
>>>> points towards a problem with the compiler itself rather than the
>>>> collects?
>>>>
>>>>
>>>
>>> It's probably a buffering problem somewhere.  Matthew?
>>>
>>> --  
>>>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli
>>> Barzilay:
>>>                   http://www.barzilay.org/                 Maze is
>>> Life!
>>>
>>>
>>>
>>
>> _________________________________________________
>>   For list-related administrative tasks:
>>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>