Add pre-build linux binaries.

[end2endzone]

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.

[end2endzone]

Note to others who see this issue:
I do not have access to multiple linux platform (or distributions). I also don't know what makes a linux executable not work on another linux distribution. If you can provide help on this issue, it would be appreciated.

[MatthewScholefield]

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?

[end2endzone]

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.
Sorry, I may be confusing multiple things.

[MatthewScholefield]

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:

• x86_64: Desktop 64bit (aka "amd64"). Most desktop/laptops of course use this
• armv7l: Raspberry Pi processor
• x86: Desktop 32bit (aka "i368"). Not many people support this anymore really
• arm64: Mobile 64bit. Many cellphones (ie. running Termux) and a small selection of new power-efficient laptop

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.

[end2endzone]

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 bin2cpp_unittest depends on googletest library which may (or may not) depends on systems libraries.

There are 3 executable to validate:

• bin2cpp
• bin2cpp_unittest
• testfilegenerator

bin2cpp and testfilegenerator can be executed without any argument. They should output a "missing argument" error.
bin2cpp_unittest can be executed with the arguments --gtest_filter=TestCLI.testVersion. The test will fail because it requires to previously execute generate_test_files.sh script.

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 :

• Linux, ubuntu 20.04, contains bin2cpp-2.4.0-ubuntu.x86_64.tar.gz, bin2cpp-2.4.0-ubuntu.x86_64.rpm and bin2cpp-2.4.0-ubuntu.x86_64.deb. It seems that I was able to create an rpm package without having to execute on a centos based distro.
• MacOS, catalina 10.15, contains bin2cpp-2.4.0-macOS Catalina.x86_64.dmg and bin2cpp-2.4.0-macOS Catalina.x86_64.tar.gz. ( I am not sure about the dmg file.
• Raspberry Pi 2 builds (on my DropBox) : bin2cpp-2.4.0-raspbian.armv7l.deb and bin2cpp-2.4.0-raspbian.armv7l.tar.gz. They might also work on Pi 4.

[MatthewScholefield]

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 .tar.gz to keep it simple in case .rpm or .deb somehow introduce a problem.

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.

[end2endzone]

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.

52/52 unit tests passed

You ran the generate_test_files.sh script ? Nice! Unit test execution does not cleanup temporary files and may have leave temporary files in bin directory or /temp directories. I am sorry. I did not had time yet to fix that. Updating the test to cleanup on success/failure is on my todo list!

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.

[MatthewScholefield]

You ran the generate_test_files.sh script ? Nice! Unit test execution does not cleanup temporary files and may have leave temporary files in bin directory or /temp directories. I am sorry. I did not had time yet to fix that. Updating the test to cleanup on success/failure is on my todo list!

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.

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.

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.