Re: Shared Libraries challenges - FreeRDP 2.0.0
On 2020/04/21 07:51, Steve Williams wrote: > I'll work through your patch to fully understand and try it out! Much of it is removing things which are already committed upstream, or obsoleted by upstream changes (and are carried over from previous update attempts to rc3). The rdpdr_main.c change is post-rc3 and disables hotplug support that depends on things not in OpenBSD.
Re: Shared Libraries challenges - FreeRDP 2.0.0
Hi,
First, thanks for pointing out the conflict with the installed older
version of freerdp. After the troubleshooting I put into this, it will
be forever in my mind now to check for a conflict with a installed
library! It wasn't a total waste of time as I understand cmake as well
as the build process a bit now.
I'll work through your patch to fully understand and try it out!
Thanks very much again. Made me groan over my coffee this morning when
I read how simple my problem was to resolve... pkg_delete freerdp :D
Cheers,
Steve W.
On 21/04/2020 5:32 a.m., Stuart Henderson wrote:
On 2020/04/20 21:05, Steve Williams wrote:
However, this new fangled CMAKE stuff is a bit annoying. lol.
It's usually much simpler to build things using ports infrastructure which
already knows how to deal with OpenBSD, e.g.
At some point, the libwinpr2.so.2.0.0 gets symbolically linked to
libwinpr2.so.2 and libwinpr2.so
lrwxr-xr-x 1 root wheel 14 Apr 20 19:33 libwinpr2.so ->
libwinpr2.so.2
lrwxr-xr-x 1 root wheel 18 Apr 20 19:33 libwinpr2.so.2 ->
libwinpr2.so.2.0.0
-rwxr-xr-x 1 root wheel 2835760 Apr 20 19:33 libwinpr2.so.2.0.0
this shared library naming scheme is wrong for OpenBSD, ports already takes
care of this.
I think the actual problem you were seeing is due to it trying to use
an old library from the installed version that doesn't have the functions
you showed.
Here is a diff against the -current ports tree which builds ok (as long
as an older version isn't already installed), obviously still has the timer
problem that you won't see until runtime, "[ERROR][com.winpr.synch.timer] -
InitializeWaitableTimer: os specific implementation is missing".
Index: Makefile
===
RCS file: /cvs/ports/x11/freerdp/Makefile,v
retrieving revision 1.39
diff -u -p -r1.39 Makefile
--- Makefile4 Nov 2019 10:30:20 - 1.39
+++ Makefile21 Apr 2020 11:29:38 -
@@ -4,20 +4,13 @@
BROKEN-hppa = undefined reference to __sync_val_compare_and_swap_4
COMMENT = client for Microsoft RDP (remote desktop protocol)
-DISTNAME = freerdp-2.0.0-rc1
-PKGNAME = freerdp-2.0.0rc1
-REVISION = 4
+DISTNAME = freerdp-2.0.0
CATEGORIES = x11 net
-# XXX This version has known security issues.
-
-# XXX Can't be updated without either timer_create() and friends or
-# an alternative timer implementation (as was done for OSX)
-
-SHARED_LIBS += freerdp-client2 0.0 # 2.0
-SHARED_LIBS += freerdp2 0.0 # 2.0
-SHARED_LIBS += winpr-tools2 0.0 # 2.0
-SHARED_LIBS += winpr20.0 # 2.0
+SHARED_LIBS += freerdp-client2 1.0
+SHARED_LIBS += freerdp2 1.0
+SHARED_LIBS += winpr-tools2 1.0
+SHARED_LIBS += winpr21.0
HOMEPAGE = https://www.freerdp.com/
MASTER_SITES =https://pub.freerdp.com/releases/
@@ -25,8 +18,9 @@ MASTER_SITES =https://pub.freerdp.com/
# Apache 2.0
PERMIT_PACKAGE = Yes
-WANTLIB += X11 Xcursor Xext Xfixes Xi Xinerama Xrender Xv avcodec
-WANTLIB += avutil c crypto cups execinfo m pthread ssl xkbfile
+WANTLIB += X11 Xcursor Xext Xfixes Xi Xinerama Xrandr Xrender Xv
+WANTLIB += avcodec avutil c crypto cups execinfo m pthread ssl
+WANTLIB += swresample xkbfile
# thread-local storage
COMPILER =base-clang ports-gcc
@@ -52,12 +46,13 @@ CONFIGURE_ARGS += -DBUILD_TESTING=ON \
-DWITH_LIBSYSTEMD=OFF \
-DWITH_OSS=OFF
-pre-configure:
- ${SUBST_CMD}${WRKSRC}/winpr/libwinpr/CMakeLists.txt
- ${SUBST_CMD}${WRKSRC}/CMakeLists.txt
+#CONFIGURE_ARGS += -DCHANNEL_RDPDR=OFF
.if ${MACHINE_ARCH} == "sparc64"
CONFIGURE_ARGS += -DWITH_NEON=OFF
.endif
+
+pre-configure:
+ cd ${WRKSRC}; ${SUBST_CMD} CMakeLists.txt winpr/libwinpr/CMakeLists.txt
.include
Index: distinfo
===
RCS file: /cvs/ports/x11/freerdp/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo28 Apr 2018 19:20:17 - 1.8
+++ distinfo21 Apr 2020 11:29:38 -
@@ -1,2 +1,2 @@
-SHA256 (freerdp-2.0.0-rc1.tar.gz) =
8JogqXEWPCeD77egtIyGBuIPl7RB9xjyUoNDgnex+Hs=
-SIZE (freerdp-2.0.0-rc1.tar.gz) = 6575999
+SHA256 (freerdp-2.0.0.tar.gz) = TuBk6HSGy2/qhdW2tgat2fAt8lznP5gYtJ3nXOvX/t8=
+SIZE (freerdp-2.0.0.tar.gz) = 6857730
Index: patches/patch-CMakeLists_txt
===
RCS file: /cvs/ports/x11/freerdp/patches/patch-CMakeLists_txt,v
retrieving revision 1.6
diff -u -p -r1.6 patch-CMakeLists_txt
--- patches/patch-CMakeLists_txt28 Apr 2018 19:20:17 - 1.6
+++ patches/patch-CMakeLists_txt21 Apr 2020 11:29:38 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-CMakeLists_txt,v 1.6 201
Re: Shared Libraries challenges - FreeRDP 2.0.0
On 2020/04/20 21:05, Steve Williams wrote:
> However, this new fangled CMAKE stuff is a bit annoying. lol.
It's usually much simpler to build things using ports infrastructure which
already knows how to deal with OpenBSD, e.g.
> At some point, the libwinpr2.so.2.0.0 gets symbolically linked to
> libwinpr2.so.2 and libwinpr2.so
> lrwxr-xr-x 1 root wheel 14 Apr 20 19:33 libwinpr2.so ->
> libwinpr2.so.2
> lrwxr-xr-x 1 root wheel 18 Apr 20 19:33 libwinpr2.so.2 ->
> libwinpr2.so.2.0.0
> -rwxr-xr-x 1 root wheel 2835760 Apr 20 19:33 libwinpr2.so.2.0.0
this shared library naming scheme is wrong for OpenBSD, ports already takes
care of this.
I think the actual problem you were seeing is due to it trying to use
an old library from the installed version that doesn't have the functions
you showed.
Here is a diff against the -current ports tree which builds ok (as long
as an older version isn't already installed), obviously still has the timer
problem that you won't see until runtime, "[ERROR][com.winpr.synch.timer] -
InitializeWaitableTimer: os specific implementation is missing".
Index: Makefile
===
RCS file: /cvs/ports/x11/freerdp/Makefile,v
retrieving revision 1.39
diff -u -p -r1.39 Makefile
--- Makefile4 Nov 2019 10:30:20 - 1.39
+++ Makefile21 Apr 2020 11:29:38 -
@@ -4,20 +4,13 @@
BROKEN-hppa = undefined reference to __sync_val_compare_and_swap_4
COMMENT = client for Microsoft RDP (remote desktop protocol)
-DISTNAME = freerdp-2.0.0-rc1
-PKGNAME = freerdp-2.0.0rc1
-REVISION = 4
+DISTNAME = freerdp-2.0.0
CATEGORIES = x11 net
-# XXX This version has known security issues.
-
-# XXX Can't be updated without either timer_create() and friends or
-# an alternative timer implementation (as was done for OSX)
-
-SHARED_LIBS += freerdp-client2 0.0 # 2.0
-SHARED_LIBS += freerdp2 0.0 # 2.0
-SHARED_LIBS += winpr-tools2 0.0 # 2.0
-SHARED_LIBS += winpr20.0 # 2.0
+SHARED_LIBS += freerdp-client2 1.0
+SHARED_LIBS += freerdp2 1.0
+SHARED_LIBS += winpr-tools2 1.0
+SHARED_LIBS += winpr21.0
HOMEPAGE = https://www.freerdp.com/
MASTER_SITES = https://pub.freerdp.com/releases/
@@ -25,8 +18,9 @@ MASTER_SITES =https://pub.freerdp.com/
# Apache 2.0
PERMIT_PACKAGE = Yes
-WANTLIB += X11 Xcursor Xext Xfixes Xi Xinerama Xrender Xv avcodec
-WANTLIB += avutil c crypto cups execinfo m pthread ssl xkbfile
+WANTLIB += X11 Xcursor Xext Xfixes Xi Xinerama Xrandr Xrender Xv
+WANTLIB += avcodec avutil c crypto cups execinfo m pthread ssl
+WANTLIB += swresample xkbfile
# thread-local storage
COMPILER = base-clang ports-gcc
@@ -52,12 +46,13 @@ CONFIGURE_ARGS += -DBUILD_TESTING=ON \
-DWITH_LIBSYSTEMD=OFF \
-DWITH_OSS=OFF
-pre-configure:
- ${SUBST_CMD}${WRKSRC}/winpr/libwinpr/CMakeLists.txt
- ${SUBST_CMD}${WRKSRC}/CMakeLists.txt
+#CONFIGURE_ARGS += -DCHANNEL_RDPDR=OFF
.if ${MACHINE_ARCH} == "sparc64"
CONFIGURE_ARGS += -DWITH_NEON=OFF
.endif
+
+pre-configure:
+ cd ${WRKSRC}; ${SUBST_CMD} CMakeLists.txt winpr/libwinpr/CMakeLists.txt
.include
Index: distinfo
===
RCS file: /cvs/ports/x11/freerdp/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo28 Apr 2018 19:20:17 - 1.8
+++ distinfo21 Apr 2020 11:29:38 -
@@ -1,2 +1,2 @@
-SHA256 (freerdp-2.0.0-rc1.tar.gz) =
8JogqXEWPCeD77egtIyGBuIPl7RB9xjyUoNDgnex+Hs=
-SIZE (freerdp-2.0.0-rc1.tar.gz) = 6575999
+SHA256 (freerdp-2.0.0.tar.gz) = TuBk6HSGy2/qhdW2tgat2fAt8lznP5gYtJ3nXOvX/t8=
+SIZE (freerdp-2.0.0.tar.gz) = 6857730
Index: patches/patch-CMakeLists_txt
===
RCS file: /cvs/ports/x11/freerdp/patches/patch-CMakeLists_txt,v
retrieving revision 1.6
diff -u -p -r1.6 patch-CMakeLists_txt
--- patches/patch-CMakeLists_txt28 Apr 2018 19:20:17 - 1.6
+++ patches/patch-CMakeLists_txt21 Apr 2020 11:29:38 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-CMakeLists_txt,v 1.6 201
Index: CMakeLists.txt
--- CMakeLists.txt.orig
+++ CMakeLists.txt
-@@ -953,9 +953,9 @@ if(WAYLAND_FOUND)
+@@ -1077,9 +1077,9 @@ if(WAYLAND_FOUND)
endif()
if(BSD)
Index: patches/patch-channels_rdpdr_client_rdpdr_main_c
===
RCS file: patches/patch-channels_rdpdr_client_rdpdr_main_c
diff -N patches/patch-channels_rdpdr_client_rdpdr_main_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-channels_rdpdr_client_rdpdr_main_c21 Apr 2020 11:29:38
-
@@ -0,0 +1,23 @@
+$OpenBSD$
+
+Index:
Shared Libraries challenges - FreeRDP 2.0.0
Hi, I heard back from cheloha@ and while there is a "Work in Progress" for Posix Timers, it's not in the imminent future. Rather than trying to debug an ancient version of FreeRDP, I am going to investigate what it would take to implement OpenBSD specific timers in FreeRDP. There's a lot of functionality that's not used in the FreeRDP code so I'm hopeful that FreeRDP is using limited functionality of the Posix Timers (there's only one call to "timer_create" and it's with CLOCK_MONOTONIC). I resurrected my desktop running OpenBSD 5.6, wiped it and installed -current, got the build system configured in less time than it took me to figure out (and repair) the network cable to my home office had been cut during some home renovations at some point in time :) For background... back in 1985, in University a lab partner and I spent a year (project course) porting Minix from x86 to sparc... before Linux had even been heard of. I'm no stranger to low level interfaces. However, this new fangled CMAKE stuff is a bit annoying. lol. My first goal was to just get FreeRDP 2.0 to compile. Well, life isn't so simple! My gut says the problem I am having pertains to shared library handling at the linking stage (or building the shared library). I've stared at this for several hours and reviewed before I hit the "send" button :) I am sure it's something stupid... This is just the start of the errors. If I include the ".o" in the list of files being linked, the linker moves on to the next error, implying that it can't find the value in the .so but can in the .o Example: ld: error: undefined symbol: WLog_IsLevelActive $ file libwinpr2.so.2.0.0 libwinpr2.so.2.0.0: ELF 64-bit LSB shared object, x86-64, version 1 $ldd libwinpr2.so.2.0 libwinpr2.so: Start End Type Open Ref GrpRef Name 09fc90c6d000 09fc90deb000 dlib 2 0 0 /root/src/freerdp-2.0.0/winpr/libwinpr/libwinpr2.so 09fc998f9000 09fc99961000 rlib 0 1 0 /usr/lib/libssl.so.48.1 09fcbd7df000 09fcbda14000 rlib 0 2 0 /usr/lib/libcrypto.so.46.1 09fccca3e000 09fccca6d000 rlib 0 1 0 /usr/lib/libm.so.10.1 09fc6517e000 09fc6518b000 rlib 0 1 0 /usr/lib/libpthread.so.26.1 Checking for the symbol in the library: $ nm libwinpr2.so.2.0.0 | grep WLog_IsLevelActive 000e9c00 *T *WLog_IsLevelActive Checking https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs Shared libraries need to be compiled with: gcc -shared -fpic|-fPIC -o libfoo.so.4.5 obj1 obj2 The library is compiled with: /usr/bin/cc -fPIC <--- -fPIC -Wno-unused-parameter -Wno-unused-macros -Wno-padded -Wno-c11-extensions -Wno-gnu -Wno-unused-command-line-argument -Wno-deprecated-declarations -DWINPR_DLL -DWINPR_DLL -DWINPR_EXPORTS -g -shared <--- -shared -Wl,-soname,libwinpr2.so.2 -o libwinpr2.so.2.0.0 CMakeFiles/winpr.dir/synch/address.c.o [SNIP LIST OF FILES] -L/usr/lib -Wl,-z,origin,-rpath,: -lssl -lcrypto -lm -lpthread -Wl,-rpath-link,/usr/X11R6/lib:/usr/local/lib At some point, the libwinpr2.so.2.0.0 gets symbolically linked to libwinpr2.so.2 and libwinpr2.so lrwxr-xr-x 1 root wheel 14 Apr 20 19:33 libwinpr2.so -> libwinpr2.so.2 lrwxr-xr-x 1 root wheel 18 Apr 20 19:33 libwinpr2.so.2 -> libwinpr2.so.2.0.0 -rwxr-xr-x 1 root wheel 2835760 Apr 20 19:33 libwinpr2.so.2.0.0 I have tried copying libwinpr2.so.2.0.0 to libwinpr2.so to ensure it's not an (obscure) issue with the symbolic link. The library in this specific example lives in: /root/src/freerdp-2.0.0/winpr/libwinpr The final "cc" command that does the linking: /usr/bin/cc -Wno-unused-parameter -Wno-unused-macros -Wno-padded -Wno-c11-extensions -Wno-gnu -Wno-unused-command-line-argument -Wno-deprecated-declarations -DWINPR_DLL -g CMakeFiles/xfreerdp-client.dir/xf_gdi.c.o [SNIP LIST OF FILES] CMakeFiles/xfreerdp-client.dir/cli/xfreerdp.c.o -o xfreerdp -L/usr/local/lib -L/usr/X11R6/lib -L/root/src/freerdp-2.0.0/client/common -L/root/src/freerdp-2.0.0/libfreerdp -L/root/src/freerdp-2.0.0/winpr/libwinpr -Wl,-z,origin,-rpath,/usr/local/lib:/root/src/freerdp-2.0.0/client/common:/root/src/freerdp-2.0.0/libfreerdp:/root/src/freerdp-2.0.0/winpr/libwinpr: -lX11 -lXinerama -lXext -lXcursor -lXv -lXrender -lXrandr -lXfixes -lfreerdp-client2 -lfreerdp2 -lm -lossaudio -lwinpr2 -Wl,-rpath-link,/usr/X11R6/lib:/usr/local/lib The actual linker command executed: "/usr/bin/ld" -e __start --eh-frame-hdr -Bdynamic -dynamic-linker /usr/libexec/ld.so -o xfreerdp /usr/bin/../lib/crt0.o /usr/bin/../lib/crtbegin.o -L/usr/local/lib -L/usr/X11R6/lib -L/root/src/freerdp-2.0.0/client/common
