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

Kiyoshi KANAZAWA yoi_no_myoujou at yahoo.co.jp
Fri Mar 30 03:49:13 PST 2012


Hi, Ivan,

I don't have the problem with libatomic_ops compiled by gcc-4.4.7 -m32.
Everything cleared on "release" branch.


I checked "master" release without installing gc-7.1.
Make & make check passed (All 14 tests passed) with gcc:
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
under the condition that "-R($TOPDIR)/.libs" specifyed.
Without "-R($TOPDIR)/.libs", make check failed:
  make  check-TESTS
  make[2]: Entering directory `/tmp/ivmai-bdwgc-cfca1cc'
  ld.so.1: cordtest: fatal: libgc.so.1: open failed: No such file or directory
  /bin/bash: line 5:  1941 Killed                  ${dir}$tst
  FAIL: cordtest
(many other tests failed with the same message.)

With Oracle cc, make check failed event if I specifyed "-R($TOPDIR)/.libs":
  make  check-TESTS
  make[2]: Entering directory `/tmp/ivmai-bdwgc-cfca1cc'
  ld.so.1: cordtest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/: symbol GC_init: referenced symbol not found
  /bin/bash: line 5: 19437 Killed                  ${dir}$tst
  FAIL: cordtest
(many other tests failed with the same message.)
May be it is because solarisstudio12.3 & solstudio12.2, updated version of SUNWspro, has its own libgc.so.
With LD_LIBRARY_PATH who has no path to solarisstudio12.3 & solstudio12.2, make & make check passed.
(I remove these pathes when I install softwares with gcc.)
But it is not good for (Sun|Oracle) cc users.

I hope "make check" will link libgc.so in its own directory without -R, and independent of LD_LIBRARY_PATH.
This is the only thing I want to mention about "master" branch.


--- On Fri, 2012/3/30, Ivan Maidanski <ivmai at mail.ru> wrote:

