If you don't have 32 bit systems, and you are only able to build a 64 bit gcc, then here's the major headache you're going to have, and it's VERY VERY subtle.
This means that you will need to compile 32 bit code using "gcc -m32". Simple, right? If only.... The PRIMARY REASON that I build both native 32 and 64 bit gcc builds is so that you have a gcc which produces 32 bit output by default, and another which produces 64 bit output by default. This proved to be a HUGE win, because there are a lot of software products for which getting -m32 into the compiler CLI is not at all trivial. Example: boost. David and I both struggled to figure out how to hack the source tree to get it to use either "gcc -m32" or "gcc -m64" consistently. The scripts and hacks were complex and insane. Once we had the native gcc builds, the problem sovled itself, and now boost builds with virtually no special hacks at all. We essentially found a generic solution to a very general purpose problem. Now, having said that, there might be another solution for you here. What we really want is not native 32/64 bit gcc builds, what we really want is a gcc which produces 32 bit output by default (WITHOUT specifying -m32) and one does the same for 64 bit. It just so happens that we accomplished this by building native 32/64 bit builds. I believe that you can compile gcc and SPECIFY what the default output format should be. You might be able to build a 64 bit gcc which produces 64 bit output by default, and then build a 64 bit gcc which produces 32 biut output by default. I am not entirely sure, but this is probably worth experimenting with. Another solution you might try would be to look at how I wrapped gcc on AIX. On AIX 6 at least, you can NOT build a 64 bit gcc. It's just not supported for whatever reason. That means you can ONLY build the 32 bit version. The approach I took was to make the 64 bit version is a wrapper script around the 32 bit version, that sets -m64 when necessary. The code that produces the wrapper script is part of the gnu/gcc efsdeploy rules, which you are already looking at. As you are probably aware, I always try to avoid the wrapper script approach, and use it as a last resort, but it one tool you have at your disposal. The problem is that "testing" it is going to mean building a LOT of binary content for EFS, and seeing how well it works. On Fri, Nov 16, 2012 at 9:38 AM, Steven Jenkins <[email protected]> wrote: > On Thu, Nov 15, 2012 at 5:59 PM, Phillip Moore > <[email protected]> wrote: >> On Thu, Nov 15, 2012 at 4:51 PM, Steven Jenkins >> <[email protected]> wrote: >>> I was looking through >>> gnu/gcc/efsdeploy/hooks/install-post/01_patch_specs as well as the >>> gcclib creation and have two questions: >>> >>> 1- what is the driver behind the following: >>> >>> s{(\%\{\!nostdlib:\%\{\!nodefaultlibs:\%\(link_ssp\))}{$sequence >>> $1}gmsx; >> >> Just a simple, reliable way to get the change we want into the >> generated spec file. Once I figured out how I wanted the spec file >> to change, I found a simple regexp that would get the job done >> generically. >> > > I get the ideal in general, but I mean that line specifically: i.e., > what problem(s) does that line fix? on which platform(s)? > >>> 2- Also, if one is not building all the platforms natively (e.g.., you >>> aren't building x86-32 platforms but only the 64-bit ones), then >>> instead of using the $emulates logic with the merging that is done by >>> the gcclib creation's rsync, you can instead rsync over lib and lib64 >>> separately, setting rpath32 to the lib and rpath64 to lib64. Or is >>> there a problem with that approach? >> >> Well, that's a fair question. You'll have to try that approach, build >> a lot of dependencies, and see what breaks. I'd be very surprised if >> you can actually build only x86-64 binaries, and avoid building x86-32 >> altogether, but feel free to try. >> >> What's there works, and works very well. If you start changing it, >> be prepared for subtle downstream breakage that you'll have fun >> finding and fixing. > > I agree with you that gratuitous changes to this are risky, but I do > not have access to 32-bit systems, so I don't see a lot of choice on > this (and various users have vendor-provided libraries that are > 32-bit, so I have to support linking those). Note that I'm building > with multilib support, so if I did produce 32-bit binaries (e.g., > provide an x86-32.rhel.5, for example), then that would be > cross-compiled anyway, not native. > > I'm definitely open to suggestions. > > Thanks, > Steven > _______________________________________________ > EFS-dev mailing list > [email protected] > http://mailman.openefs.org/mailman/listinfo/efs-dev _______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
