Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8179887

Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

    Details

    • Type: Bug
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: 9
    • Fix Version/s: 11
    • Component/s: hotspot
    • Labels:
      None

      Backports

        Description

        It seems that OpenJDK build fails on Linux systems with newer glibc (>= 2.24), because readdir_r got deprecated, see https://lwn.net/Articles/696469/.

        /home/xbmc/shenandoah-jdk9/hotspot/src/os/linux/vm/os_linux.inline.hpp: In static member function 'static dirent* os::readdir(DIR*, dirent*)':
        /home/xbmc/shenandoah-jdk9/hotspot/src/os/linux/vm/os_linux.inline.hpp:109:18: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated [-Werror=deprecated-declarations]
           if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
                          ^~~~~~~~~
        In file included from /home/xbmc/shenandoah-jdk9/hotspot/src/os/linux/vm/jvm_linux.h:44:0,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/prims/jvm.h:31,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/utilities/debug.hpp:29,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/runtime/globals.hpp:28,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/memory/allocation.hpp:28,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/memory/memRegion.hpp:28,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/gc/shared/barrierSet.hpp:28,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/runtime/handles.hpp:28,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/memory/universe.hpp:28,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/code/oopRecorder.hpp:28,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/asm/codeBuffer.hpp:28,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/asm/assembler.hpp:28,
                         from /home/xbmc/shenandoah-jdk9/hotspot/src/share/vm/precompiled/precompiled.hpp:29:

        Initially assigning to hotspot/runtime, seems the closest one. This might be the important thing to get into 9 or 9u.

          Activity

          Hide
          dholmes David Holmes added a comment -
          Unless there is a runtime failure on platforms with glibc 2.24 this seems not essential for 9. Build failures are annoying but can be worked around in general and we are too late in the 9 release to make changes in 9 - unless the change is simply to ignore the deprecation warning ie a simple build change? But then the developer can do that locally themselves.

          The actual functional change needs more in-depth analysis. See discussion:

          https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html
          Show
          dholmes David Holmes added a comment - Unless there is a runtime failure on platforms with glibc 2.24 this seems not essential for 9. Build failures are annoying but can be worked around in general and we are too late in the 9 release to make changes in 9 - unless the change is simply to ignore the deprecation warning ie a simple build change? But then the developer can do that locally themselves. The actual functional change needs more in-depth analysis. See discussion: https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html
          Hide
          andrew Andrew Hughes added a comment -
          Taking this one as I've encountered it on building OpenJDK 7 & 8 too, where the build is broken due to the default use of -Werror.

          For existing releases (7,8, 9), I think the right thing is to just disable the deprecation warning.

          For 10, we can look at switching to readdir. My examination of the call sites (src/os/linux/vm/perfMemory_linux.cpp, src/share/vm/runtime/arguments.cpp) so far shows that the DIR* used is local to the function calling readdir_r in each case. The calling code also uses it as if it was a readdir(DIR*, dirent*) call, with the redirection to readdir_r and its additional argument being contained in os_linux.inline.hpp:
            
            if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
              errno = status;
              return NULL;
            } else
              return p;

          As glibc is multi-thread safe on different directory streams, this could be potentially be simplified to just 'return readdir(dirp)'. Indeed, src/os/linux/vm/os_linux.cpp already uses ::readdir(dir) and the allocated buffer is never used by the calling code; it uses the return value of readdir.
          Show
          andrew Andrew Hughes added a comment - Taking this one as I've encountered it on building OpenJDK 7 & 8 too, where the build is broken due to the default use of -Werror. For existing releases (7,8, 9), I think the right thing is to just disable the deprecation warning. For 10, we can look at switching to readdir. My examination of the call sites (src/os/linux/vm/perfMemory_linux.cpp, src/share/vm/runtime/arguments.cpp) so far shows that the DIR* used is local to the function calling readdir_r in each case. The calling code also uses it as if it was a readdir(DIR*, dirent*) call, with the redirection to readdir_r and its additional argument being contained in os_linux.inline.hpp:      if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {     errno = status;     return NULL;   } else     return p; As glibc is multi-thread safe on different directory streams, this could be potentially be simplified to just 'return readdir(dirp)'. Indeed, src/os/linux/vm/os_linux.cpp already uses ::readdir(dir) and the allocated buffer is never used by the calling code; it uses the return value of readdir.

            People

            • Assignee:
              andrew Andrew Hughes
              Reporter:
              shade Aleksey Shipilev
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: