Re[9]: [Gc] gc make fail on Solaris 10 x86_64 with gcc-3.* & -m64 option

Ivan Maidanski ivmai at mail.ru
Wed Mar 28 07:32:24 PST 2012


Hi Kiyoshi,

Wed, 28 Mar 2012 21:05:09 +0900 (JST) Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp>:
> Hi, Ivan,
> 
> According to ChangeLog,
> "release" is 7.2alpha6 + changes from 2011-06-15 to 2012-03-26.

Yes, correct. This is 7.2 final release candidate (it is not released, so the version from release branch is 7.2alpha7 snapshot).

> "master" is [7.3alpha2] (development)

This is 7.3alpha2 release candidate (again, it is not released, so the version from master branch is 7.3alpha1 snapshot).
Finally, on release, "development" word would be replaced with exact date.

> The answer to your question:
> > You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
> is No. Later one.

I've asked you because there 2 libs (bdwgc and libatomic_ops) and both have 2 versions planned for releasing (more stable 7.2 ("release" branch) and a development alpha 7.3 contained in "master" branch of Git repo). In the first case (1) you had reported about bdwgc-7.2 and in (2) you had reported about libatomic_ops-7.3alpha, it looked strange to me (why not to test to libs of the same version) - so I've asked you whether there were no problems with bdwgc-7.3alpha and libatomic_ops-7.2 or you just skipped their testing for now. (I'm really sorry for giving 2x2 libs in total to test and probably confusing you.)

> 
> 
> (1) release
> (1.1) suggestion
> OK. I misunderstood as if GC_SOLARIS_THREADS and GC_THREADS were completely different.
> (1.2) test result by gcc
> Nothing to mention.
> (1.3) test result with Oracle cc
> I may try to make it conditional, but it needs time.
> And I'm re-building all the NGU software I use. Much more time I need.
> 
> (2) master
> > What about "release" branch of it (is it working or the same problem, or has not been tested)?
> As mentioned in (1), no same problem in "release" branch.

My test Solaris environment is:
Solaris 10u9 x86
gcc version 3.4.6 (x86)
cc: Sun C 5.11 SunOS_i386 2010/08/13

I tested libatomic_ops (both release and master) with gcc, cc -m32, cc -m64. It succeeded.

> I'll try gdb for "master" branch later.
> 
> By the way, it is written  "Require automake 2.61 instead of v2.64." in [7.3alpha2] ChangeLog.
> The latest version I can find is automake-1.11.3.

Thanks for spotting it - the correct is autoconf 2.61 (I'll change master ChangeLog in both bdwgc and libatomic_ops).

> Do I need another one to test "master" branch ?

I've just improved -fPIC processing in configure (libatomic_ops in both release and master branches). As your reported you succeeded with libatomic_ops-7.2 but failed wit libatomic_ops-7.3alpha, I don't thing my recent commit fixes the bug in test_atomic on your side (but nonetheless, please try).

> 
> Regards,
> 
> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> 
> 
> --- On Wed, 2012/3/28, Ivan Maidanski <ivmai at mail.ru> wrote:
> 
> > Hi Kiyoshi,
> > 
> > Tue, 27 Mar 2012 23:53:27 +0900 (JST) Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp>:
> > > Hi, Ivan,
> > > 
> > > Done without Git.
> > > 
> > > (1) release
> > 
> > To be precise, you testing "release" branch of BDWGC (gc7.2) here.
> > 
> > > (1.1) suggestion
> > > I guess it is better to set -DGC_THREADS for Solaris by default.
> > > There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
> > 
> > No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
> > (i.e., now it does not mean that thr_ interface is used)
> > 
> > > Now, it is said in doc/README.solaris2 that
> > >   SOLARIS THREADS:
> > >   The collector must be compiled with -DGC_THREADS to be thread safe.
> > >   This assumes use of the pthread_ interface.  Old style Solaris threads
> > >   are no longer supported.
> > 
> > The doc is correct.
> > 
> > > 
> > > (1.2) test result by gcc
> > > make & make check passed with all the combination of
> > > (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
> > > 
> > > (1.3) test result with Oracle cc
> > > Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
> > > make check fails (both -m32 & -m64).
> > > It might be caused by some compile switches.
> > > Error message is such as
> > > libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o   -L/usr/local/GNU/lib -ldl -lc  -xarch=sse4_1 -m32  
> > > Undefined                       first referenced
> > >  symbol                             in file
> > > GC_start_world                      .libs/alloc.o
> > > ..
> > > ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
> > > make[1]: *** [libgc.la] Error 2
> > > make[1]: Target `all-am' not remade because of errors.
> > > make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
> > > make: *** [all-recursive] Error 1
> > > make: Target `all' not remade because of errors.
> > > make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
> > 
> > Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
> > Please, if possible, investigate the problem with PTHREADS AM. 
> > 
> > > 
> > > 
> > > (2) master
> > 
> > You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
> > What about "release" branch of it (is it working or the same problem, or has not been tested)?
> > 
> > > It is confusing.
> > > make & make check passed with
> > > (gcc-3.4.3, gcc-4.6.3,  solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
> > > and (gcc-4.4.7)  (-m64),
> > > but make check fails only with (gcc-4.4.7) (-m32).
> > > 
> > > libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o  -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
> > > make[3]: Leaving directory `/tmp/ivmai-master/tests'
> > > make  check-TESTS
> > > make[3]: Entering directory `/tmp/ivmai-master/tests'
> > > /bin/bash: line 5: 16359 Segmentation Fault      ${dir}$tst
> > > FAIL: test_atomic
> > 
> > Looks like a compiler bug. We could probably make a workaround
> > Could you please run it under gdb and tell me exact source line of Seg Fault?
> > 
> > > Missing: AO_nop_acquire
> > > Missing: AO_store_acquire
> > > Missing: AO_short_store_acquire
> > > Missing: AO_char_store_acquire
> > > Missing: AO_int_store_acquire
> > > Missing: AO_nop_release
> > > Missing: AO_load_release
> > > Missing: AO_short_load_release
> > > Missing: AO_char_load_release
> > > Missing: AO_int_load_release
> > > Missing: AO_store_read
> > > Missing: AO_short_store_read
> > > Missing: AO_char_store_read
> > > Missing: AO_int_store_read
> > > Missing: AO_load_write
> > > Missing: AO_short_load_write
> > > Missing: AO_char_load_write
> > > Missing: AO_int_load_write
> > > Missing: AO_nop_release_write
> > > Missing: AO_load_release_write
> > > Missing: AO_short_load_release_write
> > > Missing: AO_char_load_release_write
> > > Missing: AO_int_load_release_write
> > > Missing: AO_nop_acquire_read
> > > Missing: AO_store_acquire_read
> > > Missing: AO_short_store_acquire_read
> > > Missing: AO_char_store_acquire_read
> > > Missing: AO_int_store_acquire_read
> > > Testing add1/sub1
> > > Succeeded
> > > 
> > > I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
> > 
> > Missing AO_XXX is normal.
> > 
> > Regards.
> > 
> > > 
> > > --- Kiyosih <yoi_no_myoujou at yahoo.co.jp>
> > > 
> > > 
> > > --- On Tue, 2012/3/27, Ivan Maidanski <ivmai at mail.ru> wrote:
> > > 
> > > > Hi Kiyoshi,
> > > > 
> > > > Tue, 27 Mar 2012 06:27:04 +0900 (JST) Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp>:
> > > > > > Everything is OK now.
> > > > > > I tested all the combination of
> > > > > > (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
> > > > > 
> > > > > wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
> > > > > correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
> > > > > 
> > > > > --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> > > > > 
> > > > 
> > > > Would also be good if you test recent BDWGC/libatomic_ops snapshots instead of gc-7.1/7.2alpha6:
> > > > 
> > > > In case you don't use Git, to test the recent "release" branch snapshot (corresponding to 7.2 final candidate):
> > > > 
> > > > wget https://github.com/ivmai/bdwgc/zipball/release
> > > > unzip release
> > > > cd ivmai-bdwgc-*/
> > > > wget https://github.com/ivmai/libatomic_ops/zipball/release
> > > > unzip release
> > > > mv ivmai-libatomic_ops-* libatomic_ops
> > > > ./configure
> > > > make check
> > > > 
> > > > The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
> > > > 
> > > > Regards.
> > > >
> > >
> 



More information about the Gc mailing list