Quick update on this, reverting to purely using LFS-6.8 works fine. That's glibc-2.13 and gcc-4.52, so not quite what I'm going for, but with that toolchain I might be able to do a raw build of glibc-2.12.2, and then gcc-4.8.3. I'll proceed and let y'all know.
On Tue, Apr 18, 2017 at 8:23 PM Joe Weidenbach <[email protected]> wrote: > Hello all, > > First off, it's been a loooong time. I was around back in the dark ages > of LFS 1 and 2, and have been using LFS on and off ever since for my home > and business systems. If anyone else is still around from those old days > (I was SCDrumz back on the IRC), Howdy! It's great to see LFS so healthy > after all these years. > > I'm trying something out, on a brand new LFS-8.0 system, and probably am > just loving pain a bit too much. But, because it's linux and because I am > stubborn, I'm continuing to try nonetheless. I've got the full 8.0 system > up and running, complete with plasma 5. It's a thing of beauty. > > I am, however, a VFX artist and developer, and as such am trying to get a > development environment up and running. The current VFX platform (CY17) > calls for Glibc-2.12 and GCC-4.8.3: http://www.vfxplatform.com/. > > The quintessential system most VFX Software is built for is RHEL 6.8 (or > CentOS if you prefer). Most installs on Ubuntu have to go through some > translation (it's all proprietary in my world). Yes, I'm aware how old > that is. I've got most everything working on Ubuntu 16.04 though, with > glibc-2.23 on the desktop side, so there's at least a chance I should still > be able to get this going without the VM or docker route. (Also Centos 6.8 > won't even boot to the installer on my late-2015 hardware, so just > installing the older system isn't an option) > > I'm trying to set up a cross-compiling toolchain based on the CY17 spec, > and I figured what better to follow than the LFS toolchain setup. I've > successfully gotten glibc-2.12.2 and gcc-4.8.3 building with binutils-2.27 > (and if a lower-versioned binutils is the answer, huzzah!), but at the end > of the first pass, the sanity check fails. > > As written, it actually passes; readelf -l actually returns the correct > value for my ld-linux.so. But, trying to run ./a.out results in a > segfault. I've put it through both gdb and valgrind, and the failure is in > dl-init.c somewhere. running strings on my gcc and libc.so.6 shows that I > built with my gcc-4.8.3, and ldd works just fine. Moreover, the individual > executables run without segfaulting, but the moment I try to compile the > dummy.c, it's like the whole thing goes crazy. Across the numerous > rebuilds I've done (starting fresh and blowing away my toolchain dir each > time), it's been very consistent. I do install texinfo-4.13 and make-3.82 > in my toolchain up front after binutils (the gcc build fails with > texinfo-6.3, and glibc fails with make-4.2.1). > > All that said, I'm aware that this might all be a pipe dream, and using my > bleeding-edge development system to do actual work (to the specs for my > field) might not be possible. I'm glad to post logs if anyone wants them, > I've scoured them and not found anything useful. GCC, Glibc, and binutils > are all compiling without errors at this point (there's lots of c++11 > warnings in the gcc build, but I'm not overly worried about those--I assume > that readelf -l working indicates the compiler itself is working, and the > error is more likely in glibc), so I feel like I'm 99.9% there--if I can > get the dummy.c to not segfault I should be able to move forward with the > toolchain. But, I've searched google to no end and found nothing. Does > anyone have a starting point for me to try and track down what's failing? >
-- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
