I am attempting to compile wxWidgets 2.8.11 on Windows 7 x64 for use with Code::Blocks, and I keep running into the same error.
I have MinGW installed as stated, and the proper things added to the path (c:\mingw\bin and c:\mingw\mingw32\bin).
I followed the instructions given here: http://wiki.codeblocks.org/index.php?title=Compiling_wxWidgets_2.8.6_to_develop_Code::Blocks_%28MSW%29
After cleaning, I attempt to compile, and get:
-DWXMAKINGDLL -Wno-ctor-dtor-privacy -MTgcc_mswudll\monodll_dummy.o -MFgcc_
ll\monodll_dummy.o.d -MD -MP ../../src/common/dummy.cpp, ...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make: *** [gcc_mswudll\monodll_dummy.o] Error 2
I tried getting rid of the gcc_mswudll folder, and it didn't help.
This is really frustrating.
Okay, I believe I solved my own problem.
I checked in the MinGW /bin, and fixed the wierd file renaming (removed the ~ from mingw32-make and mingw-get-0.dll).
For some reason, it now compiles partially, but then runs out of memory after allocating 25887232 bytes (I have 6 GB of memory, so I think it is a configuration issue).
Related
I am trying to install a program and when I run make or make -f Makefile (following the installation instructions) I get the following output:
g77 -O5 -Wall -c prep_output.f -o prep_output.o
dyld: Symbol not found: ___keymgr_global
Referenced from: /usr/local/bin/g77
Expected in: /usr/lib/libSystem.B.dylib
make: *** [prep_output.o] Abort trap: 6
I am working on a macOS Mojave 10.14.6. Following some other proposed solutions in similar problems, I've already installed Command line tools in my Xcode but that didn't do the trick. Any suggestions please??
Thanks in advance
EDIT:
I got rid of g77 and installed a compatible version of gcc (gcc8) through MacPorts. After running the make command I get the following:
g77 -O5 -Wall -c prep_output.f -o prep_output.o
make: g77: No such file or directory
make: *** [prep_output.o] Error 1
So I guess the program still needs the g77 setup? This is the program btw ([http://www.cfht.hawaii.edu/~arnouts/LEPHARE/install.html]). Is there a way to rely to the gfortran compiler for building the program?
Thanks in advance
P.S. I noticed that when I install g77 I get the following error:
x usr/local/: Can't set user=0/group=0 for usr/local`
`tar: Error exit delayed from previous errors.
However it still installs g77..
The error message indicates that your installation of g77 is broken. This has nothing to do with make or the particular project you're trying to build, except inasmuch as the project is trying to use g77 in the first place. That is a bit surprising, actually, since g77 has been obsolete for years (gfortran is the current GNU Fortran compiler), but I'm uncertain what exactly to expect from XCode in this area.
On the other hand, since the full path to the binary is /usr/local/bin/g77, I'm further inclined to think that you're not using XCode for this at all. Possibly you've dumped a g77 built on some other system into your /usr/local/bin, and it's not compatible with your Mojave system.
Your best bet is probably to
Get rid of your broken g77 installation.
Install Fink or MacPorts, or a similar project.
Install the Fink / MacPorts / whatever package for gfortran (maybe gcc-gfortran or similar in some of those) to get a working Fortran compiler.
Rely on that compiler to build your project.
I am compiling an app for 32bit machines since the creator of the app made it 64 bit. I made sure all the libraries and DLLs are 32bit, which they are. I have an issue when I compile, however. When I compile using sh make.sh, I get an error when it gets to the GCC building part. make.sh just makes sure that all the needed libraries are there for this project. There's no errors in the Makefile, make.sh, or any of the C++ files. I've been wasting hours trying to figure this out.
Here's a screenshot if it helps:
Needed to enable -D_WIN32 os flag in make.sh.
I am trying to cross-compile the Azure IoT SDK C for a Mips processor. Cross-compiling an older version of the same SDK using an older version of CMake (2.8.12.2) works just fine, so I doubt it's the code itself. I am guessing it's the Mips GCC compiler.
Error message:
CMake Error at /usr/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_2cc84/fast"
/usr/bin/make -f CMakeFiles/cmTC_2cc84.dir/build.make CMakeFiles/cmTC_2cc84.dir/build
make[1]: Entering directory '/home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o
/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc --sysroot=/usr/local/mipsisa32r2el/r23 -o CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o -c /home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_2cc84
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_2cc84.dir/link.txt --verbose=1
/usr/local/mipsisa32r2el/r23/bin/mipsisa32r2el-axis-linux-gnu-gcc --sysroot=/usr/local/mipsisa32r2el/r23 -rdynamic CMakeFiles/cmTC_2cc84.dir/testCCompiler.c.o -o cmTC_2cc84
/usr/local/mipsisa32r2el/r23/lib/gcc/mipsisa32r2el-axis-linux-gnu/4.7.2/../../../../mipsisa32r2el-axis-linux-gnu/bin/ld: this linker was not configured to use sysroots
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_2cc84.dir/build.make:97: recipe for target 'cmTC_2cc84' failed
make[1]: *** [cmTC_2cc84] Error 1
make[1]: Leaving directory '/home/axis/azure-iot-sdk-c/cmake/iotsdk_linux/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_2cc84/fast' failed
make: *** [cmTC_2cc84/fast] Error 2
Unfortunately, I am stuck with the Mips GCC compiler I have. Is there a way to disable this test-program check?
Solution was to add these to the toolchain-file:
SET (CMAKE_C_COMPILER_WORKS 1)
SET (CMAKE_CXX_COMPILER_WORKS 1)
CMake tries to compile an executable using "standard" (as per what CMake thinks is standard) compiler options and tries to run that executable, so to see if the compiler is working. The executable is simple like int main(int argc, char *argv[]) { return argc - 1; }.
You can't do that when cross-compiling. Because usually you can't link with a proper C standard library, you don't have printf, or _start or _exit or similar, passing arguments to main is implementation-defined, or you need a special linker script, or there's no emulator for your architecture, so can't run cross-compiled source on the host, etc... Simply: you usually can't run the cross-compiled executable on the host, and most of the time even the compilation is hard enough to do.
The common solution is to set before project():
set(CMAKE_TRY_COMPILE_TARGET_TYPE "STATIC_LIBRARY")
So that CMake will try to compile a static library not an executable, as explained in cmake docs CMAKE_TRY_COMPILE_TARGET_TYPE. This avoids running the linker and is intended for cross-compiling.
You can set CMAKE_C_COMPILER_WORKS and it will omit the check in CMakeTestCCompiler.cmake, but CMAKE_TRY_COMPILE_TARGET_TYPE is a more proper solution.
Well this problem is really annoying, i faced this issue for 2 day now I got solution.
Let me explain my issue first
When I delete NDK and Cmake from Sdk folder and Run my application then grable install NDK and Cmake again.
Only that time Application run and when try to run again i get this error The C Compiler is not able to compile a simple test program.
Before i was using ndkVersion "22.0.7026061" then change to thisndkVersion "21.1.6352462" and IT WORKED.
I think this is NDK problem and most of answer are outdated try this i hope this will HELP.
If using CMake GUI, you can add a boolean entry named
CMAKE_CXX_COMPILER_FORCED
then set it to True.
This will skip checking process for this build.
Ran into the same problem while re-compiling a project. Turned out that the compiler had been updated in the meantime.
After removing the build directory and creating it again, the compilation completed without errors.
I am using Windows 7 64-bit, and want to compile the non-precompiled libraries (specifically, I need Filesystem) from the command line (I do not use MSVC). I have MinGW, but read on the Boost website that MSYS shell is not supported, so I'm trying to compile the libraries from the Windows command prompt.
First of all, running bootstrap.bat results in the following error:
Building Boost.Jam build engine
'cl' is not recognized as an internal or external command,
operable program or batch file.
Failed to build Boost.Jam build engine.
Please consult bjam.log for furter diagnostics.
You can try to obtain a prebuilt binary from
http://sf.net/project/showfiles.php?group_id=7586&package_id=72941
Also, you can file an issue at http://svn.boost.org
Please attach bjam.log in that case.
Plus, there is not bjam.log file anywhere in the boost_root directory.
Disregarding this error, and trying to run the downloaded bjam.exe file, I get another error:
c:/boost_1_45_0/tools/build/v2/build\configure.jam:145: in builds-raw
*** argument error
* rule UPDATE_NOW ( targets * : log ? : ignore-minus-n ? )
* called with: ( <pbin.v2\libs\regex\build\gcc-mingw-4.5.2\debug\address-model64\architecture-x86>has_icu.exe : : ignore-minus-n : ignore-minus-q )
* extra argument ignore-minus-q
(builtin):see definition of rule 'UPDATE_NOW' being called
c:/boost_1_45_0/tools/build/v2/build\configure.jam:179: in configu
re.builds
c:/boost_1_45_0/tools/build/v2/build\configure.jam:216: in object(
check-target-builds-worker)#409.check
etc. with quite a lot of complaints. Setting the 'architecture' and 'address-model' options doesn't help.
Any suggestions?
#Andre
Following Andre's suggestion, I created minGW-bjam that was running for an hour and a half and built most of the libraries, but not the one I need at this moment: Filesystem.
Trying to compile only Filesystem, specifying version 2 with define="BOOST_FILESYSTEM_VERSION=2" and --disable-filesystem3 does not help. I get the following error:
gcc.compile.c++ bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o
In file included from ./boost/filesystem/v3/operations.hpp:24:0,
from libs\filesystem\v3\src\operations.cpp:48:
./boost/filesystem/v3/config.hpp:16:5: error: #error Compiling Filesystem version 3
file with BOOST_FILESYSTEM_VERSION defined != 3
libs\filesystem\v3\src\operations.cpp:647:26: warning:
'<unnamed>::create_symbolic_link_api' defined but not used
"g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -
DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_VERSION=2 -DBOOST_SYSTEM_DYN_LINK=1 -
I"." -c -o "bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o"
"libs\filesystem\v3\src\operations.cpp"
etc. with a lot of ...failed statements.
Any hints here?
It's easy. Just use "bootstrap.bat gcc" to select GCC
The bootstrap script assumes the msvc compiler is available. But you can build bjam by hand without the bootstrap script:
Step into the tools\build\v2\engine\src directory and call "build.bat mingw". It will create a bjam.exe. You can then put it in your %PATH% or perhaps in the root boost directory...
To be honest, I usually build bjam like this with the msvc compiler and use this "msvc-bjam" to build my mingw boost libraries.
So... the first part of the problem was solved by Andre's suggestion.
The second part was solved by setting the variable BOOST_FILESYSTEM_VERSION to 3 everywhere (the error above complains about incompatibility with what is set in file user.hpp). Although this is not the default option for Boost 1.45 that I'm using, it's the only thing that works (i.e. bjam wants to compile version 3 no matter what). So now I have version 3 of the filesystem library, and version 2 for all others, but that doesn't seem to be an issue for the moment.
I do have a problem with using Boost with OpenCV and Eigen libraries, though... off to the next challenge ;)
Since I can't comment yet, I want to add that I ran
bootstrap mingw
to generate b2 properly and then
b2 --build-dir="c:\boost_release" toolset=gcc --build-type=complete "c:\boost_release\stage"
The includes will be located at your boost root folder (boost_1_58_00/boost) and your binaries at the specified build folder.
I have a problem installing PL/Ruby for PostgreSQL 8.4 on Windows XP
PostgreSQL 8.4 is installed and working OK
Ruby-186-27 is installed and working OK
I have MinGW installed and I'm using MSYS as the command line shell
I have downloaded plruby-0.5.3 and unzipped.
My PostreSQL is in C:\Program Files\PostgreSQL\8.4
I've created a record in MSYS fstab file
c:/Progra~1/PostgreSQL/8.4 /usr/local/pgsql
I've tried calling the makefile as follows:
Running the following from the plruby-0.5.3 directory
ruby extconf.rb --with-pgsql-dir=/usr/local/pgsql
I've also tried running with
--with-pgsql-include=/usr/local/pgsql/include
--with-pgsql-include=/usr/local/pgsql/include/server
and also variations on the above i.e. using MSDOS Commands, using environment variables to pass file path, using MS DOS style directory names
The response I always get is:
have_header: checking for catalog/pg_proc.h... --------------------------- no
and then something like
"cl -nologo -E -I. -I"c:/Program Files/Ruby/lib/ruby/1.8/i386-mswin32" -I. -Ic:/Progra~1/PostgreSQL/8.4/include/server -MD -Zi -O2b2xg- -G6 conftest.c -P"
checked program was:
/* begin /
1. #include
/ end */
I'm getting pretty much the same output each time, I've checked and the pg_proc.h file is indeed in c:/Progra~1/PostgreSQL/8.4/include/server in sub-directory catalog
I've tried googling for an answer and it seems that quite a few people have had a problem with compiling Ruby shared libary on Windows in general with this type of issue, and others had issues creating PL/Ruby but I haven't found an answer anywhere on how to resolve this issue.
Thanks in advance for any help you may be able to give.
That looks like you're trying to run something based on autoconf using the MSVC compiler. Last I checked, that was not supported by autoconf. I think autoconf requires mingw and gcc, not MSVC.