The linker said: error adding symbols: Malformed archive. Searching leads me to translate that error to "too many open files". See: https://github.com/OSSystems/meta-browser/issues/194
Apparently, gold does not have this issue, but I have not tested.
Tom
On Mon, Apr 13, 2020 at 12:05 PM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
On Mo, 13.04.20 09:56, Tom Callaway (tcallawa@xxxxxxxxxx) wrote:
> C) Chromium's build process gets...angrier. Still doable, but you have to
> do things like set ulimit -n 4096. (Fun fact: the man page section for
> ulimit says that for -n, "most systems do not allow this value to be set".
> Guess modern Linux isn't most systems.)
Hmm what precisely fails?
Note that in systemd we took the liberty to bump RLIMIT_NOFILE's hard
limit to 512K a while back, which one can effectively understand as
"there's no limit on fds anymore" (this was on suggestion of some
kernel folks, because fds are these days tracked like memory and hence
are accounted like that too and are not as expensive as hey used to
be). We would have liked to bump the matching soft limit too (i.e. the
one you tweak with ulimit -n), but that's something what we can't do
without breaking compability a litte bit too agressively: fds above
1023 are not compatible with select(), and plenty software still uses
select() (they really shouldn't, it's a terrible interface), and it's
a silent failure.
Long story short: If there are programs that are likely to deal with
large numbers of fds (like in your case, the linker I presume?) they
should probably just bump the soft limit to the hard limit early on in
their C code, and thus just get as many fds they want. Raising the
soft limit up to the hard limit is an unprivileged operation and can
be done by regular users. Programs that do that should reset the soft
limit back to 1K before forking off foreign programs again though,
again for compatibility with any such programs that use select().
Very short version: consider filing a bug against your linker tool (or
whichever other tool needed the ulimit -n above), and ask them to set
RLIMIT_NOFILE's soft value to the hard value. And then they will just
work without any manual limit bumping for regular people on modern
distros.
Lennart
--
Lennart Poettering, Berlin
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
