Build of any gcc breaks on my sparc / illumos env
Hi, I'm the maintainer of the XStreamOS/illumos distro, mainly x86 but we also have a sparc version. I'm currently trying to upgrade a T4 system running XStreamOS/sparc as of illumos 2019. This system contains a gcc 4.7 that I used to build all the various userland components, built on a previous XStreamOS basic system through a gcc 3. I don't know what changed in the env of the T4 system, with respect to the previous where I built gcc 4.7. On this system I cannot build any of gcc 5,6,7,8,9,10. The build always breaks here: libtool: link: /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/xgcc -shared-libgcc -B/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc -nostdinc++ -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs -B/usr/gcc/6/sparc-sun-solaris2.11/bin/ -B/usr/gcc/6/sparc-sun-solaris2.11/lib/ -isystem /usr/gcc/6/sparc-sun-solaris2.11/include -isystem /usr/gcc/6/sparc-sun-solaris2.11/sys-include -shared -nostdlib /usr/lib/crti.o /usr/lib/values-Xa.o /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/crtbeginS.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,-z -Wl,allextract ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -Wl,-z -Wl,defaultextract -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -lm -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc -lgcc_s -lc -lgcc_s -lc /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/crtendS.o /usr/lib/crtn.o -Wl,-M -Wl,libstdc++-symbols.ver-sun -Wl,-h -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.22 ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility.o: symbol .gcc_except_table (section): offset 0x74d8ddf1 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility.o: symbol .gcc_except_table (section): offset 0x74d8de11 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility-atomic-c++0x.o: symbol .gcc_except_table (section): offset 0x74d8de99 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility-atomic-c++0x.o: symbol .gcc_except_table (section): offset 0x74d8deb9 is non-aligned As an example, the ".libs/compatibility.o" file is built like this: libtool: compile: /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/xgcc -shared-libgcc -B/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc -nostdinc++ -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs -B/usr/gcc/6/sparc-sun-solaris2.11/bin/ -B/usr/gcc/6/sparc-sun-solaris2.11/lib/ -isystem /usr/gcc/6/sparc-sun-solaris2.11/include -isystem /usr/gcc/6/sparc-sun-solaris2.11/sys-include -I/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/include/sparc-sun-solaris2.11 -I/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/include -I/data/sources/sonicle/xstream-userland-gate/components/gcc-6/gcc-6.5.0/libstdc++-v3/libsupc++ -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=compatibility.lo -g -O2 -c /data/sources/sonicle/xstream-userland-gate/components/gcc-6/gcc-6.5.0/libstdc++-v3/src/c++98/compatibility.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o .libs/compatibility.o I cannot find what is causing this non-aligned problem. This is how configure is invoked: /data/sources/sonicle/xstream-userland-gate/components/gcc-6/gcc-6.5.0/configure --prefix=
Re: Build of any gcc breaks on my sparc / illumos env
On Mon, Jun 20, 2022, 5:14 AM Gabriele Bulfon via Gcc wrote: > Hi, > > I'm the maintainer of the XStreamOS/illumos distro, mainly x86 but we also > have a sparc version. > I'm currently trying to upgrade a T4 system running XStreamOS/sparc as of > illumos 2019. > This system contains a gcc 4.7 that I used to build all the various > userland components, built on a previous XStreamOS basic system through a > gcc 3. > I don't know what changed in the env of the T4 system, with respect to the > previous where I built gcc 4.7. > On this system I cannot build any of gcc 5,6,7,8,9,10. > The build always breaks here: > > libtool: link: > > /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/xgcc > -shared-libgcc > -B/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc > -nostdinc++ > -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src > -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs > -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs > -B/usr/gcc/6/sparc-sun-solaris2.11/bin/ > -B/usr/gcc/6/sparc-sun-solaris2.11/lib/ -isystem > /usr/gcc/6/sparc-sun-solaris2.11/include -isystem > /usr/gcc/6/sparc-sun-solaris2.11/sys-include-shared -nostdlib > /usr/lib/crti.o /usr/lib/values-Xa.o > /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/crtbeginS.o > .libs/compatibility.o .libs/compatibility-debug_list.o > .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o > .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o > .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,-z > -Wl,allextract ../libsupc++/.libs/libsupc++convenience.a > ../src/c++98/.libs/libc++98convenience.a > ../src/c++11/.libs/libc++11convenience.a -Wl,-z -Wl,defaultextract > > -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs > -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src > -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs > -lm > -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc > -lgcc_s -lc -lgcc_s -lc > /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/crtendS.o > /usr/lib/crtn.o -Wl,-M -Wl,libstdc++-symbols.ver-sun -Wl,-h > -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.22 > ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility.o: > symbol .gcc_except_table (section): offset 0x74d8ddf1 is non-aligned > ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility.o: > symbol .gcc_except_table (section): offset 0x74d8de11 is non-aligned > ld: fatal: relocation error: R_SPARC_DISP32: file > .libs/compatibility-atomic-c++0x.o: symbol .gcc_except_table (section): > offset 0x74d8de99 is non-aligned > ld: fatal: relocation error: R_SPARC_DISP32: file > .libs/compatibility-atomic-c++0x.o: symbol .gcc_except_table (section): > offset 0x74d8deb9 is non-aligned > ... > Any chance the linker script is missing an align directive ahead of this section? Or it is insufficient? Or (unlikely) broken? --joel > As an example, the ".libs/compatibility.o" file is built like this: > > libtool: compile: > > /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/xgcc > -shared-libgcc > -B/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc > -nostdinc++ > -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src > -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs > -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs > -B/usr/gcc/6/sparc-sun-solaris2.11/bin/ > -B/usr/gcc/6/sparc-sun-solaris2.11/lib/ -isystem > /usr/gcc/6/sparc-sun-solaris2.11/include -isystem > /usr/gcc/6/sparc-sun-solaris2.11/sys-include > -I/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/include/sparc-sun-solaris2.11 > -I/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/include > -I/data/sources/sonicle/xstream-userland-gate/components/gcc-6/gcc-6.5.0/libstdc++-v3/libsupc++ > -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -Wall -Wextra > -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once > -ffunction-sections -fdata-sections -frandom-seed=compatibility.lo -g -O2 > -c > /data/sources/sonicle/xstream-userland-gate/components/gcc-6
Re: Build of any gcc breaks on my sparc / illumos env
Who may be responsible for this alignment? The same Makefile has been used in other distros, and the same 4.7 that I'm using was built on another previous system without problems, but now produces this error itself on the new system. I bet this is something about the env on the new system, but I don't know what piece is responsible for this alignment. Any clue? Gabriele Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com eXoplanets : https://gabrielebulfon.bandcamp.com/album/exoplanets Da: Joel Sherrill A: Gabriele Bulfon Cc: GCC Data: 20 giugno 2022 13.04.17 CEST Oggetto: Re: Build of any gcc breaks on my sparc / illumos env On Mon, Jun 20, 2022, 5:14 AM Gabriele Bulfon via Gcc wrote: Hi, I'm the maintainer of the XStreamOS/illumos distro, mainly x86 but we also have a sparc version. I'm currently trying to upgrade a T4 system running XStreamOS/sparc as of illumos 2019. This system contains a gcc 4.7 that I used to build all the various userland components, built on a previous XStreamOS basic system through a gcc 3. I don't know what changed in the env of the T4 system, with respect to the previous where I built gcc 4.7. On this system I cannot build any of gcc 5,6,7,8,9,10. The build always breaks here: libtool: link: /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/xgcc -shared-libgcc -B/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc -nostdinc++ -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs -B/usr/gcc/6/sparc-sun-solaris2.11/bin/ -B/usr/gcc/6/sparc-sun-solaris2.11/lib/ -isystem /usr/gcc/6/sparc-sun-solaris2.11/include -isystem /usr/gcc/6/sparc-sun-solaris2.11/sys-include -shared -nostdlib /usr/lib/crti.o /usr/lib/values-Xa.o /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/crtbeginS.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,-z -Wl,allextract ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -Wl,-z -Wl,defaultextract -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -lm -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc -lgcc_s -lc -lgcc_s -lc /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/crtendS.o /usr/lib/crtn.o -Wl,-M -Wl,libstdc++-symbols.ver-sun -Wl,-h -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.22 ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility.o: symbol .gcc_except_table (section): offset 0x74d8ddf1 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility.o: symbol .gcc_except_table (section): offset 0x74d8de11 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility-atomic-c++0x.o: symbol .gcc_except_table (section): offset 0x74d8de99 is non-aligned ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility-atomic-c++0x.o: symbol .gcc_except_table (section): offset 0x74d8deb9 is non-aligned ... Any chance the linker script is missing an align directive ahead of this section? Or it is insufficient? Or (unlikely) broken? --joel As an example, the ".libs/compatibility.o" file is built like this: libtool: compile: /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/xgcc -shared-libgcc -B/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc -nostdinc++ -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs -B/usr/gcc/6/sparc-sun-solaris2.11/bin/ -B/usr/gcc/6/sparc-sun-solaris2.11/lib/ -isystem /usr/gcc/6/sparc-sun-solaris2.11/include -isystem /usr/gcc/6/sparc-sun-solaris2.11/sys-include -I/data/sources/sonicle/xstream-userla
Re: Build of any gcc breaks on my sparc / illumos env
On Mon, Jun 20, 2022, 7:23 AM Gabriele Bulfon wrote: > Who may be responsible for this alignment? > The same Makefile has been used in other distros, and the same 4.7 that > I'm using was built on another previous system without problems, but now > produces this error itself on the new system. > I bet this is something about the env on the new system, but I don't know > what piece is responsible for this alignment. > This would come from binutils. Did you upgrade those also? I think if you use a -v on the linking gcc invocation, it should show the linker.xommand and script used. Just follow that info to locate the linker script and then look just before the unaligned section. --joel > > Any clue? > Gabriele > > > *Sonicle S.r.l. *: http://www.sonicle.com > *Music: *http://www.gabrielebulfon.com > *eXoplanets : *https://gabrielebulfon.bandcamp.com/album/exoplanets > > > -- > > > *Da:* Joel Sherrill > *A:* Gabriele Bulfon > *Cc:* GCC > *Data:* 20 giugno 2022 13.04.17 CEST > *Oggetto:* Re: Build of any gcc breaks on my sparc / illumos env > > > > > On Mon, Jun 20, 2022, 5:14 AM Gabriele Bulfon via Gcc > wrote: > >> Hi, >> >> I'm the maintainer of the XStreamOS/illumos distro, mainly x86 but we >> also have a sparc version. >> I'm currently trying to upgrade a T4 system running XStreamOS/sparc as of >> illumos 2019. >> This system contains a gcc 4.7 that I used to build all the various >> userland components, built on a previous XStreamOS basic system through a >> gcc 3. >> I don't know what changed in the env of the T4 system, with respect to >> the previous where I built gcc 4.7. >> On this system I cannot build any of gcc 5,6,7,8,9,10. >> The build always breaks here: >> >> libtool: link: >> >> /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/xgcc >> -shared-libgcc >> -B/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc >> -nostdinc++ >> -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src >> -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs >> -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs >> -B/usr/gcc/6/sparc-sun-solaris2.11/bin/ >> -B/usr/gcc/6/sparc-sun-solaris2.11/lib/ -isystem >> /usr/gcc/6/sparc-sun-solaris2.11/include -isystem >> /usr/gcc/6/sparc-sun-solaris2.11/sys-include-shared -nostdlib >> /usr/lib/crti.o /usr/lib/values-Xa.o >> /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/crtbeginS.o >> .libs/compatibility.o .libs/compatibility-debug_list.o >> .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o >> .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o >> .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,-z >> -Wl,allextract ../libsupc++/.libs/libsupc++convenience.a >> ../src/c++98/.libs/libc++98convenience.a >> ../src/c++11/.libs/libc++11convenience.a -Wl,-z -Wl,defaultextract >> >> -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs >> -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src >> -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs >> -lm >> -L/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc >> -lgcc_s -lc -lgcc_s -lc >> /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/crtendS.o >> /usr/lib/crtn.o -Wl,-M -Wl,libstdc++-symbols.ver-sun -Wl,-h >> -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.22 >> ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility.o: >> symbol .gcc_except_table (section): offset 0x74d8ddf1 is non-aligned >> ld: fatal: relocation error: R_SPARC_DISP32: file .libs/compatibility.o: >> symbol .gcc_except_table (section): offset 0x74d8de11 is non-aligned >> ld: fatal: relocation error: R_SPARC_DISP32: file >> .libs/compatibility-atomic-c++0x.o: symbol .gcc_except_table (section): >> offset 0x74d8de99 is non-aligned >> ld: fatal: relocation error: R_SPARC_DISP32: file >> .libs/compatibility-atomic-c++0x.o: symbol .gcc_except_table (section): >> offset 0x74d8deb9 is non-aligned >> ... > > > Any chance the linker script is missing an align directive ahead of this > section? Or it is insufficient? Or (unlikely) broken? > > --joel > > >> >> As an example, the ".libs/compatibility.o" file is built like this: >> >> libtool: compile: >> >> /data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/xgcc >> -shared-libgcc >> -B/data/sources/sonicle/xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc >> -nostdinc++ >> -L/data/sources/sonicl
Re: Build of any gcc breaks on my sparc / illumos env
Thanks! This is what I get adding "-v", and to me it's not telling anything interesting, maybe you can see more than I can? Reading specs from /data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/specs COLLECT_GCC=/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/xgcc COLLECT_LTO_WRAPPER=/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/lto-wrapper Target: sparc-sun-solaris2.11 Configured with: /data/sources/sonicle/xstream-userland-gate/components/gcc-6/gcc-6.5.0/configure --prefix=/usr/gcc/6 --mandir=/usr/gcc/6/share/man --bindir=/usr/gcc/6/bin --libdir=/usr/gcc/ 6/lib --sbindir=/usr/gcc/6/sbin --infodir=/usr/share/info --sysconfdir=/etc --without-gnu-as --with-as=/usr/bin/as --build=sparc-sun-solaris2.11 --sbindir=/usr/gcc/6/bin --libdir=/usr/gcc/6/ lib --libexecdir=/usr/gcc/6/lib --host sparc-sun-solaris2.11 --build sparc-sun-solaris2.11 --target sparc-sun-solaris2.11 --with-pkgversion='XStreamOS 6.5.0-XS-2' --with-bugurl=https://bugs. xstreamos.org --enable-plugins --enable-objc-gc --enable-initfini-array --enable-languages=c,c++,fortran,lto,objc --without-gnu-ld --with-ld=/usr/bin/ld --with-build-time-tools=/usr/gnu/spar c-sun-solaris2.11/bin --disable-libitm --without-gnu-as --with-as=/usr/bin/as LDFLAGS=-R/usr/gcc/6/lib Thread model: posix gcc version 6.5.0 (XStreamOS 6.5.0-XS-2) COMPILER_PATH=/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/:/usr/ccs/bin/ LIBRARY_PATH=/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-B' '/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc' '-nostdinc++' '-L/data/sources/sonicle/old-xstream-userl and-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src' '-L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstd c++-v3/src/.libs' '-L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs' '-B' '/usr/gcc/6/sparc-sun-solaris2.11 /bin/' '-B' '/usr/gcc/6/sparc-sun-solaris2.11/lib/' '-isystem' '/usr/gcc/6/sparc-sun-solaris2.11/include' '-isystem' '/usr/gcc/6/sparc-sun-solaris2.11/sys-include' '-shared' '-nostdlib' '-L/ data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs' '-L/data/sources/sonicle/old-xstream-userland-gate/component s/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src' '-L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs' '-L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc' '-o' '.libs/libstdc++.so.6.0.22' '-mcpu=v9' /data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/collect2 -V -G -dy -z text -M /data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/spa rcv7/./gcc/libgcc-unwind.map -Y P,/usr/gcc/6/lib:/lib:/usr/lib -R /usr/gcc/6/lib -L /usr/gcc/6/lib -Qy -o .libs/libstdc++.so.6.0.22 -L/data/sources/sonicle/old-xstream-userland-gate/componen ts/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src -L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -L /data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs -L/data/sources/sonicle/old-xstream-userland-gate/components /gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs -L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/sr c -L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -L/data/sources/sonicle/old-xstream-userland-gate/components/g cc-6/build/sparcv7/./gcc -L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc /usr/lib/crti.o /usr/lib/values-Xa.o /data/sources/sonicle/old-xstream-userlan d-gate/components/gcc-6/build/sparcv7/./gcc/crtbeginS.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibil ity-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -z allextract ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/li bc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -z defaultextract -lm -lgcc_s -lc -lgcc_s -lc /data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gc c/crtendS.o /usr/lib/crtn.o -M libstdc++-symbols.ver-sun -h libstdc++.so.6 ld: Software Generation Utilities - Solaris Link Edito
Re: remove intl/ directory?
On Sat, Jun 18, 2022 at 1:01 PM Bruno Haible wrote: > > Hi, > > As the long-term GNU gettext maintainer, I would suggest to remove the intl/ > directory from the GCC distribution. > > The effect for the users would be: > * On systems without glibc, users who want an internationalized GCC > installation would have to install GNU gettext first. Then the GCC > binaries would be linked with the shared library libintl.so > (unless gettext was built with --disable-shared); they would no longer > contain the libintl code in 'cc1', 'cc1plus', etc. > * On systems with glibc, no change. > > The effect for the GCC maintainers would be: > * Easier to stay up-to-date with upstream libintl. > * Less maintenance work with *.m4 files such as > codeset.m4 > glibc21.m4 > intdiv0.m4 > inttypes_h.m4 > inttypes.m4 > inttypes-pri.m4 > lcmessage.m4 > stdint_h.m4 > uintmax_t.m4 > ulonglong.m4 > * Reduced risk of a CVE that would impact GCC binaries. > > Rationale: > * This intl/ code is from 2003; of course several bugs have been > fixed in it over the last 19 years. > * At that time GNU packages were still favouring static libraries. > GNU libtool became widely reliable only about in 2005. > * Since then, distros have been favouring shared libraries over > static libraries, in order to be able to fix CVEs without > rebuilding many dependent binaries. > * For this reason, GNU gettext removed the support for this way > of packaging libintl in version 0.20 (May 2019). The NEWS entry > said: > - The --intl option of the gettextize program (deprecated since 2010) is > no longer available. Instead of including the intl sources in your > package, we suggest making the libintl library an optional prerequisite > of your package. This will simplify the build system of your package. > - Accordingly, the Autoconf macro AM_GNU_GETTEXT_INTL_SUBDIR is gone > as well. > > This point came up while discussing with Eric Gallager, who is working on > the GCC configury. > Hi, just for some additional context for anyone reading from the archives, but this conversation came out of autoconf sr #110324: https://savannah.gnu.org/support/?110324 My work can be seen in the refs/users/egallager/heads/autotools-tinkering branch, which I'm also mirroring on GitHub here: https://github.com/cooljeanius/gcc/tree/me/autotools-tinkering The latest pending patch I've submitted from this branch is here: https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596654.html As for the underlying topic of this thread, personally I see removing the intl/ subdirectory as just one possible solution to the issue of its autoconf macros being outdated, the other would be to fix autoupdate so that it can handle things properly, but I can see how that would be harder. Whichever solution turns out to be the simplest for everyone involved will be the one I'll support. Thanks, Eric > I don't volunteer to implement this suggestion, but I can give advice where > needed. > > Bruno >
Change in preprocessor behavior
At some point between GCC 9 and GCC 12, the preprocessor started behaving differently. Before if GCC were launched as /lib/cpp or /usr/bin/cpp (I think) it would assume the user wanted to preprocess something and automatically launch in preprocessor mode. Now the behavior has changed and it just acts as the normal compiler. Can someone kindly point me to the patch or commit where this feature was changed, and the rationale for doing so? Thank you. -- Dave Blanchard
Re: remove intl/ directory?
Hi Iain,
> So, indeed, part of this is quite straight forward - we can amend the
> Makefile.def
> to specify that GCC should use gettext-runtime (it will be used if the
> directory is
> present, otherwise there will be no intl support).
>
> The tricky part is that we need to use the runtime ‘uninstalled’, and here is
> where
> intl is helpful - it provides a ‘config.intl’ that can be sourced via
> gettext-sister.m4
> to provide the neccessary configure input to directories that want to use
> intl.
>
> I have hacked a change to gettext-sister.m4 that fishes the same information
> out
> of gettext-runtime/Makefile (as configured in $build) - obviously this is
> going to be
> fragile w.r.t different versions of gettext-runtime (so I am not suggesting
> this is a
> viable patch) - simply something to illustrate what needs to be figured out.
>
> So - the changes are in Makefile.def and config/gettext-sister.m4 (the patch
> includes
> the regenerated files for convenience of use).
>
> I tried this with gettext-0.21 on macOS 10.15 and, AFAICT, it DTRT - but
> needs work
> to resolve the main point above.
Excellent! Glad to see that you are going ahead so quickly.
I have now added the necessary support for this "uninstalled" situation from
the gettext side:
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=6f048e30a88282ed6712ce8d6000302fd287daad
This is in a form that is maintainable from gettext's side.
I believe that with this, you can change these lines from gettext-sister.m4
BUILD_INCLUDED_LIBINTL=`grep BUILD_INCLUDED_LIBINTL
../gettext-runtime/Makefile|sed s/BUILD_INCLUDED_LIBINTL\ =\ //`
USE_NLS=`grep USE_NLS ../gettext-runtime/Makefile|sed s/USE_NLS\ =\ //`
LIBICONV=`grep ^LIBICONV ../gettext-runtime/Makefile|sed s/LIBICONV\ =\ //`
INTL_MACOSX_LIBS=`grep ^INTL_MACOSX_LIBS ../gettext-runtime/Makefile|sed
s/INTL_MACOSX_LIBS\ =\ //`
XGETTEXT=`grep XGETTEXT ../gettext-runtime/Makefile|sed s/XGETTEXT\ =\ //`
GMSGFMT=`grep GMSGFMT ../gettext-runtime/Makefile|sed s/GMSGFMT\ =\ //`
POSUB=`grep POSUB ../gettext-runtime/Makefile|sed s/POSUB\ =\ //`
LIBINTL="\${top_builddir}/../gettext-runtime/intl/.libs/libintl.a $LIBICONV
$INTL_MACOSX_LIBS"
INCINTL="-I\${top_builddir}/../gettext-runtime/intl"
roughly to this:
relative_builddir='${top_builddir}/../gettext-runtime'
. ${top_builddir}/../gettext-runtime/uninstalled-config.sh
There is also a GCC specific quirk, that I upstreamed into GNU gettext:
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=fdc2bd236a6a62b477c1fca4205df10b0e64266b
> P.S. I am slighty surprised that configuring with —disable-java does not
> appear to stop
> the on-screen popup appearing that tells me I need to install Java to use
> this … that
> would be an irritation when using this on a headless box.
Thanks for reporting this; it should be fixed now, through
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=971dcbdbebb05d7ae8aa6399a0c79442fa996c5c
You find a tarball from the current gettext git, that contains all these
changes, in https://alpha.gnu.org/gnu/gettext/gettext-20220620.tar.gz .
Obviously, the GCC documentation will have to say that all this works only
with GNU gettext 0.22 or newer, i.e. after I make the next release.
Bruno
Re: remove intl/ directory?
Eric Gallager wrote: > personally I see removing > the intl/ subdirectory as just one possible solution to the issue of > its autoconf macros being outdated The autoconf macros are only the smaller part of the problem. The bigger part is the C code of libintl. [1][2] Bruno [1] https://gcc.gnu.org/pipermail/gcc/2022-June/238920.html [2] https://gcc.gnu.org/pipermail/gcc/2022-June/238925.html
