[m-dev.] Upgrading Boehm GC, attempt #2
paul at bone.id.au
Wed Sep 23 12:41:38 AEST 2015
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?
case $(uname) in
cp -r ../libatomic_ops boehm_gc/libatomic_ops;
ln -s ../libatomic_ops boehm_gc/libatomic_ops;
> 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.
More information about the developers