[m-dev.] Upgrading Boehm GC, attempt #2

[Paul Bone]

On Tue, Jan 20, 2015 at 12:00:17PM +1100, Julien Fischer wrote:
> 
> Hi Paul,
> 
> I've finally had a change to look at this some more.
> 
> On Sat, 15 Nov 2014, Paul Bone wrote:
> 
> >If anyone would like to test this on Windows that would be helpful.  In
> >particular I'm not sure how the symlink from boehm_gc/libatomic_ops to
> >libatomic_ops will be handled on a windows file system.
> 
> On MSYS it results in an error, you will need to copy the libatomic_ops
> directory on Windows.   It's probably alright on Cygwin, so if the
> output of uname matches "*MINGW*" you should copy instead of link.
> 

I don't easily have a machine to test with, what's the best way to do this,
and does uname need any arguments?

I have:

    case $(uname) in
        *MINGW*)
            cp -r ../libatomic_ops boehm_gc/libatomic_ops;
            ;;
        *)  
            ln -s ../libatomic_ops boehm_gc/libatomic_ops;
            ;;
    esac

> One other problem I have noticed with the upgraded collector is that if
> your compiler and related tools are installed in C:\Program Files\...
> then various automake / libtool generated things don't handle spaces in
> directory paths correctly and the whole thing breaks.  (For MinGW64, the
> issue seems to be related to the fact that the value of LD is directory
> qualified -- and not suitably escaped -- in libatomic_ops/Makefile.
> Unfortunately, I haven't yet managed to work out what is actually
> filling this value in.)  I'll retry MinGW64 with the development tools
> installed in a directory without spaces.

You might need to test and commit a patch to the
https://github.com/Mercury-Language/libatomic_ops repository, in the Mercury customisations branch.


-- 
Paul Bone