I am now trying to install mingw for a couple of hours, however I keep on getting the following error message:
"install: gcc-c++-4.8.1-4-mingw32-bin.tar.lzma
installing gcc-c++-4.8.1-4-mingw32-bin.tar.lzma
mingw-get-gui: * ERROR * unexpected end of archive reading header record"
and cannot find any solution to my problem. I tried to reinstall 7zip, because I thought it may caused from that. I am trying to install gcc on a 32-bit Windows 7. I would be really happy for any suggestions.
Bye!
Even though this is an old question, I will post an answer, in case other users come across this again.
I encountered the same problem:
at first I did not notice that something went wrong with the installation/upgrade itself, because the graphical update manager showed a line like "everything went successful" ...
if I had bothered to look into the log details, I would have seen the error messesage mingw-get-gui: * ERROR * unexpected end of archive reading header record and immediately known, that something went wrong (its really misleading, to show a dialog saying that a task was completed successfully when there were errors!).
But pertaining to your problem (or at least this was, what caused mine):
Cause
most likely something went wrong, when the mentioned archive file was downloaded. Unfortunately, mingw-get seems to ignore download errors and continues as if nothing went wrong... thus the error message archive header record is invalid, because it is not really an archive file, but a text file containing the HTML error message.
To complicate things further, mingw-get caches these files and when you try to re-install the packages it uses these invalid, cached files.
Solution
One way of fixing this, would be to delete the cached files and then re-install the package.
The cached files should be at
<mingw directory>\var\cache\mingw-get\packages
e.g.
C:\MinGW\var\cache\mingw-get\packages
Side Note: if you "lost" the error message like me, and don't know, for which packages there was an error, you can search the cache directory for files which contain the HTML error message, e.g. a search term like <html> should work; also these files are quite small, but there may also be other valid packages with small file size to this is no unambiguous criterion
If you continue to get error messages * ERROR * unexpected end of archive reading header record with the mingw-get tool you could also try to download the file manually and place it in the folder for the cached packages.
For re-installing the packages you could use the graphical interface of mingw-get (e.g. remove and then install the package) or, for example the command line version
mingw-get --reinstall install <package name>
for mingw packages the <package name> is usually just the prefix of the file name (before the first version number), e.g. for
libiconv-1.14-3-mingw32-dev.tar.lzma
the package name would be libiconv. For msys packages the package name usually has the prefix msys-, e.g. something like msys-libopts
(you should be able to see if it's a mingw or a msys package by looking at the part of the file name that comes after the first version number, e.g. for libiconv-1.14-3-mingw32-dev.tar.lzma: ...3-mingw32-de...)
Related
I need to install make command on windows, and I am told to follow the guide here: https://gist.github.com/evanwill/0207876c3243bbb6863e65ec5dc3f058#make, which is quoted as follows:
Go to ezwinports.
Download make-4.1-2-without-guile-w32-bin.zip (get the version without guile).
Extract zip.
Copy the contents to your Git\mingw64\ merging the folders, but do NOT overwrite/replace any existing files.
(Keep in mind you can easy add make, but it doesn't come packaged with all the standard UNIX build toolchain--so you will have to ensure those are installed and on your PATH, or you will encounter endless error messages.)
But after finishing those steps (extract zip and merging the folders), I run the make command and get a bash: make: command not found error.
I have added 'C:\Program Files\Git\mingw64\bin' to my PATH environment variable and have confirmed that file 'make.exe' exists in 'C:\Program Files\Git\mingw64\bin'.
I find one or two similar problems asked under the comments of the guide website, but they just haven't get answers;
and I also find some answers on stackOverFlow that says using choco install make instead, but I'm not sure if these two packages are the same.
Can you give me some suggestions to fix this?
I need to get the meta data, especially the iptc meta data from the uploaded files on the server.
I have found two packages I can import, but both of them require the "libiptcdata" libary. It should not be a problem, but after I installed the libary with brew, as it is written on both of the packages page, and typed go get "https://github.com/Melraidin/iptc" (for example, one of the two packages I wanted to use), I got the following error:
../../github.com/Melraidin/iptc/main.go:10:10: fatal error: libiptcdata/iptc-data.h: No such file or directory
#include <libiptcdata/iptc-data.h>
^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
The error is real, the file is really is not there, but how then it could work at anyone else? I found these 2 packages suggestion of using on a few page.
Thank you for your help
First, I have removed the brew installed "libiptcdata" libary, than installed the following libaries:
"libiptcdata0"
"libiptcdata0-dev"
"python-iptcdata"
with these three, the "go get" is managed to run, and could continue working on the original problem...
I'm cross-compiling ecasound, which goes well up to the point that all binaries get compiled, but fails during (at the end of?) the installation phase.
The thing is, I don't see any error message or anything, so I'm left guessing here:
ecasound: installs files in /home/buildroot/buildroot-2018.02-rc2/output/target//home/buildroot/buildroot-2018.02-rc2/output
make[1]: *** [/home/buildroot/buildroot-2018.02-rc2/output/build/ecasound-2.9.1/.stamp_target_installed] Error 1
make: *** [_all] Error 2
Full output: https://pastebin.com/ca6FJebB (hope this contains enough details)
Presumably the ecasound 'make install' returns (silently?) with an error. We don't have an ecasound package in upstream Buildroot, so it is hard to know what you are doing, but the install location (../output/target/home/buildroot/..) certainly looks wrong.
It did work after first doing a complete build, followed by ecasound seperately, indicating it was missing dependencies. Turned out the missing piece here was: BR2_PACKAGE_PYTHON_CURSES.
In case anyone wants to build ecasound for buildroot, a working package is available in my github account.. Not sure if it's clean code/by the book, but it works..
The problem is your install path somehow duplicated itself
/home/buildroot/.../target//home/buildroot/...
I have seen this several times too, and havent really found a way to fix it except to make clean & make again
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll
Windows XP, Erlang R13B02 (erts-5.7.3)
Today werl desn't want compile any erlang file
c(binm).
** exception error: undefined function compile:file/2
in function c:c/2
Yesterday all work.
P.S install R14B03, can't compile again
That is a very odd error. Have you by accident deleted the compile.beam file from your OTP installation? A re-installation of R13B02 might solve it, if you don't want to change the OTP version.
But if you don't need to use R13B02 for any particular reason, I recommend taking the opportunity to uninstall it and install the latest version (R14B03) instead (http://www.erlang.org/download.html). There have been many improvements, in particular regarding type specifications.
What does io:format("~p~n", [code:get_path()]). print? It should contain a directory like somepath/lib/compiler-4.7.2/ebin. Check that that directory actually exists, and that it contains the file compile.beam.