<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 1, 2014 at 5:24 PM, Julien Fischer <span dir="ltr"><<a href="mailto:jfischer@opturion.com" target="_blank">jfischer@opturion.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On Tue, 1 Jul 2014, Julien Fischer wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Fri, 27 Jun 2014, Paul Bone wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jun 27, 2014 at 05:16:09PM +1000, Peter Wang wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, 27 Jun 2014 16:18:26 +1000, Paul Bone <<a href="mailto:paul@bone.id.au" target="_blank">paul@bone.id.au</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jun 27, 2014 at 03:33:46PM +1000, Peter Wang wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, 27 Jun 2014 11:27:40 +1000, Paul Bone <<a href="mailto:paul@bone.id.au" target="_blank">paul@bone.id.au</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Of course my change here is only a workaround. The real fix is patching<br>
glibc.<br>
</blockquote>
<br>
Well, I prefer you do not commit it. If it's just to continue your<br>
development, I think you could rebuild glibc with --disable-lock-elision<br>
and LD_PRELOAD libpthread?<br>
</blockquote>
<br>
What if other users have the same error? This affects all<br>
asm_fast.gc.par.stseg grades. I can't resonably ask other users, including<br>
yourself, either to buy a processor without this extension or to always use<br>
an older version of glibc.<br>
</blockquote>
<br>
I guess I'm expecting that it to be fixed one way or another, in due<br>
time, if more popular Boehm GC-using software is affected.<br>
</blockquote>
<br>
I've no intention of waiting the unspecified amount of time it will take for<br>
1) the bug to be acknowledged*<br>
2) the bug to be patched<br>
3) the patches to trickle down to actually be installed on people's<br>
systems.<br>
<br>
*: I don't think that the developers of glibc and/or Andi will actually be<br>
any worse than any other developer in this regard. I'm not making a<br>
personal attack I'm just cynical.<br>
</blockquote>
<br>
This change has broken compilation of the collector on OS X (and<br>
probably other systems) (in hlc.par.gc)<br>
<br>
cp gc.a libpar_gc.a<br>
clang -multiply_defined suppress -dynamiclib -single_module -install_name \<br>
/Users/jfischer/Mercury-<u></u>Install/mercury-14.01.1-beta-<u></u>2014-07-01/bin/lib/mercury/<u></u>lib/libpar_gc.dylib \<br>
-o libpar_gc.dylib alloc.o reclaim.o allchblk.o misc.o mach_dep.o os_dep.o mark_rts.o headers.o mark.o obj_map.o blacklst.o finalize.o new_hblk.o dbg_mlc.o malloc.o stubborn.o checksums.o pthread_support.o pthread_stop_world.o darwin_stop_world.o typd_mlc.o ptr_chck.o mallocx.o gcj_mlc.o specific.o gc_dlopen.o backgraph.o win32_threads.o pthread_start.o thread_local_alloc.o dyn_load.o -lc Undefined symbols for architecture x86_64:<br>
"_GC_setup_mark_lock", referenced from:<br>
_GC_init in misc.o<br>
ld: symbol(s) not found for architecture x86_64<br>
clang: error: linker command failed with exit code 1 (use -v to see invocation)<br>
make[2]: *** [libpar_gc.dylib] Error 1<br>
make[1]: *** [submake] Error 2<br>
To clean up from failed install, remove /Users/jfischer/Mercury-<u></u>Workspaces/mercury.local-4/<u></u>stage2/install_grade_dir.hlc.<u></u>par.gc<br>
make: *** [install_grades] Error 1<br>
<br>
Please do not modify the Boehm GC unless you have first tested your<br>
changes on multiple OSs, not just Linux. The code in the collector<br>
related to threads is far too delicate to just assume that it is going<br>
to work.</blockquote></div></div></blockquote><div><br></div><div>Actually, the problem here is that GC_setup_mark lock is only defined if PARALLEL_MARK is defined, but the call to it in misc.c</div><div>does not check that for that.</div>
<div><br></div><div>Cheers,</div><div>Julien. </div></div><br></div></div>