On Tue, Nov 6, 2012 at 2:10 PM, Phillip Moore <[email protected]> wrote: > On Tue, Nov 6, 2012 at 12:53 PM, Steven Jenkins > <[email protected]> wrote: >> I've been working on gcc recently (gcc 4.7.2, primarily on RHEL 5 & >> RHEL 6) and am encouraged to see others are doing so (Note: I've not >> been using the efs-deploy-config-gnu-gcc infrastructure, but I'm >> looking at it as a baseline). I have a couple of observations: > ... >> 2- Are there some test cases out there for multilib handling? I've >> put together some tests I'm doing for that handling, but it would be >> great if we had a consistent test suite. Once I have things converted >> to this infrastructure, I'm happy to submit what I have. > > If by test case you mean a distribution that is built using the > multilib functionality, I don't know. First of all, the "test suite" > for builds of gcc isn't even used, since it requires autogen, and I've > never had much luck getting that (and it's myriad dependencies) to > build.
I also skip the gcc test suite, as the dependencies and infrastructure are a bear. > > Are you talking about getting the normal gcc test suite to work, or > are you talking about building a distribution of some other software > that will test/verify the multilib bits? > The latter. For example, take two trivial C programs: - somelib.c, to be built 32-bit - driver.c, with a dependency on somelib.o (main() is in driver.c) so the two tests are: 1- can somelib.o be built as a 32-bit object on a 64-bit system -- this isn't a common use case, by the way; it's just needed for the next test 2- can driver be built on a 64-bit platform and 'do the right thing' with the 32-bit somelib.o -- this is the common use case I've seen our users encounter (ie, they've gotten a 32-bit library from some vendor, and now they need to use it on a 64-bit platform) I've had user reports of some awkwardness linking things like that correctly, and I'm experimenting with some different specfile modifications & gcclib layouts to see if there is an easier way to support compiles with vendor-supplied 32-bit libs. Adding additional link directives is the usual mechanism I recommend, but I'd like to see if we can get the specfile & gcclib configured so that the search path mechanism finds the right libraries automatically. Suggestions welcome there. > In general, the efsdeploy build system avoids the need for using the > multilib stuff by providing both 32 and 64 bit native tool chains, > that produce the right default output. In practice, that means you > very rarely build a 32 bit binary using the 64 bit compiler, or vice > versa (that does work, BTW, on some platforms). > >> 3- I notice fortran just got removed. Do people actually need >> Objective C? (ie, --enable-languages objc) > > I have no idea -- I've always built gcc with those languages, and > added fortran when it worked, an wasn't a PITA to build. In the 25 > years I've been building gcc for people, I've very rarely had requests > for fortran. I can count them on one hand, I think. It's rare in my experience as well, although I recently had to build the ATLAS stack for someone (including LAPACK), and the user wanted some fortran bits turned on, so it was necessary there. Thanks, Steven _______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
