I don't think it will help: sh-3.2$ getconf ARG_MAX;sudo sh -c "ulimit -s 65532;ulimit -s;getconf ARG_MAX" 262144 65532 262144
(ARG_MAX was 262144, changed stack size and confirmed change, ARG_MAX was still 262144) That's assuming getconf can tell (I think it can), and isn't just giving back a hardcoded value. Indeed, from what I've seen looking at the XNU source, it can't be raised without building a custom kernel (NOT a practical option). With some OSs, ARG_MAX aka NCARGS is adjustable, with others it isn't. macOS's is not necessarily the lowest with an apparently fixed limit, but not exceptionally high either. Usually such situations mean that the approach of passing a huge number of command line arguments all at once is simply wrong (it's just not good to depend on a non portable limit); but I don't know enough about (GNU) libtool to suggest a workaround or alternative (if any). In particular, if there's a way to break it up and use libtool to incrementally build a library, I'm not seeing it in a very quick skim of the documentation. > On Nov 27, 2019, at 15:50, Dave Allured - NOAA Affiliate via macports-users > <[email protected]> wrote: > > I am trying to solve "Argument list too long" when building [email protected]_3 from > source under macports. The command that fails is "libtool clang++", used > here to combine a large number of objects into a single library libgdal.la > <http://libgdal.la/>. The trac ticket is > https://trac.macports.org/ticket/59510 > <https://trac.macports.org/ticket/59510> . > > I found advice suggesting that the maximum command length is related to the > stack size. I am not sure this is correct for Mac OS. However, if true, > this would be an easy fix for argument list too long. > > Can anyone tell me whether increasing the stack size would increase the > maximum command length? If so, what is the best way to increase stack size > in a port file or patch, such that it would apply when this libtool command > is executed?
