Add pre-build linux binaries. #32
Comments
|
Note to others who see this issue: |
|
Provided you statically link rapidassist, the executable will work across any linux distribution since from what I can tell it doesn't link to any other libraries. The one caveat is that since glibc is only forwards compatible (if that's the right way to put it), the version of glibc you compile with is the oldest version it supports. So generally this just means if you build in CI using Ubuntu 18.04, it would run on all recent Linux distros (~2018 and newer). Does this make sense? |
|
Thank you for the feedback. Quite honestly, I am confused with all this. I do understand what you mean about glibc forward compatibility: you mean that if I compile bin2cpp from an "old enough" distro, it should be binary compatible with all recent distros. However, I though that cpu architectures (like I386, Amd64, Arm64 and 32 bit vs 64 bit) was important. I also though that linux "flavors" were important. Like an executable compiled on a Debian based distros (Ubuntu, Linux Mint, etc.) was not binary compatible with an executable compiled on a Redhat based distros (Fedora, CentOS, RHEL, openSuSE). Am i wrong ? Maybe you are saying all this because bin2cpp (and rapidassist) does not rely on other library and that is why bin2cpp should be compatible across multiple distros and distro flavors. |
|
Oh right, of course the cpu architecture does indeed also matter. However, targeting x86_64 (aka "desktop 64bit") should cover the majority of users. A quick explanation of architectures:
TL;DR, x86_64 is good enough for prebuilt executables. With regard to linux distros, each executable links to a certain version of various shared libraries which is the primary reason for incompatibilities. If you statically link all your dependencies (or don't have any), you don't have to worry about this. So, in summary, in your case targeting x86_64 and statically linking libraries (in your case just RapidAssist) will cover the majority of users. Let me know if you'd like any more clarification on any of these areas. |
Removed cmake/* files from the output binary package. Now creating optional NSIS or WIX installation package if the required software is installed on the system. Creating CONTRIBUTING.md and CODE_OF_CONDUCT.md documents. For issue #32.
…dentification function in GetOsNameAndVersion.cmake. For issue #32.
|
Hi. I managed to create multiple binary packages for different platforms. Could you validate they execute properly on your side ? As you previously said, the problem lies with dependencies to system libraries. The executable There are 3 executable to validate:
If you would like to help, could you tell me if you are able to execute all builds ? You can find a download link from the CI builds on GitHub from b561c9d :
|
|
Sweet! I just verified and both the Linux .tar.gz and the Raspberry Pi .tar.gz worked (executables showed help info and 52/52 unit tests passed) without installing googletest. Also, it's up to you, but personally, I'd just distribute the Anyways, just for reference, I'm using Arch Linux and a Raspberry Pi 3 B on Raspbian 10. Edit: Also, I don't have a Mac so I couldn't test that file. |
|
Hi. Thank you very much helping me with this issue. It is very kind of you to spend some of your free time helping others. Having a community here with people willing to help other is what made me join github. I agree that releasing the application in a zip-like format would make deploying bin2cpp as a "portable app" easier. I also struggled a lot while creating a package for macos since I know very few things about the platform. I will follow your advice and remove all platform-specific package creation code (rpm, dem, dmg, etc) and only leave the code for creating tar.gz files. I will keep the package creation code on Windows since this is somehow expected by Windows users. The typical user case for Windows users is to get to download an installer (commonly called a setup) from the app website for installing. I created temporary tag 2.4.0-rc.1 for archiving the package creation code if I ever need to refer back to it.
You ran the I will be able to close this in a few days once I have updated documentation and other stuff. P.S. Would you like to be listed in the as a contributor or in the AUTHOR file ? If you wish, I would gladly add your name to the file for your contribution. |
No worries. I just couldn't help myself and needed to see the pretty green indicator saying all tests pass before I could sleep soundly xD.
Whatever you would like; I'm just happy I was able to help :). Regardless, I'm glad there's now working Linux builds so that it's easier to use in new projects. |
…le stupid with and deploy a tar.gz archive on these platforms. This is also specified in #32.
* feature-issue32: * Fixed issue #32: Add pre-build linux binaries. Renamed `GetOsNameAndVersion.cmake` script to `GetOsReleaseInfo.cmake`. Also simplified the script and added more comments. Moved code from `cmake/GetOsNameAndVersion.cmake` to `GetLinuxReleaseInfo.cmake`, `GetMacReleaseInfo.cmake` and `GetWindowsReleaseInfo.cmake`. Removed all package creation for linux and macos builds. Keep it simple stupid with and deploy a tar.gz archive on these platforms. This is also specified in #32. Fixed install_googletest.bat script for compilation of googletest under VS2017. Fixed an incorrect space after the definition BIN2CPP_VERSION environment variable. Fixed typo in build_windows.yml. Replaced bash by cmd for shell. Trying to fix build step "Get bin2cpp version" on windows. Updated CMakeLists.txt to generate a bundle on macOS. Fixed invalid indentation and typos in CMakeLists.txt. Added new bin2cpp icons. Modified windows builds to build for 64 bit Fixed compilation on Windows. Modified GitHub Action scripts to archive the pattern `bin2cpp-${{env.BIN2CPP_VERSION}}-*.*`. Trying to archive installation packages in GitHub Actions. For issue #32. Code cleanup. Fixed a bug where only RPM package was build on ubuntu. Fixed macOS identification function in GetOsNameAndVersion.cmake. For issue #32. First draft for creating packages based on current os. For issue #32. Added new files and directories to the output binary package: docs, Removed cmake/* files from the output binary package. Now creating optional NSIS or WIX installation package if the required software is installed on the system. Creating CONTRIBUTING.md and CODE_OF_CONDUCT.md documents. For issue #32.
A good addition to the project would be to provide pre-build binaries for linux. They could be downloaded as a portable version (in a compressed file).
The INSTALL documentation could also be updated to specify which platforms are supported.
The text was updated successfully, but these errors were encountered: