Bugzilla – Bug 946048
binutils broken on ppc64 (big endian)
Last modified: 2015-10-21 14:39:12 UTC
Ncurses doe not build on ppc64 (this is the only failing architecture). The message is short: [ 92s] gcc -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g - pipe -D_REENTRANT --param max-inline-insns-single=1200 -shared -Wl,--version-script,resulting.map -Wl,-soname,`basename ../lib/libtinfo.so.6.0 .6.0`.6 ,-stats,-lc -o ../lib/libtinfo.so.6.0 ../obj_s/access.o ../obj_s/add_tries.o ../obj_s/alloc_ttype.o ../obj_s/codes.o ../obj_s/comp_captab.o ../obj_s/co mp_error.o ../obj_s/comp_hash.o ../obj_s/db_iterator.o ../obj_s/doalloc.o ../obj_s/entries.o ../obj_s/fallback.o ../obj_s/free_ttype.o ../obj_s/getenv_ num.o ../obj_s/home_terminfo.o ../obj_s/init_keytry.o ../obj_s/lib_acs.o ../obj_s/lib_baudrate.o ../obj_s/lib_cur_term.o ../obj_s/lib_data.o ../obj_s/l ib_has_cap.o ../obj_s/lib_kernel.o ../obj_s/lib_keyname.o ../obj_s/lib_longname.o ../obj_s/lib_napms.o ../obj_s/lib_options.o ../obj_s/lib_raw.o ../obj _s/lib_setup.o ../obj_s/lib_termcap.o ../obj_s/lib_termname.o ../obj_s/lib_tgoto.o ../obj_s/lib_ti.o ../obj_s/lib_tparm.o ../obj_s/lib_tputs.o ../obj_s /lib_trace.o ../obj_s/lib_ttyflags.o ../obj_s/lib_twait.o ../obj_s/name_match.o ../obj_s/names.o ../obj_s/obsolete.o ../obj_s/read_entry.o ../obj_s/rea d_termcap.o ../obj_s/strings.o ../obj_s/tries.o ../obj_s/trim_sgr0.o ../obj_s/unctrl.o ../obj_s/visbuf.o ../obj_s/define_key.o ../obj_s/hashed_db.o ../ obj_s/key_defined.o ../obj_s/keybound.o ../obj_s/keyok.o ../obj_s/version.o -L../lib -Wl,-O2 -Wl,-Bsymbolic-functions -Wl,--hash-size=8599 -Wl,--as-ne eded [ 92s] /usr/lib64/gcc/powerpc64-suse-linux/5/../../../../powerpc64-suse-linux/bin/ld:resulting.map:113: syntax error in VERSION script [ 92s] collect2: error: ld returned 1 exit status [ 92s] Makefile:1013: recipe for target '../lib/libtinfo.so.6.0' failed [ 92s] make[1]: *** [../lib/libtinfo.so.6.0] Error 1 [ 92s] make[1]: *** Waiting for unfinished jobs.... [ 93s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/ncurses-6.0/ncurses' [ 93s] Makefile:317: recipe for target '../lib/libncurses.so' failed [ 93s] make: *** [../lib/libncurses.so] Error 2 [ 93s] make: Leaving directory '/home/abuild/rpmbuild/BUILD/ncurses-6.0/progs' [ 93s] + rm -rf /tmp/ncurses.D4aZQ04X [ 93s] error: Bad exit status from /var/tmp/rpm-tmp.jcfXhf (%build) the version script is named ncursest.map and at line 113 I see } NCURSES_TIC_5.9.20150530; ... in context [...] NCURSES_TIC_5.9.20150530 { global: _nc_strict_bsd; } NCURSES_TIC_5.7.20081102; NCURSES_TIC_6.0.current { global: _nc_write_object; local: _*; } NCURSES_TIC_5.9.20150530; <<<<<<<< line 113 NCURSES_TINFO_5.0.19991023 { global: [...]
(In reply to Dr. Werner Fink from comment #0) > /usr/lib64/gcc/powerpc64-suse-linux/5/../../../../powerpc64-suse-linux/bin/ > ld:resulting.map:113: syntax error in VERSION script ... > the version script is named ncursest.map and at line 113 I see Actually, the file is 'resulting.map' not ncursest.map (possibly it's generated from that). Can you please show us that one?
(In reply to Michael Matz from comment #1) I would do if I would find a ppc64 host on which I could build ncurses. Currently I've the problem that the remaining ppc64 hosts do not allow screen which I use to run configure of ncurses (this because the configure script should run within a terminal for autodetection). I've no idea where this name `resulting.map' comes from as on x86_64 there is no such file AFAICS from autobuild directory.
Created attachment 647492 [details] temporary file resulting.map This I have found during build ... seems to a copy of ncursest.map
(In reply to Dr. Werner Fink from comment #3) It should be noted that this file was done on a x86_64!
Created attachment 648938 [details] resulting.ppc64.map I am able to build on ppc64 guest and recreate the failure, so reporting the resulting.map file (as resulting.ppc64.map) (In reply to Dr. Werner Fink from comment #4) > (In reply to Dr. Werner Fink from comment #3) > > It should be noted that this file was done on a x86_64! The reported line 113 for ppc64 has a missing local compared to x86-64 provided in resulting.map attachment. === x86-64: NCURSES6_TIC_6.0.current { global: _nc_write_object; local: _*; } NCURSES6_TIC_5.9.20150530; <= line 113 === === ppc64: NCURSES6_TIC_6.0.current { global: _nc_write_object; local: } NCURSES6_TIC_5.9.20150530; <= line 113 ===
That means that entry got removed when transforming ncurses.map to resulting.map. That's consistent with the sources I see. Most entries in the .map files that have _* at all are of this form: local: _*; _nc_mvcur; Note that there's some line following the _*; entry. ncurses-6.0-patches.tar.gz adds this: +NCURSES_TIC_6.0.current { + global: + _nc_write_object; + local: + _*; +} NCURSES_TIC_5.9.20150530; _No_ line following _*; entry. The transformation from ncurses.map to resulting map happen with this rule added by configure to Makefile: resulting.map: $UNALTERED_SYMS sed $cf_sed_options < $UNALTERED_SYMS >\$@ The $cf_sed_options are generated by configure as well, and amongst them contain this: if test "x$WILDCARD_SYMS" = xno then cf_sed_options="$cf_sed_options -e \"s/_\*;//g\"" fi So, if WILDCARD_SYMS are 'no' then all entries '_*;' are removed, which is what happen here on ppc64. For most other version entries (those containing following lines) this is harmless, but for the newly added entry this leaves us with an invalid one, namely 'local: }'. So, the question is, why is WILDCARD_SYMS no on ppc64 only, when it is obviously not so on all other platforms. There is a configure test involved with an testing linker script, and that obviously fails, but I lack time right now to see why it fails; probably some of the grep expressions it's using there don't work on ppc64.
I have a proposed patch in https://build.opensuse.org/request/show/333695 that is solving the build problem.
(In reply to Michel Normand from comment #7) Hopefully the now used [DT] for the (e)grep command does not cause trouble on other architectures. Nevertheless, the question rises why on BE ppc64 there is this difference as on BE ppc it seems to work. Or why are symbols which are located in text section on ppc found in the data section on ppc64?
(In reply to Dr. Werner Fink from comment #8) > (In reply to Michel Normand from comment #7) > > Hopefully the now used [DT] for the (e)grep command does not cause trouble > on other architectures. Nevertheless, the question rises why on BE ppc64 > there is this difference as on BE ppc it seems to work. Or why are symbols > which are located in text section on ppc found in the data section on ppc64? ppc64 is using functions descriptors, in data section as per (1) On most other Linux platforms, including ppc64le, function symbols point directly to the function code in the text section. (thanks to Ulrich Weigand for the details) (1) http://www.ibm.com/developerworks/library/l-ppc/index.html look at "Function descriptors -- the .opd section"
Therefore ncurses bug, not binutils. Back to Werner.
(In reply to Michael Matz from comment #10) Already fixed
Michel, I can't see your fix anywhere else but in our package. In case you haven't done it yet could you please send your patch to bug-ncurses@gnu.org as well?
(In reply to Tomas Cech from comment #12) > Michel, > > I can't see your fix anywhere else but in our package. In case you haven't > done it yet could you please send your patch to bug-ncurses@gnu.org as well? Oups, forget it :( Thanks for the reminder. I just sent the patch today to above email @, I am expecting to see it soon in the bug-ncurses ML (1) (1) https://lists.gnu.org/mailman/listinfo/bug-ncurses
(In reply to Michel Normand from comment #13) > (In reply to Tomas Cech from comment #12) > > Michel, > > > > I can't see your fix anywhere else but in our package. In case you haven't > > done it yet could you please send your patch to bug-ncurses@gnu.org as well? > > Oups, forget it :( Thanks for the reminder. > I just sent the patch today to above email @, I am expecting to see it soon > in the bug-ncurses ML (1) > > (1) https://lists.gnu.org/mailman/listinfo/bug-ncurses Thanks!