Closed mfurseman closed 2 years ago
The RPC dependency comes from Asyn, without the TIRPC change static linking fails:
/usr/bin/g++ -o streamApp -Wl,-Bstatic -L/mnt/build/support/StreamDevice/lib/linux-x86_64 -L/mnt/build/prefix/lib/linux-x86_64 -Wl,-rpath,/mnt/build/support/StreamDevice/lib/linux-x86_64 -Wl,-rpath,/mnt/build/prefix/lib/linux-x86_64 -rdynamic -m64 streamApp_registerRecordDeviceDriver.o streamAppMain.o -lstream -lasyn -ldbRecStd -ldbCore -lca -lCom -Wl,-Bdynamic -lpthread -lreadline -lm -lrt -ldl -lgcc
/mnt/build/prefix/lib/linux-x86_64/libasyn.a(drvVxi11.o): In function `vxiCreateDeviceLink':
/mnt/build/support/asyn/asyn/O.linux-x86_64/../../asyn/vxi11/drvVxi11.c:320: undefined reference to `xdr_free'
/mnt/build/support/asyn/asyn/O.linux-x86_64/../../asyn/vxi11/drvVxi11.c:295: undefined reference to `clnt_sperror'
/mnt/build/prefix/lib/linux-x86_64/libasyn.a(drvVxi11.o): In function `vxiDestroyDevLink':
/mnt/build/support/asyn/asyn/O.linux-x86_64/../../asyn/vxi11/drvVxi11.c:402: undefined reference to `xdr_free'
/mnt/build/support/asyn/asyn/O.linux-x86_64/../../asyn/vxi11/drvVxi11.c:393: undefined reference to `clnt_sperror'
...
Shouldn‘t those symbols already be in libasyn.a when you have built that one statically?
Ah, that is a good point. I am taking a look to see why they are not. Do you have an issue with any of the other commits?
For the dynamic build the libasyn.so keeps track of the dependency on libtirpc.so and everything is resolved at runtime. For the static builds it is not so simple. One either has to repackage the existing system libtirpc.a into libasyn.a, or specify the requirement to link against it when building an executable. Out of these two, I think the latter is more tidy.
Need to check later. I‘m on vacation now. :-)
Okay, enjoy your leave!
@dirk-zimoch Did you have a chance to look at these changes?
I have merged this (and part of Ralph's PR #80) manually into release 2.8.21
Hi Dirk,
We are building StreamDevice for Linux / Mingw and using INSTALL_LOCATIONS under CentOS 8. This revealed a few compatibility issues that I expect others do not often see. These changes:
strncasecmp
when _WIN32 is set for a Mingw build.