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
<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-users+unsubscr...@googlegroups.com
<mailto:turbovnc-users+unsubscr...@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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/9a277423-8105-beb4-effa-eb8620f315c1%40virtualgl.org.
