RFR: 8333326: Linux Alpine build fails after 8302744

Severin Gehwolf sgehwolf at openjdk.org
Mon Jun 3 09:05:08 UTC 2024


On Sat, 1 Jun 2024 05:56:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> we run into a basename related build issue on Alpine Linux
>> 
>> basename related issue :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_alpine_x86_64-opt/jdk/test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp: In member function 'virtual void cgroupTest_read_numerical_key_value_success_cases_Test::TestBody()':
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_alpine_x86_64-opt/jdk/test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp:139:19: error: 'basename' was not declared in this scope; did you mean 'rename'?
>>   139 | const char* b = basename(test_file);
>>       | ^~~~~~~~
>>       | rename
>> 
>> 
>> Additionally giving a 'const char*'  to basename results in a warning as error because basename interface gets a char* .
>
> test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp line 39:
> 
>> 37: #ifdef MUSL_LIBC
>> 38: #include <libgen.h> // for basename
>> 39: #endif
> 
> Does glibc provide its own definition of `basename`? From what I can see on Linux `man -s 3 basename` shows:
> 
> SYNOPSIS
>        #include <libgen.h>
> ..
>        char *basename(char *path);
> 
> which seems to be the same as what you now have for MUSL-C. ???

Good point. The man page also has:


VERSIONS
       There are two different versions of basename() - the POSIX version  de‐
       scribed above, and the GNU version, which one gets after

               #define _GNU_SOURCE         /* See feature_test_macros(7) */
               #include <string.h>

       The  GNU  version  never  modifies  its argument, and returns the empty
       string when path has a trailing slash, and in particular also  when  it
       is "/".  There is no GNU version of dirname().

       With glibc, one gets the POSIX version of basename() when <libgen.h> is
       included, and the GNU version otherwise.


So it sounds like we use the GNU version when `glibc` is being used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19497#discussion_r1624071373


More information about the hotspot-runtime-dev mailing list