Any suggestions to fix “In function ‘GetLocalClientCreds’ error = storage size of ‘peercred’ isn’t known error during make build of TurboVNC?

[SugarRayLua]

Hello, again, TurboVNC Community,

I’m still trying to build TurboVNC for Alpine Linux x86 from downloaded tarball. I managed to get cmake to work successfully and got through 84% of the make build before I got an “in function ‘GetLocalClientCreds’ error = storage size of ‘peercred’ isn’t known error”. I’m still a Linux novice and searched the web for other users who encountered that error and most said that setting either the CFLAGS or CPPFLAGS variable to “-D_GNU_SOURCE” (e.g. make CFLAGS=-D_GNU_SOURCE) allowed the make build to compile. However, setting neither flag fixes the problem and allows the make build for me.

Does anyone have any other suggestions?

I appreciate any assistance anyone could offer.

Thanks and have a good night. 

[DRC]

Please post the full text of the error so I can see where it is occurring. Build errors are never very meaningful without context.

On May 15, 2021, at 12:50 AM, SugarRayLua <meaning...@gmail.com> wrote:

Hello, again, TurboVNC Community,

--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/797b6ea1-993a-4e5e-a718-d6f47b94379dn%40googlegroups.com.

[SugarRayLua]

Ok, thanks.

Here is what I believe is the most verbose debugging of the relevant part of the make where the build stopped:

Pruning file 'unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/flags.make'.

     Finished prerequisites of target file 'unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o'.

    Must remake target 'unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o'.

Putting child 0x565bb320 (unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o) PID 674 on the chain.

Live child 0x565bb320 (unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o) PID 674 

[ 84%] Building C object unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o

Reaping winning child 0x565bb320 PID 674 

Live child 0x565bb320 (unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o) PID 675 

/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c: In function 'GetLocalClientCreds':

/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c:1178:18: error: storage size of 'peercred' isn't known

 1178 |     struct ucred peercred;

      |                  ^~~~~~~~

Reaping losing child 0x565bb320 PID 675 

make[2]: *** [unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make:96: unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o] Error 1

Removing child 0x565bb320 PID 675 from chain.

Reaping losing child 0x565d3d60 PID 673 

make[1]: *** [CMakeFiles/Makefile2:2834: unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/all] Error 2

Removing child 0x565d3d60 PID 673 from chain.

Reaping losing child 0x565ac240 PID 522 

make: *** [Makefile:150: all] Error 2

Removing child 0x565ac240 PID 522 from chain.“

Please let me know if you need more information.

Sincerely, 

[DRC]

Can you rerun with

make VERBOSE=1

? I need to see which include directories are being passed to the compiler, because it seems as if one of the in-tree X.org headers isn’t being picked up (or are you using TVNC_SYSTEMX11?)

On May 15, 2021, at 4:46 PM, SugarRayLua <meaning...@gmail.com> wrote:

Ok, thanks.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/ac661251-a0ef-4606-9ba2-a934692d4224n%40googlegroups.com.

[SugarRayLua]

Thanks again for your continued help.

If I am understanding you correctly, no, I did not make the build with adding the switch “TVNC_SYSTEMX11=1”) if that was what your were asking (i.e. just did “make”)

Here is the relevant debug output again but with make VERBOSE=1:

[ 84%] Built target sync

make  -f unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/depend

make[2]: Entering directory '/root/turbovnc-2.2.6'

cd /root/turbovnc-2.2.6 && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /root/turbovnc-2.2.6 /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os /root/turbovnc-2.2.6 /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/DependInfo.cmake --color=

make[2]: Leaving directory '/root/turbovnc-2.2.6'

make  -f unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build

make[2]: Entering directory '/root/turbovnc-2.2.6'

[ 84%] Building C object unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o

