Do you know how many 64-bit architectures Fedora has?

[Marcin Juszkiewicz]

Hi

During last few days I fetched over 26 thousand of Fedora package 
repositories. Plan to go though all spec files and submit some patches 
mainly related to my aarch64 work.

We live in a world where most of Linux systems are either 32 or 64 bit. 
But do you know how many 64-bit architectures Fedora and RHEL have?

According to spec files we have at least 8 while current Fedora has 1 
primary and 4 secondary ones.

x86-64 is main one which most of developers use for everything
aarch64 is my favourite secondary one
ppc64 is probably fastest one
ppc64le is little endian version of previous
s390x is fridge size mainframe (is such small exist)

Specs also mention ia64 (not supported Itanium), alpha (I have some 
friends who still own them but do not run), sparc64/sparcv9 (even Debian 
got rid of sparc support).

But why I write?

Because there are lot of code like:

%ifarch x86_64 ppc64 ia64 s390x sparc64
     USE_64=1
%endif

Where is should be:

%if 0%{?__isa_bits} == 64
  USE_64=1
%endif

Which works since RHEL6 (from what I know). And it automatically covers 
all 64-bit architectures not only those which maintainer remembers.

So please do me a favour and take a look at your packages and adapt 
their spec files. Otherwise sooner or later such patch may land in 
bugtracker but instead I could fix some other package at same time.

[Neal Gompa]

On Mon, Aug 24, 2015 at 9:12 AM, Marcin Juszkiewicz <mjuszkiewicz(a)redhat.com
>  wrote: 
>  Hi
>
>  During last few days I fetched over 26 thousand of Fedora package
>  repositories. Plan to go though all spec files and submit some patches
>  mainly related to my aarch64 work.
>
>  We live in a world where most of Linux systems are either 32 or 64 bit.
>  But do you know how many 64-bit architectures Fedora and RHEL have?
>
>  According to spec files we have at least 8 while current Fedora has 1
>  primary and 4 secondary ones.
>
>  x86-64 is main one which most of developers use for everything
>  aarch64 is my favourite secondary one
>  ppc64 is probably fastest one
>  ppc64le is little endian version of previous
>  s390x is fridge size mainframe (is such small exist)
>
>  Specs also mention ia64 (not supported Itanium), alpha (I have some
>  friends who still own them but do not run), sparc64/sparcv9 (even Debian
>  got rid of sparc support).
>
>  But why I write?
>
>  Because there are lot of code like:
>
>  %ifarch x86_64 ppc64 ia64 s390x sparc64
>      USE_64=1
>  %endif
>
>  Where is should be:
>
>  %if 0%{?__isa_bits} == 64
>   USE_64=1
>  %endif
>
>  Which works since RHEL6 (from what I know). And it automatically covers
>  all 64-bit architectures not only those which maintainer remembers.
>
>  So please do me a favour and take a look at your packages and adapt their
>  spec files. Otherwise sooner or later such patch may land in bugtracker but
>  instead I could fix some other package at same time.
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct 

​Oh, yes! I was trying to find something like this all weekend for my Copr
for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on
64-bit systems, but on 32-bit systems it should remain /usr/lib.

You just made my day. ​


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Marcin Juszkiewicz]

W dniu 24.08.2015 o 15:18, Neal Gompa pisze:
>  ​ Oh, yes! I was trying to find something like this all weekend for
> my
>  Copr for reprepro. I have to make a patch to access apt-methods in
>  /usr/lib64 on 64-bit systems, but on 32-bit systems it should remain
>  /usr/lib.
>
>  You just made my day. ​ 
You know that %_libdir is what you want? /usr/lib on 32bit, /usr/lib64 
on 64bit.

[Daniel P. Berrange]

On Mon, Aug 24, 2015 at 09:18:16AM -0400, Neal Gompa wrote:
>  
>  ​Oh, yes! I was trying to find something like this all weekend for my Copr
>  for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on
>  64-bit systems, but on 32-bit systems it should remain /usr/lib.
>  
>  You just made my day. ​ 
You should not really assume that all 64-bit architectures use /usr/lib64
either - %{_libdir} expands to the right directory path per architecture.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

