Jeremy Huntwork wrote: > On 3/14/12 11:32 PM, Bryan Kadzban wrote: >> It *almost* looks like sysroot is the equivalent of a DESTDIR >> install, where all the libs are installed into<sysroot >> prefix>/whatever/path, but ask for /whatever/path at runtime (e.g. >> when ld.so is looking for DT_NEEDED entries, or in DT_RPATH entries >> in libs themselves, or when the new compiler is run and it tries to >> find includes) -- is that accurate, or not really? > > Yes, it's like that. If you configure sysroot to be /mnt/lfs then by > default gcc will look in /mnt/lfs/usr/include, etc. for system > headers and so on. But in the proposed method, because we've also > swapped out all hard coded instances of /usr and /lib to be /tools > and /tools/lib, then sysroot is actually configured for > /mnt/lfs/tools/include etc.
I think that could be a little excessive. No matter what compiler configuration flags we use, we will need to change all the hardcoded instances of /usr and /lib to /tools and /tools/lib. (Though /usr could also *potentially* be /tools/usr, I suppose. We have never done that in the past, but I don't see any critical reason it couldn't be done. It's just a *lot* less clean in terms of the compiler search paths, I think.) And we can make the compiler search in the /mnt/lfs prefix with a symlink: /tools -> /mnt/lfs/tools. OTOH there may be other benefits; continuing to read... > Which is all good, it's just enough to get our libc running and then > we build a native compiler and linker that looks in /tools and not > /mnt/lfs/tools This is pass2 binutils/gcc, right? Looks like it from the flags to the gcc configure script; just making sure... >> <possibly not-well-founded opinions below...> >> >> If upstream does endorse sysroot as the way all cross compilers >> should be built, I'm not sure I buy that argument. (But that might >> just be because it's different. :-/) I'm also not sure if they >> actually do; I've heard both this and its opposite asserted. > > It's true, we aren't building a full cross compiler, nor am I > proposing we make full advantage of what sysroot is intended for > (although it is conceivable to cross build your entire system and > bypass chapter 5 completely, I think CLFS has done this). However, > upstream has provided the functionality, and their devs have > evaluated our cross->native build method and said 'use sysroot'. Well... *one* of their devs has looked at the gcc bug and said "use sysroot", at least. OTOH there have been at least a few cases at work where I've built, or been involved in building, some set of programs that I think can be made to solve someone else's problem, when it's really not the best fit for what they need. And I can't tell that, because I'm too invested in the stuff I've written. I'm not saying this particular gcc developer was in that state (of believing the thing they built was appropriate, even when it's not), but having been in it a few times myself, it's hard to notice. I don't know the group of people who work on gcc well enough to know who tends to work on what, so this might also be way out in left field. > Greg says I'm hanging on to this fact 'doggedly', but I think it's an > important consideration. And I disagree that our needs are so foreign > to toolchain devs - they may not have the same goals and motivation > as we do, but they will definitely understand what we are trying to > achieve and are therefore some of the best people to offer technical > opinions. As long as those opinions aren't colored by what they've just been working on, as mine get to be from time to time. :-) >> If I understand what it is, then I think sysroot is a good idea for >> real cross compilation, where the host can't execute binaries built >> for the target, because you'll need a different ld.so. But we're >> not doing that, either, except possibly when converting from a >> 32-bit system under a 32-bit kernel, to a 64-bit system (either >> multilib or pure64); the old kernel won't load the new binaries. > > No, we're not - but we are trying to keep anything from the host > 'out'. Sure, but a "real" cross compiler *could* do that (in theory) by looking at file types at runtime, while still searching the host system. It's not necessarily the case that sysroot will definitely always do this. It's harder to do that with include files, of course, since they don't tag themselves with an architecture type (except using preprocessor symbols, in which case it probably doesn't matter which file you get). (In fact I've seen a few cases where the build system for some random program tries to link in the 32-bit version of libgcc or libdl or something like that, dumping a warning to stderr from the linker. But because it also asks for the 64-bit file, everything ends up working. OTOH this is after the chroot, and doesn't happen with base LFS packages as far as I know. It's beyond-BLFS stuff IIRC.) > We go to great lengths to make sure that the toolchain is kept > 'clean' from the host system and from what I've seen, this is the > best way to do it. It seems like there are four different things that we need to ensure are not found on the host: - include files - libraries (including gcc internal libs like libgcc, or the startfiles) - helper binaries (as, ld, cpp, etc.) - config files (specs file if it exists, ld.so.conf) We currently use -B/tools/lib/ for the helper binaries, and the patch for some of the startfiles, but the existing setup works fine for everything else here. And poking at pass1 gcc's -dumpspecs output, it's either not-terribly-hard, or impossible, to override the path to the helper binaries in the specs file. It *might* work to replace "as" and "collect2" with the full proper paths. Of course, this might have been tried, as well, and might fail badly for the temp compiler(s) built during pass2, even if it works on the pass1 compiler.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
