Talk:Makepkg

upx

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 makepkg-optimize^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)

CARCH and CHOST

Can we get some information detailing about how to use these variables properly in makepkg.conf?

My CPU supports x86_64_v3, but I want to make sure that I do this right in makepkg.conf, and it would be useful information to have for those such as myself with no prior experience of dabbling with specific architectures.

Neko-san (talk) 21:39, 9 December 2021 (UTC)

Building from files in memory

Am I correct in my understanding that this tip: https://wiki.archlinux.org/title/Makepkg#Building_from_files_in_memory will result in filling up the RAM over time, assuming no reboot, to the point of rendering the system unusable? (And if so, that a strong warning should be warranted?)

(If I'm following correctly, the proposal to set `BUILDDIR=/tmp/makepkg` in makepkg.conf is the dangerous part, I used that setting for years following this tip before I understood the implications, and in these years likely had my system crash for lack of memory a few times.)

—This unsigned comment is by Bonob (talk) 22:13, 9 January 2023. Please sign your posts with ~~~~!

tmpfs does not grow infinitely; it has a fixed upper bound. According to Tmpfs#Examples, the default value for this upper bound is half of your total memory. From personal experience (of compiling Linux kernels past a certain versions, and web browsers), you will probably run out of space in /tmp before your system becomes unusable. In the scenario in which you do exhaust half of your memory this way and use up the rest of it, the Linux kernel should start evacuating pages to swap (which I recommend you have setup), and then invoke oom-killer to start killing processes to free memory. Both of those mechanisms try to be smart about the sacrifices that they make.

I don't really think a strong warning is necessary:

• There is already a note cautioning you against running out of memory.
• If you are someone who leaves their computer on, then I don't think it's that unreasonable to be more sensitive about filling up /tmp without explicitly being told.

-- CodingKoopa (talk) 22:54, 10 January 2023 (UTC)