Bug 109051

Summary: Configure takes long time for multibuild of run-time libraries
Product: gcc Reporter: Martin Liška <marxin>
Component: bootstrapAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED WORKSFORME    
Severity: normal CC: andrea.corallo, przemyslaw.wirkus, rguenth, sjames
Priority: P3    
Version: 13.0   
Target Milestone: ---   
Host: x86_64-linux-gnu Target: arm-linux-gnueabi
Build: Known to work:
Known to fail: Last reconfirmed:
Bug Depends on:    
Bug Blocks: 84402    

Description Martin Liška 2023-03-07 12:32:29 UTC 
I've just noticed that a slower cross compiler build can be killer by a builder service:

[   24s] + ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++ --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/13 --with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin --with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --with-slibdir=/usr/arm-suse-linux-gnueabi/sys-root/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-13 --program-prefix=arm-none-eabi- --target=arm-none-eabi --disable-nls --with-sysroot=/usr/arm-suse-linux-gnueabi/sys-root --with-build-sysroot=/usr/arm-suse-linux-gnueabi/sys-root --with-build-time-tools=/usr/arm-suse-linux-gnueabi/bin --with-newlib --enable-multilib --with-multilib-list=aprofile,rmprofile --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-shared --disable-threads --disable-tls --disable-bootstrap --enable-link-mutex --disable-libsanitizer --build=x86_64-suse-linux --host=x86_64-suse-linux
...
[ 1113s]   esac;                                                        \
[ 1113s] done
[ 1113s] make[3]: Leaving directory '/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git6506/obj-x86_64-suse-linux/arm-none-eabi/libgcc'
[ 1762s] make[1]: Entering directory '/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git6506/obj-x86_64-suse-linux'
[ 1762s] Checking multilib configuration for libstdc++-v3...
[ 1762s] mkdir -p -- arm-none-eabi/libstdc++-v3
[ 1762s] Configuring in arm-none-eabi/libstdc++-v3

As seen, at this place there's no output and the step takes 600s on a pretty fast machine. So please, emit an output so that it doesn't get killer by a builder.
Comment 1 Martin Liška 2023-03-07 12:34:28 UTC 
Build example where it's killed:
https://build.opensuse.org/package/live_build_log/devel:gcc:next/gcc13:cross-arm-none-gcc13/openSUSE_Factory_ARM/aarch64

[13016s] make[3]: Leaving directory '/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git6506/obj-aarch64-suse-linux/arm-none-eabi/libgcc'
[18421s] qemu-system-aarch64: terminating on signal 15 from pid 48801 (<unknown process>)


Job seems to be stuck here, killed. (after 5400 seconds of inactivity)
[18425s] ### VM INTERACTION END ###
Comment 2 Richard Biener 2023-03-07 12:38:54 UTC 
Are you sure it's not really stuck?  Is it linking many target libs in parallel?
Comment 3 Martin Liška 2023-03-07 12:41:25 UTC 
(In reply to Richard Biener from comment #2)
> Are you sure it's not really stuck?  Is it linking many target libs in
> parallel?

Dunno, it's slow even on a reasonably fast machine, so I can imagine it can take hours on a slow builder. It's not linking, it's running configure serially.
Comment 4 Andreas Schwab 2023-03-07 13:30:47 UTC 
This appears to be the effect of make's output sync, and configuring umpteen multilibs just takes a long time (3357s during the last sucessful build).
Comment 5 Drea Pinski 2023-03-29 23:55:38 UTC 
aprofile is 10 multilibs and rmprofile is 21 multilibs.
so 31 multilibs in total (if I counted correctly).

that is a lot of building in general.
Comment 6 Sam James 2024-08-02 02:49:02 UTC 
(In reply to Andreas Schwab from comment #4)
> This appears to be the effect of make's output sync, and configuring umpteen
> multilibs just takes a long time (3357s during the last sucessful build).

Yes, I think this is just make -Oline or similar. I see the same sort of thing when I use it. There might be a real problem it was masking but without the logs it's hard to say.