Totally unworkable on Linux with fatal errors and Error 2 while compiling

[Callistemon]

On Windows, openSeaChest just works properly, like anything on Windows. On Manjaro, Linux Mint, and Ubuntu 21.10, there are fatal errors and Error 2 when using make release, make clean or make. This is totally unworkable and is a waste of hours for nothing. Why aren't binaries provided for more than only CentOS?

Because make is from GNU, an organization that spends most of their time relentlessly whining about how any traces of anything proprietary is malicious, it is not possible to compile anything with make without ruining the day. make is trash to an extent like nothing else and is the very single worst thing about using Linux instead of Windows. In fact, I was entering a long series of commands through multiple pages of instructions for openSeaChest UEFI, and did not reach an error until stupid evil make raged into presence as a dumpster fire, ruining hours of effort. This issue is about openSeaChest Linux, but make deserves shaming words to be mentioned at every opportunity.

The only solution is to provide binaries for Debian and Arch based systems, or provide source code that can be compiled without any involvement of make, which shouts at you with *** that represent rage and the word Stop telling you to give up. GCC is installed and the Linux kernel version is 5.13.19-2.

[vonericsen]

Hi @Callistemon,

Make sure you have performed a recursive clone to pull the submodules for openSeaChest to build. That is most likely the error you are receiving. We have examples and information on recursive cloning in our building instructions section on git.

We also recently pulled in an update to use meson for building which may be easier in some cases (and is definitely faster). I have tried it by installing it through the ubuntu apt repository as well as installing it through the python package with pip.
If you wish to use make, ensure you have done a recursive clone, then type make release. This should resolve the build error you are seeing now.

