[Gc] libatomic_ops: time to alpha release?

Is there a reason to put together an alpha release for libatomic_ops before putting one together for the gc?

I seem to be able to build everything again, sort of, after a

rm /usr/share/aclocal/librapi2.m4

(actually, I did back it up somewhere)

It seems to be the case that if some ancient package drops something into /usr/share/aclocal and then doesn't get updated, autotools break?

More importantly, it also seems I still need to move libtool.m4 out of the way to reconfigure, which I think is unacceptable. It seems like Petter's patch from http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3379
fixes that. Is there a reason not to commit it? If I understand correctly, this forces us to permanently remove libtool.m4, create an m4 subdirectory, and presumably check the generated contents of that into the tree, so that libtool is again part of the tree. That's a minor annoyance, but seems OK, since it seems to be the new improved way of doing things. Does this sound right?

Hans

-----Original Message-----
Sent: Wednesday, October 14, 2009 4:38 AM
Subject: [Gc] libatomic_ops: time to alpha release?
Hi!
It seems the parties agreed on the building scripts issues...
Is it time to make an alpha tarball for libatomic_ops? If
yes, I could change the version info in the CVS and prepare
the tarball.
Bye.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

Ivan Maidanski

2009-10-15 06:36:17 UTC

Hi!

Post by Boehm, Hans
Is there a reason to put together an alpha release for libatomic_ops before putting one together for the gc?

Not sure for alpha, but someone on the ML asks for a newer tarball in http://www.hpl.hp.com/research/linux/atomic_ops/download.php4

At least, I think, the atomic_ops version info should be updated in the coming GC tarball.

Post by Boehm, Hans
I seem to be able to build everything again, sort of, after a
rm /usr/share/aclocal/librapi2.m4
(actually, I did back it up somewhere)
It seems to be the case that if some ancient package drops something into /usr/share/aclocal and then doesn't get updated, autotools break?
More importantly, it also seems I still need to move libtool.m4 out of the way to reconfigure, which I think is unacceptable. It seems like Petter's patch from http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3379
fixes that. Is there a reason not to commit it? If I understand correctly, this forces us to permanently remove libtool.m4, create an m4 subdirectory, and presumably check the generated contents of that into the tree, so that libtool is again part of the tree. That's a minor annoyance, but seems OK, since it seems to be the new improved way of doing things. Does this sound right?

