problem to build
Closed this issue · 10 comments
Interesting project, I tried to use it but on the /codecserver-softmbe# dpkg-buildpackage stage i get the next error
make[1]: Entering directory '/root/codecserver-softmbe'
dh_makeshlibs -Xlibsoftmbe.so
make[1]: Leaving directory '/root/codecserver-softmbe'
dh_shlibdeps
dpkg-shlibdeps: error: no dependency information found for /usr/local/lib/libcodecserver.so.0.1.0 (used by debian/codecserver-driver-softmbe/usr/lib/x86_64-linux-gnu/codecserver/libsoftmbe.so)
Hint: check if the library actually comes from a package.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/codecserver-driver-softmbe.substvars debian/codecserver-driver-softmbe/usr/lib/x86_64-linux-gnu/codecserver/libsoftmbe.so returned exit code 255
dh_shlibdeps: Aborting due to earlier error
make: *** [debian/rules:3: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
What can I do?
Orlin Mirchev
May I ask you on what platform you are doing this? I tested only on ARM (for Raspberry Pi), and on that platform, the libcodecserver.so.0.1.0 file should be be provided by the libcodecserver package and should be located in /usr/lib/arm-linux-gnueabihf/libcodecserver.so.0.1.0. I may make wrong assumptions on the location of that file on untested platforms, thus I am wondering what you are running on, and what instructions you used to install openwebrx. If that turns out to be the problem, I can easily fix this in an update.
I do it on OMV 5.x that's mean Debian GNU/Linux 10 (buster) on x86-64. After I ask the question i start investigate and found libcodecserver.so.01.0 and libcodecserver.so.0.2.0 on the system. I I installed openwebrx following the official Manual instalation instruction.
But I resolved the problem starting old version of openwebrx on docker. In generally I will be happy to resolve the problem with digital your way to be cappable to use future versions of openwebrx. Thank you.
Same issue here:
dpkg-shlibdeps: error: no dependency information found for /usr/local/lib/libcodecserver.so.0.2.0 (used by debian/codecserver-driver-softmbe/usr/lib/x86_64-linux-gnu/codecserver/libsoftmbe.so)
Hint: check if the library actually comes from a package.
dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/codecserver-driver-softmbe.substvars debian/codecserver-driver-softmbe/usr/lib/x86_64-linux-gnu/codecserver/libsoftmbe.so returned exit code 255
dh_shlibdeps: error: Aborting due to earlier error
make: *** [debian/rules:3: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
Running it in a docker container based on the latest and dev docker images from upstream. The underlying host is running on an x86 architecture.
checked for the dependency:
root@139634256d77:/opt/openwebrx/codecserver-softmbe# apt install libcodecserver
[...]
libcodecserver is already the newest version (0.2.0~56.gbpaa9b1d).
libcodecserver set to manually installed.
root@139634256d77:/opt/openwebrx/codecserver-softmbe# apt install libcodecserver-dev
[...]
libcodecserver-dev is already the newest version (0.2.0~56.gbpaa9b1d).
root@139634256d77:/opt/openwebrx/codecserver-softmbe# dpkg-build
Could it be the source of the packages?
Get:1 https://repo.openwebrx.de/debian experimental/main amd64 libcodecserver amd64 0.2.0~56.gbpaa9b1d [64.7 kB]
Get:2 https://repo.openwebrx.de/debian experimental/main amd64 libcodecserver-dev amd64 0.2.0~56.gbpaa9b1d [16.2 kB]
I’ve noticed the same problem when building in a Docker container. Adding this to the Dockerfile just before running dpkg-buildpackage gets past the error:
RUN sed -i "\$a\ \\noverride_dh_shlibdeps:\\n\\tdh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info" debian/rules
However, the resulting plugin doesn’t load.
$ codecserver
Hello, I'm the codecserver.
now scanning for modules...
registering new driver: "ambe3k"
loading devices from configuration...
unable to load device: driver "softmbe" not available
auto-detecing devices...
scanning for "ambe3k" devices...
device scan complete.
Everything works fine when I build and install on the host.
@omirchev I just tried this on a freshly installed Debian buster and dpkg-buildpage did produce the Debian packages. However, the Debian repository for openwebrx ("Official release" following this procedure) installs libcodecserver.so not in /usr/local/lib, but rather in /usr/lib. Thus I suspect that you didn't get from the package, but rather installed it using some other method. To work around this, you can use --ignore-missing-info as suggested by @gizmotronic above or you can just compile using the traditional cmake / make / make install approach, bypassing dpkg-buildpkg.
@gizmotronic this looks like the libsoftmbe library generated is either not accessible from the codecserver docker, or the library is placed in the wrong location and codecserver cannot find it. We didn't really intend to have this running in a docker container but if you could share/link the steps to create the docker (including the Dockerfile etc.), we could have a look at why this fails.
My entire process is encapsulated within the Dockerfile using a multi-stage build. Simply run docker build -t some:tag . (assuming the Dockerfile is in your current working directory).
FROM jketterl/openwebrx:stable AS builder
# Add OpenWebRX repository
RUN apt-get update
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y \
gnupg \
wget
RUN wget -O - https://repo.openwebrx.de/debian/key.gpg.txt | apt-key add
RUN echo "deb https://repo.openwebrx.de/debian/ buster main" > /etc/apt/sources.list.d/openwebrx.list
# Install toolchain and dependencies
RUN apt-get update
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y \
build-essential \
git-core \
debhelper \
cmake \
libprotobuf-dev \
protobuf-compiler \
libcodecserver-dev
# Build mbelib
WORKDIR /build
RUN git clone https://github.com/szechyjs/mbelib.git
WORKDIR ./mbelib
RUN dpkg-buildpackage -b
# Build codeserver-softmbe
WORKDIR /build
RUN dpkg -i libmbe1_1.3.0_*.deb libmbe-dev_1.3.0_*.deb
RUN git clone https://github.com/knatterfunker/codecserver-softmbe.git
WORKDIR ./codecserver-softmbe
RUN sed -i "\$a\ \\noverride_dh_shlibdeps:\\n\\tdh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info" debian/rules
RUN dpkg-buildpackage -b
# Build the final image
FROM jketterl/openwebrx:stable
COPY --from=builder \
/build/codecserver-driver-softmbe_0.0.1_*.deb \
/build/libmbe1_1.3.0_*.deb \
/opt/packages/
RUN apt-get update \
&& apt-get install -y \
gnupg \
wget \
&& wget -O - https://repo.openwebrx.de/debian/key.gpg.txt | apt-key add \
&& echo "deb https://repo.openwebrx.de/debian/ buster main" > /etc/apt/sources.list.d/openwebrx.list \
&& apt-get update \
&& apt-get install -y \
codecserver-driver-all \
libcodecserver \
libprotobuf17 \
&& dpkg -i /opt/packages/*.deb \
&& echo "\n[device:softmbe]\ndriver=softmbe" >>/usr/local/etc/codecserver/codecserver.conf \
&& rm -rf /var/lib/apt/*My hardware is off doing other interesting things at the moment, but it would be interesting to see this work completely within a container, at some point.
Ah! That was very helpful indeed. The bottom line is that for the codecserver built into this docker container to find a driver, the corresponding shared library must be located in /usr/local/lib/codecserver. The Debian package for codecserver-softmbe however installs the shared library in /usr/lib/codecserver because this is the place where Debian packages should install stuff like that. An ugly hack to make this work would be to alter the build process to install in /usr/local and then to convince the Debian build environment not to touch /usr/local.
The above can be achieved by adding the following to the Dockerfile in the same place where you already have the other hack (i.e. before RUN dpkg-buildpackage -b):
RUN sed -i "\$a\ \\noverride_dh_usrlocal:\\n\\t@:" debian/rules
RUN sed -i "1a SET(CMAKE_INSTALL_LIBDIR /usr/local/lib)" CMakeLists.txt
The modified Dockerfile is attached: Dockerfile.txt
I hope this finally addresses those issues -- let us know how it goes, thank you and all the best!
Thank you! That solves the problem, and it’s working perfectly.
Yey! Thank you -- closing this issue.