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?
- Makefiles can just extend the environment's CFLAGS by not doing any explicit assignment, but using operators like
+=instead. See also . -- Lahwaacz (talk) 12:11, 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/upx.sh 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 AUR. 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/upx.sh, 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
- 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)
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)