wine is broken about box86 HOT 11 OPEN

This might be an esync of fsync issue? Did you tried with WINE_ESYNC=0 and/or WINE_FSYNC=0?

from box86.

This might be an esync of fsync issue? Did you tried with WINE_ESYNC=0 and/or WINE_FSYNC=0?

still nothing

$ export WINE_FSYNC=0
$ export WINE_ESYNC=0

$ WINE_FSYNC=0 WINE_ESYNC=0 winecfg
Debug level is 1
Dynarec for ARMv8, with extension: HALF FAST_MULT EDSP NEON VFPv4 IDIVA AES PMULL PageSize:4096 Running on - - - - - - - - - - - - - - - - with 8 Cores
Params database has 31 entries
Box86 with Dynarec v0.3.7 d3d971d built on Jul 20 2024 18:36:41
BOX86: Wine detected, WINEPRELOADRESERVE=""
Using default BOX86_LD_LIBRARY_PATH: ./:lib/:lib32/:x86/:i686/
Using default BOX86_PATH: ./:bin/
Counted 29 Env var
Looking for /home/osaka/wine/bin/wine
argv[1]="winecfg.exe"
Rename process to "wine"
Using native(wrapped) libdl.so.2
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux.so.2
Using native(wrapped) libpthread.so.0
Using native(wrapped) librt.so.1
Using native(wrapped) libbsd.so.0
Using emulated /home/osaka/wine/bin/../lib/wine/i386-unix/ntdll.so
Debug level is 1
Dynarec for ARMv8, with extension: HALF FAST_MULT EDSP NEON VFPv4 IDIVA AES PMULL PageSize:4096 Running on - - - - - - - - - - - - - - - - with 8 Cores
Params database has 31 entries
Box86 with Dynarec v0.3.7 d3d971d built on Jul 20 2024 18:36:41
BOX86: Wine detected, WINEPRELOADRESERVE=""
Using default BOX86_LD_LIBRARY_PATH: ./:lib/:lib32/:x86/:i686/
Using default BOX86_PATH: ./:bin/
Counted 31 Env var
Looking for /home/osaka/wine/bin/wine
argv[1]="winecfg.exe"
Rename process to "wine"
Using native(wrapped) libdl.so.2
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux.so.2
Using native(wrapped) libpthread.so.0
Using native(wrapped) librt.so.1
Using native(wrapped) libbsd.so.0
Using emulated /home/osaka/wine/bin/../lib/wine/i386-unix/ntdll.so
Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL ATOMICS SHA1 SHA2 PageSize:4096 Running on - - - - - - - - - - - - - - - - with 8 Cores
Will use Hardware counter measured at 24.0 MHz emulating 3.0 GHz
Params database has 80 entries
Box64 with Dynarec v0.3.0 built on Jul 20 2024 00:41:07
BOX64: Detected 48bits at least of address space
Counted 33 Env var
BOX64 LIB PATH: ./:lib/:lib64/:x86_64/:bin64/:libs64/:/lib/x86_64-linux-gnu/:/usr/lib/x86_64-linux-gnu/
BOX64 BIN PATH: ./:bin/:/usr/local/sbin/:/usr/local/bin/:/usr/sbin/:/usr/bin/:/sbin/:/bin/:/usr/games/:/usr/local/games/:/snap/bin/:/home/osaka/wine/bin/
Looking for /home/osaka/wine/bin/wineserver
Rename process to "wineserver"
Using native(wrapped) libdl.so.2
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libpthread.so.0
Using native(wrapped) libutil.so.1
Using native(wrapped) librt.so.1
Using native(wrapped) libbsd.so.0
wine: chdir to /tmp/.wine-1000/server-b301-669be82b : No such file or directory

from box86.

Well, I don't know then. Can you do a bisect to find the exact commit that broke it?

(I was thinking of the futexv syscall, that is needed for ESYNC iirc, that got enable lately, but it should still be disable for BAD_SIGNAL build, that should be used on RK3588 unless something change kernel side, so it must be something else)

from box86.

Well, I don't know then. Can you do a bisect to find the exact commit that broke it?

(I was thinking of the futexv syscall, that is needed for ESYNC iirc, that got enable lately, but it should still be disable for BAD_SIGNAL build, that should be used on RK3588 unless something change kernel side, so it must be something else)

i have found commit d3d971d to break wine, the commit before: 2e589f4 still works

from box86.

Oh?! That one. Ummm, interesting.

I have to think of a solution then.

can you check if your armhf libc expose any of those symbols:

__lstat64_time64
__stat64_time64
__fstatat64_time64
__fstat64_time64

(you can use nm -D /PATH/TO/libs.so | grep _time64 for example)

from box86.

i hope i took the right lib, i found it in /usr/lib/arm-linux-gnueabihf

$ nm -D /usr/lib/arm-linux-gnueabihf/libc.so.6 | grep _time64
00066210 T __aio_suspend_time64@@GLIBC_2.34
00086d84 T __clock_nanosleep_time64@@GLIBC_2.34
000b1e74 T __epoll_pwait2_time64@@GLIBC_2.35
000a2530 W __fcntl_time64@@GLIBC_2.34
000a2838 T __fstat64_time64@@GLIBC_2.34
000a29d8 T __fstatat64_time64@@GLIBC_2.34
000a5b68 T __fts64_children_time64@@GLIBC_2.34
000a5714 T __fts64_close_time64@@GLIBC_2.34
000a5504 T __fts64_open_time64@@GLIBC_2.34
000a57cc T __fts64_read_time64@@GLIBC_2.34
000a5b44 T __fts64_set_time64@@GLIBC_2.34
000a7f00 T __ftw64_time64@@GLIBC_2.34
000c9270 T __gai_suspend_time64@@GLIBC_2.34
00090c1c T __glob64_time64@@GLIBC_2.34
00091bd8 T __globfree64_time64@@GLIBC_2.34
000adc48 T __ioctl_time64@@GLIBC_2.34
000a8a80 T __lstat64_time64@@GLIBC_2.34
00066fb4 T __mq_timedreceive_time64@@GLIBC_2.34
00067194 T __mq_timedsend_time64@@GLIBC_2.34
000a7f18 T __nftw64_time64@@GLIBC_2.34
000b2594 W __prctl_time64@@GLIBC_2.34
000a9808 T __stat64_time64@@GLIBC_2.34
0007e45c T __time64@@GLIBC_2.34
0009e5c8 T __wait3_time64@@GLIBC_2.34
0009e6a4 T __wait4_time64@@GLIBC_2.34