Q. Why aren't binaries provided for more than only CentOS?
A. Binaries built in cent OS run on just about all other current distributions due to their packages being more downstream versions from others (generally) so other distributions with newer packages are able to run them since newer glibc provides good backwards compatibility. This project was started for our enterprise customers, who are all using centOS/redhat or equivalent systems, so this seemed appropriate to fit most needs. I have investigated a statically built tool, but we do not generally release statically built tools since licensing can be complicated. Recently, I have been doing internal testing with Musl libc which solves much of those headaches (both for us and customers we've talked to internally), and this will likely be what we migrate to in the long term for Github releases.

If the CentOS build does not work for you, can you please share the output you are getting from the system with the error?

[Callistemon]

We also recently pulled in an update to use meson for building which may be easier in some cases (and is definitely faster). I have tried it by installing it through the ubuntu apt repository as well as installing it through the python package with pip. If you wish to use make, ensure you have done a recursive clone, then type make release. This should resolve the build error you are seeing now.

After using cd /home/spindle/Downloads/openSeaChest-21.06.21/ or cd /home/spindle/Downloads/openSeaChest-21.06.21/Make/gcc, using meson --buildtype=release builddir returns ERROR: Neither directory contains a build file meson.build.

If the CentOS build does not work for you, can you please share the output you are getting from the system with the error?

The binary files do nothing when double-clicked on Manjaro or Linux Mint. When using the terminal and entering cd /home/spindle/Downloads/openseachest_exes_CentOS7_x86_64/openseachest_exes/ and entering openSeaChest_Basics, it returns command not found. On Windows, it just works after using cd and entering the filename in the Command Prompt.

[vonericsen]

Hi @Callistemon,

I am sorry I missed this earlier, but I now see you likely pulled the tag from the Jun 2021 release. That was before we received the meson request.
Back on this tag you will have to use make. If you have done the recursive clone, I would expect it to work now from the openSeaChest/Make/gcc directory
If you switch to the develop branch and make sure it is up to date you can use meson from the openSeaChest directory.

The binary files do nothing when double-clicked on Manjaro or Linux Mint. When using the terminal and entering cd /home/spindle/Downloads/openseachest_exes_CentOS7_x86_64/openseachest_exes/ and entering openSeaChest_Basics, it returns command not found. On Windows, it just works after using cd and entering the filename in the Command Prompt.

I downloaded and extracted the last release on a fresh install of ubuntu and the execute permission was there, but you may want to check that is set properly. I was able to run the tools ok too. I don't expect anything to happen when double clicking since these are command line tools, but I would expect they should be executable unless that permission was removed for security or something like that.

I'm downloading manjaro now and will give it a test to see if I can recreate this issue.

[vonericsen]

I tested manjaro and it did not have issues either:

My guess is when executing, the ./ path is not being provided so the system is only searching system directories for openSeaChest. If you are executing with ./openSeaChest_Basics you may need sudo unless you have configured other permissions.

If you have copy-pasted the tools off a USB that was formated with FAT32 (and possibly exFAT) the execute permission may be missing. This can be fixed with chmod +x openSeaChest*.

[Callistemon]

There is still an ERROR: with the latest source code. At least meson appears to put effort into a clean output, instead of requiring you to look through garbage flying everywhere to find errors as make does.

meson-log.txt

My guess is when executing, the ./ path is not being provided so the system is only searching system directories for openSeaChest. If you are executing with ./openSeaChest_Basics you may need sudo unless you have configured other permissions.

If you have copy-pasted the tools off a USB that was formated with FAT32 (and possibly exFAT) the execute permission may be missing. This can be fixed with chmod +x openSeaChest*.

Edit: yes apparently it does need ./openSeaChest_Basics even after the directory is changed to the folder. Thanks for clarifying.

[vonericsen]

I will setup a fresh clone to see if I can repeat this as best I can to figure out what may have happened.
My current guess is that the submodules may not be pulled to their latest point, but that is what I'll investigate.
It may be as simple as running git submodule update --init --recursive to force them all to update, but there may be a step in between. I'm going to try starting with the tag like it appears was used first, then work from there going to the develop branch to see where a step may have been missed or I forgot to mention.

As for the ./ vs cd into a directory and running without ./, Windows is forgiving in this case and will search your current directory, but Linux does not do this...It may be possible to configure, but I have not tried.
In Linux (and other Unix-like systems I've used) they will search /usr/bin, /usr/local/bin, /usr/sbin, and /usr/local/sbin and possibly a few other places. Similar to using the command which to search if a program is available on the system. Since you used cd this changed the present working directory (pwd), but the search path for applications is still the same. By adding ./ it is saying look for this application in the current directory. If you were instead in the user home directory (~) in the terminal, you could provide the full path to the executable to run it too. For example: ~/Downloads/openSeaChest/openSeaChest_Basics if that was the relative path to it.

[eli-schwartz]

As for the ./ vs cd into a directory and running without ./, Windows is forgiving in this case and will search your current directory, but Linux does not do this...It may be possible to configure, but I have not tried.

This is textbook behavior on operating systems that aren't named "Windows" (not limited to Linux). The current directory is intentionally excluded from the executable search path on the grounds that it is a massively dangerous security hole.

On Windows, it is presumably presumed to not be an issue since "no one uses command lines anyway". :)

and did not reach an error until stupid evil make raged into presence as a dumpster fire, ruining hours of effort. This issue is about openSeaChest Linux, but make deserves shaming words to be mentioned at every opportunity.

provide source code that can be compiled without any involvement of make, which shouts at you with *** that represent rage and the word Stop telling you to give up.

While I do like meson as much as the next meson core developer, I have got to say this confusing hatred of make has really made my day... I don't think that make itself is anything particularly evil, although admittedly some patterns of writing Makefiles are encouraged by the fact that Make is a command runner, not a build system, and thus cannot really check for dependencies, verify system interfaces are present (or check their calling conventions and define suitable macros), and a whole range of other things on top of the use of recursive make...

Because make is from GNU, an organization that spends most of their time relentlessly whining about how any traces of anything proprietary is malicious, it is not possible to compile anything with make without ruining the day.

Actually make is from POSIX, an organization that maintains standards which are used by both GNU and proprietary Unix operating systems. There are a number of different softwares all called make, even Microsoft has one (https://docs.microsoft.com/en-us/cpp/build/reference/nmake-reference?view=msvc-170) and GNU just happens to have written a fairly popular one, known as "GNU make".

The GNU autotools go to special efforts to make sure that autotools projects correctly compile on any make, not just the GNU make, and even proprietary makes. :)

(autotools is a build system, which make on its own is not, and hence autotools can do clever checks before erroring out with inscrutable compiler "no such file or directory" errors.)

[eli-schwartz]

We also recently pulled in an update to use meson for building which may be easier in some cases (and is definitely faster).

@vonericsen meson does make sure that meson subprojects work, and will automatically pull them as a git submodule if relevant, so that error should indeed be much harder to hit with meson. :)

[vonericsen]

This is textbook behavior on operating systems that aren't named "Windows" (not limited to Linux). The current directory is intentionally excluded from the executable search path on the grounds that it is a massively dangerous security hole.

On Windows, it is presumably presumed to not be an issue since "no one uses command lines anyway". :)

This makes sense to me. I thought security would also be a reason for this behavior.
There was a patch MSFT made around Win8 to prevent loading DLLs from the current directory since that could introduce malicious code to the system. I remember having to make updates to some of our internal projects for that as well.

@vonericsen meson does make sure that meson subprojects work, and will automatically pull them as a git submodule if relevant, so that error should indeed be much harder to hit with meson. :)

