[m-dev.] IL, Mono and Portable .NET

Jonathan Morgan jonmmorgan at gmail.com
Fri Feb 3 16:34:19 AEDT 2006


On 2/1/06, Julien Fischer <juliensf at cs.mu.oz.au> wrote:
>
>
> On Wed, 1 Feb 2006, Jonathan Morgan wrote:
> > So I would assume, but as you can see from mercury-users,  I can't even
> get
> > mercury-compiler-0.12.2 even starting to compile on Cygwin, and the IL
> grade
> > refuses to build under MSYS/MinGW.
>
> I'm having a look at the cygwin thing now.  Can you be more specific how
> the
> il grade refuses to build under MSYS/MinGW?


You can see the (relevant) output of make install.  It would seem that there
is (somewhere) a problem with paths, as it is trying to deal with IL files
in c:/msys, which is msys' root directory, rather than somewhere in the
directory structure where it is building it (it should be in
c:/msys/installs/mercury- compiler-0.12.2/runtime).

In order to avoid problems with the path, I followed the instructions in
README.MinGW and configured with ./configure --prefix c:/msys/local/mercury-
0.12.2, but obviously this won't affect the build process.

make[2]: Entering directory `/installs/mercury-compiler-0.12.2
/tmp_dir/boehm_gc'
make[2]: Nothing to be done for `install_lib'.
make[2]: Leaving directory `/installs/mercury-compiler-0.12.2/tmp_dir/boehm_gc'
make[2]: Entering directory `/installs/mercury-compiler-0.12.2
/tmp_dir/runtime'
ilasm      /dll /quiet /OUT=mercury_il.dll mercury_il.il


Microsoft (R) .NET Framework IL Assembler.  Version 1.1.4322.573

Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

Assembling 'C:/msys/dll.IL' , no listing file, to EXE --> 'C:/msys/dll.EXE'

Could not open C:/msys/dll.IL



Assembling 'C:/msys/quiet.IL' , no listing file, to EXE -->
'C:/msys/dll.EXE'

Could not open C:/msys/quiet.IL



Assembling 'C:/msys/OUT=mercury_il.dll' , no listing file, to EXE -->
'C:/msys/dll.EXE'

Could not open C:/msys/OUT=mercury_il.dll



Assembling 'mercury_il.il' , no listing file, to EXE --> 'C:/msys/dll.EXE'

Source file is ANSI



Assembled method TempHack::get_ftn_ptr_heap_pointer_compare

Assembled method TempHack::get_ftn_ptr_heap_pointer_unify

Assembled method TempHack::get_ftn_ptr_typeclass_info_compare

Assembled method TempHack::get_ftn_ptr_typeclass_info_unify

Assembled method TempHack::get_ftn_ptr_base_typeclass_info_compare

Assembled method TempHack::get_ftn_ptr_base_typeclass_info_unify

Assembled method TempHack::get_ftn_ptr_type_info_compare

Assembled method TempHack::get_ftn_ptr_type_info_unify

Assembled method TempHack::get_ftn_ptr_type_ctor_info_compare

Assembled method TempHack::get_ftn_ptr_type_ctor_info_unify

Assembled method TempHack::get_ftn_ptr_type_ctor_desc_compare

Assembled method TempHack::get_ftn_ptr_type_ctor_desc_unify

Assembled method TempHack::get_ftn_ptr_tuple_compare

Assembled method TempHack::get_ftn_ptr_tuple_unify

Assembled method TempHack::get_ftn_ptr_pred_compare

Assembled method TempHack::get_ftn_ptr_pred_unify

Assembled method TempHack::get_ftn_ptr_func_compare

Assembled method TempHack::get_ftn_ptr_func_unify

Assembled method TempHack::get_ftn_ptr_float_compare

Assembled method TempHack::get_ftn_ptr_float_unify

Assembled method TempHack::get_ftn_ptr_void_compare

Assembled method TempHack::get_ftn_ptr_void_unify

Assembled method TempHack::get_ftn_ptr_c_pointer_compare

Assembled method TempHack::get_ftn_ptr_c_pointer_unify

Assembled method TempHack::get_ftn_ptr_ref_compare

Assembled method TempHack::get_ftn_ptr_ref_unify

Assembled method TempHack::get_ftn_ptr_string_compare

Assembled method TempHack::get_ftn_ptr_string_unify

Assembled method TempHack::get_ftn_ptr_character_compare

Assembled method TempHack::get_ftn_ptr_character_unify

Assembled method TempHack::get_ftn_ptr_int_compare

Assembled method TempHack::get_ftn_ptr_int_unify

Assembled method TempHack::get_ftn_ptr_array_compare

Assembled method TempHack::get_ftn_ptr_array_unify

Assembled method TempHack::get_ftn_ptr_type_desc_compare

Assembled method TempHack::get_ftn_ptr_type_desc_unify

Assembled method GenericCall::semidet_call_3

Assembled method GenericCall::semidet_call_4

Assembled method GenericCall::semidet_call_5

Assembled method GenericCall::semidet_call_6

Assembled method GenericCall::semidet_call_7

Assembled method GenericCall::semidet_call_8

Assembled method GenericCall::result_call_4

Assembled method GenericCall::result_call_5

Assembled method GenericCall::result_call_6

Assembled method GenericCall::result_call_7

Assembled method GenericCall::result_call_8

Assembled method GenericCall::result_call_9

Assembled method Init::.cctor

Assembled method Init::responsible_for_initialising_runtime

Assembled method Init::init_runtime



***** FAILURE *****

make[2]: *** [mercury_il.dll] Error 1
make[2]: Leaving directory `/installs/mercury-compiler-0.12.2
/tmp_dir/runtime'
To clean up from failed install, remove tmp_dir
make[1]: *** [install_grades] Error 1
make[1]: Leaving directory `/installs/mercury-compiler-0.12.2'

Also, I have tried building hlc.par.gc with MinGW/MSYS and pthreads-w32
2.7.0 (see http://sourceware.org/pthreads-win32/), and got the following
errors:

/installs/mercury-compiler-0.12.2/tmp_dir/scripts/mgnuc --grade hlc.par.gc
--no-mercury-stdlib-dir --c-debug --no-ansi   --  -I/installs/mercury-
compiler-0.12.2/tmp_dir/boehm_gc
-I/installs/mercury-compiler-0.12.2/tmp_dir/boehm_gc/include
-I/installs/mercury-compiler-0.12.2/tmp_dir/mps_gc/code
-DMERCURY_BOOTSTRAP_H -DMERCURY_CONF_BOOTSTRAP_H     -c mercury_context.c -o
mercury_context.o
mercury_context.c: In function `MR_init_context':

mercury_context.c:98: conversion to non-scalar type requested

make[2]: *** [mercury_context.o] Error 1
make[2]: Leaving directory `/installs/mercury-compiler-0.12.2
/tmp_dir/runtime'
To clean up from failed install, remove tmp_dir
make[1]: *** [install_grades] Error 1
make[1]: Leaving directory `/installs/mercury-compiler-0.12.2'

Line 98 of mercury_context.c is the following one:

#ifdef    MR_THREAD_SAFE
    c->MR_ctxt_owner_thread = (MercuryThread) NULL;
#endif

It seems that the MercuryThread type becomes the pthread_t type, which in
pthreads-w32 is a structure - whether that has anything to do with it or
not, I don't know, but I think it likely.

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20060203/2f17a10c/attachment.html>


More information about the developers mailing list