i see :
000a2838 T __fstat64_time64@@GLIBC_2.34
000a29d8 T __fstatat64_time64@@GLIBC_2.34
000a8a80 T __lstat64_time64@@GLIBC_2.34
000a9808 T __stat64_time64@@GLIBC_2.34

from box86.

Do you build the tip of master branch with "-D_TIME_BITS=32" or without it (the default _TIME_BITS is 64, and it's broken)?

Can you compare the required symbols of both binaries, the faulty master and the working, earlier commit? The command if I'm not mistaken is objdump -T box86

from box86.

Do you build the tip of master branch with "-D_TIME_BITS=32" or without it (the default _TIME_BITS is 64, and it's broken)?

i only used -D_TIME_BITS=32 for older working 2e589f4 since i had to (or else it errored), i didn't add it for d3d971d because i thought it would cause more issues and it wasn't mentioned in COMPILE.md anyway

but i recompiled the d3d971d and master (c5bccdf) with -D CMAKE_C_FLAGS="-D_TIME_BITS=32" and winecfg is working now!

Can you compare the required symbols of both binaries, the faulty master and the working, earlier commit? The command if I'm not mistaken is objdump -T box86

build-master-broken.txt = faulty master (no -D_TIME_BITS=32)

build-master-time.txt = working master (yes -D_TIME_BITS=32)

build-test.txt = faulty d3d971d (no -D_TIME_BITS=32)

build-time32.txt = working d3d971d (yes -D_TIME_BITS=32)

build-working.txt = working earlier commit 2e589f4 (yes -D_TIME_BITS=32)

(cant build 2e589f4 without -D_TIME_BITS=32 or it errors)

diff between working earlier commit 2e589f4 and master compiled with -D_TIME_BITS=32 is that master has those extra lines:

__fstat64_time64
__fstatat64_time64
__lstat64_time64
my___fstat64_time64
my___fstatat64_time64
my___lstat64_time64
my___stat64_time64
__stat64_time64

the difference between master compiled without -D_TIME_BITS=32 and working earlier commit 2e589f4 is:

master without -D_TIME_BITS=32 has this:

__clock_gettime64
__fcntl_time64
__fstat64_time64
__fstatat64_time64
__fts64_children_time64
__fts64_close_time64
__fts64_open_time64
__fts64_read_time64
__ftw64_time64
getrlimit64
__getsockopt64
__glob64_time64
__ioctl_time64
__lstat64_time64
my___fcntl_time64
my_fstat
my___fstat64_time64
my___fstatat64_time64
my_lstat
my___lstat64_time64
my___stat64_time64
__nanosleep64
__nftw64_time64
__prctl_time64
__pthread_cond_timedwait64
__pthread_mutex_timedlock64
__recvmsg64
__select64
__semctl64
__sendmsg64
__setsockopt64
__stat64_time64
__time64

while working earlier commit 2e589f4 with -D_TIME_BITS=32 has:

clock_gettime
fcntl64
fopen
fstat64
fstatat64
fts_children
fts_close
fts_open
fts_read
ftw64
getrlimit
getsockopt
glob64
ioctl
lstat64
mmap
nanosleep
nftw64
prctl
pthread_cond_timedwait
pthread_mutex_timedlock
recvmsg
select
semctl
sendmsg
setsockopt
stat
stat64
time

from box86.

For now I'd suggest either:

• CMake forcing _TIME_BITS to 32 in the main CMakeLists
• a short warning stating that time64 builds may not be functional, enclosed in an #ifdef _TIME_BITS == 64

from box86.

Can you update box86 and try again, see if it's fixed now?

from box86.

Can you update box86 and try again, see if it's fixed now?

sorry for answering late, i have a build error (building 66a91b8, cmake .. -D RK3588=1 -D CMAKE_BUILD_TYPE=RelWithDebInfo)

[ 42%] Building C object CMakeFiles/box86.dir/src/libtools/myalign64.c.o
/home/osaka/git/box86/src/libtools/myalign64.c: In function ‘UnalignStat64’:
/home/osaka/git/box86/src/libtools/myalign64.c:32:31: error: ‘struct stat64’ has no member named ‘__st_ino’; did you mean ‘st_ino’?
   32 |     i386st->__st_ino    = st->__st_ino;
      |                               ^~~~~~~~
      |                               st_ino
/home/osaka/git/box86/src/libtools/myalign64.c: In function ‘AlignStat64’:
/home/osaka/git/box86/src/libtools/myalign64.c:69:9: error: ‘struct stat64’ has no member named ‘__st_ino’; did you mean ‘st_ino’?
   69 |     st->__st_ino        = i386st->__st_ino;
      |         ^~~~~~~~
      |         st_ino
make[2]: *** [CMakeFiles/box86.dir/build.make:803: CMakeFiles/box86.dir/src/libtools/myalign64.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:370: CMakeFiles/box86.dir/all] Error 2
make: *** [Makefile:166: all] Error 2

from box86.