I've successfully developed a C++ code using Visual Studio on Windows, and my current task involves transitioning it to a Unix-based supercluster. The complication arises as the supercluster necessitates a Unix transcript of the build event for proper execution. I'm seeking guidance on how to effectively address this challenge. Any insights or suggestions on how to resolve this issue would be greatly appreciated.

> a Unix transcript of the build event for proper execution.
What does this mean?

To produce a build on *ix systems, you typically use make or cmake.
https://linux.die.net/man/1/make
https://linux.die.net/man/1/cmake
You might be able to export a makefile from visual studio that you can then copy to your *ix platform.

To capture the output of a build (error messages etc), use redirection.
make -f Makefile 1>result.txt 2>&1
This
- runs make using Makefile as the input
- redirects standard out to result.txt
- redirects standard error to standard out (which is now result.txt)

To be honest I even don't know what does that mean. The person responsible for executing the code on cluster told me that do not have visual studio proxy on the cluster and for me to be able to run the code on cluster I need to provide them with Unix transcript of the code. Thanks for your help. let me try what you suggested.

Are those their exact words?

Maybe they just mean copy the source code from your windows machine to the cluster.

If it's a simple project with all source and header files in the same directory, you can get away with just doing
g++ *.cpp

Windows executable (.exe files, PE file format) can not run on Unix/BSD systems.

So, at the very least, you will have to re-compile (re-build) your source code in order to be able to run on Unix/BSD.

Be aware that there is not the one "Unix" operating system! Instead, there is a whole family of operating systems that are considered "Unix derivatives", such as FreeBSD, OpenBSD, Solaris, AIX, HP-UX and even MacOS X (Darwin). There also are "Unix-like" operating systems, such as Linux, that were developed independently (from scratch), but that "mimic" Unix. Which one exactly is used on the cluster?

Anyhow, Microsoft Visual Studio (Microsoft Visual C++) is not available on Unix/BSD systems, so you will have to re-compile your source code using whatever C/C++ compiler is available on your Unix/BSD operating system! Often this is either GCC or Clang. Enterprise Unixes usually have their own proprietary compilers, like Solaris has Oracle Developer Studio C++ compiler and AIX has the IBM xlC/C++.

Ideally, if your source code is "pure" C/C++, it should compile on Unix/BSD without any modifications. In reality, there are many pitfalls, though, because different C/C++ compilers always have different quirks. Furthermore, if your code uses any Microsoft-specific extensions or any Win32 API stuff, then you will definitely have to re-write your code in order to make it work on Unix/BSD (POSIX API) 😏

@kigar64551 you are absolutely right. I had to rebuild the code in Unix based operating system. I used gcc, to do so, I had to do a lot of modifications cuz some libraries from visual studio and their built-in functions were not available Unix. Thanks for your helpful information. I appreciate it.

@salem c
Actually yes, It was what I was told. Thanks for your help.

the reverse is equally true... going from ix to windows will frequently require removal of nonstandard headers, rewriting sections, and so on. Code must be carefully written to avoid this, and in many cases, it simply cannot be avoided and you end up needing macros to swap out parts of the code for the current OS and build.

Code written for Unix/BSD or other Unix-like operating systems usually uses the POSIX API (i.e. <unistd.h>), which I wouldn't call "non-standard". It is standardized and supported on a whole lot of operating systems, but a different/orthogonal standard than the C Standard Library; and it simply is not supported natively on Windows. You can use Cygwin to build such code on Windows, though.

The other way around, you may (or may not) be able to run "native" Windows programs on Linux, macOS and BSD thanks to Wine.

POSIX API (i.e. <unistd.h>), which I wouldn't call "non-standard"

It's not part of the C++ standard so isn't standard C++. Perhaps there's an argument to be made to the committee that it should be...