[Bug other/82708] libmpx fails to compile due to PATH_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708 --- Comment #7 from joseph at codesourcery dot com --- On Wed, 25 Oct 2017, keno at juliacomputing dot com wrote: > First, the build process looking for the headers in /sys-include rather > than /include where glibc installs them. Leads to the same symptoms as > reported in this issue. You should be using a sysroot; directories such as $target/include and $target/sys-include should only ever have libc headers in bare-metal cases where you're using e.g. newlib and the concept of a native directory structure is meaningless. The sysroot must *not* be the same as the $prefix where the compiler is installed, or as $prefix/$target; it needs to be another directory, e.g. $prefix/$target/sysroot. glibc must be configured with --prefix=/usr and installed under the sysroot. > Then, I tried using --with-sysroot which I wasn't using before, but then I got > confusion between /usr/include and /include (most parts of $sysroot/include should not exist. Again, sysroot must not be $prefix/$target. (However, sysroot/lib and sysroot/usr/lib must exist even for configurations using directories such as lib64, though they can be empty directories in that case. Again, see how build-many-glibcs.py does things.)
[Bug other/82708] libmpx fails to compile due to PATH_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708 Keno Fischer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Keno Fischer --- I have unsuccessfully tried to make that option work. I am able to build glibc with the bootstrap compiler, but the second stage build invariably fails. I ran into a bunch of problems. First, the build process looking for the headers in /sys-include rather than /include where glibc installs them. Leads to the same symptoms as reported in this issue. Then, I tried using --with-sysroot which I wasn't using before, but then I got confusion between /usr/include and /include (most parts of the build system looking in usr/include, but others such as when building libgcc seem to be looking in /include/). If I symlink those paths together things progress farther but eventually fail to link. I also tried replicating the glibc script you pointed to, without much luck (some mixture of the above symptoms). Given that I get a well functioning cross compiler, using the original recipe with a simple patch to mpxrt-utils.c to bypass the broken limits.h file, I'm tempted to move on and leave this be. I'll note at this point that e.g. http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass2.html also suggests patching the limits.h file manually, so at least I'm not the only one. I guess I had hoped that there was something that could be done in the gcc build system to make this experience less frustrating for the next person. If not that, a modern guide on how to do this by somebody who knows how it's supposed to be would be great, since all the guides out there seem to have some step of "and this is where we hack around gcc/glibc's broken build systems". It sounds like things have improved since those guides were written, which is great, but I have no idea what the right commands are. I am grateful you took the time to answer my questions here.
[Bug other/82708] libmpx fails to compile due to PATH_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708 --- Comment #5 from joseph at codesourcery dot com --- The expectation for bootstrapping such a cross toolchain is that GCC is configured and built twice. The first build is static-only, C-only, inhibit-libc, disables lots of libraries such as libmpx. That is used to build and install glibc. The second build of GCC, configured with glibc present, is fully functional with all required languages. See what glibc's build-many-glibcs.py script does for details of the modern approach for bootstrapping cross toolchains with glibc.
[Bug other/82708] libmpx fails to compile due to PATH_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708 --- Comment #4 from Keno Fischer --- Ah, ok sorry I was confused. I probably should have mentioned that I'm doing a cross compile to a glibc based system, so I'm building the compiler, then building glibc, and then going back and building the runtime libraries. The exact script I'm using is here: https://github.com/staticfloat/julia-docker/blob/master/workerbase/lib/build_crosscompiler.sh So at the compiler build stage, the limits.h header indeed does not exist, but it does exist once we go back to build the rest of the runtime libraries (because we built glibc in the meantime). Is there something I should be running to regenerate these files before building the runtime libraries?
[Bug other/82708] libmpx fails to compile due to PATH_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708 --- Comment #3 from joseph at codesourcery dot com --- That's not the test I'm talking about. The relevant one is gcc/Makefile.in's LIMITS_H_TEST, run during a build stage rather than a configure stage, so you need to look at the setting of BUILD_SYSTEM_HEADER_DIR and how it got that value.
[Bug other/82708] libmpx fails to compile due to PATH_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708 --- Comment #2 from Keno Fischer --- It looks like different parts of the build system may be disagreeing on that. I see checking limits.h usability... yes in the log in one place and then checking limits.h usability... no later in the same log. Are there different usability checks for this header?
[Bug other/82708] libmpx fails to compile due to PATH_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708 --- Comment #1 from joseph at codesourcery dot com --- If you have correctly configured GCC so that it can find the system headers at configure time, include-fixed/limits.h should be constructed as a concatentation of limitx.h, glimits.h and limity.h and thus include libc's limits.h indirectly. If $(LIMITS_H_TEST) failed to find the system headers, that's what you should be debugging.
