A year back i have developed a small script in perl for a customer and developed its .exe using pp .
we delivered .exe file along with basic cygwin(1.52) install files to run that .exe to customer.
Now we got an enhancement in the script .we lost all dev environment for cygwin .Again we installed fresh cygwin with 1.7 version ,coded and generated .exe file.this file is not running in the customer environment who have cygwin 1.52.Just it will be balnk after executing the .exe
we cannot ask customer to upgarde the test environment.
what is other way to make it run .exe with cygwin dll 1.7 on cygwin 1.52.
Any help would be higly appreciated.
Rgds,
sowm
The developers of Cygwin are strict about upward compatibility, but they don't try to provide backward compatibility between major releases, like between 1.5 and 1.7. This means you can build a program on 1.7 that runs on 1.5 only as long as you avoid calling functions that were added to the Cygwin DLL in 1.7.
Most likely the reason your code calls 1.7-only functions is that it is using libraries that auto-discover platform features. There could be other reasons, but without any details about what exactly is failing, it's difficult to guess.
If the problem is due to third-party libraries, as I'm guessing, it may be practical to spend time to figure out how to make them revert to the common functionality provided by both 1.5 and 1.7. For instance, with an autoconf-based system, you can hand-edit the config.h file the configure script produces to turn off use of some discovered features. This in turn means building all those libraries from source yourself, rather than downloading binary versions from the Cygwin project repository and using them directly.
It may be easier to pull a Cygwin 1.5 environment out of the Cygwin Time Machine.
By the way, you are aware that distributing Cygwin and executables built with it requires that those executables comply with the GPL, or that you buy a Cygwin commercial distribution license, right? If not see the FAQ.
Install 1.5 with http://cygwin.com/setup-legacy.exe
Related
I'm working on a project, which targets both Windows and Linux (and possible in the future MacOS). It consists of some applications with several shared libraries. It is written in modern C++ and modern CMake. It also uses 3rd-party libraries like Qt, OpenCV, Boost, GraphicsMagick, samplerate, sndfile. Those dependencies are handled through Conan package manager. I'm building both on Linux (Ubuntu 18.04, GCC 8.1) and Windows (via WSL - also Ubuntu 18.04, MinGW-w64 8.1). I'm using fairly recent versions of 3rd-party libraries with custom built options (strictly speaking - different versions than available on Ubuntu's APT, e.g. Qt v5.11.3, or custom built of GraphicsMagick)
I'm using CPack. On Windows I'm building NSIS installer, but on Linux I would like to use DEB generator (may be other if needed). All of my targets (written apps and shared libs) have appropriate CMake's INSTALL configurations, so they are copied correctly into the generated installers (component based installation). The real problem comes with packaging of 3rd-party dependencies.
Problem
Strictly speaking, I have no idea, how to do it well using CMake+CPack+Conan, both on Linux and Windows. I've read a lot of articles and posts, but I'm stucked. I would like to have something, that automatically bundles into the installer all 3rd party libraries used by project with needed plugins and, what is the most important, with needed system/compiler libraries (libgomp, libstdc++ and so on).
Possible solution
To my surprise, on Windows, this task is fairly easy, because every DLL used by app (my libs, 3rd-party libs and system/compiler libs) needs to be located where executable is. I'm engaging Conan into this, by importing all used DLLs into bin directory. In the end, in most naive way of packaging, I will just copy the bin directory into the installer and it should work. But I'm not sure, if this approach is OK.
On Linux, things are more complicated. First, there is arleady a package manager. Unfortunately, libraries/compilers available there are too old for me (e.g. on APT there is only Qt 5.9.6 ) and are built using different compile options. So, the only way for me is to ship them with my software (like in Windows). There are also issues with searching for dynamic libraries by ld, RPATH handling and so on. At the moment, the only solution I see is to write something like 'launcher' for my app, which sets LD_LIBRARY_PATH before program starts. After that, in this case we can just copy bin or lib directory to the DEB installer and this should work. But still, I don't know if this is correct approach.
Other solutions
I've also looked into other solutions. One of them was BundleUtilities from CMake. It doesn't work for me. It has a lot of problems in recognizing, whether some library is system or local one. Especially in WSL, where it stucked in processing dependencies to USER32.dll, KERNEL32.dll. BundleUtilities in Windows worked for me only with MSYS, but in MSYS I've failed to compile some 3rd-party libraries (GraphicsMagicks via Conan) and that's the reason, why I'm using WSL.
Summary
I'm looking for good and verified method of packaging C++ projects with multiple apps, libs and shipped 3rd-party libs, both for Windows and Linux. How are you doing things like this? Are you just copying bin and/or lib dirs to the installers? How (in terms of CMake/CPack code) are you doing that? INSTALL(DIRECTORY ...), or similar? I'm not sure, but I think that this problem should be already solved in the industry. ;)
Thanks for all suggestions.
First, Conan is a package manager for development, not for distribution, that's why you didn't find an easy way to solve your problem. Second, most of discussions are made at Conan issue, including bugs and questions. There you will find a big community + Conan devs which are very helpful.
with needed system/compiler libraries
This is not part of Conan. Why you don't use static linkage for system libraries?
Talking about CPack, we have an open discussion about it usage with Conan: https://github.com/conan-io/conan/issues/5655
Please, join us.
I see few options for your case:
on package method, run self.copy and all dependencies from self.cpp_deps, which includes all libraries, so you can run Cpack
Use Conan deploy generator to deploy all artifacts, and using a hook you can run cpack or any other installer tool
Out friend SSE4 is writing a new blog post about Deployment + Conan, I think it can help you a lot. You can read a preview here.
Regards!
I have a box running Win2k to support a few legacy applications that can't be migrated forward at this point that I'd like to manage for most part with Cygwin.
However, the current Cygwin installer requires Windows XP 3. The installer referenced by the good folks at at Cygwin Time Machine runs just fine, but when I attempt to configure any suggested circa release area and proceed, the installer errors out attempting to download setup-2.bz2.sig and setup-2.ini.sig.
The circa release area I'm attempting to use is here.
Directory listing is not enabled, so really can't tell you anything more than the fact that setup-2.ini and setup-2.bz2 are there, but their signatures are not. Seems to be the case for a random sample of other releases listed here.
Cygwin Time Machine was enormously helpful in resolving this issue. Essentially, my woes were caused by
attempting to draw in packages from the Cygwin's 1.7 "development" branch (the setup-2.* errors).
using a setup installer too fresh for my purposes.
Digging around the Internet Archive, I found the last installation page update in which Windows 2000 (1 June 2013) still supported and downloaded the cached installer (link to setup.exe).
Cygwin Time Machine suggested these alternatives:
ftp://www.fruitbat.org/pub/cygwin/setup/snapshots/setup-2.602.exe
ftp://www.fruitbat.org/pub/cygwin/setup/snapshots/setup-2.573.2.3.exe
ftp://www.fruitbat.org/pub/cygwin/setup/snapshots/setup-2.523.exe
However, the 1 Jun 2013 installer (link) is considerably newer, can make use of a fresher repository (I'm able to install python 2.7.3 rather than 2.5.2), and has the nice filter feature we're used to in more modern installers.
Finally, Fruitbats does not archive the signatures for the setup package lists. You run at your own risk.
To ignore signatures, run the setup installer with an -X flag, i.e.:
c:\...> setup.exe -X
That about wraps it up. I have a mid-2013 Cygwin 1.7 installed on Win2k Advanced Server SP4.
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.
Just today i checked my ubuntu with installing wine in it ,
Delphi 3 to 7 worked perfectly (Rad studios did not work because they use .net scraps).
But all of the application i made worked perfectly!!!!!
And i heard that it also works well in mac with WineBottler
Is it possible to create a header linux executable and put my vcl application and requird wine stuff into it and distribute as a single executable (.bin)
there is(was) a solution for Linux from Borland, called Kylix. Kylix is based on some older Qt-stuff.
But I would give FreePascal/Lazarus a try, it's pretty cool! and the compiler compiles for many different platforms.
I guess this is what winelib is for. However I have never tried it. (Wasn't Kylix Delphi + winelib compiled for Linux?)
Since Wine is now stable (reached the 1.0 version some time ago), it could make sense to ask the user to install it using its Linux packages manager. It's very fast and easy. So Wine will be always up to date, according to the distribution used.
Then it's very easy to install any Windows program with Wine.
Since Delphi executables are mostly self-contained (if you don't use the BDE or some external database libraries), your clients will install your Delphi application alla "Windows" way, that is, by running a Setup program from Wine.
And it will work fine, as is.
Using WineLib is not a good idea, even not advised by Wine developers, as far as I remember. At least for closed-source software: in one or two years, perhaps you won't release another version of your program, but Wine and WineLib will have evolved a lot... If you use Wine as an external package, your client can be sure there will be some end user enhancements.
If your software is purely Open Source, then using WineLib could make sense. But even the WineLib headers can evolved, so perhaps your source won't evolve at the same speed...
I have about a few problems with a new install of the Qt SDK. I probably only need advice, but specific answers are also welcome. Before I begin a mini-story, I am running RHEL5 on academic license under VirtualBox on OSX 10.6. Using Qt version 4.5.3. This is my situation...
1.) I couldn't compile because g++ wasn't found. I fixed this by creating a link: g++ -> g++34. This allowed me to compile but it generated more errors at link-time. I had installed the framework in my home directory unintentionally so I uninstalled/reinstalled the entire SDK to /usr/local/qt.
2.) At this point I could compile but the linker complained about a missing freetype package. I had that already installed but wasn't sure why it couldn't be found. So I installed a few packages that I thought might be missing like libqt4-devel and libqt4-devel-debug. I also installed a few other general programming packages for later use.
3.) Somehwere in this process I can no longer run qmake. I ran it before and I have it installed at /usr/local/qt/qt/bin/qmake. I could create a link to it (though I shouldn't have to OR I could ensure that the location was in the PATH var). However, at this point Qt Creator says there's no Qt installation found. I re-pointed it to the installation location (using Tools/Options) but it still won't run qmake or anything else for that matter...
I only need this linux install to compile and test my Qt projects which I am developing in OSX. So my question is, should I just wipe this RHEL install and start over? And if so, should I use something else like Ubuntu? I am having plenty of hassles that I don't want to deal with as is. Note, this project will require good OpenGL support.
Is there a particular reason that you don't simply use the Qt package that's part of RHEL?
If for some reason you need to build your own, you can get all of the build dependancies with:
$ yum install yum-utils
$ yum-builddep <whatever the qt package's name is>
#scotchi is right, and you should try to use the Qt package that comes with your system unless you need a very different version. I don't know what version of Qt comes with RHEL but if its not up-to-date enough for you (and it might not be, see below) then you could consider changing OS versions. I would only do this after trying his suggestion though, because you may be able to get things working without the hassle of a full OS install.
Now, as to why you might want to switch: RHEL is, as its name ("Enterprise Linux") indicates aimed at companies who want to run servers, or large deployments of desktops. It emphasizes stability and reliability over being cutting edge. Fairly often the version of the compiler and development libraries lag a little behind the curve. This is what their clients want: a stable platform they can develop against and run programs on for a period of time, not constantly needing to keep up with the latest changes, and thoroughly tested. But for people doing development at home it may not be necessary to stay that conservative. I don't know if this is for work, school or personal programming, but it sounds to me like you should move to one of the more desktop-oriented distros. Ubuntu is great, as is Fedora. If you prefer a RHEL-like environment, then choose Fedora.