cd /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os && /usr/bin/cc -DCLIENTIDS -DCOMPOSITE -DDAMAGE -DDPMSExtension -DGLXEXT -DHASXDMAUTH -DHAS_SHM -DHAVE_DIX_CONFIG_H -DHAVE_SHA1_IN_LIBSHA1 -DHAVE_XSHMFENCE -DIPv6 -DMITSHM -DMONOTONIC_CLOCK -DNVCONTROL -DPANORAMIX -DPRESENT -DRANDR -DRENDER -DRES -DSCREENSAVER -DSHAPE -DTCPCONN -DTURBOVNC -DUNIXCONN -DUSE_POLL -DXACE -DXCSECURITY -DXDMCP -DXF86BIGFONT -DXFIXES -DXINPUT -DXRECORD -DXTEST -DXV -I/root/turbovnc-2.2.6/unix/include -I/root/turbovnc-2.2.6/unix/Xvnc/X_include -I/root/turbovnc-2.2.6/common/zlib -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/Xext -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/include -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/miext/damage -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/present -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/../../lib/pixman/pixman -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/../render -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/../../../lib/libsha1  -w -O3 -DNDEBUG    -fno-strict-aliasing -o CMakeFiles/os.dir/access.c.o   -c /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c

/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c: In function 'GetLocalClientCreds':

/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c:1178:18: error: storage size of 'peercred' isn't known

 1178 |     struct ucred peercred;

      |                  ^~~~~~~~

make[2]: *** [unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make:96: unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o] Error 1

make[2]: Leaving directory '/root/turbovnc-2.2.6'

make[1]: *** [CMakeFiles/Makefile2:2834: unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/all] Error 2

make[1]: Leaving directory '/root/turbovnc-2.2.6'

make: *** [Makefile:150: all] Error 2

[DRC]

I think this is also a distribution-specific issue.  I verified that my build is using the same code path in access.c that your build is using.  If sys/socket.h defines SO_PEERCRED, then access.c will try to use 'struct ucred'.  (NOTE: access.c is X.org code, not TurboVNC code.)  However, 'struct ucred' is apparently only defined if _GNU_SOURCE is defined, so the first thing I would do is 'make VERBOSE=1' and verify whether _GNU_SOURCE is defined on the command line that builds access.c.  If it isn't, then it's probably because this build system check failed: https://github.com/TurboVNC/turbovnc/blob/main/unix/Xvnc/CMakeLists.txt#L4-L9, which would happen if features.h doesn't define __GLIBC__ on your system.  It could also be that, for whatever reason, your system doesn't define 'struct ucred'.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/01f07e12-e2ea-40db-9a95-d5ba1c962addn%40googlegroups.com.

[SugarRayLua]

Thanks,  DRC.

If I am understanding your instructions correctly, I do not think _GNU_SOURCE is defined on the command line that builds access.c:

“

Building C object unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o

cd /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os && /usr/bin/cc -DCLIENTIDS -DCOMPOSITE -DDAMAGE -DDPMSExtension -DGLXEXT -DHASXDMAUTH -DHAS_SHM -DHAVE_DIX_CONFIG_H -DHAVE_SHA1_IN_LIBSHA1 -DHAVE_XSHMFENCE -DIPv6 -DMITSHM -DMONOTONIC_CLOCK -DNVCONTROL -DPANORAMIX -DPRESENT -DRANDR -DRENDER -DRES -DSCREENSAVER -DSHAPE -DTCPCONN -DTURBOVNC -DUNIXCONN -DUSE_POLL -DXACE -DXCSECURITY -DXDMCP -DXF86BIGFONT -DXFIXES -DXINPUT -DXRECORD -DXTEST -DXV“

Alpine Linux uses musl although I do have glib also installed. 

Is there any simple instructions you could offer for me to modify CMakeFile or my Make build to enable _GNU_SOUCE? I’ve tried make CFLAGS=-D_GNU_SOURCE but that doesn’t work.  As a novice user, I don’t have the knowledge to do any other changes myself.

I’ll write the Alpine Linux support also to see if there is anything they can suggest.

Thanks for your continued efforts to help.

Sincerely 

[SugarRayLua]