> Hi Kiyoshi,
> 
> Thu, 29 Mar 2012 23:53:04 +0900 (JST) Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp>:
> > Hi, Ivan,
> > 
> > Yes, you are right.
> > -D__PIC__=1 is defined and -fPIC is not specified.
> > I noticed my error.
> 
> So, just to confirm, now you don't have the problem with libatomic_ops compiled by gcc-4.4.7 -m32, correct?
> 
> > I'm afraid I got bdwgc-master but unzipped bdwgc-release.
> > 
> > Downloaded the latest one again as follows:
> > % wget --no-check-certificate https://github.com/ivmai/bdwgc/zipball/master
> > % unzip master
> > % cd ivmai-bdwgc-cfca1cc
> > % wget --no-check-certificate https://github.com/ivmai/libatomic_ops/zipball/master
> > % unzip master
> > % mv ivmai-libatomic_ops-531888d libatomic_ops
> > % ./autogen.sh
> > 
> > Made a tar-ball of this directory once, and took out files from the tar-ball for every test.
> > configured such as
> > ./configure --enable-threads=posix CC=cc -m32.
> > 
> > make & make check pass with -m64, but make check fails with -m32,
> > independent of (cc, gcc-VERSION).
> > 
> > Results of make check is:
> > PASS: cordtest
> > ld.so.1: gctest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/gctest: symbol GC_get_version: referenced symbol not found
> > /bin/bash: line 5: 23352 Killed                  ${dir}$tst
> > FAIL: gctest
> > ld.so.1: leaktest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/leaktest: symbol GC_set_find_leak: referenced symbol not found
> > /bin/bash: line 5: 23370 Killed                  ${dir}$tst
> > FAIL: leaktest
> > ...
> > ====================================
> > 9 of 14 tests failed
> > Please report to gc at linux.hpl.hp.com
> > ====================================
> 
> It looks like you have already installed old gc7.1 (m32) shared library on your host and trying gc7.2 (or gc7.3) tests (linked against shared libgc.so) - of course they will fail because they use some symbols not offered by old libgc.so (v7.1).
> 
> Please do "make uninstall" (or make install) before make check.
> 
> Regards.
> 
> > 
> > Regards,
> > 
> > --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> > 
> > --- On Thu, 2012/3/29, Ivan Maidanski <ivmai at mail.ru> wrote:
> > 
> > > Hi Kiyoshi,
> > > 
> > > Thu, 29 Mar 2012 20:37:41 +0900 (JST) Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp>:
> > > > Hi, Ivan,
> > > > 
> > > > About libatomic_ops/master with gcc-4.4.7 -m32:
> > > > Coredump seems to be caused by AO_compare_double_and_swap_double_full.
> > > > I used Sun dbx (gdb does not accept "ELF 32-bit" format produced by /usr/ccs/bin/ld).
> > > > % dbx test_atomic
> > > > For information about new features see `help changes'
> > > > To remove this message, put `dbxenv suppress_startup_message 7.9' in your .dbxrc
> > > > Reading test_atomic
> > > > Reading ld.so.1
> > > > Reading libpthread.so.1
> > > > Reading libc.so.1
> > > > (dbx) run                                                                    
> > > > Running: test_atomic 
> > > > (process id 29080)
> > > > t at 1 (l at 1) signal SEGV (no mapping at the fault address) in AO_compare_double_and_swap_double_full at line 193 in file "x86.h"
> > > >   193     __asm__ __volatile__("xchg %%ebx,%6;" /* swap GOT ptr and new_val1 */
> > > 
> > > This means __PIC__ is defined. Please check whether test_atomic is compiled and linked with -fPIC option. (it should present). If not, check you're testing the most recent snapshot (i.e., configure.ac contains "AC_MSG_CHECKING(whether gcc -fPIC causes __PIC__ definition)" ).
> > > Please check this.
> > > 
> > > > 
> > > > By the way, "master" branch does not require "--enable-threads=posix", right ?
> > > > ./configure says "configure: WARNING: unrecognized options: --enable-threads"
> > > 
> > > "master" branch of which library?
> > > I guess you mean libatomic_ops library - it does not have such option (regardless of the branch you use - master or release) because it is meaningless without threads support.
> > > 
> > > > 
> > > > 
> > > > I checked "release" branch with "./configure --enable-threads=posix" again.
> > > > (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3, solarisstudio12.3, solstudio12.2), (-m32, -m64).
> > > > All the combination passed make & make check.
> > > 
> > > Yes, I understand that you have not problem with bdwgc/release but it would be good if you report me whether "master" branch of bdwgc is ok or not.
> > > 
> > > Let me list the commands for testing latest snapshot of "master" branch of BDWGC:
> > > 
> > > wget https://github.com/ivmai/bdwgc/zipball/master
> > > unzip master
> > > cd ivmai-bdwgc-*
> > > wget https://github.com/ivmai/libatomic_ops/zipball/master
> > > unzip master
> > > mv ivmai-libatomic_ops-* libatomic_ops
> > > ./autogen.sh
> > > ./configure --enable-threads=posix
> > > make check
> > > 
> > > > 
> > > > Regards,
> > > > 
> > > > --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> > > > 
> > > > 
> > > > 
> > > > --- On Thu, 2012/3/29, Ivan Maidanski <ivmai at mail.ru> wrote:
> > > > 
> > > > > Hi Kiyoshi,
> > > > > 
> > > > > I've finally understand why do you fail with bdwgc if using Sun CC.
> > > > > 
> > > > > Here is how to invoke configure:
> > > > > CC=cc CFLAGS="-xO3 ... -DGC_THREADS" ./configure
> > > > > ...
> > > > > checking for thread model used by GCC... no
> > > > > ...
> > > > > linking without pthread_support.o -> linkage error
> > > > > 
> > > > > This is wrong, the correct way is:
> > > > > CC=cc CFLAGS="-xO3 ..." ./configure --enable-threads=posix
> > > > > 
> > > > > This is caused by the fact, that configure auto-detects threading model by parsing compiler output expecting the compiler is GCC, if it fails it assumes no MT support.
> > > > > 
> > > > > I've updated README.solaris2: https://github.com/ivmai/bdwgc/commit/cfca1cca99c757ac33c114ad3e9dd77ef430c0fa
> > > > > 
> > > > > PS. Still you have undiagnosed problem with libatomic_ops/master with gcc-4.4.7 -m32 on Solaris.
> > > > > 
> > > > > Regards.
> > > > > 
> > > > > Wed, 28 Mar 2012 19:32:24 +0400 Ivan Maidanski <ivmai at mail.ru>:
> > > > > > 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.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > 
> > > > 
> > > > _______________________________________________
> > > > Gc mailing list
> > > > Gc at linux.hpl.hp.com
> > > > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> > > > 
> > 
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> > 



More information about the Gc mailing list