re: toolchain/53960: sparc64 fails to build

[matthew green <mrg%eterna.com.au@localhost>]

The following reply was made to PR toolchain/53960; it has been noted by GNATS.

From: matthew green <mrg%eterna.com.au@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: toolchain-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
    netbsd-bugs%netbsd.org@localhost
Subject: re: toolchain/53960: sparc64 fails to build
Date: Sat, 09 Feb 2019 09:21:41 +1100

 > Trying to build sparc64 after the switch to gcc 7 fails for me:
 > =
 
 > creating msgconv
 > --- msgmerge ---
 > ld: /usr/lib/libgomp.so: undefined reference to `gomp_ialias_omp_destroy=
 _lock'
 > ld: /usr/lib/libgomp.so: undefined reference to `gomp_ialias_omp_test_ne=
 st_lock'
 > ld: /usr/lib/libgomp.so: undefined reference to `gomp_ialias_omp_set_loc=
 k'
 > ld: /usr/lib/libgomp.so: undefined reference to `gomp_ialias_omp_destroy=
 _nest_lock'
 > ld: /usr/lib/libgomp.so: undefined reference to `gomp_ialias_omp_init_ne=
 st_lock'
 > ld: /usr/lib/libgomp.so: undefined reference to `gomp_ialias_omp_test_lo=
 ck'
 > ld: /usr/lib/libgomp.so: undefined reference to `gomp_ialias_omp_unset_l=
 ock'
 > ld: /usr/lib/libgomp.so: undefined reference to `gomp_ialias_omp_init_lo=
 ck'
 > ld: /usr/lib/libgomp.so: undefined reference to `gomp_ialias_omp_set_nes=
 t_lock'
 > ld: /usr/lib/libgomp.so: undefined reference to `gomp_ialias_omp_unset_n=
 est_lock'
 > *** [msgmerge] Error code 1
 > nbmake[11]: stopped in /work/obj/sparc64/work/src/tools/gettext/build/ge=
 ttext-tools/src
 > =
 
 > I removed obj and destdir before the build.
 
 odd.  why is gettext looking for libgomp?  i see that there is =
 
 build issue in libgomp like the above (a simple input file
 using "gcc -fopenmp test.c" will show it), but i'm more curious
 why gettext is wanting it!
 
 i haven't seen this in my builds and i've run gcc7 hosted builds
 on amd64 and my sparc64 build is well beyond tools.
 
 in any case, i'm looking at libgomp -- there seems to be some
 issue with its internal renaming.  the above should end up
 present, perhaps with different names.  still not sure what
 exactly is happening, but perhaps simply enabling symver for
 this library will fix it (the above symbols are handled
 differently for systems without GNU sym ver support, and at
 the moment the configury chooses not us.)
 
 
 .mrg.