You are not logged in.

#1 2015-01-15 22:05:16

dougr
Member
From: Sunnyvale, CA
Registered: 2015-01-15
Posts: 3
Website

PKGBUILD arch array conventions

I've noticed a lot of packages explicitly list i686 and/or x86_64 in their PKGBUILD's architecture list. From the PKGBUILD man page:

arch (array)
Defines on which architectures the given package is available (e.g., arch=('i686' 'x86_64')). Packages that contain no architecture specific files should use arch=('any').

If you have a package whose source is portable C code, what should the PKGBUILD's architecture list be? From the man page description, I'd think 'any'. I can also imagine only including the architectures I've built and tested on, but then when would it make sense to use 'any' (since presumably even script based source should be tested on each architecture as well)?

Offline

#2 2015-01-15 22:17:38

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: PKGBUILD arch array conventions

Would the binary built on i686 work on x86_64? If not, use i686 and x86_64, not 'any'.

Offline

#3 2015-01-15 22:20:10

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: PKGBUILD arch array conventions

'any' is not the same as 'i686' and 'x86_64'.  'any' is only for packages that can be built once and installed on either architecture.  This would be data-file only packages, and scripting languages (python, java).


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#4 2015-01-15 22:29:59

dougr
Member
From: Sunnyvale, CA
Registered: 2015-01-15
Posts: 3
Website

Re: PKGBUILD arch array conventions

Ah, I see. So the man page is referring to the output of the build containing architecture specific files, not the input. I thought it meant something like having x86_64 specific assembly code as part of your input.

Offline

#5 2015-01-15 22:54:22

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: PKGBUILD arch array conventions

Yes, the output is the package.  The input is just a PKGBUILD.  So if the package will contain architecture specific files ... and any package with compiled binaries will be architecture-specific.

As to whether you should list both architectures when you haven't tested it on both - I'd generally say go for it.  If you know there is anything that wouldn't build on another architecture then don't, but it if is reasonably portable code then list both.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#6 2015-01-16 15:42:04

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: PKGBUILD arch array conventions

Trilby wrote:

As to whether you should list both architectures when you haven't tested it on both - I'd generally say go for it.  If you know there is anything that wouldn't build on another architecture then don't, but it if is reasonably portable code then list both.

I disagree, many software authors assume that the way ubuntu/debian and fedora/redhat setup things will work on everything.
Arch does several things different, which often means i686 and x86_64 need specific changes to work.


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#7 2015-01-16 15:46:07

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: PKGBUILD arch array conventions

I build for i686 before listing it, but don't test them beyond that.

Offline

Board footer

Powered by FluxBB