Sorry, typographical error—I meant to say I have glibc installed. 

[DRC]

I assume you also have the glibc development headers/library installed?  If so, then /usr/include/features.h should exist, and that header should define __GLIBC__.  If it doesn't, then that's also a distribution-specific issue.

If you have the glibc development headers/library installed and the build is still failing, then I'm clueless.  The TurboVNC build system detects glibc in exactly the same way that the (autotools-based) X.org build system does.  Thus, the X.org Alpine package may have faced similar difficulties, and it may be instructive to look at that package and see how they worked around them.

glibc is a documented requirement of the TurboVNC Server on Linux.  Even if we were able to work around this specific compatibility issue with musl, there are many others that would pop up.

DRC

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/08f243f1-58bf-4799-9df9-3d2d28f7c0d7n%40googlegroups.com.

[SugarRayLua]

Thanks, DRC. 

I do have glibc and its headers installed. I found features.h in the usr/include directory and printed its code as follows:

iPad:/usr/include# cat ./features.h

#ifndef _FEATURES_H

#define _FEATURES_H

#if defined(_ALL_SOURCE) && !defined(_GNU_SOURCE)

#define _GNU_SOURCE 1

#endif

#if defined(_DEFAULT_SOURCE) && !defined(_BSD_SOURCE)

#define _BSD_SOURCE 1

#endif

#if !defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE) \

 && !defined(_XOPEN_SOURCE) && !defined(_GNU_SOURCE) \

 && !defined(_BSD_SOURCE) && !defined(__STRICT_ANSI__)

#define _BSD_SOURCE 1

#define _XOPEN_SOURCE 700

#endif

#if __STDC_VERSION__ >= 199901L

#define __restrict restrict

#elif !defined(__GNUC__)

#define __restrict

#endif

#if __STDC_VERSION__ >= 199901L || defined(__cplusplus)

#define __inline inline

#elif !defined(__GNUC__)

#define __inline

#endif

#if __STDC_VERSION__ >= 201112L

#elif defined(__GNUC__)

#define _Noreturn __attribute__((__noreturn__))

#else

#define _Noreturn

#endif

#endif

Sorry about my continued linux knowledge limit but is defining _GNU_SOURCE 1 the same as defining _GLIBC_ as you suggested? If so, then will let the Alpine Linux support know what you’ve said and wait to see if they can offer any further suggestions.

If my features.h file doesn’t define _GLIBC_ could I modify the file myself to define it? I realize that it is a header file and part of an important library of core code so may not be a good idea. However, I’m not running any critical files on my linux install, and if the Alpine Linux support thought it might work by adding a definition to that file, I’d be willing to try it.

What do you think?

Sincerely,

[DRC]

I just noticed that, earlier, you tried to do:

    make CFLAGS=-D_GNU_SOURCE

That won't work with CMake-generated Makefiles, because CMake populates the compiler flags in the Makefiles whenever it generates the build.  Try instead:

    cd {build-directory}
    rm -rf CMake*
    cmake {any-other-CMake-args-you-need} -DCMAKE_C_FLAGS="-D_GNU_SOURCE -D__GLIBC__" {source-directory}
    make

NOTE: 'rm -rf CMake*' clears any cached build state.  Doing that isn't necessary with a fresh build directory, nor is it necessary when rebuilding.  I only suggested it above in order to make 100% sure that the new compiler flags are applied, because I can't remember how aggressively CMake caches those.

If that doesn't work, then I will repeat my advice to look at the X.org X server package for Alpine and see what they did to make it build.  X.org also requires __GLIBC__ to be defined in features.h.

To answer your question about __GLIBC__, there are other places within the TurboVNC Server code that check for __GLIBC__ to be defined, so it's best to define both __GLIBC__ and _GNU_SOURCE.

DRC

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/18137fd8-d832-479d-960a-18fa2cb7a786n%40googlegroups.com.

[SugarRayLua]

Partial success! :-)

DRC, 

