liblabview_grpc_server.so RT20.5 Compatability Issues

[RahndelDaVandal]

I have been running v1.2.7.1 on a 9046 with NILRT 20.5 for a while now without issues. After noticing that the latest release (v1.5.0.1) includes a gRPC update to v1.62, addressing multiple CVEs, I proceeded with the upgrade.

After rebuilding my RTEXE and deploying both the updated RTEXE and the new .so file to my 9046, my application started throwing error 7 ("File Not Found") at launch.

I verified the permissions for /home/lvuser/natinst/bin/liblabview_grpc_server.so and ran ldd to check for missing dependencies. This revealed a dependency issue with libstdc++:

According to opkg, there are no available updates for libstdc++. I then attempted to rebuild the .so file directly on the RIO, following the steps in the building section of the repo. However, it appears that CMake v3.15 or higher is required, while NILRT 20.5 only includes CMake v3.10.3.

Any advice on how to proceed from here would be greatly appreciated.

AB#3121991

[jplotzke]

The same error/issue is present on NI Linux RT 2022Q4

[RahndelDaVandal]

I just set up another 9046 with 23Q4 and it has the same issue. I was going to try RT24 but I cannot select 2020 as the enviroment

[jplotzke]

I updated my system to NILRT 24Q4 and looks like all deps are met, but in LabVIEW 2021 SP1 I get:

Error 13 occurred at Call Library Function Node in grpc-lvsupport-release.lvlib:Create Client.vi:560001->test_service_client.lvlib:Create Client.vi

Possible reason(s):

LabVIEW: (Hex 0xD) Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format.
=========================
Shareable board exclusively owned.

admin@xxx:~# ldd /home/lvuser/natinst/bin/liblabview_grpc_server.so
ldd: warning: you do not have execution permission for `/home/lvuser/natinst/bin/liblabview_grpc_server.so'
        linux-vdso.so.1 (0x00007ffdddf71000)
        librt.so.1 => /lib/librt.so.1 (0x00007f16021f2000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f1601fe2000)
        libm.so.6 => /lib/libm.so.6 (0x00007f1601f04000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f1601eea000)
        libc.so.6 => /lib/libc.so.6 (0x00007f1601cec000)
        /lib/ld-linux-x86-64.so.2 (0x00007f1602f7a000)

[jplotzke]

I walked backwards in version using LabVIEW 2021 SP1 / NILRT 24Q4 and v1.2.7.1 is the last version where I can use the Linux RT shared library without getting error 13 shown above. Starting at v1.3.0.1, I only get error 13 calling the shared library.

[bkeryan]

One of the changes between these two releases was to change the build_on_rt.yml GitHub Actions workflow to run on ubuntu-22.04 instead of ubuntu-latest: v1.2.7.1...v1.3.0.1#diff-1aa17a452944c018d4d6082d40c9488080590f216a44507f64fc2b8803c9259e

This was done to avoid upgrading to ubuntu-24.04. This shouldn't cause this problem, but it highlights that the build agent has newer binaries than NILRT 20.5. If the build process is linking against the system libc instead of the toolchain libc, it can pull in symbols that don't exist in the older libc present in the toolchain and NILRT 20.5.

The cmake toolchain file uses CMAKE_SYSROOT: https://github.com/ni/grpc-labview/blob/83f85d1fad2fab22ce342a8cdabb4773c79e86d0/nilrt-x86_64.cmake
I wonder if this configuration is working correctly and linking against the toolchain libc.

BTW, the toolchain was recently updated to target NILRT 2023Q4, but v1.3.0.1 was still using a toolchain from 2018.

[jplotzke]

Starting in grpc-labview v1.3.0.1, I see undefined symbols on NILRT 24.8 - this likely coincides with my error 13 trying to use v1.3.0.1+.

Obviously this is a slightly different issue than the original post, but closely related. I can break this into a separate issue if needed.

admin@xxx:~# ldd -r ./liblabview_grpc_server_1.2.7.1.so
ldd: warning: you do not have execution permission for `./liblabview_grpc_server_1.2.7.1.so'
        linux-vdso.so.1 (0x00007ffe6039a000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00007f6dd73e5000)
        librt.so.1 => /lib/librt.so.1 (0x00007f6dd7fa4000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6dd73e0000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f6dd73db000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f6dd71cb000)
        libm.so.6 => /lib/libm.so.6 (0x00007f6dd70ed000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f6dd70d3000)
        libc.so.6 => /lib/libc.so.6 (0x00007f6dd6ed5000)
        /lib/ld-linux-x86-64.so.2 (0x00007f6dd7fb4000)

