I have:
- OS: WIndows 7
- MinGW, gcc 4.8.0.
- MSYS 7.2
- Dowloaded log4cplus-1.1.1 from it's website .
./configure - done well.
But at "make" I receive error with message "undefined reference Mutex::Mutex(Mutex::type)". I searched for ctors for that class inside code, it can be found at:
log4cplus-1.1.1\include\log4cplus\thread\syncprims-pub-impl.h
log4cplus-1.1.1\include\log4cplus\thread\impl\syncprims-pthreads.h
log4cplus-1.1.1\include\log4cplus\thread\impl\syncprims-win32.h
But I don't know how to order comlier use any of them. I checked in MakeFile, they included as include files, I added to config.cxx define WIN32, that still don't work.
How to order my compiler compile log4cplus correctly?
Please try the patch attached to ticket #282. This should be fixed on 1.1.x branch already.
Related
So I just recently downloaded a C++ IDE called Code::Blocks and made a new project. But when I tried to Build and Run it, the code gave some errors. I know that it isn't a problem with syntax or anything like that because I ran the default code that Code::Blocks provided. The error is the following:
Project/Target: "firstcpp - Debug":
The compiler's setup (GNU GCC Compiler) is invalid, so Code::Blocks cannot find/run the compiler.
Probably the toolchain path within the compiler options is not setup correctly?!
Do you have a compiler installed?
Goto "Settings->Compiler...->Global compiler settings->GNU GCC Compiler->Toolchain executables" and fix the compiler's setup.
Tried to run compiler executable 'C:\MinGW/bin/gcc.exe', but failed!
Skipping...
Nothing to be done (all items are up-to-date).
It seems to me like there is some kind of issue with the C++ compiler, but I thought Code::Blocks already came with a C++ compiler, so I'm not too sure what the issue here. I also followed their instructions to go to Settings->Compiler...->Global compiler settings->GNU GCC Compiler->Toolchain executables, but I'm not too sure what they mean by fix the compiler. Here is a screenshot of what I'm seeing:
Also here's info on my PC if you need it:
At this point I'm not too sure what to do to fix this problem. I have asked my friends about this problem(they have already successfully downloaded and used Code::Blocks), and they said that they never encountered this problem while they were installing it.
You need to ensure that you have a working installation of the GNU Compiler Collection, and that the paths you select for your toolchain exist.
If you don't already have GCC Installed, the easiest way would be to download a Code::Blocks distribution that comes pre-bundled with MinGW from the download site. However, it's also possible for you to install GCC through other means, such as:
Installing GCC with MinGW through msys2, or
Installing GCC with scoop install gcc on Windows
In either case, you need to select the installation path that contains the bin directory when setting up the toolchain in Code::Blocks.
In case you didn't notice, C::B formed the path to compiler with both "\" back slashes and "/" slashes, which simply isn't a valid Windows path !!
Slashes are used in Linux not Windows! But for some reason C::B is not getting this. And probably your Mingw is well set !!
C:\MinGW/bin/gcc.exe should be C:\MinGW\bin\gcc.exe
I had pretty hard time trying to fix this in win 7 32 bit/C::B version 20.03 but with no success, i checked all available options and settings, and actually i started to think that it's a bug.
EDIT 1
This seems to be related to linking to the mono library, once I remove any kind of reference to mono code and remove the linking to the library from my CMakeList.txt file, debugging works as expected.
EDIT 2
Okay, I've discovered something interesting. This actually might not have anything to do with how I am linking libraries, it appears to be directly related to how I am initialising a class in my unit test. For whatever reason, if I use my normal syntax of TypeDeclaration variableName; the unit test fails immediately with the error code 0xc0000135, but if I change it to read TypeDeclaration variableName(); the code will run. Only problem is that I then get a warning stating empty parenthesis interpreted as a function declaration. I came from linux using g++ to compile my code and there was never an issue, now all of a sudden trying to compile on windows using cygwin or mingw means I can't use the normal standard c++ syntax to actually do work...
Edit 3
I've discovered that this issue is occurring because the libraries I am dependent on aren't actually being copied into the build directory of my unit test project. If I manually copy the required libraries into my build directory debugging works as expected, will need to learn how to express this requirement in CMakeList.txt
More Details
CLion Specifics
CLion 2018.3.1
Build #CL-183.4588.63, built on December 5, 2018
JRE: 1.8.0_152-release-1343-b16 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
Toolchain Settings
Cygwin 32 bit version 2.11.2
CMake version 3.13.1
Make version 4.2.1
gcc version 7.3.0
Debugger Cygwin GDB version 8.1.1
catch.hpp for unit testing.
Problem
When debugging a unit test, CLion reports the following error:
During startup program exited with code 0xc0000135.
Google returns a lot of Qt and netbeans related results, everyone suggests to add C:\mingw\bin to the system PATH variable. However I am not using mingw I am using cygwin. I tried adding C:\cygwin\bin to my PATH directory but that does not help. I also tried switching toolchain to use mingw to see if that would help. but the same problem occurs with debugging.
Not sure what else I can do to proceed in resolving this one, any ideas would be most welcome.
Hi anyone can help with dependency_info.dat No such file or directory? I'm using Xcode 7 with gcc 4.8
-dependency_info /path/my_project/build/my_project/Debug/my_project.build/Objects-normal/x86_64/my_project_dependency_info.dat
g++-4.8: error:/path/my_project/build/my_project/Debug/my_project.build/Objects-normal/x86_64/my_project_dependency_info.dat: No such file or directory
Command /usr/local/bin/g++-4.8 failed with exit code 1
what does -dependency_info flag do? How can I remove this flag?
The error went away after I deleted the path specified in Build Settings "Path to Linker Dependency Info File" for the project and the targets. So far the app is compiling and running fine without a specified path.
I had a very similar error with Xcode 7.2, OpenCV 3 and El Capitan.
In my case (and probably in yours as well), it's a linker error disguised as something else.
My project builds fine via terminal (because it already has a makefile that uses gcc), but no chance with XCode even after I configure everything in Build Settings pane according to the makefile.
This answer saved me. My OpenCV was installed using macports (it might have been precompiled binaries, or compiled on my machine, can't remember). It turns out that it's compiled with libc++ and not libstdc++.
Changing the C++ Standard Library setting accordingly in Build Settings did the trick for me.
For me it was trying to use a "/" in the app's display name that caused the build error
I cannot compile anything with the current version of emscripten from the ubuntu repos
Here is the error
http://pastebin.com/j5Z0ztTs
I suspect it might be because emscripten is outdated in the repos, but why is there no bug reports??
Could anyone help? I cannot find any updated information.
Thanks in advance.
The reason is because you are using the /usr/bin/clang++ that comes with your Linux distribution.
This version does not support Javascript backend. In order to use emscripten, you have to compile fastcomp (an LLVM clang compiler with Javascript backend added)
If you have not built fastcomp yet, Emscripten won't work.
Check out this page for installation instructions:
http://kripken.github.io/emscripten-site/docs/building_from_source/LLVM-Backend.html
If you have already built fastcomp, then the problem is in your emscriptenrc file, and moreover your PATH.
This is how I worked around the issue:
I created a file called emscriptenrc.sh that did this:
export PATH=/home/mike/emscripten/fastcomp/build/master/bin:/home/mike/emscripten/fastcomp/build/master/include:/home/mike/emscripten/fastcomp/build/master/lib:$PATH
then after I created that file
I rebuilt the ~/.emscripten configuration file by calling
./emcc -v from the emscripten build directory -- this seemed to get the right version of clang registered...
now you can go ahead and compile with emcc
I would suggest reading http://kripken.github.io/emscripten-site/docs/building_from_source/LLVM-Backend.html
as well as the rest of the documentation prior to trying to use emscripten.
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.