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
000009fc90c6d000 000009fc90deb000 dlib 2 0 0
/root/src/freerdp-2.0.0/winpr/libwinpr/libwinpr2.so
000009fc998f9000 000009fc99961000 rlib 0 1 0
/usr/lib/libssl.so.48.1
000009fcbd7df000 000009fcbda14000 rlib 0 2 0
/usr/lib/libcrypto.so.46.1
000009fccca3e000 000009fccca6d000 rlib 0 1 0
/usr/lib/libm.so.10.1
000009fc6517e000 000009fc6518b000 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
-L/root/src/freerdp-2.0.0/libfreerdp
-L/root/src/freerdp-2.0.0/winpr/libwinpr
-L/usr/bin/../lib
-L/usr/lib
CMakeFiles/xfreerdp-client.dir/xf_gdi.c.o
[SNIP LIST OF FILES]
-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
-rpath-link /usr/X11R6/lib:/usr/local/lib:/usr/local/lib/freerdp2
-lcompiler_rt
-lc
-lcompiler_rt
/usr/bin/../lib/crtend.o
I tried changing the -rpath-link path to include the local build
directories with no change in behaviour:
-rpath-link
/usr/X11R6/lib:/usr/local/lib:/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:
I'm lost right now. Can anyone shed some light on what I'm missing?
Thanks,
Steve W.