Ok. Checked in the first patch and regenerated (adding m4 folder). Added m4 folder to the repo. (autoreconf says "the contents of m4/lt~obsolete.m4 should be added to aclocal.m4" - I've ignored it, is it ok?)

Post by Boehm, Hans
Hans

Subject: [Gc] libatomic_ops: time to alpha release?
Hi!
It seems the parties agreed on the building scripts issues...
Is it time to make an alpha tarball for libatomic_ops? If
yes, I could change the version info in the CVS and prepare
the tarball.

Bye.

Petter Urkedal

2009-10-15 16:55:51 UTC

Post by Ivan Maidanski
Ok. Checked in the first patch and regenerated (adding m4 folder). Added m4 folder to the repo. (autoreconf says "the contents of m4/lt~obsolete.m4 should be added to aclocal.m4" - I've ignored it, is it ok?)

That should be the job of aclocal, which is invoked by autoreconf. If
the output comes from the libtoolize sub-command, it may be that it
thinks you're running that command separately, in which case it's
harmless, but you may need to look for m4/lt~obsolete.m4 in aclocal and
compare to be really sure. On my end it does not complain, and aclocal
(1.10.2) has inserted an include statement
"m4_include([m4/lt~obsolete.m4])".

Ivan Maidanski

2009-10-15 17:07:32 UTC

Hi!

That should be the job of aclocal, which is invoked by autoreconf. If
the output comes from the libtoolize sub-command, it may be that it ...

Yes.

Post by Petter Urkedal
... thinks you're running that command separately, in which case it's
harmless, but you may need to look for m4/lt~obsolete.m4 in aclocal and
compare to be really sure. On my end it does not complain, and aclocal
(1.10.2) has inserted an include statement
"m4_include([m4/lt~obsolete.m4])".

Yes, inserted this include. (you can see it in the repo while it's there.)

Bye.

Boehm, Hans

2009-10-15 17:12:36 UTC

From: Ivan Maidanski
Sent: Wednesday, October 14, 2009 11:36 PM
Hi!

Post by Boehm, Hans
Is there a reason to put together an alpha release for

libatomic_ops before putting one together for the gc?
Not sure for alpha, but someone on the ML asks for a newer
tarball in
http://www.hpl.hp.com/research/linux/atomic_ops/download.php4
At least, I think, the atomic_ops version info should be
updated in the coming GC tarball.

I agree that a libatomic_ops tar-ball would be nice. But I think we should get the whole GC tar-ball out first, so that we make sure that all the pieces fit. At that point, it should be pretty trivial to just extract the libatomic_ops piece.

I completely agree that the version info should be updated, presumably to match the GC version.

Thanks again for all your work on this.

Hans

Petter Urkedal

2009-10-15 16:38:44 UTC

Yes, that can happen. aclocal needs to scan all the files because it
does not know which file contains the macro it's looking for. It would
be better if they could enforce the convention that each file contains a
macro of exactly the same name in uppercase (or by extension a set of
macros which starts with the same prefix). Then aclocal could pick it
up directly.

Post by Boehm, Hans
More importantly, it also seems I still need to move libtool.m4 out of the way to reconfigure, which I think is unacceptable. It seems like Petter's patch from http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3379
fixes that. Is there a reason not to commit it? If I understand correctly, this forces us to permanently remove libtool.m4, create an m4 subdirectory, and presumably check the generated contents of that into the tree, so that libtool is again part of the tree. That's a minor annoyance, but seems OK, since it seems to be the new improved way of doing things. Does this sound right?

I don't think we need to commit the files under m4 to the repo, since
they are not used by configure. The only benefit I can see of
committing them is for someone who has all Autotools except Libtool.
So, to minimise the number of generated files in the repo, my suggestion
is to cvsignore them instead.

Boehm, Hans

2009-10-15 17:20:37 UTC

From: Petter Urkedal
Sent: Thursday, October 15, 2009 9:39 AM
I don't think we need to commit the files under m4 to the
repo, since they are not used by configure. The only benefit
I can see of committing them is for someone who has all
Autotools except Libtool.
So, to minimise the number of generated files in the repo, my
suggestion is to cvsignore them instead.

It sounds like I misunderstood something here. These files are used only by autoconf to generate configure? They are not needed by libtool itself in order to drive the compilation? If so, I agree that it seems better not to check them in, though I think we do need the empty directory in the repository and the tar-ball? Otherwise the reconfiguration process seemed to fail.

Thanks for the explanation.

Hans

Petter Urkedal

2009-10-15 17:38:08 UTC

That's right. The contents of the required m4 files, including
acinclude.m4, gets copied into aclocal.m4, except it seems than those
which reside in the m4 dir may be included. I hadn't notice the
includes before. Then Autoconf uses aclocal.m4 when to instantiate the
macros from configure.ac into configure. On the other hand, the
build-aux files (compile, config.sub, config.guess, ...) are required.
Note also that when leaving out the other m4 files, it does not make
sense to keep aclocal.m4 in the repository either due to the includes.

Boehm, Hans

2009-10-15 17:57:16 UTC

From: Petter Urkedal
Sent: Thursday, October 15, 2009 10:38 AM
Subject: Re: [Gc] libatomic_ops: time to alpha release?

From: Petter Urkedal
Sent: Thursday, October 15, 2009 9:39 AM
I don't think we need to commit the files under m4 to the repo,
since they are not used by configure. The only benefit I

can see of

committing them is for someone who has all Autotools

except Libtool.

So, to minimise the number of generated files in the repo, my
suggestion is to cvsignore them instead.

It sounds like I misunderstood something here. These files

are used only by autoconf to generate configure? They are
not needed by libtool itself in order to drive the
compilation? If so, I agree that it seems better not to
check them in, though I think we do need the empty directory
in the repository and the tar-ball? Otherwise the
reconfiguration process seemed to fail.
That's right. The contents of the required m4 files,
including acinclude.m4, gets copied into aclocal.m4, except
it seems than those which reside in the m4 dir may be
included. I hadn't notice the includes before. Then
Autoconf uses aclocal.m4 when to instantiate the macros from
configure.ac into configure. On the other hand, the
build-aux files (compile, config.sub, config.guess, ...) are required.
Note also that when leaving out the other m4 files, it does
not make sense to keep aclocal.m4 in the repository either
due to the includes.
_______________________________________________

That sounds like a plan.

I don't see the warning that Ivan complained about either, so I suspect that with these changes, and the libatomic_ops version changes, we should be largely OK.

Hans

Petter Urkedal

2009-10-15 17:59:02 UTC

Post by Boehm, Hans
It sounds like I misunderstood something here. These files are used only by autoconf to generate configure? They are not needed by libtool itself in order to drive the compilation? If so, I agree that it seems better not to check them in, though I think we do need the empty directory in the repository and the tar-ball? Otherwise the reconfiguration process seemed to fail.

I forgot to comment on the directory. Yes, it seems it needs to be
present. I can remember if CVS supports checking in empty directories,
but it might be nice in my opinion to move "acinclude.m4" to
"m4/gc_set_version.m4" just to tidy the toplevel directory. Otherwise,
one can create an dummy entry like ".dir".

Ivan Maidanski

2009-10-15 18:49:21 UTC

Hi!

Ok. Finally, what should I do in details?

Bye.

Petter Urkedal

2009-10-15 18:57:25 UTC

Post by Ivan Maidanski
Hi!

Ok. Finally, what should I do in details?

Just move the file in the repo, or in practice recommit since its CVS.
That's it, since aclocal already gets the "-I m4" argument.

Ivan Maidanski

2009-10-15 19:51:58 UTC

Hi!

Post by Ivan Maidanski
Hi!

Ok. Finally, what should I do in details?

Just move the file in the repo, or in practice recommit since its CVS.
That's it, since aclocal already gets the "-I m4" argument.

Did this way (and regenerated). The last line of autoreconf printing:
libtoolize: You should add the contents of `m4/lt~obsolete.m4' to `aclocal.m4'.

The rest seems to work ok.

PS. What's about http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3435 (it seems there are problems in the scripts for OpenBSD and Solaris/shared)?

Bye.

Petter Urkedal

2009-10-15 22:35:25 UTC

Post by Ivan Maidanski
PS. What's about http://thread.gmane.org/gmane.comp.programming.garbage-collection.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.

# 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?

Boehm, Hans

2009-10-15 23:18:01 UTC

From: Petter Urkedal
Sent: Thursday, October 15, 2009 3:35 PM
Subject: Re: [Gc]: libatomic_ops: time to alpha release?

Post by Ivan Maidanski
PS. What's about

http://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

http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2008-February/002127.html

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?

# 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.

Hans

Ivan Maidanski

2009-10-16 07:35:17 UTC

Hi!

From: Petter Urkedal
Sent: Thursday, October 15, 2009 3:35 PM
Subject: Re: [Gc]: libatomic_ops: time to alpha release?

Post by Ivan Maidanski
PS. What's about

The only thing I found was
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2008-February/002127.html
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.

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.
Hans

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.

Bye.

Andreas Tobler

2009-10-16 07:55:15 UTC

Hi!

Post by Boehm, Hans
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.
Hans

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.

For the record. I mentioned this failure on the 1st of October to you
Ivan with included patch. Ivan immediately fixed the issue and I resynced.

Here I run MacOS-X 10.5.8 on a core 2 duo.

Just synced again and both, the 32-bit and the 64-bit target compile and
test run fine.

Andreas

Ivan Maidanski

2009-10-18 18:37:40 UTC

Hi!

Post by Andreas Tobler
Hi!

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.

For the record. I mentioned this failure on the 1st of October to you
Ivan with included patch. Ivan immediately fixed the issue and I resynced.
Here I run MacOS-X 10.5.8 on a core 2 duo.
Just synced again and both, the 32-bit and the 64-bit target compile and
test run fine.
Andreas

Andreas, could you re-sync and make check again (either for 32 or 64-bit target)? (I have been manipulating with "extern" a bit today.)

Bye.

Andreas Tobler

2009-10-18 19:07:28 UTC

Hi Ivan,

Post by Ivan Maidanski
Andreas, could you re-sync and make check again (either for 32 or
64-bit target)? (I have been manipulating with "extern" a bit today.)

Everthing fine here, i386/i686/x86_64-apple-darwin9.8.0.

I have some compiler warnings with i686 and x86_64 which I have to
investigate. But these were here for a longer time.

The tests run fine on each config.

Thanks,
Andreas

Ivan Maidanski

2009-10-18 19:19:49 UTC

Hi!

Post by Andreas Tobler
Hi Ivan,

Post by Ivan Maidanski
Andreas, could you re-sync and make check again (either for 32 or
64-bit target)? (I have been manipulating with "extern" a bit today.)

Everthing fine here, i386/i686/x86_64-apple-darwin9.8.0.

i386/i686 - I guess you mean the same thing (or did You really supply -march=i386? ;) ).

Post by Andreas Tobler
I have some compiler warnings with i686 and x86_64 which I have to
investigate. But these were here for a longer time.

Would be nice if you copy them here.

Post by Andreas Tobler
The tests run fine on each config.
Thanks,
Andreas

Bye.

Andreas Tobler

2009-10-18 19:59:47 UTC

Hi Ivan,

Post by Andreas Tobler

Post by Ivan Maidanski
Andreas, could you re-sync and make check again (either for 32 or
64-bit target)? (I have been manipulating with "extern" a bit today.)

Everthing fine here, i386/i686/x86_64-apple-darwin9.8.0.

i386/i686 - I guess you mean the same thing (or did You really supply -march=i386? ;) ).

Well, the box I run this stuff on is a MacBook Pro, as already mentioned
it has a core2duo which can do both, 32-bit and 64-bit stuff.

A plain bdwgc/configure gives me a i386-apple-darwin9* as the running arch.
But for the 64-bit tests I have to set CC to "gcc -m64" and pass the
configure the host/target/build tripplet with x86_64-apple-darwin9*
The same I can do for i686, but w/o CC setting to "gcc -m64".

I did this but I added some flags you recently told me to do:

--enable-gc-assertions --enable-parallel-mark --enable-munmap=6

For the plain i386 config I did not pass these options.

In the first moment I thought it was the architecture which causes the
warnings below, but it is the set of flags I pass to the configure script.

Post by Andreas Tobler
I have some compiler warnings with i686 and x86_64 which I have to
investigate. But these were here for a longer time.

Would be nice if you copy them here.

Not needed ;)
The warning is simple, redefinition of USE_MMAP. One time in
include/private/gcconfig.h and the other time via include/private/config.h

Attached a patch which silences these warnings on darwin, tested on
i386/i686/x86_64-apple-darwin9*, I expect, that this is also necessary
for ppc and iphone darwin. But not tested ;)

Thanks,
Andreas

Ivan Maidanski

2009-10-19 04:50:27 UTC

Hi!

Post by Andreas Tobler
...