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