Your idea worked! It just turned out that I had to had set in cmake -DCMAKE_C_FLAGS=“-D_GNU_SOURCE” and then it would make compile and make install (adding -D__GLIBC__ broke the cmake for some reason and didn’t seem to be needed to finish the build).

However, when I actually started to try and use TurboVNC, I could start vncserver, but when I tried to connect from a client, it would not finish connecting and the log file indicated the connection aborted due to some illegal commands. I suspect that actually might be a problem with the x86 emulator running the Alpine Linux (as it is known to not be able to yet run all Linux programs) but before I ask for any continued assistance, I’d like to double check with you that TurboVNC theoretically (if I got it working) could do what I was hoping it to do. Specifically, could I:

1) connect remotely to TurboVNC vncserver with any VNC viewer (i.e. not just TurboVNC vncviewer)? I want to be able to do so since I’m aiming to use TurboVNC to allow me to see Linux 3D graphics on my iPad Alpine LInux emulator which the server is on does not have 3D graphics capabilities itself (so VirtualGL won’t helP) and the viewer client is a separate app on my iPAD that is not a Linux device (i.e. I couldn’t install TurboVNC vncviewer on it)

2) view 3D graphics (eg openGL graphics) originating from the linux TurboVNC vncserver headless host given as I mentioned above that the headless host does not have any means to render 3D graphics (i.e. no ability to connect directly from the LInux server to the iPAD’s graphic system) and no link from the iPad’s separate non-Linux VNC viewer to render 3D graphics from the viewer itself. My understanding is that the TurboVNC program is the only VNC program that can software render 3D graphics coming from the VNC server and convert such graphics to a 2D image to then send and be displayed on the VNC non-linux, non 3D graphics viewer. If I am mistaken in this ability of TurboVNC’s then, I will not ask you further for assistance in trying to get this to work for my needs and the needs of the iSH Linux x86 emulator community (it may still be useful for the larger Alpine LInux community though as you helped me show that it at least can be built on that distribution).

I appreciate your further thoughts and time; I’ve learned a lot more about Linux, cmake, make and X from trying to build this on my machine.

Sincerely, 

[DRC]

However, when I actually started to try and use TurboVNC, I could start vncserver, but when I tried to connect from a client, it would not finish connecting and the log file indicated the connection aborted due to some illegal commands. I suspect that actually might be a problem with the x86 emulator running the Alpine Linux (as it is known to not be able to yet run all Linux programs)

If the emulator doesn’t have full support for various x86 SIMD instruction sets, then that could explain it. Try setting JSIMD_FORCENONE=1 in the environment to turn off SIMD acceleration in libjpeg-turbo, but understand that that will reduce the performance of the TurboVNC Server dramatically.

1) connect remotely to TurboVNC vncserver with any VNC viewer (i.e. not just TurboVNC vncviewer)? I want to be able to do so since I’m aiming to use TurboVNC to allow me to see Linux 3D graphics on my iPad Alpine LInux emulator which the server is on does not have 3D graphics capabilities itself (so VirtualGL won’t helP) and the viewer client is a separate app on my iPAD that is not a Linux device (i.e. I couldn’t install TurboVNC vncviewer on it)

Yes. Refer to the TurboVNC User’s Guide for compatibility notes. Generally, any VNC viewer will work, but only VNC viewers that support the TightVNC decoder with TurboVNC’s optimizations and the RFB flow control extensions will perform optimally in all cases. Currently, that includes only the TurboVNC and TigerVNC Viewers.

2) view 3D graphics (eg openGL graphics) originating from the linux TurboVNC vncserver headless host given as I mentioned above that the headless host does not have any means to render 3D graphics (i.e. no ability to connect directly from the LInux server to the iPAD’s graphic system) and no link from the iPad’s separate non-Linux VNC viewer to render 3D graphics from the viewer itself. My understanding is that the TurboVNC program is the only VNC program that can software render 3D graphics coming from the VNC server and convert such graphics to a 2D image to then send and be displayed on the VNC non-linux, non 3D graphics viewer. If I am mistaken in this ability of TurboVNC’s then, I will not ask you further for assistance in trying to get this to work for my needs and the needs of the iSH Linux x86 emulator community (it may still be useful for the larger Alpine LInux community though as you helped me show that it at least can be built on that distribution).

