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: 10
    • Component/s: hotspot
    • Labels:
      None

      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: