SBo scripts not building on current (read 1st post, pls)

ponce · 05-26-2019, 09:27 AM

Quote:

Originally Posted by olear

I just made it myself (simple backport). I can check my build server at work tomorrow and give you a patch.

thank you in advance!

dugan · 05-26-2019, 06:35 PM

Has this been reported yet? I'm trying to build libgtop 2.34 (for Plank), and I'm getting:

Code:

Making all in lib
make[2]: Entering directory '/tmp/SBo/libgtop-2.34.0/lib'
perl ./lib.pl < ../features.def > lib-t
Assigning non-zero to $[ is no longer possible at ./lib.pl line 3.
make[2]: *** [Makefile:826: lib.c] Error 255
make[2]: Leaving directory '/tmp/SBo/libgtop-2.34.0/lib'
make[1]: *** [Makefile:583: all-recursive] Error 1
make[1]: Leaving directory '/tmp/SBo/libgtop-2.34.0'
make: *** [Makefile:467: all] Error 2
bash-5.0#

UPDATE: Had the same problem with 2.36, but 2.38 built with a version bump.

willysr · 05-26-2019, 07:18 PM

Quote:

Originally Posted by dugan

Has this been reported yet? I'm trying to build libgtop 2.34 (for Plank), and I'm getting:

Code:

Making all in lib
make[2]: Entering directory '/tmp/SBo/libgtop-2.34.0/lib'
perl ./lib.pl < ../features.def > lib-t
Assigning non-zero to $[ is no longer possible at ./lib.pl line 3.
make[2]: *** [Makefile:826: lib.c] Error 255
make[2]: Leaving directory '/tmp/SBo/libgtop-2.34.0/lib'
make[1]: *** [Makefile:583: all-recursive] Error 1
make[1]: Leaving directory '/tmp/SBo/libgtop-2.34.0'
make: *** [Makefile:467: all] Error 2
bash-5.0#

UPDATE: Had the same problem with 2.36, but 2.38 built with a version bump.

i just pushed an update to 2.38.0 in my branch
it will go to the next public update

olear · 05-28-2019, 05:12 PM

Quote:

Originally Posted by ponce

thank you in advance!

Sorry for the late reply.

I could not take the modifications from work since it's under a commercial license, but I already had a opensource patch that I found on my spare laptop that I forgot, I updated/verified that it patches against a vanilla qtbase-5.9.8 and builds (-openssl(-linked) -opensource) and links against OpenSSL 1.1 on Slackware -current GCC 8.3.0 and Windows 8.1 MSVC 2015.

You will probably need to adjust diff paths if you patch against the "fat" source from Qt, I only use qtbase and qtx11extras.

If you have any issues etc just let my know.

Regards

Ole-André

ponce · 05-29-2019, 01:23 AM

thanks a lot, olear! I just made a fast test with some qt5 apps using openssl and everything seems fine!

I just readded a couple of things that were present in the previous commit: it's ok for you if I set you as the commit author? if you prefer I can also remove the non-patching stuff...

Code:

--- ./qt5.SlackBuild.orig       2019-05-25 02:35:19.000000000 +0200
+++ ./qt5.SlackBuild    2019-05-29 06:22:31.179209000 +0200
@@ -157,6 +157,10 @@
  \( -perm 666 -o -perm 664 -o -perm 640 -o -perm 600 -o -perm 444 \
   -o -perm 440 -o -perm 400 \) -exec chmod 644 {} \+
 
+# Backport support for openssl-1.1.x
+( cd qtbase
+  patch -p1 < $CWD/patches/qtbase59-openssl11.patch )
+
 # Limit -reduce-relocations to ix86 and x86_64.
 # https://bugreports.qt-project.org/browse/QTBUG-36129
 if echo $ARCH | grep -q '\(i.86\|x86_64\)' 2>/dev/null; then
@@ -189,7 +193,7 @@
   qtbase/mkspecs/common/gcc-base.conf
 
 export CFLAGS="$SLKCFLAGS"
-export CXXFLAGS="$SLKCFLAGS -std=c++11"
+export CXXFLAGS="$SLKCFLAGS"
 ./configure -v \
   -confirm-license \
   -opensource \
@@ -217,7 +221,7 @@
   -no-strip \
   -release \
   -no-use-gold-linker \
-  -c++std c++11 \
+  -optimized-qmake \
   $CCACHE \
   $CODECS \
   $PULSE \

olear · 05-29-2019, 09:37 AM

Good. The patch should also be easy to maintain (backporting ssl fixes from latest Qt if needed, compatibility with future 5.9.x releases (it already support 5.9.1 to 5.9.8)).

shelldweller · 05-29-2019, 12:59 PM

Hello Fellow Slackers,

I have been having a problem with VICE since a few system updates ago. VICE builds just fine, and used to work just fine. However, after one of the -current updates in the past few weeks (not sure which one, I wasn't paying that close of attention), now when I start up any of the VICE instances (all give the same result), I get a window with only a blank grey screen instead of the usual shades-of-blue (in the case of x64). I have checked this on a fresh installation of -current as well as my daily driver, and I get the same result. I also tried building the latest versions of xa and VICE from source and the dreaded GSOD is still there. Trying this on other distros (including 14.2) does not present this problem.

My hunch is that it is related to libglvnd being added as a new dependency for mesa. I have no evidence to support this except that the problems with VICE seemed to start right around that same time.

Screenshot attached. Any ideas? Thanks in advance.....

ponce · 05-29-2019, 01:11 PM

I'm not able to replicate your GSOD (x64 works fine here on current).

maybe you could have some hints launching "x64" from a terminal and having a look at the output (it even has a "-verbose" command line option that slightly increases verbosity)...

pelaocds · 05-29-2019, 05:06 PM

I am having issues compiling 'barrier' on current.
Have reported it to the maintainer but he doesn't have any issues.

Quote:

/usr/bin/ld: warning: libssp.so.0, needed by /usr/lib64/gcc/x86_64-slackware-linux/8.3.0/../../../../lib64/libdns_sd.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /usr/lib64/gcc/x86_64-slackware-linux/8.3.0/../../../../lib64/libdns_sd.so: undefined reference to `__stack_chk_fail@LIBSSP_1.0'

Any advice?

USUARIONUEVO · 05-29-2019, 05:11 PM

Quote:

Originally Posted by pelaocds

I am having issues compiling 'barrier' on current.
Have reported it to the maintainer but he doesn't have any issues.

Any advice?

since i see gcc-8 in the message , i think your not in a updated current system, cause some weeks a go updates gcc8 to gcc9

pelaocds · 05-29-2019, 05:28 PM

Quote:

Originally Posted by USUARIONUEVO

since i see gcc-8 in the message , i think your not in a updated current system, cause some weeks a go updates gcc8 to gcc9

Thanks. Have upgraded and now the error has been updated too hahaha

Quote:

/usr/bin/ld: warning: libssp.so.0, needed by /usr/lib64/gcc/x86_64-slackware-linux/9.1.0/../../../../lib64/libdns_sd.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /usr/lib64/gcc/x86_64-slackware-linux/9.1.0/../../../../lib64/libdns_sd.so: undefined reference to `__stack_chk_fail@LIBSSP_1.0'
collect2: error: ld returned 1 exit status
make[2]: *** [src/gui/CMakeFiles/barrier.dir/build.make:764: bin/barrier] Error 1
make[2]: Leaving directory '/tmp/SBo/barrier-2.1.2/build'
make[1]: *** [CMakeFiles/Makefile2:919: src/gui/CMakeFiles/barrier.dir/all] Error 2
make[1]: Leaving directory '/tmp/SBo/barrier-2.1.2/build'
make: *** [Makefile:152: all] Error 2
bash-5.0#

bassmadrigal · 05-29-2019, 06:03 PM

Looks like you should recompile your dependencies... at a minimum avahi, as that is what contains libdns_sd.so, which is pointing to the non-existent libssp.so.0

shelldweller · 05-29-2019, 08:15 PM

Quote:

Originally Posted by ponce

maybe you could have some hints launching "x64" from a terminal and having a look at the output (it even has a "-verbose" command line option that slightly increases verbosity)...

Good thinking. However, in my attempt to generate some verbose output, I started comparing different build environments. I ran into something interesting that is more pressing, I think.

I get no GSOD on a bare-metal install of -current. So, YAY there. The GSOD pops up in a fresh install inside of a VM however (only on -current, the same steps in a 14.2 vm result in a working VICE). I am using VMWare to manage my virtual machines, and I am now having troubles while compiling open-vm-tools.

Code:

libtool: compile:  gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"10.2.0\" "-DPACKAGE_STRING=\"open-vm-tools 10.2.0\"" -DPACKAGE_BUGREPORT=\"open-vm-tools-devel@lists.sourceforge.net\" -DPACKAGE_URL=\"\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"10.2.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DX_DISPLAY_MISSING=1 -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DNO_XSM=1 -DNO_XCOMPOSITE=1 -DNO_MULTIMON=1 -I. -I/tmp/SBo/open-vm-tools-10.2.0-7253323/lib/include -I/tmp/SBo/open-vm-tools-10.2.0-7253323/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DHAVE_ICU_38 -DVMX86_TOOLS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_DEFAULT_SOURCE -DENABLE_RESOLUTIONKMS -DVMTOOLS_USE_GLIB -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -O2 -fPIC -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -Wno-deprecated-declarations -Wno-unused-const-variable -Wno-unused-but-set-variable -MT hgfsServer.lo -MD -MP -MF .deps/hgfsServer.Tpo -c hgfsServer.c  -fPIC -DPIC -o .libs/hgfsServer.o
hgfsServer.c: In function ‘HgfsServerRead’:
hgfsServer.c:6542:43: error: taking address of packed member of ‘struct HgfsReplyReadV3’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
 6542 |                                           &reply->actualSize);
      |                                           ^~~~~~~~~~~~~~~~~~
hgfsServer.c:6563:56: error: taking address of packed member of ‘struct HgfsReplyRead’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
 6563 |                                        reply->payload, &reply->actualSize);
      |                                                        ^~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:507: hgfsServer.lo] Error 1
make[2]: Leaving directory '/tmp/SBo/open-vm-tools-10.2.0-7253323/lib/hgfsServer'
make[1]: *** [Makefile:485: all-recursive] Error 1
make[1]: Leaving directory '/tmp/SBo/open-vm-tools-10.2.0-7253323/lib'
make: *** [Makefile:540: all-recursive] Error 1

So, I guess my VICE issue has morphed into an open-vm-tools issue. Thanks for giving me the idea to explore in that direction. I'm starting to think the original GSOD (daily driver, not a VM) is due to missing firmware, long story there. Building open-vm-tools will help me narrow down the issue a bit further. MUCH appreciated......

pelaocds · 05-29-2019, 08:19 PM

Quote:

Originally Posted by bassmadrigal

Looks like you should recompile your dependencies... at a minimum avahi, as that is what contains libdns_sd.so, which is pointing to the non-existent libssp.so.0

That was it! Have recompiled avahi and barrier compiled smoothly now. Thanks!

ponce · 05-29-2019, 10:52 PM

Quote:

Originally Posted by shelldweller

I am using VMWare to manage my virtual machines, and I am now having troubles while compiling open-vm-tools.

Code:

libtool: compile:  gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"10.2.0\" "-DPACKAGE_STRING=\"open-vm-tools 10.2.0\"" -DPACKAGE_BUGREPORT=\"open-vm-tools-devel@lists.sourceforge.net\" -DPACKAGE_URL=\"\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"10.2.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DX_DISPLAY_MISSING=1 -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DNO_XSM=1 -DNO_XCOMPOSITE=1 -DNO_MULTIMON=1 -I. -I/tmp/SBo/open-vm-tools-10.2.0-7253323/lib/include -I/tmp/SBo/open-vm-tools-10.2.0-7253323/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -I/usr/include -DUSE_ICU -DHAVE_ICU_38 -DVMX86_TOOLS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_DEFAULT_SOURCE -DENABLE_RESOLUTIONKMS -DVMTOOLS_USE_GLIB -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -O2 -fPIC -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -Wno-deprecated-declarations -Wno-unused-const-variable -Wno-unused-but-set-variable -MT hgfsServer.lo -MD -MP -MF .deps/hgfsServer.Tpo -c hgfsServer.c  -fPIC -DPIC -o .libs/hgfsServer.o
hgfsServer.c: In function ‘HgfsServerRead’:
hgfsServer.c:6542:43: error: taking address of packed member of ‘struct HgfsReplyReadV3’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
 6542 |                                           &reply->actualSize);
      |                                           ^~~~~~~~~~~~~~~~~~
