<div>On 2/1/06, Julien Fischer <<a href="mailto:juliensf@cs.mu.oz.au" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">juliensf@cs.mu.oz.au </a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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?</blockquote><div> 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 <a href="http://sourceware.org/pthreads-win32/">http://sourceware.org/pthreads-win32/ </a>), 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 </div></div>