“view 3D graphics (eg openGL graphics) originating from the linux TurboVNC vncserver headless host” is awkward terminology, so I don’t quite understand your meaning there. If you mean that you want to remotely display the output of the TurboVNC host’s graphics card/GPU, then no, TurboVNC cannot do that. TurboVNC creates one or more virtual X servers on demand, and those virtual X servers are not connected to the host’s graphics hardware (VirtualGL is used to establish that connection for the purpose of enabling GPU acceleration for OpenGL.) If software-rendered OpenGL is all you need, however, then the TurboVNC Server does support that. It is not the only VNC server that supports that, however. TigerVNC does too, although their server is generally a lot harder to build.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/78975d38-d828-4605-b9db-e85f6b2c590en%40googlegroups.com.

[SugarRayLua]

Thanks, again, DRC. That answers all of my questions, and yes, I meant to say that all I needed was software-rendered OpenGL which x11vnc that I was using didn’t seem to be able to render.

I did try to set the environment variable as you suggested. It didn’t, however, remedy the illegal command. Here is the log with the reference to the illegal instruction at the end (TurboVNC vncserver running on Alpine Linux on iPad x86 emulator; Remoter VNC viewer client app on same iPad connecting via local host):

iPad:/opt/TurboVNC/bin# cat /root/.vnc/iPad:1.log

TurboVNC Server (Xvnc) 32-bit v2.2.6 (build 20210521)

Copyright (C) 1999-2021 The VirtualGL Project and many others (see README.txt)

Visit http://www.TurboVNC.org for more information on TurboVNC

23/05/2021 11:53:44 Using security configuration file /opt/TurboVNC/etc/turbovncserver-security.conf

23/05/2021 11:53:44 Enabled security type 'tlsvnc'

23/05/2021 11:53:44 Enabled security type 'tlsotp'

23/05/2021 11:53:44 Enabled security type 'tlsplain'

23/05/2021 11:53:44 Enabled security type 'x509vnc'

23/05/2021 11:53:44 Enabled security type 'x509otp'

23/05/2021 11:53:44 Enabled security type 'x509plain'

23/05/2021 11:53:44 Enabled security type 'vnc'

23/05/2021 11:53:44 Enabled security type 'otp'

23/05/2021 11:53:44 Enabled security type 'unixlogin'

23/05/2021 11:53:44 Enabled security type 'plain'

23/05/2021 11:53:44 Desktop name 'TurboVNC: iPad:1 (root)' (iPad:1)

23/05/2021 11:53:44 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t

23/05/2021 11:53:44 Listening for VNC connections on TCP port 5901

23/05/2021 11:53:44   Interface 0.0.0.0

23/05/2021 11:53:44 Framebuffer: BGRX 8/8/8/8

23/05/2021 11:53:44 New desktop size: 1240 x 900

23/05/2021 11:53:44 New screen layout:

23/05/2021 11:53:44   0x00000040 (output 0x00000040): 1240x900+0+0

23/05/2021 11:53:44 Maximum clipboard transfer size: 1048576 bytes

23/05/2021 11:53:44 VNC extension running!

XFree86-Bigfont extension: shmget() failed, size = 790528, Function not implemented

XFree86-Bigfont extension: shmget() failed, size = 790528, Function not implemented

XFree86-Bigfont extension: shmget() failed, size = 790528, Function not implemented

XFree86-Bigfont extension: shmget() failed, size = 790528, Function not implemented

XFree86-Bigfont extension: shmget() failed, size = 790528, Function not implemented

XFree86-Bigfont extension: shmget() failed, size = 790528, Function not implemented

