User:Quequotion/32-bit package guidelines

From ArchWiki
Jump to navigation Jump to search
Package creation guidelines

CLRCrossEclipseElectronFree PascalGNOMEGoHaskellJavaKDEKernelLispMinGWNode.jsNonfreeOCamlPerlPHPPythonRRubyRustVCSWebWine

Legacy 32-bit software can be built and installed on machines of another native architecture, such as x86_64. This article explains the production and conventions of such packages.

Package naming

Comment: Split packages are characterized by pkgbase, not pkgname. The pkgbase name does not matter for package naming. The link both 32-bit and native versions does not list split packages. -- Lahwaacz (talk) 10:29, 23 March 2019 (UTC)
I think what's happened is that few people have any use for the kind of "-multilib" packages I've described here, and as such there are none remaining in the AUR. There was a time (when x86_64 was relatively new) when this convention (however unofficial and undocumented) existed, but it is now (appropriately) out of date. You may dispute that, but I distinctly recall building such packages based on the packages of others I had found in the AUR (version 3). If there are no such packages in existence anymore, then there is no need to document this convention. I have to admit I didn't deeply look into the list of packages that AUR search returned, but having done so now I should point out one particular package, dosbox-multilib-patchedAUR which should probably be a "lib32-" package, and may be using this convention (incorrectly?).
Also "package naming" as a section header doesn't explicitly refer to pkgname, but I can see how it might be interpreted that way. All of the conventions I've described here are intended for pkgbase; I was hoping I would not have to explicitly point that out (should be clear if someone also reads te PKGBUILD page) quequotion (talk) 13:45, 23 March 2019 (UTC)
This section should be intended for pkgname as in all other related pages.
If you intend this page to be moved to the main namespace, you should make sure that everything described here reflects the current conventions as agreed by the whole community. If you are not sure, I'd better ask somewhere. Personal preferences and controversial practices don't belong on a "package guidelines" page.
-- Lahwaacz (talk) 14:42, 23 March 2019 (UTC)
I did not invent this; I learned it from other packagers PKGBUILDs. Not sure how I have failed to communicate that these are neither personal preferences nor controversial practices (there would have had to have been a discussion about it in its time in order for it to be controversial, but I am not aware of one), but rather a convention that appears to be out of date (and was never formalized to begin with). Again, if it is outdated I don't mind cutting it, it's here because at least at a time there was such a custom. This is part of the reason this page is needed: 32-bit packages are an increasingly obscure topic with lacking and outdated documentation.
I might go so far as to replace this section with a blurb that explicitly states the old practice is defunct, and that "-multilib" is to be used exclusively for the dual-architecture toolchain packages you described. quequotion (talk) 01:57, 24 March 2019 (UTC)
It does not matter who invented it, the point is that the practice did not get established enough in the community to be called a guideline. I don't see a point in documenting outdated things - simply remove it. As for the need of this page: its non-existence since the early history clearly indicates how (un)popular the topic is. The need for guidelines or wiki pages in general is driven by popularity, not by obscurity of the topic. -- Lahwaacz (talk) 14:44, 24 March 2019 (UTC)
This content of this page does exist though, it's just inappropriately placed as a section of the makepkg page. Also, as both official lib32- and unofficial "-x32" packages continue to exist, their packaging methods need to be documented. quequotion (talk) 16:30, 24 March 2019 (UTC)
It's not like all packaging methods for every possible package in the AUR should be documented in a set of guidelines. -- Lahwaacz (talk) 16:55, 24 March 2019 (UTC)
"lib32-" packages are available from [multilib], an official repository (see link above). That alone is sufficient cause to require documentation on their packaging. Furthermore, at one time I maintained my own repository of 32-bit packages, some of which were not available in [multilib] and some of which were replacements for official packages with issues such as missing architecture-specific includes, misplaced or missing pkgconfig, and missing 32-bit executables, which prevented the official packages from being used as build dependencies, etc. This documentation is necessary as long as archlinux is distributing 32-bit packages. quequotion (talk) 00:49, 25 March 2019 (UTC)
OK, fair enough. Thanks for putting it all together. -- Lahwaacz (talk) 08:07, 25 March 2019 (UTC)

Variables and parameters


Specify these bash variables in a PKGBUILD to tell the compiler to output 32-bit code:

export CFLAGS+=" -m32"
export CXXFLAGS+=" -m32"
export LDFLAGS+=" -m32"
export PKG_CONFIG_PATH='/usr/lib32/pkgconfig'

File placement

Comment: About the add includes in separate folder (/usr/include32), why do this instead off do like in other lib32- packages? other lib32- packages remove the includes and add the non-32bits counterparts into depends=() -- Sl1pkn07
Such packages may be inappropriately discarding architecture-specific includes.
If a 32-bit source package requires 32-bit includes, it will fail to build against the includes of the native package. I don't know of an easier way to check if header files provide architecture-specific datatypes, etc. Not every 32-bit package will need includes, and that can be handled in package(), but some do. Safer to assume all do.
Setting the --includedir flag does not mandate installing the files; I'd rather (recommend to) have it set for packages that need them, then let packagers decide for themselves if they need to install those files. quequotion (talk) 06:22, 15 April 2019 (UTC)
Any of the lib32- packages provides from repos ([multilib] or [multilib-testing], witch have the lib32- packages) have files installaded in /usr/include32, can you see this with pkgfile -d /usr/include32/, the only exceptions of this is
lib32-glibc, lib32-libtiff, lib32-libunwind, lib32-llvm, which have the includes inside /usr/include, but with different name (lib32-libtiff is a great example).
Instead off use /usr/include32, why can be installed under /usr/include/<foo>32?. I think is better if the root include directory directory is tracked by filesystem package -- Sl1pkn07
I don't mind changing the location. As long as the files are provided when needed, they can be anywhere that fits with policy. How about --includedir=/usr/include/$pkgbase32? quequotion (talk) 15:35, 15 April 2019 (UTC)
--includedir=/usr/include/$pkgbase32 or --includedir=/usr/include/$pkgname32 is ok for me, but i think is better if ask to official package maintainer what is her opinion -- Sl1pkn07

Ensure lib32 package files do not conflict with native package files. For example, if a package builds using GNU Autoconf, specify the following to configure:

--program-suffix="-32" \
--lib{exec,}dir=/usr/lib32 \
--includedir=/usr/include32 \ 


Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Add any information on how x32 packages could be built here. (Discuss in User talk:Quequotion/32-bit package guidelines#-x32?)

Building a 32-bit package

First, enable the multilib repository and install multilib-devel.

Use linux32(8) on makepkg to ensure the package is built in a 32-bit environment:

$ linux32 makepkg