On Fri, 2021-09-24 at 14:13 -0700, Oleg Smolsky via Gcc-help wrote: > ...and the workaround for that issue was to add `--target=x86_64- > linux-gnu` > which, as I understand it, switches the build into the cross-compiler > mode. > I think there was some variance in the treatment of that flag in GCC > versions 7/10/11... > > Curiously, `--target=x86_64-pc-linux-gnu` does not help... I am > guessing > that matches the host... And also, the generated executable bundle > only has > full names like `x86_64-linux-gnu-c++`, there are no `c++`, `cpp` etc. > > Can anyone shed some light on this aspect of the build process please? I'm not sure how do you mean by "sysroot GCC". If you want a compiler running on the existing host system but produce executables running in the sysroot (after reboot/chroot into it), yes you need to build GCC as a cross compiler because the output of the compiler normally can't run on the host. It's better to use "--target=x86_64-sysroot-linux-gnu" to make it clear that you're building a cross compiler. If you don't like the prefix in the executable name, I think it's able to override it with --program- prefix="" (not tried). If you want a compiler running in sysroot (after reboot/chroot into it), cross-compile it with a cross compiler (using --host=x86_64-sysroot- linux-gnu). You may find some way to pretend the executables for sysroot "runnable on the host", but it's not the expected usage of GCC building system and likely to be broken if something in the building system changes. > > > On Thu, Sep 23, 2021 at 6:42 PM Oleg Smolsky <osmolsky@xxxxxxxxxxxx> > wrote: > > > Hello there! I'm trying to setup a GCC 11.2 using --with- > > sysroot=$sysroot > > (into which glibc is already installed). I get far enough to have > > `xgcc` > > executable (which works). The executable itself is configured to get > > glibc > > from sysroot (I did that via LDFLAGS): > > > > ``` > > $ ldd ./gcc/xgcc > > linux-vdso.so.1 (0x00007ffec27d7000) > > libm.so.6 => /opt/sysroot/usr/lib/libm.so.6 > > (0x00007fc12463c000) > > libc.so.6 => /opt/sysroot/usr/lib/libc.so.6 > > (0x00007fc124440000) > > /opt/sysroot/usr/lib/ld-linux-x86-64.so.2 => > > /lib64/ld-linux-x86-64.so.2 (0x00007fc124718000) > > ``` > > > > where > > LDFLAGS="-Wl,--dynamic-linker,$sysroot/usr/lib/ld-linux-x86- > > 64.so.2,--rpath,$sysroot/usr/lib" > > > > Things break a little further down the road when building libgomp: > > > > checking whether we are cross compiling... configure: error: in > > `.../gcc11sr/_obj/x86_64-pc-linux-gnu/libgomp': > > configure: error: cannot run C compiled programs. > > > > The issue here, it seems, is the absence of LDFLAGS that I had > > passed to > > the top-level `configure` script. We can see the compiler invocation > > in the > > log: > > > > configure:3996: .../gcc11sr/_obj/./gcc/xgcc - > > B.../gcc11sr/_obj/./gcc/ > > -B/opt/gcc-11sr/x86_64-pc-linux-gnu/bin/ > > -B/opt/gcc-11sr/x86_64-pc-linux-gnu/lib/ -isystem > > /opt/gcc-11sr/x86_64-pc-linux-gnu/include -isystem > > /opt/gcc-11sr/x86_64-pc-linux-gnu/sys-include -o conftest -g -O2 > > conftest.c >&5 > > > > The compiler yields a correctly-formed executable when I take that > > very > > command line and add LDFLAGS. > > > > So, finally my question: is this the right way to build a > > "sysrooted" GCC? > > IIRC this recipe worked in the GCC7 days... > > > > Thanks in advance, > > Oleg. > > -- Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
