I have an application that gets built under MinGW. I have my source code under Git, but I ought to have my build environment under proper configuration management too, so that if I need to repeat a build from 6 months ago I can do it with the same versions of the compiler, libraries etc.
Is there any way of doing this? I've read up on "repeatable" builds, but that seems to be about running the build twice with the same versions of everything and getting a bitwise identical output, which is necessary for certain security properties. My problem is how to restore the version of MinGW files that I had at some point in the past.
The crude and primitive way would be to just archive a snapshot of C:\mingw every time I use pacman. But I'm hoping for something a bit smarter.
The standalone builds of MinGW-w64 from http://winlibs.com/, which can build for both Windows 32-bit and 64-bit, have no installation procedure. Just extract the download and you have a working build environment.
This even allows you to even have multiple versions of MinGW-w64 side by side.
Just make sure no other installed MinGW (like the one in C:\mingw) is in your PATH so the different versions don't get accidentally mixed up.
Related
While I am setting up MinGW-W64 (from sourceforge) exe file (for Windows 10) for C++, it shows a message that it was not downloaded correctly. My best guess is that I have a Anaconda/Jupyter setup having MinGW-W64, and it is making all the fuss. How to set it up for both C++ (VS Code / Code lite) and Python/Jupyter/Anaconda?
Make sure you don't mix versions in environment variables like PATH.
Maybe your download was bad?
Or you may have an antivirus software preventing the installation...
You could try a standalone MinGW-w64 build from https://winlibs.com/, which doesn't requite installation - just extract the archive and point VSCode to it.
I have installed the latest version of Eclipse on my Windows 7 64-bit machine and the mingw compiler. In setting up a Hello World project, all goes well until I am asked for the Cross Settings what the Prefix is and the Path. The Path is obvious, it's the path to the compiler. However, I haven't the slightest idea what the Prefix is and Googling for much of the day hasn't enlightened me other than finding that a lot of other people have asked the question. Unfortunately the answers I've found appear to be for specific hardware. All I want to do is to produce an executable that will run on a Windows 32 bit or 64 bit machine.
So, what is the Prefix and how do I find what it should be?
What is probably happening here is that CDT is not locating your MingW or GCC installations.
simple - but unlikely reason - covering bases
There can be many reasons, from the simple - but unlikely at this point:
You don't have mingw installed
You don't have GCC installed
This can be tested easily by starting a shell and running gcc --version.
CDT heuristic not working
To more complicated reasons relating to your installation not being detected because the heuristic in CDT did not work on your machine. To find the correct settings, CDT will do:
Check $MINGW_HOME/bin for existence
Check <Eclipse install location>/mingw/bin for existence
Look for mingw32-gcc.exe or x86_64-w64-mingw32-gcc.exe on the PATH
Check C:\MinGW for existence
If CDT cannot find any of the above, you may lead to the situation you are in.
So, how to fix it!
Option 1
Start Eclipse from within a mingw set up shell. i.e. the one you can successfully run gcc --version from. That way Eclipse will inherit an environment that can launch GCC successfully.
Option 2
Set your environment up so that MINGW_HOME is properly defined. You can do this at the system level or within the build settings in Eclipse CDT. For example, on my machine in the build settings for the project (Right-click on the project, choose Properties, then choose C/C++ -> Environment) I have set:
MINGW_HOME to C:\MinGW
MSYS_HOME to C:\MinGW\msys\1.0
PATH to ${MINGW_HOME}\bin;${MSYS_HOME}\bin;<my normal path>
and this allows Eclipse to launch gcc as part of the build process.
NOTE The above setting were done automatically on my machine because mingw was correctly located by the heuristic.
Here is a screenshot of the build settings if it helps:
Prefix: Under the hood
To try and answer part of your original question about what Prefix is, I provide the below information. It is unlikely to be particularly helpf
Prefix, in GCC parlance, refers to the directory under which all the related GCC files are placed. With different prefixes you can have multiple GCC installed on your machine.
From the GCC FAQ:
It may be desirable to install multiple versions of the compiler on
the same system. This can be done by using different prefix paths at
configure time and a few symlinks.
The concept comes from autotools in general. Autotools is the standard GNU make system (where you do ./configure && make - simplified). The prefix is the command line option to the configure stage (--prefix) to specify where to install the tool to. GCC above uses the --prefix to allow multiple GCCs on your system.
If you really want to know more about this, read the autobook. The section on configuring covers --prefix:
‘--prefix=prefix’
The –prefix option is one of the most frequently
used. If generated ‘Makefile’s choose to observe the argument you pass
with this option, it is possible to entirely relocate the
architecture-independent portion of a package when it is installed.
For example, when installing a package like Emacs, the following
command line will cause the Emacs Lisp files to be installed in
‘/opt/gnu/share’:
$ ./configure --prefix=/opt/gnu
It is important to stress that this behavior is dependent on the generated files making use of this
information. For developers writing these files, Automake simplifies
this process a great deal. Automake is introduced in Introducing GNU
Automake.
Additionally, Mingw takes advantage of all this prefix options. Read more about that on mingw's site. But the short of it is that the main prefix for mingw is /mingw.
usually I deploy my Java apps as a bundle which contains the JVM, so there's no need to install a JVM on the system.
Btw: This is no jnlp applet, this is a normal Swing Application.
I did this using ant's fx:deploy. This already works for 64bit systems.
My problem is, that I want to deploy this application to a 32bit system and don't get it to work.
Here's what I did:
I've set up a clean Windows 7 (32bit) instance and installed a 32bit JVM. Now i ran my ant script to build a bundled Java app and it built a App.exe.
But when I tried to start this exe by double clicking, I get the following message box
If I click OK, I get another message box
After this the app is terminated.
I did not find anything searching the web relating to bundling for 32/64 bit systems.
So I would be very glad if someone can point me in the right direction.
Many thanks in advance!
Greetings, -chris-
Looks like a known bug fixed for an upcoming JavaFX version (currently known as 2.2.40):
RT-25715 The Windows launcher generated by the packager fails to load msvcr100.dll on 32-bit OS
RT-22610 .exe created by fx:deploy can't be executed due to missing msvcr100.dll
On the bug case, the user mentions a work-around:
If I give a try to the workaround documented in RT-22610, which is to copy runtime\jre\bin\msvcr100.dll side to my application's launcher binary, it fixes it.
I think the bug is fixed in JDK 8, so another possible work-around is to download a JDK 8 early access release and use the packaging tools from there to package a Java 7 application (though I have never tried that and am not sure if it would work).
Just a small modification to #jewelsea's Fix:
copying msvcr100.dll into the app/ folder instead putting it right next to the exe also works, and at least it is somewhat hidden away then.
If you're generating an MSI you can hack the WXS file used by WIX to automatically copy msvcr100.dll into the app folder. Making FX Deploy verbose will tell you where it's putting the temporary WXS file you can copy and modify and use to override the WXS like you would the program icon for example.
Our VB6 application relies heavily on the use of scrrun.dll (Windows Scripting Host). Until a year ago we used to deploy this dll with our installer. Since the Windows Scripitng Host is supposed to be part of Windows we removed the dll from the installation package. However, now and then surface customers who have a non functional scrrun.dll on their system and we have to help them reinstall or reregister it.
So, should we put the scrrun.dll back in the installation package? Should we perform some check on installation? Or should we just live with the fact that we have to provide hands on support to some of our customers to set their systems right?
Don't try to deploy these libraries as part of a normal setup.
Microsoft Scripting Runtime must be installed through the use of a
self-extracting .exe file. For versions of Scripting Runtime mentioned
at the beginning of this article, the only way to distribute it is to
use the complete self extracting .exe file located at the following
locations...
It is possible that some users employ an older anti-malware suite, many of which tried to disable scripting. It is more likely though that some users have managed to break their Windows installation, either themselves or by using applications improperly packaged to try to include these libraries - and blindly remove them from the system on uninstall (cough, cough - Inno).
The libraries involved have been tailored code for some time. This is why the ancient .CAB file was "recalled" long ago. There is no single copy of them intended to run on any random version of Windows, and there are no redist packs for any modern version of Windows. The correct fix is a system restore or repair install.
While this can't be blamed directly on InnoSetup because it is the result of poorly authored scripts it is frustrating enough and common enough that I won't cry when its signature is added to anti-malware suites. There are just too many poorly written examples loose in the wild copy/pasted by too many people.
I spend plenty of time undoing the damage caused by uninstalls of these applications and have grown quite weary of it. Where possible I use isolated assemblies now in self-defense, which helps a lot. Windows File Protection is getting better about preventing abusive action for system files too.
But in general you are much better off avoiding any dependency on scripting tools in an application. There isn't very much that they can do as well as straight code anyway, though it may take some time to write alternative logic.
I've been using RCS (revision control system) from MKS Source Integrity for several old projects. I have to move to a new Windows 7 computer. The old version I have does not install on Windows 7, and a new version of the software is very expensive.
What is the best free or cheep source of RCS for Windows 7? Also, will it be compatible with MKS Toolkit which I am still going to install?
The official website for RCS has Windows 32-bit binaries, but they are dated. YMMV. http://www.cs.purdue.edu/homes/trinkle/RCS/.
Edit: I just tried the binaries (from the first zip file). They seem to work on a trivial text file.
I put them in a directory. Then I created an "RCS" directory. Then I created a text file. Then I ran "set TZ=EST" in my cmd.exe window (the tools require a timezone). Then I was able to check the text file in and out with the RCS command line tools.
Note that large files are probably not supported given the date of the binaries.
If you want the binaries to be available system wide, you have to place them in a location on your Windows PATH and set the TZ environmental variable to the zone you need in your account's environment.
RCS offers reverse merge which can be useful when you want to apply selected fixes for ECO version of your software without addition on less tested product enhancements. I was able to produce ECO version of real-time control system with several hundred fixes without the assistance of software engineers working on the next release of the product. ClearCase did not offer similar capability at the time.
We used rcs and gmake. Build scripts were written in Perl. Each ran on native Windows. I wish the idiots at the software company in Washington would use / instead of \ for file separator.
On Windows 7 64-bit SETUP32.EXE fails "not compatible with the version of Windows you're running"
My workaround:
Copy sintcm32.dll from a 32-bit machine into c:\windows\syswow64.
In Explorer, double-click a .pj file, set description to "MKS Source Integrity Project/Sandbox File" and target to "[network location]\mkssi\mkssi32.exe"
Create start menu shortcuts to "[network location]\mkssi\mkssi32.exe" etc.
Git (MSysGit) works on Windows 7 and is free. There is a learning curve associated with Git, which I think is worth it (for the benefits you get, especially regarding a distributed VCS), but some may disagree. This bundles come with bash and an ssh client (useful synchronization with remote repositories).
EDIT: For RCS specifically, there is an RCS package via Cygwin or an independent package from the Purdue RCS Homepage (the latter says "The latest PC (OS/2 DOS Win95 NT)", but I guess it might work on Windows 7, I'm fairly sure the Cygwin package works on Win 7).