Greg Schafer wrote: > Conversely, the more I think about it, the more I don't like it.. will say > more after I've done some analysis. However, I haven't written it off yet..
Looking forward to it. > We are trying to eliminate the "target ld doesn't like host libc" issue, > aren't we? If so, the above test case tells us immediately because we know > it doesn't work. Anyhoo, I'll follow up when I have some more facts. If you recall, there were two issues with the host I mentioned. First we hit the ld issue, but that can be resolved as we've already noted in this thread. Even after fixing this, there remains an issue with bootstrapping GCC pass 1 (the actual error appears to be related to a mis-generated spec file for stage 2 - I can set this up again if you need to see the exact error), and the root cause is probably connected to the multilib setup. If the problem is due to a multilib setup, then I would think we would want to account for it in our build method. It would allow us to build from a wider range of hosts. If there is truly something wrong with the host's libc such that we can't bootstrap GCC, but we can produce a minimal GCC from it - a gcc capable enough to in turn build a usable temporary libc which is proven solid by both the ability to bootstrap gcc against it and possible testing after we make libgcc_s.so.1 - doesn't that make the build method itself more robust? Perhaps there's something I'm not quite seeing correctly - I'm sure you'll let me know if so... :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
