can we add a macos CI per this change?

@karelzak we've been holding off updating to util-linux 2.40 in Nixpkgs for a long time because of this issue. Could you please take a look?

Looks good to me; @t-8ch, any comments?

The commit subject is really not great.

A comment why there is no problem time ABI problem on macOS.
I guess macOS has been 64-bit only for some time.

It seems that the motivation for uuid_time64 is to enable use of 64-bit time on 32-bit platforms. On 64-bit platforms, uuid_time is 64-bit. I believe the check for glibc is because 64-bit time on 32-bit systems is supported by glibc (and maybe musl?) but not libc++.

I have no idea if Darwin supports it.

Sources:

The symbol uuid_time64 is conditionally defined. It only exists on
32-bit platforms that use the glibc library and enable support for
the 64-bit time_t type.

#3037

The pull that added uuid_time64:
#2610

@iskarian thank you for the background research!

@t-8ch
macOS supported 64-bit and aggressively pushed developers to build only for 64 bit since version 10.7, released in July 2011¹. It has been 64-bit only since version 10.15, released in October 2019. Which, however you look at it, is a very, very long time on that platform. Neither myself, nor anybody I know has access to an Apple toolchain that can build for 32-bit and hasn't for a very long time².

From looking at system headers, as they exist now, I see the following in /usr/include/i386/_types.h:

#if defined (__i386__) || defined (__x86_64__)
...
typedef long                    __darwin_time_t;
...
#endif

where __darwin_time_t eventually becomes time_t and is also used directly in timeval. Which indicates that whole time API is 32 bit on 32 bit platforms and 64 bit on 64 bit ones. Which, in turn, seems to indicate that uuid_time64 shenanigans are unnecessary on that platform and uuid_time should unconditionally be an alias to __uuid_time there.

This is all conjectural, however, since, as I mentioned I don't have an ability to actually build and check what happens on 32-bit³.

To remind you, right now the situation is that libuuid doesn't build on macOS at all, 64-bit or 32, and it has been the case for many months.

I am going to add a short summary of the above to the commit message in the hope that this will finally get the fix merged and the issue resolved.

Please also change the commit subject to something matching the common style.

libuuid: fix uuid_time on macOS without attribute((alias)).

And also add some newlines to the commit message.

In general it would be great if somebody could contribute CI configurations for macOS (and Windows for that matter).
That way any breakage can be recognized before it hits a release or the master branch.

@t-8ch Commit message amended as requested.

@karelzak not sure what the process is in this project, so can this be merged now or there is something else that needs to be done?

Thank you!

@karelzak This should be ready.

Ah, I forgot this for release v2.41. Sorry.

@karelzak I think this did not make to 2.41.2 release?

The commit f59b47d is within stable/v2.41 branch and should be released in v2.41.2.

Note that if you want something included in the next stable release, it's fine to create a pull request against the relevant stable/vX.Y branch.