From ArchWiki


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)Reply[reply]

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)Reply[reply]


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)Reply[reply]

Building from files in memory

Am I correct in my understanding that this tip: 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)Reply[reply]

/* Parallel compilation */ Directly using nproc to determine the number of jobs you can run is not good practice and RAM needs to be considered.

I do not have a source, but it's my understanding that gcc can use upwards of 1.5-2GB of ram per job during compilation, and as such it is recommended to limit the number of jobs to how many GB of RAM a system has divided by 2 or the output of `nproc`, whichever is the lower value. Apologies if I'm not following procedure to edit the wiki, this is my first edit.

—This unsigned comment is by Parax (talk) 2023-01-30T19:07:33. Please sign your posts with ~~~~!

Those limits are arbitrary, e.g. packages like trilinosAUR exceed them by a large margin. There are also other compilers than gcc, tests can be run, etc. -- Alad (talk) 19:15, 30 January 2023 (UTC)Reply[reply]
I would think that basing the job recommendations on a safer lower limit would be more beneficial to newer users on the wiki. More advanced users are better aware of the edge cases.
—This unsigned comment is by Parax (talk) 2023-01-30T19:24:32. Please sign your posts with ~~~~!
Except there's nothing pointing out those are safe lower limits or a general case. A new user seeing an arbitrary limit would only end up disappointed when it's exceeded or not met. -- Alad (talk) 21:13, 30 January 2023 (UTC)Reply[reply]
The numbers can't be included in a general note. I'd be fine with at most something very general like "Avoid compiling larger packages in tmpfs to prevent running out of memory." in Makepkg#Building from files in memory. — Lahwaacz (talk) 22:48, 30 January 2023 (UTC)Reply[reply]