Bug 241710 - please increase ARG_MAX
Summary: please increase ARG_MAX
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
Keywords: patch
Depends on:
Reported: 2019-11-04 20:09 UTC by Thierry Thomas
Modified: 2019-11-12 23:27 UTC (History)
2 users (show)

See Also:

Bump arg_max (511 bytes, patch)
2019-11-05 22:46 UTC, Pedro F. Giffuni
no flags Details | Diff
Double ARG_MAX (512 bytes, patch)
2019-11-12 23:27 UTC, Pedro F. Giffuni
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thierry Thomas freebsd_committer 2019-11-04 20:09:35 UTC
[See also the closed PR 208154]

I'm trying to upgrade the port french/aster to the latest stable
release. This is a complex port: it has no Makefile (in the upstream
tarball, but of course there is a Makefile for the port), and it uses a
combination of setup.py (Python) and a bundled waf.
At this point, it builds, but the latest step (linkage) fails with the
following message:
gfortran9: fatal error: cannot execute
execv: Argument list too long

Yes, linkage is done by gfortran, in a classical way:
gfortran9 (some -Wl parameters) (a very long list of object files .o) (a
list of several libraies with their paths)

but the problem is not caused neither by gfortran nor by the final
linker: if I execute the same command line manually from my shell, it
succeeds and the aster program is built.

So I guess that the problem is caused partly by the arguments list, but
also by the environment variables brought by the build system.

On my machine, `getconf ARG_MAX' returns 262144.

There's a sysctl kern.argmax, but it's read-only and initialized to ARG_MAX.

On PR 208154, for the same problem with Libreoffice, a work-around was to disable-mergelibs. I'll try to apply the same with Code_Aster, but it's not that easy with their build system (no configure).

Anyway, it would be a good thing to increase this limit, as other OSes do.
Comment 1 Pedro F. Giffuni freebsd_committer 2019-11-05 22:46:58 UTC
Created attachment 208895 [details]
Bump arg_max

I think what Solaris/illumos calls _ARG_MAX32 would be a reasonable default.
Is this enough?

I don't know any alternative solution. :(
Comment 2 Pedro F. Giffuni freebsd_committer 2019-11-12 23:27:09 UTC
Created attachment 209120 [details]
Double ARG_MAX

On further thought: adopting the Solaris/illumos ARG_MAX32 limit is a huge bump: it involves practically multiplying the existing value by four!

It is better to be more conservative: perhaps just double it. I also like the NetBSD notation better. Please confirm this solves the issue.

FWIW, macOS also has the same limit we currently have.