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! On Sunday, May 23, 2021 at 1:23:57 PM UTC-7 DRC wrote: > 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 > On 5/23/21 2:05 PM, SugarRayLua wrote: > > 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 > > On Sunday, May 23, 2021 at 7:38:28 AM UTC-7 DRC wrote: > >> >> 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. >> >> 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, >> >> On Friday, May 21, 2021 at 3:15:26 PM UTC-7 DRC wrote: >> >>> 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 >>> On 5/21/21 3:44 PM, SugarRayLua wrote: >>> >>> >>> 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, >>> On Friday, May 21, 2021 at 9:42:10 AM UTC-7 DRC wrote: >>> >>>> 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 >>>> On 5/20/21 4:13 PM, SugarRayLua wrote: >>>> >>>> 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 >>>> On Wednesday, May 19, 2021 at 7:26:04 AM UTC-7 DRC wrote: >>>> >>>>> 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'. >>>>> On 5/15/21 9:36 PM, SugarRayLua wrote: >>>>> >>>>> 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 >>>>> >>>>> On Saturday, May 15, 2021 at 5:05:14 PM UTC-7 DRC wrote: >>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> 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, >>>>>> >>>>>> On Saturday, May 15, 2021 at 5:04:43 AM UTC-7 DRC wrote: >>>>>> >>>>>>> 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, >>>>>>> >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/turbovnc-users/797b6ea1-993a-4e5e-a718-d6f47b94379dn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> -- >>>>>> 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/ac661251-a0ef-4606-9ba2-a934692d4224n%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/turbovnc-users/ac661251-a0ef-4606-9ba2-a934692d4224n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> -- >>>>> 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/01f07e12-e2ea-40db-9a95-d5ba1c962addn%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/turbovnc-users/01f07e12-e2ea-40db-9a95-d5ba1c962addn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> -- >>>> 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/08f243f1-58bf-4799-9df9-3d2d28f7c0d7n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/turbovnc-users/08f243f1-58bf-4799-9df9-3d2d28f7c0d7n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- >>> 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/18137fd8-d832-479d-960a-18fa2cb7a786n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/turbovnc-users/18137fd8-d832-479d-960a-18fa2cb7a786n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >> 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/78975d38-d828-4605-b9db-e85f6b2c590en%40googlegroups.com >> >> <https://groups.google.com/d/msgid/turbovnc-users/78975d38-d828-4605-b9db-e85f6b2c590en%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- > 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/9fd18102-40d5-4eaf-94d3-a34eef721b38n%40googlegroups.com > > <https://groups.google.com/d/msgid/turbovnc-users/9fd18102-40d5-4eaf-94d3-a34eef721b38n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/e24e4a7b-5e06-42d4-9a1b-c052208543e0n%40googlegroups.com.
