/usr/bin/ld: cannot find -lopenzwave

[ghost]

First, thank you for this very interesting library. I'm trying to get it to work on Ubuntu 17.04 for a home automation project, but run into a build problem.

Following the instructions in the readme

1. git submodule update --init
2. cd open-zwave
3. PREFIX=$(pwd)/../.lib/ make install

Step 3 results in "install: cannot create directory ‘//usr/local/lib/x86_64-linux-gnu’: Permission denied" This is because it is not run as root, I thought the use of PREFIX would install it locally. I realize this is an openzwave thing and maybe this is fine, if so, it would be nice to have a comment in the doc.

Ignoring that error for now, after installing gominozw running go run gominozw.go there is a linking error: "/usr/bin/ld: cannot find -lopenzwave"

Looking into gooopenzwave_linux.go the #cgo LDFLAGS contains the library "-L${SRCDIR}/.lib/lib -l openzwave", however the library folder created by openzwave's make install is called lib64 instead of lib.

Can you suggest the best way to solve this? Thanks!

[jimjibone]

Hi! Thanks for trying out my library.

Your error in step 3 seems a little strange to me. When I run the command I get an error when the OpenZWave makefile is trying to copy over pkg-config files: cp: cannot create regular file '//usr/local/lib/x86_64-linux-gnu/pkgconfig/libopenzwave.pc': Permission denied. This seems to be an issue with the OpenZWave makefiles which I haven't been able to get to the bottom of. However, it's not a problem as the library has been successfully installed into the .lib directory by this point. I agree that there should be a note in the readme for this project though!

However, the error that you're seeing in step 3 is new to me. Would you mind pasting some more of the make output around that error? It would be good to know at what point in the Makefiles it is tripping up.

For your second issue, this is just something I hadn't run in to yet as I more recently moved over to building the library on a Raspberry Pi running a 32-bit OS 😄 I think this can be easily solved by adding the additional lib64 search path for now.

[ghost]

Awesome, thanks for the quick fix!

It looks like the install error is indeed a bug in openzwave. According to the documentation at https://github.com/OpenZWave/open-zwave/blob/master/INSTALL: pkg-config file is installed into (prefix)/lib(64)/pkgconfig/libopenzwave.pc

In open-zwave/cpp/build/Makefile:226 it says:

@echo "Installing Pkg-config Files @install -d $(DESTDIR)/$(pkgconfigdir)

running "PREFIX=$(pwd)/../.lib make install" results in:

Installing Pkg-config Files in //usr/local/lib/x86_64-linux-gnu/pkgconfig

pkgconfigdir is missing the PREFIX folder. DESTDIR is empty by the way. So, where is pkgconfigdir defined? It looks to be in open-zwave/cpp/hidapi/Makefile.am:5 where it says:

if OS_FREEBSD pkgconfigdir=$(prefix)/libdata/pkgconfig else pkgconfigdir=$(libdir)/pkgconfig endif

Since the os is OS_LINUX, the prefix is ignored and libdir is used. From there the trail gets cold as I'm not clear when this is executed.

[ghost]

Maybe a separate issue, just let me know. "dep ensure" sometimes deletes the "open-zwave" and the ".lib" folders. This makes goopenzwave quite unhappy as you can image.

I'm quite new to this environment but my guess is that the project is pulled down again from github and "git submodule update --init" isn't called. Is there a configuration to tell dep to do this, or to at least not remove the existing project?

[jimjibone]

Hmm, ok. Thanks for digging into it a bit more. I've done some more digging as well and I can't find a nice solution to this one! After a quick look it seems like OpenZWave is doing some non-standard stuff for getting the prefix/lib paths for the current system, so it seems to work OK for standard installs but not for something with an alternative prefix.

The openzwave/open-zwave#1495 PR seems to be touching on a very similar issue, but isn't the solution we're hoping for (it will make it worse).

To be honest, I was thinking of switching over to use a system-wide installation of OpenZWave. That would make the make install step less error-prone, it would encourage goopenzwave to utilise the shared OpenZWave configuration files and it would also help with your second post regarding dep ensure... the main reason for not using a system-wide installation before was because I was convinced that the C++ API had changed dramatically since I first wrote the Go package, but actually that was not the case.

Maybe it's worth moving the dep ensure to a new issue. This is a problem I am probably about to encounter myself, actually.

[ghost]

That makes a lot of sense. It is pretty standard after all to user 3rd party library binaries from the system lib directory. Not sure if there is a raspberry pi binary of openzwave but it is a separate concern. It is also nice not to have to deal with the dep ensure problem. Anyways, I think the issue is solved.

Thanks again!