flatpak
rofiles-fuse prevents flatpak-builder from stripping binaries
Linux distribution and version
Fedora 31
Flatpak-builder version
1.0.9
Flatpak version
1.4.3
Description of the problem
I'm trying to build and FD.o SDK extension with MinGW-w64 toolchain.
If strip is set to true, build fails after install stage:
make[1]: Nothing to be done for 'install-target'.
make[1]: Leaving directory '/run/build/binutils-mingw-w64/_flatpak_build'
stripping: files/bin/x86_64-w64-mingw32-size
FB: Running: strip --remove-section=.comment --remove-section=.note --strip-unneeded /home/gasinvein/.cache/flatpak-builder/state/rofiles/rofiles-RxCkKZ/files/bin/x86_64-w64-mingw32-size
stripping: files/bin/x86_64-w64-mingw32-objdump
FB: Running: strip --remove-section=.comment --remove-section=.note --strip-unneeded /home/gasinvein/.cache/flatpak-builder/state/rofiles/rofiles-RxCkKZ/files/bin/x86_64-w64-mingw32-objdump
strip: unable to copy file '/home/gasinvein/.cache/flatpak-builder/state/rofiles/rofiles-RxCkKZ/files/bin/x86_64-w64-mingw32-objdump'; reason: Read-only file system
Error: module binutils-mingw-w64: Child process exited with code 1
FB: unmounting rofiles-fuse /home/gasinvein/.cache/f
If I pass --disable-rofiles-fuse to flatpak-builder, everything builds fine.
Steps to reproduce
Build flathub/flathub#1252 with stripping enabled.
I believe I've found the root cause. binutils (and gcc) autotools creates hardlinks on install, so that e.g. files bin/i686-w64-mingw32-objdump and i686-w64-mingw32/bin/objdump are the same file. While rofiles-fuse unconditionally denies write access if a file has more than one link, even if it's not present in the source mount dir:
static gboolean
can_write_stbuf (const struct stat *stbuf)
{
/* If it's not a regular file or symlink, ostree won't hardlink it, so allow
* writes - it might be a FIFO or device that somehow
* ended up underneath our mount.
*/
if (!(S_ISREG (stbuf->st_mode) || S_ISLNK (stbuf->st_mode)))
return TRUE;
/* If the object isn't hardlinked, it's OK to write */
if (stbuf->st_nlink <= 1)
return TRUE;
/* Otherwise, it's a hardlinked file or symlink; it must be
* immutable.
*/
return FALSE;
}
@alexlarsson Should it be considered an rofiles-fuse (ostree) bug, or it's intended behavior?
I noticed that this happen also when files are installed without a write permission.
Two of the offenders are cpanm and go install.
For go install there's an easy workaround, just set GOFLAGS=-modcacherw.
For cpanm, that I'm not actually sure that the fault lies with it and not the specific module, Test::LeakTrace in my case, I use this:
post-install:
- find /app -type f ! -perm -0200 -exec chmod u+w '{}' \;
@tinywrkb I believe this is unrelated, the original issue can't be fixed by changing permissions.