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
