components/binutils/patches/cache.c.patch
changeset 7310 88d40c6177a1
parent 7309 2655ef11c386
child 7312 6b323adaf9e7
--- a/components/binutils/patches/cache.c.patch	Wed Nov 02 08:17:06 2016 -0700
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,28 +0,0 @@
-# Patch submitted to the binutils project:
-# https://sourceware.org/bugzilla/show_bug.cgi?id=19260
---- bfd/cache.c	2014-10-14 00:32:02.000000000 -0700
-+++ bfd/cache.c	2015-11-17 21:23:28.679754360 -0800
-@@ -77,6 +77,23 @@
- {
-   if (max_open_files == 0)
-     {
-+#if defined(__sun) && !defined(__sparcv9) && !defined(__x86_64__)
-+      /* Very inelegant handling of the 255 file descriptor limit
-+       * in 32-bit Solaris libc.
-+       * The problem is that setrlimit(2) can raise RLIMIT_NOFILE
-+       * in 32-bit to a value that is not supported by libc, resulting
-+       * in "Too many open files" errors.
-+       * This can happen even if max_open_files = rlim.rlim_cur / 8.
-+       * For example, if rlim.rlim_cur == 65536, then max_open_files == 8192.
-+       * This essentially reverts to the behavior from binutils 2.23.1
-+       * for 32-bit Solaris only.
-+       * We hope to have this 32-bit libc limitation removed soon.
-+       * 64-bit Solaris libc does not have this limitation.
-+       */
-+      max_open_files = 16;
-+      return max_open_files;
-+#endif
-+
-       int max;
- #ifdef HAVE_GETRLIMIT
-       struct rlimit rlim;