Re: [Gc]: libatomic_ops: time to alpha release?
ivmai at mail.ru
Fri Oct 16 00:35:17 PDT 2009
"Boehm, Hans" <hans.boehm at hp.com> wrote:
> > From: Petter Urkedal
> > Sent: Thursday, October 15, 2009 3:35 PM
> > To: gc at napali.hpl.hp.com
> > Subject: Re: [Gc]: libatomic_ops: time to alpha release?
> > On 2009-10-15, Ivan Maidanski wrote:
> > > PS. What's about
> > https://thread.gmane.org/gmane.comp.programming.garbage-collect
> > ion.boehmgc/3435 (it seems there are problems in the scripts
> > for OpenBSD and Solaris/shared)?
> > # 1 (OpenBSD). We're missing a case for the thread configuration.
> > Someone could try the attached patch, but I don't know if
> > it's the right way to do it. I basically copied the FreeBSD case.
> The only thing I found was
> My guess would be that this will require a bit more work than Petter's patch. Bu I may be wrong. In any case, this isn't a showstopper for a release; I don't think it has ever worked. If we can't get a volunteer interested in OpenBSD to fix this, could we run the test without threads for now?
Nonetheless, I've applied the patch.
> > # 3 (Solaris). The dynamic loader does not find a GCC
> > support library. This is probably as issue with the
> > installation and runtime environment on the machine, rather
> > than with GC. It may be fixable with a line in ld.so.conf,
> > or by setting LD_LIBRARY_PATH, or with a Solaris-equivalent.
> > Still I believe the location of libgcc_s should have been
> > hard-coded in the compiler. Is the compiler moved, or is the
> > -R option causing trouble?
> Unfortunately, this is also a bit reminiscent of past experiences. I have managed to test on Solaris 10 / SPARC, but it has also always needed weird hand-tweaking on my machine due to compiler misinstallation issues. Since it seems to work with disable-shared, I also don't think this is a show-stopper, so it would be nice to fix the test.
> Did we resolve the MacOS issue? It looks like a recent change could have affected this. Maybe it was just slightly out of date? Otherwise the output of nm | grep GC_fail_count on the two files might be interesting. The version in allchblk.c is declared extern, so I also don't see the problem.
This recent change was made on Oct 1, and it's unclear whether the buildbot automatically fetches the latest CVS or the source is manually supplied. i don't think it' a bug in the compiler but I've prepared the patch to make GC_fail_count declaration in the old style (it's a bit ugly and I don't want to apply it unless it really solves the problem). The patch is attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 821 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20091016/db28f265/ivmai179.obj
More information about the Gc