https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #37 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Wed, 9 Oct 2019, stsp at users dot sourceforge.net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 > > --- Comment #36 from Stas Sergeev <stsp at users dot sourceforge.net> --- > (In reply to jos...@codesourcery.com from comment #35) > > what you want. I'm familiar with many of the details through having > > written multiple such build systems myself. > > But even you do make the wrong expectations. > Most of your suggestions (which are very reasonable by > themselves) do not work or require additional tweaks. > configure reacts inadequately on them. They're essentially hints about approaches to look at - not full recipes, because that ends up in writing a whole build system. > Does --with-sysroot disable prefix, or prefix should > be set to '/' explicitly? Or to something else? A toolchain always has a prefix, as configured using --prefix=. --with-sysroot sets a sysroot path (normally under the prefix, but that isn't required). In the case where the target has an OS with a root filesystem that can have libraries and headers installed for native compilation, the --with-sysroot directory is expected to be laid out like the relevant parts of the target's root filesystem. > If I naively do > --with-build-sysroot=$DESTDIR --with-sysroot=/ > why this won't work? I suppose there will be some > differences in a directory layout, like no $target > dir, but otherwise it can work? The build sysroot directory needs to contain the target libraries. For example, include/ or usr/include/ (depending on how the toolchain is configured) under that directory should contain headers, lib/ or usr/lib/ should contain .a and .so files. These need to be files for the target. > You suggest --with-sysroot=$prefix/$target but I > don't understand why is so, as normally I have > (1) $prefix/bin/$target-gcc > and > (2) $prefix/$target/bin/gcc > If I set --with-sysroot=$prefix/$target then I > can get (2), but how to get (1)? I advise ignoring the files in $prefix/$target/bin/, which are nothing to do with the sysroot (they are host binaries). They aren't intended to be run directly; they're an implementation detail. Some, such as the binutils ones ($prefix/$target/bin/as etc.) may be run automatically by GCC. Others, such as $prefix/$target/bin/gcc, may be of little use (unless the compiler ends up using them when it re-execs the compiler driver when linking, which can happen in certain cases - if it does, it sets environment variables to allow it to work properly). > I think this is an rtfm point, is this sysroot trick documented > anywhere? I think it falls between the cracks of the different toolchain components. Each component documents how to configure and build that component, in isolation. But this trick is part of how you build a whole toolchain rather than part of how one component is built, so no one component is the right place to document it. Existing build systems such as crosstool-ng are a good place to look for such tricks. However, many such build systems are full of tricks that once were necessary but haven't been for many years, or approaches that still work but have long been obsolescent. When writing build-many-glibcs.py I tried to use the preferred current approach to everything and avoid those obsolescent tricks, but that only shows you one case of building toolchains for a glibc target (and without the relocation issues being discussed in this bug, as those weren't relevant for that script).
