[m-users.] Mercury on ARM

[Tycho Luyben]

I got slightly further by making sure HAVE_UCONTEXT, HAVE_SYS_CONTEXT and
HAVE_SIGINFO_T are unset. It gets a bit further then but now fails on
mercury_signal.c line 74 storage size of act isn't known.


On Tue, Jun 4, 2013 at 11:29 AM, Tycho Luyben <tycho at e-lab.nl> wrote:

> stack_t is defined in linux/signal.h while it includes signal.h ; you're
> not supposed to include linux/signal.h at all I think. By just copy/pasting
> the stack_t definition into mercury_signal.h it compiles again, but then
> drops out on missing siginfo_t. That means i'm stuck as siginfo seems to be
> huge *and* seems to be included from signal.h and yet it cannot find it.
>
> Any ideas?
>
>
>
>
> On Tue, Jun 4, 2013 at 10:41 AM, Tycho Luyben <tycho at e-lab.nl> wrote:
>
>> This appears to be a gcc bug in 4.6.3 which is the one my Ubuntu has;
>> mgnuc seems to inherit the affliction. The suggested workaround is using
>> -O1 to build; this works. Next error;
>>
>> In file included from /usr/include/ucontext.h:27:0, from
>> mercury_memory.c:64:/usr/include/arm-linux-gnueabihf/sys/ucontext.h:107:5:
>> error: unknown type name ‘stack_t’make[2]: *** [mercury_memory.o] Error 1
>>
>>
>> On Tue, Jun 4, 2013 at 10:26 AM, Tycho Luyben <tycho at e-lab.nl> wrote:
>>
>>> Make seems to succeed, but when running make install, I get this:
>>>
>>> In file included from mercury_deep_copy.c:59:0:mercury_deep_copy_body.h:
>>> In function ‘MR_deep_copy’:mercury_deep_copy_body.h:850:1: error: unable to
>>> find a register to spill in class ‘LO_REGS’mercury_deep_copy_body.h:850:1:
>>> error: this is the insn:(insn 399 402 400 41 (set (mem:SI (plus:SI
>>> (reg/f:SI 13 sp) (const_int 4 [0x4])) [0 S4 A32]) (reg/v/f:SI 945 [orig:622
>>> lower_limit ] [622])) mercury_deep_copy_body.h:345 637 {*thumb2_movsi_vfp}
>>> (nil))mercury_deep_copy_body.h:850: confused by earlier errors, bailing
>>> outPreprocessed source stored into /tmp/ccExTTfj.out file, please attach
>>> this to your bugreport.make[2]: *** [mercury_deep_copy.o] Error 1
>>>
>>>
>>> On Mon, Jun 3, 2013 at 6:37 PM, Julien Fischer <jfischer at opturion.com>wrote:
>>>
>>>>
>>>>
>>>> On Mon, 3 Jun 2013, Tycho Luyben wrote:
>>>>
>>>>
>>>>> Ah that sounds great! I should not do the github then but the zip?
>>>>>
>>>>
>>>> No, you should grab a source tarballs from our download site:
>>>> <http://dl.mercurylang.org/**index.html<http://dl.mercurylang.org/index.html>
>>>> >.
>>>>
>>>> The archives generated by github will not contain the pre-generated
>>>> C files.
>>>>
>>>> Cheers,
>>>> Julien.
>>>>
>>>>
>>>>  On Jun 3, 2013 4:53 PM, "Julien Fischer" <jfischer at opturion.com>
>>>>> wrote:
>>>>>
>>>>>       Hi again,
>>>>>
>>>>>       On Mon, 3 Jun 2013, Tycho Luyben wrote:
>>>>>
>>>>>             Is it possible to get Mercury working on ARM? I cannot
>>>>> find any
>>>>>             references to it, except from 2005 which is outdated. It
>>>>> seems because
>>>>>             of the C generation, it should be capable of compiling the
>>>>> compiler to
>>>>>             ARM from an Intel machine using a cross compiler? And then
>>>>> (if needed)
>>>>>             bootstrap with that? Any issues with that ? Did anyone do
>>>>> that?
>>>>>
>>>>>
>>>>>       I should have read the last part of that a little more carefully.
>>>>>       You don't need a Mercury compiler to bootstrap the compiler.
>>>>>       The Mercury source distribution contains pre-generated C files,
>>>>> so
>>>>>       you should be able to boostrap the compiler with just a C
>>>>> compiler.
>>>>>       (Given the appropriate build tools, e.g. make etc, you should
>>>>> just
>>>>>       be able to compile it directly on your ARM machine.)
>>>>>
>>>>>       Cheers,
>>>>>       Julien.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>>
>>>
>>> Op de inhoud van deze e-mail en op alle diensten en producten van en
>>> onder E-lab BV of E-lab BV websites en werk namen zijn onze algemene
>>> voorwaarden <http://e-lab.nl/Voorwaarden.rtf> van toepassing. Aan de
>>> inhoud van de email en bijlagen kunnen geen rechten worden ontleend.
>>>
>>> The content of this e-mail as well as all services and products of E-lab
>>> BV fall under our terms of service. No rights may be derived from the
>>> content or attachments of this message.
>>>
>>
>>
>>
>> --
>>
>>
>> Op de inhoud van deze e-mail en op alle diensten en producten van en
>> onder E-lab BV of E-lab BV websites en werk namen zijn onze algemene
>> voorwaarden <http://e-lab.nl/Voorwaarden.rtf> van toepassing. Aan de
>> inhoud van de email en bijlagen kunnen geen rechten worden ontleend.
>>
>> The content of this e-mail as well as all services and products of E-lab
>> BV fall under our terms of service. No rights may be derived from the
>> content or attachments of this message.
>>
>
>
>
> --
>
>
> Op de inhoud van deze e-mail en op alle diensten en producten van en onder
> E-lab BV of E-lab BV websites en werk namen zijn onze algemene voorwaarden<http://e-lab.nl/Voorwaarden.rtf>van toepassing. Aan de inhoud van de email en bijlagen kunnen geen rechten
> worden ontleend.
>
> The content of this e-mail as well as all services and products of E-lab
> BV fall under our terms of service. No rights may be derived from the
> content or attachments of this message.
>



-- 


Op de inhoud van deze e-mail en op alle diensten en producten van en onder
E-lab BV of E-lab BV websites en werk namen zijn onze algemene
voorwaarden<http://e-lab.nl/Voorwaarden.rtf>van toepassing. Aan de
inhoud van de email en bijlagen kunnen geen rechten
worden ontleend.

The content of this e-mail as well as all services and products of E-lab BV
fall under our terms of service. No rights may be derived from the content
or attachments of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20130604/568978d5/attachment.html>