native compiler linked to another glibc

native compiler linked to another glibc

[Bill Cunningham]

I have a different binutils and gcc that works fine and is connected to 
the system libc. Whew, that's the important thing.

     I compile a newer glibc and save it in a a path in /mnt. The 
problems I seem to be running into I believe are addressed in that FAQs, 
at least in a similar form. I compile, or try to, a native compiler that 
will be attached to the new glibc (not the system glibc).

/source/gcc/configure --prefix=/mnt --disable-bootsrap 
--disable-multilib --disable-nls --enable-languages=c,c++ \

--with-build-time-tools=/mnt/bin CC=/mnt/old-gcc/bin/gcc 
CXX=/mnt/old-gcc/bin/g++

The binutils are in the /mnt/bin. I set '--with-build-time-tools' for 
the binutils. Compilation goes for some time and the compilation wants 
the newer includes from the new glibc. Now the path the compiler seems 
to want to look at is '/usr'bin'. For the linker. '/usr/bin/ld'. I don't 
want it to look there. And there is a complaint that /mnt/lib does not 
contain libc.a not lib_nonshared.a and another statically created 
library. I have not used the '--disable-shared' switch nor it opposite. 
Those libraries are also there. IDK why the compiler can't find 
libraries that are there unless there are links that are not set right. 
And why is it running the system ld and not the test compiler's 'ld'. Hum.

Also' /lib/cpp isn't found', it is in /bin/cpp. It needs to also be in 
/lib, so I will set a link next time. But why is the system linker in 
'/usr/bin/ld' being used and not '/mnt/bin/ld'?

B

Re: native compiler linked to another glibc

[Jim Wilson]

On Fri, Dec 24, 2021 at 6:20 PM Bill Cunningham via Gcc-help <
gcc-help@gcc.gnu.org> wrote:

>      I compile a newer glibc and save it in a a path in /mnt. The
> problems I seem to be running into I believe are addressed in that FAQs,
> at least in a similar form. I compile, or try to, a native compiler that
> will be attached to the new glibc (not the system glibc).
>

Adding a -v option to a gcc command will show what is happening inside the
gcc driver, and might give a clue as to what is going on.

Using your own glibc which is not installed in the normal location is
complicated.  I would suggest looking at
    https://sourceware.org/glibc/wiki/Testing/Builds#Testing_a_glibc_build

Note that some glibc libraries are actually linker scripts, and may have
references to /usr embedded in them.  This is why the glibc wiki recommends
using sysroot to point at the new glibc.

Jim