-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debian build seems to be broken? #174
Comments
Sorry, for the inconvenience. During the conversion of the build system the target for the static library get dropped. Unfortunately i'm not that cmake expert and i partly regret the decision. Nevertheless i started my work, but it's still not usable. Maybe you have an idea what's the problem. |
We had an issue where the .so file was named liblibmbus.so, I would assume that we removed one "lib" from the name. I don't know CMake and do not intend to learn it unless I really have to. So I am of little help. I tried to build a .deb file, but my "employer" wanted the example programs as well, I was not able to solve that without starting to patch the build files, so I went with a normal .tar.gz where I could do things between the build/installation and the final packaging in an archive file, EDIT: Sorry!, after actually looking, I cannot se any trace of a statically linked file in the .deb build. (Would once again wave the do-it-yourself flag.) This seems to e the lines that actually do something from our Makefile.
If you want both statically and dynamically linked, you might have to generate and build twice (I don't know CMake.) |
The lib prefix issue has been fixed recently. But in case we don't have a solution at the end of the week, i think about reverting. |
With the introduction of CMake there is no need for this. Drop this to avoid confusion.
@sjlongland The debian directory is now deprecated. Please take a look at #175 and modify the build.sh to build the debian packages with cmake. I will add the binaries and doc later, after you gave me the okay this is going into the right direction. |
I don't think it because of the lib prefix.
Are you certain. I think the the CMake/cpack could use some files from that directory. (But that is only my belife/assumtion. |
I did build the Dockerfile.deb image. It seems that there is a static library being built, and it is presnt in the in the resulting -dev.deb file.
|
With the introduction of CMake there is no need for those. So drop them to avoid confusion.
@fredrik-sk Do you mean before or after my changes in #175? |
@lategoodbye : After #175 |
That works, although the build time was unexpectedly short. A bigger issue is the file names don't conform to Debian packaging conventions. Nominally these would be named |
Okay, was able to hack around the package naming:
Until we start getting packages with files named |
All those those debuild/debmake/cmake crap, drives me crazy :( |
It can be a pain, but try asking your typical end user to do a They just want to press a button and "magic happens", and it doesn't seem to matter whether it's a smartphone user pressing the |
As long as cmake doesn't generate suitable deb packages, we need to switch back :(
As long as cmake doesn't generate suitable deb packages, we need to switch back :(
As long as cmake doesn't generate suitable deb packages, we need to switch back :(
@sjlongland Can you please retest with build-deb.sh? |
Looking good! That was on Debian Stretch (v9) via Docker. |
Have a look at #178 and see what you think. This adds in source packages, and also allows for signing of packages, should a user require it. |
As long as cmake doesn't generate suitable deb packages, we need to switch back :( (cherry picked from commit 107d44b)
As long as cmake doesn't generate suitable deb packages, we need to switch back :(
We're trying to build a binary
.deb
package forlibmbus
so we can distribute that instead of statically linking it. It would appear this build references files that no longer exist:Culprit seems to be this line: https://github.com/rscada/libmbus/blob/master/debian/libmbus-dev.install#L2
The build script we use used to work. Is there something we missed when preparing the sources for building as a Debian package?
The text was updated successfully, but these errors were encountered: