shnhrrsn / homebridge-openzwave

OpenZWave platform for Homebridge.
MIT License
19 stars 4 forks source link

symbol lookup error: _ZN9OpenZWave7Options3GetEv #5

Closed ne0nex closed 4 years ago

ne0nex commented 4 years ago

So when installing on a raspberry pi running raspbian, after installing Openzwave from sources after installing libopenzwave-dev, I was getting a symbol lookup error when homebridge was attempting to fire up the plugin:

symbol lookup error: /usr/lib/node_modules/homebridge-openzwave/node_modules/openzwave-shared/build/Release/openzwave_shared.node: undefined symbol: _ZN9OpenZWave7Options3GetEv

I was able to resolve this and ultimately get this working on raspbian and learned a lot about the nuance of installing this on that platform and wanted to document it here in case anyone else comes here with the same intention I had of installing this on an already running RaspberryPI3/Raspian system running homebridge (as a systemctl service too!)

Short version:

The crux of this issue is that if one installs openzwave from sources (currently 1.6) then does apt-get install libopenzwave1.5-dev then the 1.5 version of the lib will become the new system default and when building homebridge-openzwave it'll be linked against that lib which is missing the symbol indicated in the error. Installing from sources installs the 1.6 version of the include headers, so installing the libopenzwave1.5-dev package is redundant. Doing so after installing 1.6 from source will cause the plugin to be built linking to 1.5 which is missing the symbols indicated. Fix this by uninstalling the build homebridge-openzwave:sudo npm -g uninstall homebridge-openzwave (or using the webUI from config-x) and then nuking the libopenzwave1.5-dev package: sudo apt-get remove libopenzwave1.5-dev

Deep dive: Learnings about Raspberry PI install:

Installing OZW dev package 1.5 after installing OpenZwave (currently 1.6) links libopenzwave.so.1.5 (the 1.5 version) as the system libopenzwave.so in /usr/lib/arm-linux-gnueabihf/ causing the build of homebridge-openzwave to be linked against the 1.5 version as was evidenced by the error I first encountered:

homebridge: symbol lookup error: /usr/lib/node_modules/homebridge-openzwave/node_modules/openzwave-shared/build/Release/openzwave_shared.node: undefined symbol: _ZN9OpenZWave7Options3GetEv

I was able to trace this down:

ldd -r /usr/lib/node_modules/homebridge-openzwave/node_modules/openzwave-shared/build/Release/openzwave_shared.node

showing:

libopenzwave.so.1.5 => /usr/lib/arm-linux-gnueabihf/libopenzwave.so.1.5 (0x76e5f000)

One would ask, why don't you then install openzwave via apt-get and then install the lib and then build. Well, I did that and building-installing homebridge-openzwave failed with source headers not being found:

find: ‘/usr/local/include/openzwave//’: No such file or directory

Sure enough the source headers from apt-get are shoved into /usr/include instead of /usr/local/include, as is the rest of the openzwave environment. But my node environment was relying on /usr/local/include/ I could have gone to town symlinking stuff into alternate directories but that felt gross to me, so instead I built openzwave from sources.

So the steps that worked for me were to blast away the 1.5 dev package, then install OpenZwave1.6 from sources:

sudo apt-get remove libopenzwave1.5-dev
wget http://old.openzwave.com/downloads/openzwave-1.6.1123.tar.gz
tar zxvf openzwave-1.6.1123.tar.gz
cd openzwave-1.6.1123
make
sudo make install 

the default prefix for make install is /usr/local which differs from where apt-get throws everything so I then added the new directories to the LD path:

sudo sed -i '$a LD_LIBRARY_PATH=/usr/local/lib' /etc/environment

and rebuild the lib caches:

After that, I was able to get MinOZW test application to talk to /dev/ttyACM0 correctly.

Then I installed homebridge-openzwave package via the README instructions, causing it to get built properly against libopenzwave.so.1.6. Again, checked with ldd -r:

ldd -r /usr/lib/node_modules/homebridge-openzwave/node_modules/openzwave-shared/build/Release/openzwave_shared.node

correctly showing:

libopenzwave.so.1.6 => /usr/local/lib/libopenzwave.so.1.6 (0x76d12000)

Takeaway:

If you have things scattered over multiple directory trees (node and other things installed in /usr/local/ and apt-get installed things going in /usr/) then be prepared for some manual mucking about.

Being aware that things from packages want to install wherever they want by default and may differ from where another package, will assume the files are at when compiling from source is involved.

ne0nex commented 4 years ago

Marking this as closed, as I forgot to when I posted it. Resolved via removing conflicting 1.5 libs and compiling against OpenZwave1.6 from sources.