[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
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.
Created attachment 208895 [details]
I think what Solaris/illumos calls _ARG_MAX32 would be a reasonable default.
Is this enough?
I don't know any alternative solution. :(
Created attachment 209120 [details]
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.