XFree86-Bigfont extension: shmget() failed, size = 790528, Function not implemented

XFree86-Bigfont extension: shmget() failed, size = 790528, Function not implemented

23/05/2021 11:54:15 Got connection from client 127.0.0.1

23/05/2021 11:54:15 Could not enable TCP corking: Invalid argument

23/05/2021 11:54:15 Using protocol version 3.8

23/05/2021 11:54:15 Could not disable TCP corking: Invalid argument

23/05/2021 11:54:15 Full-control authentication enabled for 127.0.0.1

23/05/2021 11:54:15 Pixel format for client 127.0.0.1:

23/05/2021 11:54:15   16 bpp, depth 15, little endian

23/05/2021 11:54:15   true colour: max r 31 g 31 b 31, shift r 10 g 5 b 0

23/05/2021 11:54:15 Using tight encoding for client 127.0.0.1

23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown encoding 9 (9)

23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown encoding -65527 (ffff0009)

23/05/2021 11:54:15 Interframe comparison enabled

23/05/2021 11:54:15 Using JPEG subsampling 0, Q86 for client 127.0.0.1

23/05/2021 11:54:15 Enabling X-style cursor updates for client 127.0.0.1

23/05/2021 11:54:15 Enabling cursor position updates for client 127.0.0.1

23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown encoding -131072 (fffe0000)

23/05/2021 11:54:15 Enabling Desktop Size protocol extension for client 127.0.0.1

23/05/2021 11:54:15 Enabling LastRect protocol extension for client 127.0.0.1

23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown encoding -131071 (fffe0001)

23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown encoding -131070 (fffe0002)

23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown encoding -131069 (fffe0003)

23/05/2021 11:54:15 Using Tight compression level 2 for client 127.0.0.1

23/05/2021 11:54:15 Using 2 threads for Tight encoding

(EE) Illegal instruction at address 0x56879339

(EE) 

Fatal server error:

(EE) Caught signal 4 (Illegal instruction). Server aborting

(EE) (EE) 

Illegal instruction at address 0x56879339

(EE) 

FatalError re-entered, aborting

(EE) Caught signal 4 (Illegal instruction). Server aborting

(EE) 

xterm: fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":1"

xterm: fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":1"

Fyi

[DRC]

x11vnc is just a screen scraper.  It doesn't render anything.  It attempts, as best as it can, to figure out when pixels have changed on the X server to which it is attached, and it encodes and transmits those pixels using the RFB protocol.  Direct-rendered OpenGL, however, bypasses the mechanisms that x11vnc uses to figure out when pixels have changed, so x11vnc can't generally detect those changes.

As far as the illegal instruction failure, you may want to try various combinations of setting/unsetting JSIMD_FORCENONE=1 in the environment and passing -DTVNC_SYSTEMLIBS=0 or -DTVNC_SYSTEMLIBS=1 to cmake when configuring the build.  It occurred to me that we are using a SIMD-accelerated zlib implementation as well.  Passing -DTVNC_SYSTEMLIBS=0 to the build will disable it and use the system's zlib implementation (and the system's bzip2 and FreeType implementations, so you'll need those dev kits installed as well.)  If that doesn't work, then I have no clue.  You are very far outside of the scope of my support.  Hopefully you can get away with disabling the SIMD-accelerated zlib implementation but leaving SIMD acceleration enabled in libjpeg-turbo.  That would at least give you good performance for the most common cases.

At this point, any further issues will need to be addressed on your end, unless you can confirm that those issues affect TurboVNC on supported platforms.  Good luck.

DRC

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/9fd18102-40d5-4eaf-94d3-a34eef721b38n%40googlegroups.com.

[SugarRayLua]

Thank you very much for all of your help. I’ll try all of your suggestions. If they don’t work now, I’ll try them again as the iSH emulator gets updated. I may also try and built TurboVNC on an Alpine docker image just to see if problem might be Alpine linux vs my emulator.

If I get it to work, I’ll definitely let you know :-)

Have a great week!