[Neal Gompa]

On Mon, Aug 24, 2015 at 9:26 AM, Marcin Juszkiewicz <mjuszkiewicz(a)redhat.com
>  wrote: 
>  W dniu 24.08.2015 o 15:18, Neal Gompa pisze:
>
> > ​ Oh, yes! I was trying to find something like this all weekend for my
> > Copr for reprepro. I have to make a patch to access apt-methods in
> > /usr/lib64 on 64-bit systems, but on 32-bit systems it should remain
> > /usr/lib.
> >
> > You just made my day. ​
> >
>
>  You know that %_libdir is what you want? /usr/lib on 32bit, /usr/lib64 on
>  64bit.
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  
I'm well aware. The buildsystem is fine. It's the code that's the problem.

On Mon, Aug 24, 2015 at 9:27 AM, Daniel P. Berrange <berrange(a)redhat.com&gt;
wrote:

>  On Mon, Aug 24, 2015 at 09:18:16AM -0400, Neal Gompa wrote:
>  >
>  > ​Oh, yes! I was trying to find something like this all weekend for my
>  Copr
>  > for reprepro. I have to make a patch to access apt-methods in /usr/lib64
>  on
>  > 64-bit systems, but on 32-bit systems it should remain /usr/lib.
>  >
>  > You just made my day. ​
>
>  You should not really assume that all 64-bit architectures use /usr/lib64
>  either - %{_libdir} expands to the right directory path per architecture.
>
>  Regards,
>  Daniel
>  --
>  |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
>  :|
>  |: http://libvirt.org              -o-             http://virt-manager.org
>  :|
>  |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/
>  :|
>  |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc
>  :|
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  
​Well, the problem is that ​the path to apt-methods is hardcoded in
reprepro itself. Thankfully, it's in a #define, but I don't know of a good
way to fix it beyond just replacing the #define for 64-bit systems. ​If
someone can suggest a better way than how I'm doing it now, I'm all ears,
because I hate this patch[0].

[0]:
http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/mirrorer/reprepro.g...


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Jonathan Wakely]

On 24/08/15 09:31 -0400, Neal Gompa wrote:
> ​Well, the problem is that ​the path to apt-methods is hardcoded in
> reprepro itself. Thankfully, it's in a #define, but I don't know of a good
> way to fix it beyond just replacing the #define for 64-bit systems. ​If
> someone can suggest a better way than how I'm doing it now, I'm all ears,
> because I hate this patch[0].
>
> [0]:
> http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/mirrorer/reprepro.g...
You could add -DSTD_METHOD_DIR=%{_libdir}/apt/methods to the compiler
flags.

[Jonathan Wakely]

On 24/08/15 14:39 +0100, Jonathan Wakely wrote:
> On 24/08/15 09:31 -0400, Neal Gompa wrote:
> >​Well, the problem is that ​the path to apt-methods is hardcoded in
> >reprepro itself. Thankfully, it's in a #define, but I don't know of a good
> >way to fix it beyond just replacing the #define for 64-bit systems. ​If
> >someone can suggest a better way than how I'm doing it now, I'm all ears,
> >because I hate this patch[0].
> >
> >[0]:
> >http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/mirrorer/reprepro.git/tree/reprepro-use-lib64-on-64bit-systems.patch
>
> You could add -DSTD_METHOD_DIR=%{_libdir}/apt/methods to the compiler
> flags. 
Oops, to keep the quotes it would be

  -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'

[Neal Gompa]

On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely <jwakely(a)redhat.com&gt; wrote:

>  On 24/08/15 14:39 +0100, Jonathan Wakely wrote:
>
> > On 24/08/15 09:31 -0400, Neal Gompa wrote:
> >
> >> ​Well, the problem is that ​the path to apt-methods is hardcoded in
> >> reprepro itself. Thankfully, it's in a #define, but I don't know of a
> >> good
> >> way to fix it beyond just replacing the #define for 64-bit systems. ​If
> >> someone can suggest a better way than how I'm doing it now, I'm all
> ears,
> >> because I hate this patch[0].
> >>
> >> [0]:
> >>
> >>
> http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/mirrorer/reprepro.g...
> >>
> >
> > You could add -DSTD_METHOD_DIR=%{_libdir}/apt/methods to the compiler
> > flags.
> >
>
>  Oops, to keep the quotes it would be
>
>   -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
>
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  
​Would that override the in-code #define statement?​


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Jonathan Wakely]

On 24/08/15 10:06 -0400, Neal Gompa wrote:
> On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely
> <jwakely(a)redhat.com&gt; wrote:
> > Oops, to keep the quotes it would be
> >
> >  -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
>
> ​Would that override the in-code #define statement?​ 
Yes, because the #define is guarded by:

#ifndef STD_METHOD_DIR

so if it's defined on the command line then it won't get defined in
main.c

But whether you alter the #define in main.c or set it on the
command-line, using %{_libdir} seems better than /usr/lib64.

[Neal Gompa]

On Mon, Aug 24, 2015 at 10:15 AM, Jonathan Wakely <jwakely(a)redhat.com&gt;
wrote:

>  On 24/08/15 10:06 -0400, Neal Gompa wrote:
>
> > On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely <jwakely(a)redhat.com&gt;
> > wrote:
> >
> >> Oops, to keep the quotes it would be
> >>
> >>  -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
> >>
> >
> > ​Would that override the in-code #define statement?​
> >
>
>  Yes, because the #define is guarded by:
>
>  #ifndef STD_METHOD_DIR
>
>  so if it's defined on the command line then it won't get defined in
>  main.c
>
>  But whether you alter the #define in main.c or set it on the
>  command-line, using %{_libdir} seems better than /usr/lib64.
>
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  
​How do I append to the CFLAGS at the %configure statement?​


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Reindl Harald]

Am 24.08.2015 um 16:27 schrieb Neal Gompa:
>  On Mon, Aug 24, 2015 at 10:15 AM, Jonathan Wakely
> <jwakely(a)redhat.com
>  <mailto:[e-mail]>>wrote:
>
>      On 24/08/15 10:06 -0400, Neal Gompa wrote:
>
>          On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely
>          <jwakely(a)redhat.com <mailto:[e-mail]>> wrote:
>
>              Oops, to keep the quotes it would be
>
>                -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
>
>
>          ​Would that override the in-code #define statement?​
>
>
>      Yes, because the #define is guarded by:
>
>      #ifndef STD_METHOD_DIR
>
>      so if it's defined on the command line then it won't get defined in
>      main.c
>
>      But whether you alter the #define in main.c or set it on the
>      command-line, using %{_libdir} seems better than /usr/lib64.
>
>  ​How do I append to the CFLAGS at the %configure statement?​ 
you don't need

export CFLAGS="%{optflags} yourstuff"
export CXXFLAGS="%{optflags}  yourstuff"
%configure ...............

P.S.: please don't quote the list-footer

[Neal Gompa]

On Mon, Aug 24, 2015 at 10:31 AM, Reindl Harald <h.reindl(a)thelounge.net&gt;
wrote:

>  Am 24.08.2015 um 16:27 schrieb Neal Gompa:
>
> > On Mon, Aug 24, 2015 at 10:15 AM, Jonathan Wakely <jwakely(a)redhat.com
> > <mailto:[e-mail]>>wrote:
> >
> >     On 24/08/15 10:06 -0400, Neal Gompa wrote:
> >
> >         On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely
> >         <jwakely(a)redhat.com <mailto:[e-mail]>> wrote:
> >
> >             Oops, to keep the quotes it would be
> >
> >               -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
> >
> >
> >         ​Would that override the in-code #define statement?​
> >
> >
> >     Yes, because the #define is guarded by:
> >
> >     #ifndef STD_METHOD_DIR
> >
> >     so if it's defined on the command line then it won't get defined in
> >     main.c
> >
> >     But whether you alter the #define in main.c or set it on the
> >     command-line, using %{_libdir} seems better than /usr/lib64.
> >
> > ​How do I append to the CFLAGS at the %configure statement?​
> >
>
>  you don't need
>
>  export CFLAGS="%{optflags} yourstuff"
>  export CXXFLAGS="%{optflags}  yourstuff"
>  %configure ...............
>
>  P.S.: please don't quote the list-footer
>
>  
​Thanks.​


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Marcin Juszkiewicz]

W dniu 24.08.2015 o 15:31, Neal Gompa pisze:
>  ​ Well, the problem is that ​the path to apt-methods is hardcoded in
>  reprepro itself. Thankfully, it's in a #define, but I don't know of a
>  good way to fix it beyond just replacing the #define for 64-bit systems.
>  ​If someone can suggest a better way than how I'm doing it now, I'm all
>  ears, because I hate this patch[0]. 
At end of %setup add:

sed -i -e 's+/usr/lib+%{_libdir}+g' main.c

and it will replace /usr/lib with proper value on both 32 and 64 bit.

[Ray Strode]

Hi,

>  If someone can
>  suggest a better way than how I'm doing it now, I'm all ears, because I hate
>  this patch[0]. 
I think the solution you came up with from this thread is okay as a
downstream hack, but I think a better solution would be to get
upstream to ask apt at built time where to put methods.  It seems apt
has an "apt-config" binary for this:

$ apt-config dump |grep Dir::Bin::methods
Dir::Bin::methods "/usr/lib64/apt/methods";

So there's no reason this needs to be hardcoded at all.

Even better would be if apt would ship this information in it's
pkgconfig file, then it could be queried using pkg-config.

--Ray

[Dennis Gilmore]

On Monday, August 24, 2015 09:18:16 AM Neal Gompa wrote:
>  On Mon, Aug 24, 2015 at 9:12 AM, Marcin Juszkiewicz
> <mjuszkiewicz(a)redhat.com 
<snip>

>  ​Oh, yes! I was trying to find something like this all weekend for my
> Copr
>  for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on
>  64-bit systems, but on 32-bit systems it should remain /usr/lib. 
That is actually an inappropriate way to work out libbdir tyou should use the 
%{_libdir} macro, some 64 bit platforms,  alpha for instance and I thionk ia64 
from memory use /usr/lib as they are 64 bit only arches.

Dennis

[Jonathan Underwood]

On 24 August 2015 at 14:12, Marcin Juszkiewicz <mjuszkiewicz(a)redhat.com&gt; wrote:
[snip]
>  Because there are lot of code like:
>
>  %ifarch x86_64 ppc64 ia64 s390x sparc64
>      USE_64=1
>  %endif
>
>  Where is should be:
>
>  %if 0%{?__isa_bits} == 64
>   USE_64=1
>  %endif
>
>  Which works since RHEL6 (from what I know). And it automatically covers all
>  64-bit architectures not only those which maintainer remembers.
>  
It would be worthwhile adding this to:

https://fedoraproject.org/wiki/Packaging_tricks

Cheers,
Jonathan.

[Marcin Juszkiewicz]

W dniu 24.08.2015 o 16:09, Jonathan Underwood pisze:
>  It would be worthwhile adding this to:
>
>  https://fedoraproject.org/wiki/Packaging_tricks 
Added

[Chuck Anderson]

On Mon, Aug 24, 2015 at 06:02:35PM +0200, Marcin Juszkiewicz wrote:
>  W dniu 24.08.2015 o 16:09, Jonathan Underwood pisze:
>  >It would be worthwhile adding this to:
>  >
>  >https://fedoraproject.org/wiki/Packaging_tricks
>  
>  Added 
Is there an analagous macro for "all little endian arches"?  This
would be useful for the msed package.