On 12/21/07, Kaz Kylheku <kaz@xxxxxxxxxxxxxxxxx> wrote: > "NightStrike" <nightstrike@xxxxxxxxx> wrote: > > When you say "the root of the target filesystem", do you mean that > > it's the root of a directory structure containing target files that > > will be used while creating the toolchain, or that it's the root of a > > directory structure where the final toolchain, once built, will look > > for target files? I'm guessing the answer is "both"..... > > The asnwer is both. For instance, suppose you're making a cross-compiled > LInux system, and building a final user-space GCC which is integrated with > the GNU C library. > > You would already have glibc built into the sysroot (as well, you'd of > course spin it into a package to install on the target system). > > >> If we made that the sysroot, these would get mixed into the root. > > > > Is it absolutely *required* that the sysroot be a subdirectory of > > prefix to make the final toolchain relocatable, or is this where > > with-build-sysroot comes into play? > > More precisely, from http://gcc.gnu.org/install/configure.html: > > `` If the specified directory is a subdirectory of ${exec_prefix}, then it > will be found relative to the GCC binaries if the installation tree is > moved. '' > > I think where --with-build-sysroot comes into play is that it allows these > target system materials (like glibc) to be pulled from somewhere other than > the sysroot location during the building of the cross compiler. > > This provides some flexibility as to how to structure the cross compiler > build process, in certain situations. > > I've built an entire Linux distro, including a cross toolchain that runs on > a build systems /and/ a native toolchain that runs on the target, without > ever needing to use --with-build-sysroot. It wouldn't be that helpful > because as soon as the compiler is built with the glibc materials, I want to > run it. And at that point, those materials must be in the sysroot location. > But I can imagine some situations where you don't want to run the compiler > that is built, but perhaps package it for someone else to run somewhere > else. That is what I am trying to do. To build a cross compiler, I have thus far been doing this: configure binutils with prefix=with-sysroot=/tmp/rt, having preloaded /tmp/rt/mingw/include with all of the system headers. make / install configure gcc the same way make all-gcc / make install-gcc build the runtime crt and libs, putting all of those files into $(prefix)/$(arch)/lib build the full gcc doing 'make && make install' Then I'd tar up the rt/ directory and give it to someone. This worked fine, and was even relocatable on all the systems I tried it on. It wasn't as portable as I thought, however, and as far as I understand the documentation, it shouldn't be portable at all. So, I try your method: configure binutils with prefix=/tmp/rt with-sysroot=/tmp/rt/sys-root (making sure to preload /tmp/rt/sys-root/mingw/include with all of the system headers, like I did before.) make / install configure gcc the same way make all-gcc / make install-gcc build the runtime crt and libs, putting all of those files into /tmp/rt/sys-root/mingw/lib build the full gcc doing 'make && make install' This is where it dies as follows: In file included from ../../../gcc/libgcc/../gcc/libgcc2.c:33: ../../../gcc/libgcc/../gcc/tsystem.h:90:19: error: stdio.h: No such file or directory ../../../gcc/libgcc/../gcc/tsystem.h:93:23: error: sys/types.h: No such file or directory ../../../gcc/libgcc/../gcc/tsystem.h:96:19: error: errno.h: No such file or directory ../../../gcc/libgcc/../gcc/tsystem.h:103:20: error: string.h: No such file or directory ../../../gcc/libgcc/../gcc/tsystem.h:104:20: error: stdlib.h: No such file or directory ../../../gcc/libgcc/../gcc/tsystem.h:105:20: error: unistd.h: No such file or directory In file included from /var/tmp/build/gcc-svn/build-x86_64-pc-linux/./gcc/include-fixed/syslimits.h:7, from /var/tmp/build/gcc-svn/build-x86_64-pc-linux/./gcc/include-fixed/limits.h:11, from ../../../gcc/libgcc/../gcc/tsystem.h:108, from ../../../gcc/libgcc/../gcc/libgcc2.c:33: /var/tmp/build/gcc-svn/build-x86_64-pc-linux/./gcc/include-fixed/limits.h:122:61: error: no include path in which to search for limits.h In file included from ../../../gcc/libgcc/../gcc/libgcc2.c:33: ../../../gcc/libgcc/../gcc/tsystem.h:111:18: error: time.h: No such file or directory make[2]: *** [_muldi3.o] Error 1 make[1]: *** [all-target-libgcc] Error 2 make: *** [all] Error 2 I don't understand that error. It says, for instance, that limits.h can't include limits.h. How is that possible? It also can't find any of the system headers that are in place. Why is there such drastic changes in the outcome of a toolchain build when all I did was move the location of the sysroot from being equal to prefix to being a subdirectory of prefix?
