RFC: proposed macro deffinitions for F-13

[Dennis Gilmore]

Hi All,

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.

Dennis

[Eric Sandeen]

Dennis Gilmore wrote:
>  Hi All,
>  
>  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.
>  
>  Dennis
>   
I have hacks like this in e2fsprogs.spec for example:


%ifarch %{multilib_arches}
mv -f %{buildroot}%{_includedir}/ext2fs/ext2_types.h \
      %{buildroot}%{_includedir}/ext2fs/ext2_types-%{_arch}.h
install -p -m 644 %{SOURCE1} %{buildroot}%{_includedir}/ext2fs/ext2_types.h
%endif

Unless I'm doing a Bad Thing here, maybe some macros to facilitate this
type of header mangling for multiarch?

-Eric

[Dennis Gilmore]

On Tuesday 27 October 2009 12:45:10 pm Eric Sandeen wrote:
>  Dennis Gilmore wrote:
>  > Hi All,
>  >
>  > 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.
>  >
>  > Dennis
>  
>  I have hacks like this in e2fsprogs.spec for example:
>  
>  
>  %ifarch %{multilib_arches}
>  mv -f %{buildroot}%{_includedir}/ext2fs/ext2_types.h \
>        %{buildroot}%{_includedir}/ext2fs/ext2_types-%{_arch}.h
>  install -p -m 644 %{SOURCE1} %{buildroot}%{_includedir}/ext2fs/ext2_types.h
>  %endif
>  
>  Unless I'm doing a Bad Thing here, maybe some macros to facilitate this
>  type of header mangling for multiarch? 
right now you need to define multilib_arches for that to work with my proposed 
changes you could drop your defines  and use 
%ifarch %{multilib64} %{multilib32}

maybe we want to define a multilibarches macro also   that way if/when we add a 
new multilib arch. we make one changes and rebuild everything and we support 
it. rather than changing potentially hundresd of spec files.  of course they 
will need to be changed to use the new macros.


Dennis

[Eric Sandeen]

Dennis Gilmore wrote:
>  On Tuesday 27 October 2009 12:45:10 pm Eric Sandeen wrote:
> > Dennis Gilmore wrote:
> >> Hi All,
> >>
> >> 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.
> >>
> >> Dennis
> > I have hacks like this in e2fsprogs.spec for example:
> >
> >
> > %ifarch %{multilib_arches}
> > mv -f %{buildroot}%{_includedir}/ext2fs/ext2_types.h \
> >       %{buildroot}%{_includedir}/ext2fs/ext2_types-%{_arch}.h
> > install -p -m 644 %{SOURCE1} %{buildroot}%{_includedir}/ext2fs/ext2_types.h
> > %endif
> >
> > Unless I'm doing a Bad Thing here, maybe some macros to facilitate this
> > type of header mangling for multiarch?
>  
>  right now you need to define multilib_arches for that to work with my proposed 
>  changes you could drop your defines  and use 
>  %ifarch %{multilib64} %{multilib32} 
Right, I was hoping for maybe some macros to make my above mess simpler;

%{do_magic_header_stuff} header1.h header2.h ...

-Eric

[Adam Jackson]

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} ?

In general I'd kind of prefer to see headers modified to use gcc's
predefines for __SIZEOF_LONG__ and friends instead, but I'll take what I
can get.

- ajax

[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} ?
>  
>  In general I'd kind of prefer to see headers modified to use gcc's
>  predefines for __SIZEOF_LONG__ and friends instead, but I'll take what I
>  can get. 
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

[Jakub Jelinek]

On Tue, Oct 27, 2009 at 01:24:33PM -0500, Dennis Gilmore wrote:
>  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.  
That's because %{ix86} gcc isn't multilib capable, unlike e.g. ppc/ppc64
or sparcv9/sparc64 where the support is symmetric (32-bit gcc can compile
64-bit code and vice versa), on x86_64 you need x86_64 gcc to be able to
compile 64-bit stuff.

	Jakub

[Alexander Boström]

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"

Then "ix86" would indeed not be in multiliob32. (It should rather be in
"multilib" then, for symmetry...)

/abo

[Dennis Gilmore]

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

[Ville Skyttä]

On Tuesday 27 October 2009, Adam Jackson wrote:

>  +%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} ? 
Hm, maybe a stupid question: in what sense are %{ix86} multilib in the first 
place?

[Dennis Gilmore]

On Tuesday 27 October 2009 03:48:13 pm Ville Skyttä wrote:
>  On Tuesday 27 October 2009, Adam Jackson wrote:
>  > +%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} ?
>  
>  Hm, maybe a stupid question: in what sense are %{ix86} multilib in the
>   first place? 
when you install %{ix86} packages on a x86_64 system.  same for ppc
and 
%{sparc32} and s390.  

Dennis

[Josh Boyer]

On Tue, Oct 27, 2009 at 12:40:14PM -0500, Dennis Gilmore wrote:
> +# arch macro for all supported 32 bit builds
> +%32bitarches %{ix86} %{sparc32} %{arm} s390
> +# arch macro for all supported 64 bit builds
> +%64bitarches x86_64 %{sparc64} ia64 s390x %{alpha}  
missing ppc and ppc64 respectively here, aren't you?

josh

[Dennis Gilmore]

On Tuesday 27 October 2009 02:17:57 pm Josh Boyer wrote:
>  On Tue, Oct 27, 2009 at 12:40:14PM -0500, Dennis Gilmore wrote:
>  >+# arch macro for all supported 32 bit builds
>  >+%32bitarches %{ix86} %{sparc32} %{arm} s390
>  >+# arch macro for all supported 64 bit builds
>  >+%64bitarches x86_64 %{sparc64} ia64 s390x %{alpha}
>  
>  missing ppc and ppc64 respectively here, aren't you?
>  
>  josh 
indeed i am sorry  this should be better

Dennis

[Jesse Keating]

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'm not really a fan of growing more macro goo, particularly if it's
Fedora specific macro goo :/

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Dennis Gilmore]

On Tuesday 27 October 2009 03:17:15 pm Jesse Keating 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'm not really a fan of growing more macro goo, particularly if it's
>  Fedora specific macro goo :/
>   
the multilib ones were the only ones i intended to put in redhat-rpm-config 
though im just as happy to try and get it into rpm.  the rest i had intended 
to get into rpm.

Dennis