admin@xxx:~# ldd -r ./liblabview_grpc_server_1.3.0.1.so
ldd: warning: you do not have execution permission for `./liblabview_grpc_server_1.3.0.1.so'
        linux-vdso.so.1 (0x00007ffdd37cc000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00007fedeb129000)
        librt.so.1 => /lib/librt.so.1 (0x00007fedeb124000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007fedeb11f000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007fedeb11a000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fedea1f0000)
        libm.so.6 => /lib/libm.so.6 (0x00007fedeb03a000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fedeb020000)
        libc.so.6 => /lib/libc.so.6 (0x00007fede9ff2000)
        /lib/ld-linux-x86-64.so.2 (0x00007fedeb14f000)
undefined symbol: _ZN12grpc_labview9wellknown8I2DArray13_columnsIndexE  (./liblabview_grpc_server_1.3.0.1.so)
undefined symbol: _ZN12grpc_labview9wellknown8I2DArray10_rowsIndexE     (./liblabview_grpc_server_1.3.0.1.so)

admin@xxx:~# ldd -r ./liblabview_grpc_server_1.5.0.1.so
ldd: warning: you do not have execution permission for `./liblabview_grpc_server_1.5.0.1.so'
        linux-vdso.so.1 (0x00007ffca25b2000)
        librt.so.1 => /lib/librt.so.1 (0x00007f43f5d5c000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f43f5b4c000)
        libm.so.6 => /lib/libm.so.6 (0x00007f43f5a6e000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f43f5a54000)
        libc.so.6 => /lib/libc.so.6 (0x00007f43f5856000)
        /lib/ld-linux-x86-64.so.2 (0x00007f43f6ae4000)
undefined symbol: _ZN12grpc_labview9wellknown8I2DArray10_rowsIndexE     (./liblabview_grpc_server_1.5.0.1.so)
undefined symbol: _ZN12grpc_labview9wellknown8I2DArray10_dataIndexE     (./liblabview_grpc_server_1.5.0.1.so)
undefined symbol: _ZN12grpc_labview9wellknown8I2DArray13_columnsIndexE  (./liblabview_grpc_server_1.5.0.1.so)

[bkeryan]

Yes, please file a separate issue. Those symbols are part of grpc-labview, not libc.

c++filt translates those symbols to:

undefined symbol: grpc_labview::wellknown::I2DArray::_rowsIndex     (./liblabview_grpc_server_1.5.0.1.so)
undefined symbol: grpc_labview::wellknown::I2DArray::_dataIndex     (./liblabview_grpc_server_1.5.0.1.so)
undefined symbol: grpc_labview::wellknown::I2DArray::_columnsIndex  (./liblabview_grpc_server_1.5.0.1.so)

These are static const int variables, declared here:

grpc-labview/src/well_known_messages.h

Line 52 in 95d9675

static const int _rowsIndex = 1;

However, they are not defined anywhere. Does the compiler allocate storage for them based on a declaration in a header file? And if so, which translation unit(s) does it allocate storage in?

The last time I ran into this, I looked it up in a draft of the C++ standard and I think it said that static const int variables can be defined in the class body, but they still need a separate definition. The behavior I saw at the time (~2014, with older C++03 compilers) was that GCC required the variables to be defined, but MSVC produced a linker error about multiple definitions if you did that, so I ended up using #ifdefs to define these variables only for GCC.

I think that grpc-labview is fully C++11 or newer, so the easiest fix is probably to change them from const to constexpr.

[jplotzke]

Just to loop back to this original issue, is it fair to say that:

• Starting at release v1.5.0.1, NILRT 2023Q4+ is required
• Releases v1.3.0.1 through v1.5.1.1 were released with a broken LinuxRT shared library (issue grpc-labview v1.3.0.1+ shared library does not work on LVLRT #441)
• Releases prior to and including v1.2.7.1 NILRT 2018+ is required

[RahndelDaVandal]

I would agree with your summary of the issue based on my observations. Does that mean that grpc-labview will be targeted at NILRT 2023Q+ from here on out? I have been very impressed with the implementation and have been using it for remote HMI communication but all of my projects are currently 20.5.

[jplotzke]

The root issue is that when grpc 1.62 was pulled in, this now requires gcc 7.3+, which the 2018 toolchain doesn't support. The next toolchains available (that I know of publicly available) are 2023Q1 and then 2023Q4.

@bkeryan - do you know why the 2023Q4 toolchain was specifically chosen? Is there any opposition with moving down to the previous 2023Q1 toolchain? This would add support back to NILRT 2022Q4 (libc and libstdc++ version changes between 22Q3 and 22Q4). I've done a test build with the 23Q1 toolchain and the build is successful.

[jasonmreding]

I am closing this issues as I believe everything that can be addressed has been addressed. The v1.5.0.1 release notes have been updated to indicate the oldest supported version of LabVIEW RT is 2023Q4. This was necessary to resolve CVEs for the underlying grpc libraries. The v1.6.0.1 release has since relaxed that further to 2023Q1 which is the earliest version that can be supported based on the required versions of the dependent libraries.