[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