From ArchWiki
Revision as of 04:25, 16 May 2019 by Quequotion (talk | contribs) (Warning: lib32 method vs clean chroot method: there is no "clean chroot method" to create natively 32-bit packages anymore, unless someone wants to try using Archlinux32's repositories to create a chroot.)
Jump to navigation Jump to search

optimized package options

Just to double check: the CFLAGS of /etc/makepkg.conf is overwritten by the CFLAGS that can be found in the Makefile provided with the source. This makes it ineffective as soon as a Makefile is provided, is it correct? Should it be mentioned in this case?

Kewl (talk) 10:38, 1 January 2018 (UTC)

Makefiles can just extend the environment's CFLAGS by not doing any explicit assignment, but using operators like ?= or += instead. See also [1]. -- Lahwaacz (talk) 12:11, 1 January 2018 (UTC)
Thanks that clarifies, do you think the wiki is clear enough or is it worth adding a comment about it or a link? Kewl (talk) 15:28, 1 January 2018 (UTC)
Well, the general note in the section is good enough for me, but feel free to add a comment... -- Lahwaacz (talk) 16:42, 1 January 2018 (UTC)


A feature to be aware of: do not be surprised if the UPX option does not compress your gcc binary because it only detects files that are of mime type 'application/x-executable' | 'application/x-dosexec' while gcc unless instructed otherwise would create by default a binary 'application/x-sharedlib'. This is visible in /usr/share/makepkg/tidy/ Kewl (talk) 15:33, 1 January 2018 (UTC)

Indeed, but also note that upx will not be included in pacman in the future, which is why I am providing it with makepkg-optimizeAUR. I am willing to add other mimetypes to this list, provided we can establish that it is in fact safe to compress them with upx. I've found very little about the matter by searching, so we'll probably have to conduct our own tests.
Note, you could do such tests for yourself by appending | 'application/x-sharedlib', etc to the list in /usr/share/makepkg/tidy/, before the ) at the end of the line. This seems relevant. quequotion (talk) 12:25, 16 February 2019 (UTC)

Build 32-bit packages on a 64-bit system

Rather than maintain this here, we should open an additional page for 32-bit package guidelines. quequotion (talk) 14:58, 4 March 2019 (UTC)

One discussion per topic is enough: Talk:DeveloperWiki:Building in a clean chroot#Create a 32-bit chroot. -- Lahwaacz (talk) 16:52, 16 March 2019 (UTC)
Unfortunately, there is more than one discussion to be had. Unrelated to the 32-bit clean chroot method, I'd like to publish User:Quequotion/32-bit package guidelines as a replacement for the content on this page. quequotion (talk) 15:49, 18 March 2019 (UTC)
With 32-bit package guidelines now published, I've changed my point of view on this section. The information here is good for end users, while the guidelines page is for packagers (thus lacking instructions on how to build the packages). They can co-exist. quequotion (talk) 04:19, 16 May 2019 (UTC)

Warning: lib32 method vs clean chroot method

I am concerned that the warning above this section implies that the two methods result in equivalent packages, which has never been the case. The "lib32-" method makes packages that provide libraries, architecture-specific includes, executables, etc in different locations and with different names than their native counterparts (eg, for for packaging a dependency of another 32-bit package). The clean chroot method provides packages that are "native", building against and storing libraries in /usr/lib, not appending -32 to their executables, etc. (best for packaging software that is only available in 32-bit)

Also curious what unspecified errors are being referenced, if they haven't already been worked out, or if they could not be resolved in order to make this warning obsolete. If some of those issues are things like missing architechture-specific includes, pkgconfig or executables, there are easy fixes for those. quequotion (talk) 06:58, 25 March 2019 (UTC)

Unfortunately the whole concept of using a chroot to create natively 32-bit packages imploded when I realized this can only be achieved if the package repositories used to create the chroot are also 32-bit (ie, you have to use ArchLinux32's package repository). Perhaps we should remove or alter this warning. (note, it is possible to use a chroot to create lib32 packages, just not native 32-bit packages) quequotion (talk) 04:25, 16 May 2019 (UTC)