hgfsServer.c:6563:56: error: taking address of packed member of ‘struct HgfsReplyRead’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
 6563 |                                        reply->payload, &reply->actualSize);
      |                                                        ^~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:507: hgfsServer.lo] Error 1
make[2]: Leaving directory '/tmp/SBo/open-vm-tools-10.2.0-7253323/lib/hgfsServer'
make[1]: *** [Makefile:485: all-recursive] Error 1
make[1]: Leaving directory '/tmp/SBo/open-vm-tools-10.2.0-7253323/lib'
make: *** [Makefile:540: all-recursive] Error 1

So, I guess my VICE issue has morphed into an open-vm-tools issue. Thanks for giving me the idea to explore in that direction. I'm starting to think the original GSOD (daily driver, not a VM) is due to missing firmware, long story there. Building open-vm-tools will help me narrow down the issue a bit further. MUCH appreciated......

modify a line in the SlackBuild like this

Code:

diff --git a/system/open-vm-tools/open-vm-tools.SlackBuild b/system/open-vm-tools/open-vm-tools.SlackBuild
index a294741688..cd5b4147fb 100644
--- a/system/open-vm-tools/open-vm-tools.SlackBuild
+++ b/system/open-vm-tools/open-vm-tools.SlackBuild
@@ -90,7 +90,7 @@ find -L . \
   -o -perm 440 -o -perm 400 \) -exec chmod 644 {} \;
 
 autoreconf -i
-CFLAGS="$SLKCFLAGS" \
+CFLAGS="$SLKCFLAGS -Wno-error=address-of-packed-member -Wno-error=format-overflow= -Wno-error=stringop-truncation" \
 CXXFLAGS="$SLKCFLAGS" \
 LIBS=-lcrypt \
 ./configure \

but, IMHO, this specific topic doesn't look like the proper place for an eventual discussion about an incompatibility between vmware virtual machines and vice running on them (also if under some specific conditions)...