[m-users.] Mercury on ARM

Tycho Luyben tycho at e-lab.nl
Tue Jun 4 18:41:18 AEST 2013


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20130604/631cd5f0/attachment.html>


More information about the users mailing list