This is what I've found so far...I have not figured out how to exactly repeat what @Callistemon is seeing.
I pulled at the release tag, then checked out develop, then called meson and it checks the subprojects and pulls them so it builds just fine....so I am not entirely sure what is happening right now for @Callistemon's system.
I did not realize meson did this originally and this is really cool!
@eli-schwartz if you have any idea what may have happened with @Callistemon's system to get into this state, I would like to know.

@Callistemon I haven't been able to recreate what you are seeing. It would probably be best to try a fresh clone and build with meson from develop:

1. clone: git clone --recursive --branch develop https://github.com/Seagate/openSeaChest.git
2. build with meson & ninja: meson --buildtype=release builddir & ninja -C builddir

If you are still having trouble with this, I will need a history of exactly what commands have been run in order to figure out what went wrong so I can try repeating it with exactly the same commands you used.

[Callistemon]

1. clone: git clone --recursive --branch develop https://github.com/Seagate/openSeaChest.git
2. build with meson & ninja: meson --buildtype=release builddir & ninja -C builddir

This finishes nicely without errors, but one thing to remember is to cd openSeaChest between 1 and 2. After it completes, the terminal still returns a "command not found" when inputting openSeaChest_Basics. If it's installed, it shouldn't need to use cd and ./

[vonericsen]

Glad that process was able to work, sorry I missed the cd between 1 & 2.
After those commands the tools will be built, then you can decide what to do with them. You can run them from builddir, or run ninja -C builddir install to make them runnable system-wide. I do not often install them since I am testing frequent changes, so I tend to forget about this last step.

Full process would then be:

1. clone: git clone --recursive --branch develop https://github.com/Seagate/openSeaChest.git
2. cd after cloning: cd ./openSeaChest
3. build with meson & ninja: meson --buildtype=release builddir & ninja -C builddir
4. install for system-wide use: ninja -C builddir install

[Callistemon]

Perfect. Thank you!


make vs meson
"That's just the way it is" about compiling being difficult is wrong. "Every system is different" is the wrong excuse for days being maked (not made). make doesn't even work on Ubuntu either.
(For some reason, the new openSeaChest was cloned inside the gcc folder of the previous release)

[Callistemon]

I have this issue on Windows now. After downloading the latest ZIP and using cd C:\Users\Spindle\Downloads\openSeaChest-develop, meson --buildtype=release builddir fails with ERROR: Neither directory contains a build file meson.build

Cloning with git clone --recursive --branch develop https://github.com/Seagate/openSeaChest.git is not possible because git is not recognized as an internal or external command, operable program or batch file

[eli-schwartz]

Okay, is there in fact a meson.build file in the openSeaChest-develop directory?

I find it unlikely that that is the real error. However, I would expect you to get a different error:

The Meson build system
Version: 0.61.99
Source dir: /tmp/openSeaChest-develop
Build dir: /tmp/openSeaChest-develop/builddir
Build type: native build
Project name: openSeaChest
Project version: 2.0.2
C compiler for the host machine: ccache cc (gcc 11.1.0 "cc (GCC) 11.1.0")
C linker for the host machine: cc ld.bfd 2.36.1
Host machine cpu family: x86_64
Host machine cpu: x86_64

meson.build:36:0: ERROR: Subproject exists but has no meson.build file

This happens because the subprojects are git submodules, and you need git to download those submodules correctly. It's a well known fact that Github's "download as ZIP" or "download Source Code" attachments are completely useless if a project contains git submodules.

https://git-scm.com/download/win is not that hard to acquire. :)

This project can also choose to run meson dist --formats gztar,zip from a configured build directory, when preparing a release. The resulting openSeaChest-2.0.2.tar.gz and openSeaChest-2.0.2.zip can be uploaded as release assets alongside the prebuilt executables.

A meson dist built archive contains the submodules as well, in order to guarantee that it can be built correctly once downloaded. Here are example dist archives.
openSeaChest-2.0.2.tar.gz
openSeaChest-2.0.2.zip

[Callistemon]

It was because there was a second openSeaChest-develop folder inside the first. After using cd openSeaChest-develop\openSeaChest-develop some errors occur.

[eli-schwartz]

Do you in fact have a compiler installed somewhere? Which compiler? Where is it located?

[Callistemon]

The second screenshot is after downloading this Visual Studio Community installer from https://visualstudio.microsoft.com and installing it. Once it finished installing, it had some online account login. Does this mean it's necessary to login to setup Visual Studio or is that unrelated to having it around for meson?

There's a page of instructions for Visual Studio with steps for choosing workloads, invididual components, and selecting the install location. The installation finished before the "choosing workloads" screen though.