RFR: 8333326: Linux Alpine build fails after 8302744

[David Holmes]

On Mon, 3 Jun 2024 09:02:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> 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.

Thanks @jerboaa I obviously completely missed that. :(

But as per Thomas's comment we should be using the Posix function not glibc version. Then we would not need to specialize for Musl-C.

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

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