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