With the following C code:
int main() {}
I compile under MSYS2 using gcc -o m2 m2.c . This gcc is the one installed by pacman -S gcc; version 4.9.2 target x86_64-pc-msys.
I copy m2.exe and msys-2.0.dll to a directory on another PC with a Cygwin installation. If I run m2.exe from a command prompt it executes correctly, however executing from a Cygwin Bash shell I get the error:
3 [main] m2 (4552) C:\Temp\m2.exe: *** fatal error - cygheap base mismatch detected - 0x180305408/0x180320400.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
The error message is puzzling as MSYS2 does not have any cygwin1.dll at all.
How do I fix this? Obviously I don't want to delete the Cygwin installation's cygwin1.dll .
The m2 executable does not have any dependencies other than msys-2.0.dll and built-in Windows DLLs. (I checked with Dependency Walker). It must be something about the binary built with MSYS2 GCC that is meant to search for msys-2.0.dll but instead finds the installed cygwin1.dll. Is there a workaround?
The output of ldd m2.exe is:
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffd12740000)
KERNEL32.DLL => /cygdrive/c/Windows/system32/KERNEL32.DLL (0x7ffd115f0000)
KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll (0x7ffd0f2b0000)
msys-2.0.dll => /c/Temp/msys-2.0.dll (0x180040000)
Related
I am installing a package (called CLASS, widely used in cosmology) which cannot be compiled with Apple's gcc.
I tried installing gcc by homebrew (gcc-9) and anaconda separately. But both of them could not find the standard C-library files such as stdio.h, math.h etc. I saw this problem very common in mac. I found the standard C-library files at /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/. Focusing on anaconda gcc (version 4.8.5), I then copied the files to /Users/satadru/anaconda2/include/. Now simple C-codes, such as a 'hello world' code runs fine. But when I tried to install the CLASS package, I get error arising from the problematic library files: stdio.h, math.h!! I get same error when I try to install the package using homebrew gcc-9 (after copying the library files to its concerned directory). I know that many people could run the package on catalina without any issue.
Now I have the following questions:
Are all standard C-library header files same? In other words, be it anaconda gcc 4.8.5, or gcc-9, the header files are same? Do the header files vary on different os, say linux or mac os?
Does anaconda gcc look for the header files at /Users/satadru/anaconda2/include/?
Before copying all the header files to /Users/satadru/anaconda2/include/, the directory had a few present there.
Why does not anaconda gcc installation place all of its own header files in this directory at the time of installation? Is it same when we do it on linux os?
How to solve my problem? I contacted the owner of the package and he says he himself runs the code on mac os catalina, but never faced this issue.
More information:
xcode-select --install
gives
xcode-select: error: command line tools are already installed, use "Software Update" to install updates
which gcc gives /Users/satadru/anaconda2/bin/gcc
gcc -v gives
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Users/satadru/anaconda2/bin/../libexec/gcc/x86_64-apple-darwin11.4.2/4.8.5/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure --prefix=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-gxx-include-dir=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/gcc/include/c++ --bindir=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/bin --datarootdir=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/share --libdir=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib --with-gmp=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-mpfr=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-mpc=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-isl=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-cloog=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-boot-ldflags='-Wl,-headerpad_max_install_names -Wl,-L/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib -Wl,-L/usr/lib' --with-stage1-ldflags='-Wl,-headerpad_max_install_names -Wl,-L/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib -Wl,-L/usr/lib' --enable-checking=release --with-tune=generic --disable-multilib
Thread model: posix
gcc version 4.8.5 (GCC)
I have a freebsd 8.4 machine. I want to use to use pyinstaller to create a binary for freebsd. However it looks like pyinstaller does not support freebsd by default so i have to go in the bootloader and create stuff specific to the target system.
This is giving me errors that gcc/cc is not found on the system. Here is the first error message
Platform : FreeBSD-64bit detected
Checking for 'gcc' (C compiler) : not found
Checking for 'clang' (C compiler) : not found
So then i try to install gcc via ports. I do this
cd /usr/ports/lang/gcc49
make install
It fails :
checking whether the C compiler works... no
So i checked in the file system and there is no gcc or clang or cc. It only has ccache. Here are the details from /usr/bin
CC -> /usr/local/bin/ccache
gcc -> /usr/local/bin/ccache
There is nothing in /usr/local/bin (either CC or GCC)
so if i just do gcc at the command line i get this :
ccache: FATAL: Could not find compiler "gcc" in PATH
how do i fix this. This thing is driving me nuts. pkg install is also not working with error "No repositories found "
On FreeBSD 8.4 the standard compiler is gcc (4.2), and it's located in /usr/bin. It has to be there.
It seems that ccache installation created some problem removing/overwriting something. ccache package installs compiler links in /usr/local/libexec/ccache, but if you installed it manually I'm not sure what happened.
FreeBSD 8.4 is not maintained anymore and there's no package repository anymore for it.
My suggestion is to update your system to FreeBSD 10.2 and use clang, that's the new standard compiler.
When I run
gcc test.c
in the terminal of msys,
I get the error
test.c:1:18: fatal error: x264.h: No such file or directory
#include <x264.h>
I can find the x264.h in /local/include
$ ls /local/include/
x264.h x264_config.h
Why MinGW gcc doesn't search the default place?
It's not a "default place" for MinGW GCC. The fact that you're calling native Win32 GCC from the MSYS shell does not mean it knows about these Unix paths MSYS conjures up.
Either install to the / directory or add your 3rd party library directory to the include paths on the commandline:
-I/local/include
Note the above only works from within the MSYS shell.
I just downloaded the latest versions of MinGW and Boost 1.54.0 (on Windows 7).
The first one installed smoothly (g++ 4.7.2).
When installing Boost, this is all I get:
boost_1_54_0> bootstrap.bat mingw
Building Boost.Build engine
The system cannot find the batch label specified - Test_Option
\CMake was unexpected at this time.
The compiler's path is set (from any directory, g++.exe --version returns 4.7.2).
Is there anything wrong in the way I specify MinGW?
I have installed the latest version of Cygwin, selecting the following packages during setup:
libgcc1
gcc
gcc-core
And created a file (test.c) with only this line:
#include <link.h>
Then ran the following from my Cygwin bash:
$ gcc test.c
... but got this error:
test.c:1:18: link.h: No such file or directory
Any ideas how I can fix it?
Cygwin is based on the Win32 subsystem, which means it uses Windows' executable format (COFF) and dynamic linker, i.e. it does not have an ELF dynamic linker. Hence providing the ELF-specific <link.h> would probably make little sense.