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)?
It doesn't "fix" anything. Look at what $sequence is set to. This is how we get the rpath we want into the binaries generated by our gcc builds. > >>> 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. Well, I can't really help you here, you're on your own. You *might* be able to build the native 32bit gcc on a 64bit platform, but we had problems getting that to work a few years ago. Try it, and see!! IM!HO, if you are going to be investing the effort in building your own compiler suite like this, maybe you should get someone to build you a 32 bit OS image. Now, alternately, you can just download the binaries I've built, if you can't get this done yourself. Set up the download mechanism to pull down the stuff from ftp.openefs.org, and you can get the gnu metaproj contents I've rebuilt in the last couple of weeks. I can't promise that I'll keep those uptodate, though. That's a teaser for the email I'm about to send in a minute.... _______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
