While exploring about the platform setup for OpenCASCADE, I came to know about WOK commands which arent needed for CMake build system to use with OpenCASCADE
However another option of genproj tool (for which I havent yet found any exe but DLLs..) to be used with MSVC+ in built compiler so that we dont need any gcc installation
Whats the difference between the twos and which one is better and easier??
Also suggest me how to download and install and setup genproj on windows
OCCT project provided the following build systems:
CMake. This is the main building system since OCCT 7.0.0.
It allows building OCCT for almost every supported target platform.
WOK. This was an in-house building system used by OCCT before 7.0.0 release.
The tool handled classes defined in CDL (CAS.CADE definition language) files (WOK generated C++ header files from CDL) and supported building in a distributed environment (e.g. local WOK setup builds only modified source files and reused unmodified binary / object files from local network). WOK support has been discontinued since OCCT 7.5.0 and unlikely will be able building up-to-date OCCT sources (although project structure remains compatible with WOK).
genproj. This is a Tcl script allowing to generate project for building OCCT using Visual Studio (2010+), Code::Blocks, XCode and Qt Creator. This script has been initially extracted from WOK package (where it was implemented as command wgenproj in it's shell) and now maintained independently from it.
qmake. Experimental adm/qmake solution can be opened directly from QtCreator without CMake plugin (the project files will be generated recursively by qmake). Although header files generation (filling in inc folder) still should be done using genproj (qmake scripting capabilities were found too limited for this staff).
genproj doesn't require any DLLs or EXE files - it comes with OCCT itself and requires Tcl interpreter. On Windows platform it can be executed with genconf.bat and genproj.bat batch scripts in the root of OCCT source code folder. At first launch it will ask to put a path to tclsh.exe.
While CMake is the main building tool for OCCT project, genproj remains maintained and used by (some) developers - mostly due to personal habits and hatred to CMake. They differences of genproj from CMake that could be considered as advantages in some cases:
Generated project files can be moved to another location / computer without necessity to re-generate them.
Simplified 3rd-party dependency search tool genconf with GUI based on Tcl/Tk.
Batch-script environment/configuration files (env.bat and custom.bat), although CMake script in OCCT emulates similar files.
Generated Visual Studio solution contains Debug+Release and 32bit/64bit configurations.
Running Draw Harness and regression tests can be started directly from Visual Studio (without building any INSTALL target).
No problems with CMakeCache.txt.
Limitations of genproj:
No CMake configuration files. Other CMake-based projects would not be able re-using configuration files to simplify 3rd-party setup.
Regeneration of project files should be called explicitly.
Out-of-source builds are not supported (however, each configuration is put into dedicated sub-folder).
No INSTALL target.
No PCH (pre-compiler header file) generation.
It should be noted, that several attempts have been done to make compiler / linker flags consistent between CMake and genproj, but in reality they may be different.
We've got a .NET Core app that was hosted in Azure Service Fabric. Now we are moving it to Linux-based Docker containers.
We need to be able to create 7zip archives for an external service (one of those fancy "drop your files here via ftp" interfaces which requires 7zip archives).
Until now we could use a CLI wrapper ported from .NET Framework to .NET Core. But that does no longer work once we switch to a Linux environment.
We can't change the external service (because it is not ours) and we don't want to use Windows-based Docker containers.
There is a large number of 7zip NuGet packages for .NET Framework. Very few for .NET Core (mostly outdated and no longer maintained). And none I could find for .NET Core on Linux.
Do you have any suggestions on how we could solve that issue?
UPDATE: I found one similar question among the open issues of the SevenZipSharp project. Sadly there is no solution included.
UPDATE 2: Unfortunately we can't use an alternative implementation of the LZMA algorithm. Our 3rd party requires archives in the .7z format :-(
This is not an answer as it doesn't really provide a solution to the question, but it does address why it unlikely there will come an updated 7Zip library for Linux and address the problem with a good LZMA OS-cross-platform compression engine. So it should be seen as a long Comment, I hope it's okay.
It seems 7Zip is not maintained on Linux at all, current library is rather old, and I don't trust it's compatibility with the current and newer Windows 7Zip versions, so in my view 7Zip on Linux is a no-go. It's my understanding that Igor Pavlov (creator and maintainer of Zip) only target Windows. And he's not the creator of the current and old Linux 7Zip library.
A LZMA compression engine with both Linux and Windows support is LZip (.lz).
The latest library (zlib) is 1.11 and in July 2019 I sent a request to Domani Hannes to compile a new Windows version and he was to kind to reply with a download link and the following message:
I just now built plzip-1.8 with lzlib-1.11 and mingw-w64-winpthreads-v6.0.0.
There are no longer modifications necessary to be able to compile for Windows, so it's pretty straightforward.
I guess it mean it's easy to compile newer Windows versions in the future too.
Download link to this binary: plzip_zlib_1.11.exe.
I haven't have time to test it thoroughly yet for my own project, so if anyone go down this path please share your experiences (with a risk of hijacking this thread, so maybe not :-P).
There is a Crystal equivalent of OCRA (One-Click Ruby Application Builder) but it's only for Windows and I use Linux.
Crystal unlike Ruby is not interpreted or executed in a virtual machine. Crystal is compiled to native code ahead of execution using the LLVM. Application is started by the operating system not with interpreter.
So yes, onсе compiled app can copy and run for any Linux machine with the same architecture. You may need to install system libs like libssl for use full featured stdlib but it is not critical.
Crystal app is already OCRA (all of included shards will builded into one binary) if you specially have not used dynamic linking.
What to read next:
List of supported platforms
Installation Crystal
Using the Compiler for build app
Crystal reference
And API documentation
I have developed a small application in Qt Creator on Ubuntu 12.04 which I want should run on any other linux distro (mostly different versions of CentOS and ubuntu), just like any portable application on windows does.
I want to be able to simply share the binary file of the Application, and run the application.
I am able to successfully do this in windows, by just building the project in QT Creator and then putting the required libraries in the Application directory and then transfering them to other windows systems.
I searched all over and found out that I should be trying to build the project using LSB(Linux Standard Base) Compatibility, so that it runs on other linux distros. Is that the right way to do this?
I am very new to Qt and also to Linux (dont know much of Shell Scripting).
Thus, I dont know how I should proceed to make the Application LSB Compliant.
I have refered to, the following links:
Distributing Qt-based binaries on Linux and
Deploying Qt applications on Linux but have not beem able to understand what I am suposed to do.
I also found this question here which states a very similar situation as mine, but because I am a novice, I dont know how I should do this.
Moreover, considering that the first two articles were written 6 years back, shouldn't there be a simpler way to deploy Qt apps on the linux platform now?
I also saw something about static linking, is that the way to go?
Isn't there a way by which all of this can be done through Qt Creator itself?
If there is no hope of creating a portable Qt Application for Linux, then is there a way, say a shell script or something that would combine all the steps required to compile the Qt project on another computer and run it. Say, download Qt-SDK if not present, run qmake and make and then the newly compiled application, if not already there, so that the user can run the program just by running one script.
Your problem here is not the Linux Standard Base, but rather the presence or not of the specific version of Qt you need (or a later one).
Exactly like on a Windows machine, a user may have any of Qt installed, or they may not have it at all. On Windows it is easier to check for the presence of a certain version of Qt than it is on Linux, thus it is easier to write install tools that automate the experience.
To solve your problem there are a few ways:
Inform the user that your program requires a certain version of Qt or higher, and let the user handle the problem
Learn how to create packages for every distribution you want to target and create specific packages
Use a program like 0Install or Elf Statifier to create a package/executable containing all the necessary libraries.
The latter is similar to what many Windows and Mac programs do (they include every library they need within the installer), but it is not the preferred way on Linux, which relies heavily on shared libraries.
Making a binary application compatible with any other Linux distro is practically impossible since you will never know in advance which libraries are available in distro X, or what version of that library is available. Even among a single distro (e.g. Ubuntu), binary application are almost never backward-compatible, since anything built on Ubuntu 12.04 will have dependencies on versions libraries which are installed on that version of Ubuntu, and trying to run that binary on Ubuntu 10.04 will most probably fail simply because it doesn't have a recent enough version of glibc or some other necessary library.
However, the idea can be much more implementable if you limit yourself to a finite list of distros and versions of those distros. You can then know which libraries are available for those distros, and aim for the lowest common denominator. I used to maintain a binary application which had to support several distros (Ubuntu, Fedora, OpenSUSE, SLED, Mandriva), and the way I would do it is install the oldest distro I was targeting on my build machine. That way, the binary application would be linked to the oldest versions of the libraries available on those distros. Unless there's a new major version of such a library (which happens quite rarely, and even then, distros usually distribute the previous major version for a while for compatibility purposes), your compiled binary will then be compatible with all your targeted distros.
Therefore, the quick piece of advice I would give for your situation, use the oldest LTS version of Ubuntu which is still supported (10.04 at the moment) for your development, and you should be pretty safe for most recent popular distros. For the application you already developped on Ubuntu 12.04, you should have no problem simply recompiling the same source on 10.04. Understand that you will never however achieve 100% compatibility with a compiled C++ Qt application.
If Qt is not all that important to you, you could use a higher-level or interpreted language such as Python, Java, Perl or Ruby. With such languages, you can usually count on the language implementation already being installed on the target distro.
Deploy an application in Linux is a nightmare, luckily there are some solutions. Check this projects to build a portable binary with all their dependencies bundled:
http://statifier.sourceforge.net/statifier/main.html
http://www.magicermine.com/index.html
http://www.pgbovine.net/cde.html
Another solution is make a portable 0install package:
http://0install.net/
I recomend this solution. Personally I have been problems with the 3 first packagers.
As per my knowledge, windows uses .lib and .dll extension for libraries and linux uses .a and .so. I am working on a project in ubuntu for manipulation with jpeg image files. so i want to know if these libraries can be used interchangeably in linux and windows? for example if have created example.so library in ubuntu and now i want to use it in some compiler in windows...
If you're planning on running under Wine, then yes.
Otherwise the chances are small. Windows DLLs will most probably use Windows APIs not available on Linux. Even if they're not the DLLs are built for use with compilers running on Windows.
Why not use imagemagick? http://www.imagemagick.org/script/index.php