mono fails to build with gcc-4.9.1-7.fc21 on F21 s390x with the following error: ../mini/.libs/libmono-2.0.so: undefined reference to `.L2527' collect2: error: ld returned 1 exit status The problematic file is mono/mini/method-to-ir.c Adding __attribute__((optimize (0))) to the very last function within the file - mono_spill_global_vars - fixes the problem. Adding __attribute__((optimize (0))) to any other function within the file fixes the build but leads to a segfault when a program tries using the library.
Can you provide preprocessed method-to-ir.i and list what gcc options are used to compile it? Thanks.
Created attachment 934142 [details] method-to-ir.i You are faster than I am :). Attaching method-to-ir.i & the command line used for build: gcc -DHAVE_CONFIG_H -I. -I../.. -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP -D__default_codegen__ -DUSE_COMPILER_TLS -I../.. -I../../eglib/src -I../../eglib/src -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -fno-strict-aliasing -Wdeclaration-after-statement -Wno-unused-but-set-variable -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wwrite-strings -mbackchain -D__USE_STRING_INLINES -c method-to-ir.c
Can't reproduce this: ./cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -mbackchain method-to-ir.i; as -o method-to-ir.{o,s}; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s .hidden mono_defaults .ident "GCC: (GNU) 4.9.1 20140813 (Red Hat 4.9.1-7)" .section .note.GNU-stack,"",@progbits
I think there a very similar problem on i386 building Hercules, which goes away when the cpu.c file is compiled with -O1 ... libtool: link: gcc -shared -fPIC -DPIC .libs/hconsole.o .libs/w32util.o .libs/strsignal.o .libs/impl.o .libs/config.o .libs/bldcfg.o .libs/panel.o .libs/history.o .libs/fillfnam.o .libs/ipl.o .libs/assist.o .libs/dat.o .libs/stack.o .libs/cpu.o .libs/vstore.o .libs/general1.o .libs/general2.o .libs/general3.o .libs/pfpo.o .libs/plo.o .libs/control.o .libs/crypto.o .libs/io.o .libs/decimal.o .libs/service.o .libs/scedasd.o .libs/losc.o .libs/chsc.o .libs/opcode.o .libs/diagnose.o .libs/diagmssf.o .libs/vm.o .libs/vmd250.o .libs/channel.o .libs/external.o .libs/float.o .libs/trace.o .libs/machchk.o .libs/vector.o .libs/xstore.o .libs/cmpsc.o .libs/sie.o .libs/qdio.o .libs/clock.o .libs/timer.o .libs/esame.o .libs/ieee.o .libs/dfp.o .libs/httpserv.o .libs/cgibin.o .libs/loadparm.o .libs/hsccmd.o .libs/cmdtab.o .libs/hao.o .libs/hscmisc.o .libs/sr.o .libs/ecpsvm.o -Wl,-rpath -Wl,/home/dan/hercules/hercules-3.10/.libs -Wl,-rpath -Wl,/home/dan/hercules/hercules-3.10/decNumber/.libs -Wl,-rpath -Wl,/home/dan/hercules/hercules-3.10/softfloat/.libs -L/home/dan/hercules/hercules-3.10/.libs ./.libs/libhercs.so ./.libs/libhercu.so ./.libs/libherct.so ./.libs/libhercd.so /home/dan/hercules/hercules-3.10/.libs/libhercu.so /home/dan/hercules/hercules-3.10/.libs/libhercs.so decNumber/.libs/libdecNumber.so softfloat/.libs/libsoftfloat.so -lltdl -lpthread -lrt -lz -lresolv -lnsl -lm -ldl -lbz2 -O2 -m32 -march=i686 -mtune=atom -O2 -m32 -march=i686 -mtune=atom -Wl,-z -Wl,relro -Wl,--warn-common -pthread -pthread -pthread -Wl,-soname -Wl,libherc.so -o .libs/libherc.so /usr/bin/ld: .libs/cpu.o: relocation R_386_GOTOFF against undefined symbol `.L1887' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status I'm working on the details now ...
(In reply to Jakub Jelinek from comment #3) > Can't reproduce this: > ./cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong > --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -march=z9-109 > -mtune=z10 -fno-strict-aliasing -mbackchain method-to-ir.i; as -o > method-to-ir.{o,s}; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s > .hidden mono_defaults > .ident "GCC: (GNU) 4.9.1 20140813 (Red Hat 4.9.1-7)" > .section .note.GNU-stack,"",@progbits My bad, mono builds two versions - one with -fPIC and one without it and it is actually the -fPIC that makes the difference: /usr/libexec/gcc/s390x-redhat-linux/4.9.1/cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -mbackchain -fPIC method-to-ir.i; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s U .L2527 .hidden mono_defaults .ident "GCC: (GNU) 4.9.1 20140813 (Red Hat 4.9.1-7)" .section .note.GNU-stack,"",@progbits
(In reply to Dan Horák from comment #4) > I think there a very similar problem on i386 building Hercules, which goes > away when the cpu.c file is compiled with -O1 see bug #1106758 for details
for the record - gcc-4.9.1-9.fc21 doesn't fix this problem
Yes, the fix is not in -10.fc22 either, waiting for Honza to commit it to 4.9.
So, is this still a problem with latest gcc (4.9.2-3.fc2[12])?
(In reply to Jakub Jelinek from comment #9) > So, is this still a problem with latest gcc (4.9.2-3.fc2[12])? yes, it is [sharkcz@devel3 mono]$ /usr/libexec/gcc/s390x-redhat-linux/4.9.2/cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -mbackchain -fPIC method-to-ir.i; as -o method-to-ir.{o,s}; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s U .L2534 .hidden mono_defaults .ident "GCC: (GNU) 4.9.2 20141217 (Red Hat 4.9.2-3)" .section .note.GNU-stack,"",@progbits
Ok, reproduced with cross-compiler, reducing the testcase now.
Reduced testcase (-O2 -fPIC -m64): struct { long q; } *h; long a, b, g, j, k, *c, *d, *e, *f, *i; long *baz (void); static inline int foo (void) { switch (b) { case 0: case 2: return a++; case 3: return a++; case 1: a++; } return 0; } void bar (void) { for (;;) { foo (); switch (0) { case 0: if (d) { f = baz (); g = k++; if (&h->q) { j = *f; h->q = *f; } else i = (long *) (h->q = *f); *c++ = (long) f; e += 6; break; } f = baz (); g = k++; if (&h->q) { j = *f; h->q = *f; } else i = (long *) (h->q = *f); *c++ = (long) f; e += 6; } } }
Filed upstream now.
I can confirm mono builds fine with gcc-4.9.2-5.fc21.s390x
gcc-4.9.2-6.fc21,gcc-python-plugin-0.13-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/gcc-4.9.2-6.fc21,gcc-python-plugin-0.13-3.fc21
Package gcc-python-plugin-0.13-3.fc21, gcc-4.9.2-6.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gcc-python-plugin-0.13-3.fc21 gcc-4.9.2-6.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-2063/gcc-4.9.2-6.fc21,gcc-python-plugin-0.13-3.fc21 then log in and leave karma (feedback).
gcc-python-plugin-0.13-3.fc21, gcc-4.9.2-6.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.