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 <mzerq...@0pointer.de> wrote: > On Mo, 13.04.20 09:56, Tom Callaway (tcall...@redhat.com) 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
