No such file or directory when trying to build with MSYS2 about openseachest

[vonericsen]

Thanks for the info.

I primarily use Visual Studio, so my experience with MSYS2 is a little limited, but I try to keep it up to date and working since I know some people prefer using MinGW. So from my experience with MSYS2 is that the standard terminal (MSYS2 MSYS) is used for package updates, but not necessarily compiling.
Then I use MSYS2 MinGW 64-bit to invoke make to produce the tools, but it sounds like from the last reply this is what you are currently doing.

I know cloning submodules in git is complicated depending on which version of git you are using (As seen here), but I don't think this is the problem, or solves it right now.

Your first line should have automatically done that with the --recurse-submodules option...at least to pull them based on what the top level (openSeaChest) was last updated to point towards (which should compile, but is now missing a couple fixes I've made...I intend to update this once I get a final result from someone testing some of these changes).

I did a fresh clone using the same commands as you and saw the same error.
The reason for that error message is the use of --single-branch.
I'm not super familiar with this option and haven't used it before, but it seems like it doesn't know the reference to release/Release-20.11 since the --single-branch option didn't pull anything else so it cannot find it to checkout or pull. This can be checked with git branch -a to see what branches are known and can be checked out.
I found this link which discusses using it as well as "undoing" it, which seemed to work once I did that.
This is the sequence I ran, which was able to pull the release/Release-20.11 branch for the submodules (at least those that need it):
git submodule foreach 'git config remote.origin.fetch refs/heads/*:refs/remotes/origin/*'
git submodule foreach 'git fetch'
git submodule foreach --recursive 'git checkout release/Release-20.11'
The wingetopt submodule will fail, but that's ok since it doesn't have or need this branch (this project will never really change).

There may be a better way to specify pulling only the release/Release-20.11 branch rather than this method which ends up pulling everything, but I don't know what exactly that would be.

[hashimaziz1]

Perfect, adding those few lines after the clone did the job, I've now managed to compile the binaries successfully. Those instructions should probably be added to the README. I also did the whole thing on MinGW 64 so it seems only one terminal is needed for both updating and compiling.

Quick question, what's the difference between the normal binaries and those suffixed with numbers like 300_211_64 or 210_211_64?

[vonericsen]

You can safely delete either set. It's only a simple renaming (keeping original copies).

You can delete the script, but the makefile may report a failure since it calls it to execute as part of the make process. If you modify the makefile, you can comment out, or delete the line and that should be fine.

[hashimaziz1]

I thought it might be of interest to you guys that I just posted a complete, up-to-date guide on StackExchange on how to compile the openSeaChest tool for Cygwin (and Windows) using a minGW-w64 toolchain, partially based on the README and some of the help from @vonericsen in this issue. I like the tools a lot, and since I came across them so randomly after a long time in this field, I think some wider exposure to them would benefit others working in these fields and help the utilities to gain more traction, maybe even allowing them to become available in some package managers too. Either way they're a godsend for me and I wanted to return the favour.

[vonericsen]

Hi @Kaos-Industries,
I updated the readme file to help with this issue.
I chose to remove the --single-branch from the step-by-step instructions to keep it easier for anyone else that may read it.
I also added a note of how to undo a --single-branch checkout in case anyone else runs into this issue.

If you would like to review it, please do and I will be happy to modify it some more.
If you think this clears it up, please close this issue (if you think it is ready to be closed).

[hashimaziz1]

Anyone at all? I was really looking forward to using this chest since Cygwin no longer has an actively maintained package for hdparm, and something like this is currently the only way to run SECURE ERASE on SSDs.

[vonericsen]

Hi @Kaos-Industries,

I tried to recreate this error and have not been able to. I tried on develop and release/Release-20.11.
I updated to the latest packages for everything and couldn't get any errors to show up.
I've had this installed for a while, but I followed that same process when I did this a while back. I can create a VM and try a fresh setup of everything to see if I can figure out why that error is showing up if I can repeat it.

Can you confirm which MSYS command window you are trying to use for the build?

Also, does this happen when you run the build as make -f Makefile.gccWin release? I want to confirm it's not a debug build issue even though I couldn't repeat it.

[hashimaziz1]

Hi @Kaos-Industries,

I tried to recreate this error and have not been able to. I tried on develop and release/Release-20.11.
I updated to the latest packages for everything and couldn't get any errors to show up.
I've had this installed for a while, but I followed that same process when I did this a while back. I can create a VM and try a fresh setup of everything to see if I can figure out why that error is showing up if I can repeat it.

Can you confirm which MSYS command window you are trying to use for the build?

Also, does this happen when you run the build as make -f Makefile.gccWin release? I want to confirm it's not a debug build issue even though I couldn't repeat it.

I was using the MSYS2 MSYS terminal on Windows 10. I'll try again with make -f Makefile.gccWin release.

[hashimaziz1]

I just tried with MSYS2 MinGW 64-bit and I got an error that I just remembered I also got when attempting it in the normal MSYS2 MSYS terminal. After running:

git clone --recurse-submodules --branch release/Release-20.11 --single-branch https://github.com/Seagate/openSeaChest.git openSeaChest
cd openSeaChest
git submodule foreach --recursive 'git checkout release/Release-20.11'

...I get the following output:

Entering 'opensea-common'
error: pathspec 'release/Release-20.11' did not match any file(s) known to git
fatal: run_command returned non-zero status for opensea-common

[vonericsen]

Great! Glad that worked for you!
I have noted to add that to the README for compiling with MSYS2. We can leave this open until I have pushed a README file change.

The suffixes are added by a script from my old coworker who originally set all of this MSYS2 build process up and wrote the original README. The script runs the executable after compiling and extracts some of the version information to append to the end of the file name, then it also adds _64 to denote that this is a 64bit version of the tool. The first number is the tool version, the second is the opensea-transport version. This comes from how we originally tracked tool versions internally since most of the update applied either to the tool, or mainly to opensea-transport for a very long time. It was his way of helping keep track of the tool versions that is also used by internal versions of SeaChest that he would send out. It's a little different now, but we haven't changed this part of the process yet.
This may change in the future depending on how we setup CI/CD or some other efforts we've been making internally. We may also change it as we continue working on CMake (another ongoing effort at the moment).

[hashimaziz1]

Great! Glad that worked for you!
I have noted to add that to the README for compiling with MSYS2. We can leave this open until I have pushed a README file change.

The suffixes are added by a script from my old coworker who originally set all of this MSYS2 build process up and wrote the original README. The script runs the executable after compiling and extracts some of the version information to append to the end of the file name, then it also adds _64 to denote that this is a 64bit version of the tool. The first number is the tool version, the second is the opensea-transport version. This comes from how we originally tracked tool versions internally since most of the update applied either to the tool, or mainly to opensea-transport for a very long time. It was his way of helping keep track of the tool versions that is also used by internal versions of SeaChest that he would send out. It's a little different now, but we haven't changed this part of the process yet.
This may change in the future depending on how we setup CI/CD or some other efforts we've been making internally. We may also change it as we continue working on CMake (another ongoing effort at the moment).

So to clarify, there's no difference between the two sets of binaries and I can safely delete either one? And for that matter, can I safely delete rename_seachest.sh before building to make sure that the extra binaries are never created?