RFC: proposed macro deffinitions for F-13

Dennis Gilmore dennis at ausil.us
Wed Oct 28 18:22:05 UTC 2009


On Wednesday 28 October 2009 01:41:34 am Alexander Boström wrote:
> tis 2009-10-27 klockan 13:24 -0500 skrev Dennis Gilmore:
> > On Tuesday 27 October 2009 01:16:46 pm Adam Jackson wrote:
> > > On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote:
> > > > Id like to get some feedback on the patches that i'm proposing for
> > > > F-13. quite a few packages that need to deal with differences between
> > > > 32bit/64bit  or multilib arches have defines for the appropriate
> > > > arches. sometimes incomplete since they don't include secondary
> > > > arches.
> > > >
> > > > I wanted to get some feedback. and see if there are other cases we
> > > > should add.
> > >
> > > +%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
> > > +%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
> > >
> > > Remind me what the asymmetry is for here?  Why is %{ix86} not in
> > > %{multilib32} ?
> 
> [...]
> 
> > it should be the attached patch.  the initial one was based on what gcc
> > does in its spec.  it treats %{ix86} as  not being multilib.
> >
> > +%multilib32 %{ix86} %{sparc32} ppc s390
> > +%multilib64 x86_64 %{sparc64} ppc64 s390x
> 
> I thought the idea was: "multilibXX" is arches where libs go in "libXX"

thats only part of it.  the other issue you hit is that alot of packages have 
wrapper headers and the put the real headers in with -32 or -64 prefixes

so /usr/include/foo.h includes foo-32.h or foo-64.h depending on the arch your 
building for. this is to make sure headers dont conflict on multilib arches.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20091028/3cca39ef/attachment.sig>


More information about the fedora-devel-list mailing list