+++ This bug was initially created as a clone of Bug #2019329 +++ > --- Additional comment from Pavel Raiskup on 2021-12-15 11:19:54 CET --- > > This patch could help to link against 2.2.5 symbols: > https://copr-dist-git.fedorainfracloud.org/cgit/praiskup/nosync-libc-2.2.5/nosync.git/commit/?id=0bb4978918b7de10e2d8ea7c49ccc03bf94b3856 > > Though this fails in i386, and this library needs to be built multilib: > https://copr.fedorainfracloud.org/coprs/praiskup/nosync-libc-2.2.5/build/3048930/ > > .... > cc -shared -fPIC -ldl -lpthread -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -o nosync.so fsync.o open.o > /usr/bin/ld: nosync.so: no symbol version section for versioned symbol `dlsym.5' > collect2: error: ld returned 1 exit status > > Even if the glibc versioning on i386 was fixed (or whatever is causing > this), this doesn't seem to be a long-term solution? > > It would be nice if nosync was a glibc subpackage with statically > linked dlsym() and pthread_testcancel(). But this is probably unrealistic. I'm just curious whether glibc folks could help us to answer some of the questions. - Is there a way to link a binary against 2.2.5 symbols on i386? - Could nosync.so be part of glibc (sub-package), with statically linked symbols? - Any other idea how to way-around this? For more info about the nosync.so problems please see the original bug.
You should probably build a restricted version of nosync.so that only intercepts fsync and sync. This way, you don't need to use dlsym to do any forwarding of calls. Long term, this really, really needs kernel support. I believe overlayfs2 has recently received nosync support for the upper layer.
See comment 1. I checked that RPM installation does not use O_SYNC/O_DSYNC, so just that stubbing out fsync, sync, and sync_file_range should be sufficient.