On Sat, 2018-12-01 at 19:30 +0100, Samuel Thibault wrote:
> I forgot here:
Is this really needed? From git-fcntl64.diff:
Index: glibc-2.28/sysdeps/mach/hurd/fcntl.c
===================================================================
--- glibc-2.28.orig/sysdeps/mach/hurd/fcntl.c
+++ glibc-2.28/sysdeps/mach/hurd/fcntl.c
...
@@ -215,3 +210,4 @@ strong_alias (__libc_fcntl, __libc_fcntl
libc_hidden_def (__libc_fcntl64)
weak_alias (__libc_fcntl64, __fcntl64)
libc_hidden_weak (__fcntl64)
+weak_alias (__fcntl64, fcntl64)
Index: glibc-2.28/sysdeps/mach/hurd/fcntl64.c
===================================================================
--- /dev/null
+++ glibc-2.28/sysdeps/mach/hurd/fcntl64.c
@@ -0,0 +1 @@
+/* fcntl64 is defined in fcntl.c as an alias. */
Additionally, sysdeps/mach/hurd/flock.c calls __file_lock() and the file-record-
locking patches need to patch lib{diskfs,netfs,trivfs} file-lock.c files too.
It would be much simpler to use sysdeps/posix/flock.c that calls fcntl()
directly, and scratch sysdeps/mach/hurd/flock.c as well as
libdiskfs/file-lock.c
libnetfs/file-lock.c
libtrivfs/file-lock.c
in due time.
What about libtreefs/s-file.c:treefs_S_file_lock() and it's hooks?
What it the main usage application of libtreefs?
