While helping my friend spin up MinGW and a C++ environment on his Windows 8 computer, I ran the get-mingw script and waited as it ran through all the mirrors for required downloads. However, three downloads completely failed:
libltdl - installer script hung and then moved on after pressing "OK"
automake-1.11 - installer script tried finding 1.10, then 1.9, then 1.8, then 1.7 (all of which failed) until finally settling on 1.6
mktemp - script hung and moved on after pressing "OK"
In all three cases, the script gave me a nice error log upon completion, showing that a majority of packages had been downloaded and installed except for these three, which showed up as errors. However during the installation process I had simply gone to the MinGW sourceforge page and manually found and downloaded each .bin.tar.lzma file that was missing.
Now that I have them, is there a good accepted way to unpack and plug them into my friend's existing MinGW install? In case it's tough, I'm comfortable with unix and dos command line so I'll be able to move executables into the MinGW/bin folder if that's what's needed, I just want to check for the best way to 'fix' the install.
As a side note - even though the error log says these are required packages, adding MinGW/bin/ to the PATH still allows for use of gcc and g++, although not make (possibly because of automake failure?). Is this standard behavior?
Firstly, the package issue can be fixed by using the MinGW installer - keep the packages selected and go to "apply changes" and the script will probably try to redownload the missing packages. I think the original problem was probably just a shoddy wifi connection during repository connection.
However, I then ran into a problem where I tried to run gcc and it gave me a missing -lpthread error ... but this question was able to help me fix that, and gcc and g++ are working fine now (haven't opened and tested Eclipse yet though). Just in case of link decay, the issue I cited arises from the MinGW installer script not downloading the lpthread library upon installation. To fix that issue, quoted from link:
Just run and open MinGW Installation Manager, which should be pre-installed with MinGW, select "All Packages" on the left panel, and on the right panel, search for "mingw32-pthreads-w32" packages and install them.
I think the Installation Manager has libpthread and pthread available for install, and pthread libs were the ones that seemed to solve it for me.
Related
I've successfully installed NetBeans 8.2 on my system. I've also installed MinGW and MSYS to make it compile C/C++ projects and it works flawlessly. The problem is that whenever I try to debug a program it gives me two errors:
Selected console type is not supported in your configuration, using
External terminal instead
and
GDB has unexpectedly stopped with return -1.073.741.701
and GDB is stuck loading until i press Cancel.
I noticed that if I go to C:\MinGW\bin\gdb.exe it says that the application cannot be started (Error code: 0xc00007b).
Maybe that's because I followed the official tutorial for installing MinGW and MSYS, but I wasn't able to install GDB correctly because point 15 says:
Unzip the gdb-7.0-2-mingw32-bin.tar.gz to your C:\MinGW directory so
that the gdb executable is installed into your C:\MinGW\bin directory.
but if I unzip the files, there are bin and share directories (which overlap with the existing ones), so I chose to cancel.
I could have found the issue, but I'm not sure. I ran Dependency Walker on gdb.exe and it reds out ZLIB1.DLL and KERNEL32.DLL. Do I need the 32-bit version of them? If so, where can I find the downloads?
Screenshot:
Not unzipping the files is almost definitely the problem. There is probably a dependency that doesn't, causing a runtime error.
Problem solved: as I mentioned in my edit, the problem was the 64-bit version of ZLIB1.dll, so I downloaded the 32-bit version and put it inside C:\MinGW\bin. Now everything works perfectly. Thanks to #bremen_matt for suggesting me that it was a dependency issue.
As title,
Build successful, but the exe can't run. can not found msvcr100.dll.
I can put msvcr100.dll with exe in the same dir, the exe can run.
But I just want only one exe file.
Anyone know how to do?
Has solved. This is a bug of pyinstaller3.2, the new in the git has solved this bug. Down the newest source in the github, erverything works fine.
Has solved. This is a bug of pyinstaller3.2, the new one in the git has solved this bug. Down the newest source in the GitHub, everything works fine.
This is correct, I cant tell you how much that answer helped me out. I have been trying to build a single exe Exploit to execute on Windows XP with-out it crashing for my OSCP Labs/Exam. I followed so many tutorials and nothing seems to work. I was able to build the EXE but could not get it to run under a single EXE.
If anyone who reads this is getting "This Program cannot be run in DOS mode" try running it from another machine with the same build (Windows XP). There is not much info out there on how to solve that from a Reverse Shell on a End Of Life Operating System using an EXE exploit built with Pyinstaller. (Lots of Trial and Error and determination)
Microsoft Visual C++ 2008 Redistributable Package (or some other version depending on python version) is needed in any case, python27.dll requires it
I was also receiving an error about msvcr100.dll when ran from the GUI on my build machine(WinXP SP2). This is corrected in the 3.3 Dev version on GitHub.
I installed the C++ 2008 Package but this didn't solve my problem when I re-built the EXE, the 3.3 Dev Pyinstaller was the solution.
What I did was:
Zip down the Dev version of Pyinstaller 3.3 Dev(GitHub) is the newest for 11/14/16 that I could tell. Make sure you have Python 2.7.x (I used 2.7.11) and pywin32 installed that matches (Python 2.7.x) version. (And it does matter if its 64-bit or 32-bit) Use the setup.py to install Pyinstaller, make sure you do not have a previous version already installed, if so use pip or etc. to remove. I installed with pip first and this was my whole issue.
I was able to get all of my 32-bit Single EXE Exploits to run on 64-bit/32-bit Windows machines up to Windows 10.
Once that is completed, make sure Pyinstaller is in your $PATH and follow the standard tutorials on creating a --onefile EXE. Copy to your Windows Target machine and it should work with-out error. I did not need to pull any dependencies over but you may have to include some with the --hidden command. Its greatly detailed in the Pyinstaller documentation on how to include hidden .dlls
If this still doesn't work for you try using py2exe. Its a little more complicated but it your determined you will figure it out.
If you have code written in python 2.x.x and 3.x.x you can have multiple environments of Python and have Pyinstaller installed in each. This is in the documentation as well.
Thank you jim ying. Your 2 sentence answer was exactly what I needed.
I have just started to learn C++ for school, and I'm trying to download the compiler MinGW to compile my source code. However, every time I try to compile a program an error message shows up saying that zlib1.dll is missing.
This is the error message
the program can't start because zlib1.dll is missing from your computer
I have tried installing/re-installing with no luck. I don't know what's the problem here?
Can anyone please help me with this problem as I have some homework that I need to do but I can't without the compiler.
Thanks.
I had this same problem, but fixed it like this:
I ran the MinGW Installation Manager (e.g. C:\MinGW\libexec\mingw-get\guimain.exe).
I navigated to All Packages -> MinGW -> MinGW Libraries.
I checked the boxes next to mingw32-libz (dev & dll).
I went to Installation -> Apply Changes.
Now everything worked properly.
From the MinGW getting started; an automated GUI installer assistant, or use mingw-get, is available (installed as "MinGW Installation Manager") and can be used to install additional libraries and manage dependencies. For the missing zlib libraries, add the mingw32-libz libraries as required.
It seems to have been an issue previously here on super user. It seems you may be able to get them directly from the zlib website. Open Babel has some info on it being required to be copied afterwards (together with some other dlls).
Alternatives include using the mingw-w64 distros from nuwen or mingw-builds. I've never had any issue getting these up and going. They also support x64 builds.
Had same problem here, I've just used mingw-get install mingw32-libzat the cmd and it worked.
When I try to compile a c++ program in my Mac terminal, I get the following error:
-bash: g++: command not found
but I believe I have all the files I need on my Mac to run the compiler. I have the Developer folder, which contains Xcode in Applications, g++ in the usr/bin folder, and a bunch of other folders.
How can I use these files to install the g++ compiler. Thank you!
Assuming you have the latest Xcode, go to Xcode Preferences, Downloads, and click on the Install button next to Command Line Tools. This should install and put everything into your PATH automatically.
houbysoft's answer above is correct, but the OP needs a little more detail.
The basic idea is that you need the "Command Line Tools" environment installed. But the name for that environment, and how you install it, has changed multiple times over the years. So, houbysoft's steps work for 4.3.3, but not for 3.2.6.
In the 3.2 era, the tools were called "UNIX Development". And, rather than being downloaded and installed from within Xcode, they came as part of the Xcode mpkg and were installed as part of the initial Xcode install. In most versions, there was a checkbox named "UNIX Development", usually checked by default, but in some versions it was a separate step. Looking at the "Xcode 3.2.6 and IOS SDK 4.3" disk image currently available from Apple, it's a checkbox. Anyway, that's the only officially-supported way to get them, but lots of other ways work… Here are your options:
Throw away Xcode 3.2.6 (just trash the whole /Developer) and install 4.3.3, then follow houbysoft's steps to get the Command Line Tools. Unless there's a good reason you can't use 4.3, this is almost certainly the best answer.
Throw away Xcode 3.2.6 and reinstall it, and this time make sure the "UNIX Development" checkbox is on.
Just re-run the 3.2.6 installer, and make sure the "UNIX Development" checkbox is on.
Log into developer.apple.com and look through the downloads for a package named "UNIX Development Tools", "Developer Tools CLI", "CLI Developer Environment", "Command Line Tools", or similar that corresponds to 3.2.6. There is such a package for most, but not all, versions of Xcode, and can be used to set up a command-line build environment either with or without Xcode.
Look at the invisible packages on the Xcode disk image. I don't remember whether you need just DeveloperToolsCLI.pkg, or that plus a few others, but a bit of trial and error or googling should get you there.
If everything is installed correctly, it sounds like all you need to do is get your "PATH" environment variable modified.
This closely related SuperUser question should provide the answers you need, at least if you're running under Snow Leopard. Here's another question about setting environment variables for Lion.
I'm trying to get eclipse to work with MinGW.
I've done the following:
Downloaded CDT for eclipse.
Installed MinGW.
Added C:\MinGW\bin to my path.
Opening a command prompt (CMD) and typing g++ or alike works fine.
I run eclipse, create a "New C++ Project", and only get the option saying "other toolchains".
There's a MILLION tutorials out there saying eclipse should identify MinGW on its own. It doesn't, and I don't know what to do. I've tried reinstalling everying in just about every order posible. Still no luck.
I've also noted some tutorials say something about creating a "Managed C++ Project". I've no such option, all I get is "C++ Project" and "C Project"
edit:
I have eclipse ganymede, windows x86_64, version 3.4.2
http://download.eclipse.org/eclipse/downloads/drops/R-3.4.2-200902111700/index.php
Running the "Eclipse IDE for C/C++ developers" fails, since there's no x64 version for windows. The x86 version requires x86 JAVA installed as well, and installing two versions of java, gave nothing but trouble in the past.
The instructions for setting up MinGW in Ganymede are located here.
The following are instructions and
links on how to install the current
version of MinGW. Note that these
links may become inaccurate over time
as new versions of MinGW components
are introduced. Please check the MinGW
File Release section for the latest
versions.
Download and run the MinGW setup program, MinGW-5.1.3.exe.
Select download and install the MinGW base tools and the g++ compiler.
You may select the Current or
Candidate version of these tools. You
may also install any of the other
available compilers as well.
Do not install the MinGW Make feature as the MSYS version of make
from step 5 is a more complete
implementation of make.
The MinGW setup program currently does not install the gdb
debugger. To install the debugger,
download the file from the following
location: gdb-6.6.tar.bz2
Extract the contents of the file gdb-6.6.tar.bz2 to the same location
where you installed MinGW.
If you want to use Makefile projects, download and run the setup
program from the following location:
MSYS-1.0.10.exe. MSYS provides an
implementation of make and related
command line tools. This is not
required for other types of projects
with the MinGW toolchain, which use
CDT's internal build tools to perform
the build.
Following this process resolved any problems I had.
I had the same exact problem with Eclipse Galileo and CDT 6.0.1. It turns out that CDT only recognized MinGW when it's located under c:\mingw. I had it in c:\msys\mingw so that was the problem. After I changed that everything worked fine.
The distinction between managed make projects and makefile project was removed in CDT 4.x, I think. Now there is only one type of project, but you can select different builders. CDT includes an internal builder which does not use makefiles and another one which does.
First, save yourself the effort of "reinstalling in every order possible". That is also known as trial-and-error, and will only make you more frustrated. Apply the normal problem-solving skills you have as a programmer.
Given that you have MinGW installed, what happens if you download "Eclipse IDE for C/C++ developers", start eclipse.exe, and try to create a C++-project with a MinGW toolchain?
EDIT: remember: the key in getting help with problems like these is to produce a minimal example which fails. Also, it would help if you provided URLs to the packages you installed (MinGW, Eclipse, etc.).
EDIT: I just installed CDT using the Ganymede update site, downloaded and installed MinGW from here, and restarted Eclipse, and everything worked fine. I know that doesn't help you, but it does prove that the toolchain detection isn't completely broken. Something is weird on your side.
You could try Wascana Desktop Developer. Its a distribution of Eclipse CDT configured specifically for developing on Windows.
I had the same problem (i.e. Eclipse not finding MinGW on the PATH) after I removed some of the unused files/folders from MinGW. It was ~600 MB and I was tasked to trim it down before adding to source control. I got it down to a workable ~200 MB. When I tried to re-create an Eclipse workspace afterwards, MinGW disappeared from available toolchains. It reappeared after I put the original MinGW install on the path.
HTH