Why do I get error message when using mingw32-make on Win10 cmd. here is my Makefile code
all: compile link
compile:
g++ -I src/include -c main.cpp
link:
g++ main.o -o main -L src/lib -l sfml-graphics -l sfml-window -l sfml-system
here is the output on cmd
D:\Devs\C++\T2>mingw32-make
g++ -I src/include -c main.cpp
mingw32-make: Interrupt/Exception caught (code = 0xc0000005, addr = 0x00007FF89CC5F398)
but if run it manually and individually it compiles properly?
D:\Devs\C++\T2>g++ -I src/include -c main.cpp
D:\Devs\C++\T2>g++ main.o -o main -L src/lib -l sfml-graphics -l sfml-window -l sfml-system
No error, and when I run the the main.exe file, the updated code applies.
For further information, here the libraries version I'm using:
D:\Devs\C++\T2>g++ --version
g++ (GCC) 4.8.3
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
D:\Devs\C++\T2>cmake --version
cmake version 3.20.3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
Any tips? Thank you.
0xc0000005 is an Access Violation. It's coming from mingw32-make. I had hoped it might be a configuration error, or you might be able to fix it simply by reinstalling. That appears not to be the case.
Look here or here.
The answer in both cases was related to the Windows %PATH% string. Specifically:
https://superuser.com/questions/375029/make-interrupt-exception-caught
this problem is apparently caused when the PATH variable contains
parentheses (, ), as it does on Win Vista/7. Unfortunately, the
available GNU for Windows is hopelessly outdated.
My problem was fixed by forcing make use the correct shell: insert the
following line at the beginning of your makefile.
SHELL=C:/Windows/System32/cmd.exe
Related
The applications I made with C++ sfml works on my own computer, but on my friends computers, it gives libstdc++-6.dll not found and ligcc_s_dw2-1.dll not found errors. I'm using visual studio code. I want applications to be opened on my friends computers without installing mingw to my friends computers, what can I do?
My makefile :
all: compile link run
compile:
g++ -I src/include -c main.cpp
link:
g++ main.o -o main -L src/lib -mwindows -l sfml-graphics -l sfml-window -l sfml-system -static-libgcc -static-libstdc++
run:
main
I have receive a makefile from another source. I am supposed to cross-compile on my machine (x86_64, GCC 5.3) it to use on an arm-embedded device (host). I tried to compile with a tool chain (arm_64, GCC7.5) which i installed in my /opt directory by making the following changes (those that are remarked out #) in the makefile of the project
#SYSROOT?=$(shell $(CXX) --print-sysroot)
SYSROOT= /opt/yocto/sysroots/
CXXFLAGS= -std=c++11 -I src/
CCFLAGS= -std=c++11 -I src/
#CXX_LDFLAGS= -L /usr/local/aarch64-linux/lib/ -lpthread -pthread
CXX_LDFLAGS= -L $(SYSROOT)/aarch64-yocto-linux/lib -lpthread -pthread
all: foo
foo: src/foo.cpp
$(CXX) -std=c++11 -g -o $# $^ $(CXX_LDFLAGS)
clean:
rm -rf .objs
However when the code was compiled, it could not be run on host device(arm) and there was warning during make that say along lines of skipping incompatible binaries.
I perform file on the compiled application. It read
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=99376bcc919a48224e063ec6c6892e1979b5d94e, not stripped
It is clear to me that I have compiled it with my native compiler,libraries etc.
What should i do in this case:
must i do the following before compilation or making the folder
./configure -build xxxxx -host yyyyyy
there is some files, called environment files (full of export settings) in the tool chain directory that seems to be like some configuration settings being exported. Should i use this file? or how should i use them
Regards
I followed the tutorial to connect to DolphinDB server with C++ and encounted this error message when compiling main.cpp:
$ g++ main.cpp -std=c++11 -DLINUX -DLOGGING_LEVEL_2 -O2 -I../include -lDolphinDBAPI -lssl -lpthread -luuid -L../bin -Wl,-rpath ../bin/ -o main
/usr/bin/ld: cannot find -lssl
collect2: error: ld returned 1 exit status
Note that my g++ version is above v6.2:
$ g++ --version
g++ (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
How to solve this error?
If you want to link against OpenSSL, you need to install the development package for OpenSSL, like this:
apt install libssl-dev
It may also be possible to drop the -lssl from the linker command line. (If there was a project dependency on OpenSSL, the build would not have gotten this far because the OpenSSL header files are missing, too.)
This question already has answers here:
Why does the order in which libraries are linked sometimes cause errors in GCC?
(9 answers)
Closed 6 years ago.
I am running ubuntu 16.04 with gcc.
My q.ccp file is
#include <my_messages.pb.h>
int main(int argc, char **argv)
{
google::protobuf::MyMessage* logged_msg_;
return 0;
}
command used for compilation:
g++ -m64 -Wl,-O1 -L/usr/lib/x86_64-linux-gnu /usr/local/lib/libprotobuf.a my_messages.pb.cc q.cpp -lpthread
protoc --version returns: 2.2.0
gcc --version
gcc (Ubuntu 4.8.5-4ubuntu2) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
compile error starts with
undefined reference to `google::protobuf::internal::ExtensionSet::Clear()
and gives undefined reference error for every function of protocol buffers.
Order of arguments to GCC matters a lot (libraries should go after object files and source files). You probably want
g++ -Wall -m64 -O1 -g -L/usr/lib/x86_64-linux-gnu -L/usr/local/lib/ \
my_messages.pb.cc q.cpp -lprotobuf -lpthread
(I would believe that -Wl,-O1 is wrong and useless, but I leave you to check that)
Take some time to read the GCC command options chapter of the documentation. You might want to (temporarily) use g++ -v instead of g++ in the command above to understand what is going on.
You probably should use GNU make for your build. See this example of Makefile for inspiration. Spend some time to read documentation of make.
Hi I am trying to use std::thread with G++. Here is my test code
#include <thread>
#include <iostream>
int main(int, char **){
std::thread tt([](){ std::cout<<"Thread!"<<std::endl; });
tt.join();
}
It compiles, but when I try to run it the result is:
terminate called after throwing an instance of 'std::system_error'
what(): Operation not permitted
Aborted
My compiler version:
$ g++ --version
g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
What is wrong with my test code?
UPDATE: I use the following command line to compile and run my code.
$ g++ -std=c++0x test.cpp
$ ./a.out
and I tried
$ g++ -std=c++0x -lpthread test.cpp
$ ./a.out
still the same.
I think on Linux pthread is used to implement std::thread so you need to specify the -pthread compiler option.
As this is a linking option, this compiler option need to be AFTER the source files:
$ g++ -std=c++0x test.cpp -pthread
In addition to using -std=c++0x and -pthread you must not use -static.
-std=c++11 -static -pthread -Wl,--whole-archive -lpthread -Wl,--no-whole-archive works together with -static!!!
See here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590#c4
Here's a simple CMake file for compiling a C++11 program that uses threads:
CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
list(APPEND CMAKE_CXX_FLAGS "-pthread -std=c++11 ${CMAKE_CXX_FLAGS}")
add_executable(main main.cpp)
One way of building it is:
mkdir -p build
cd build
cmake .. && make
Try compiling this way in single command:
g++ your_prog.cpp -o your_output_binary -lpthread -std=gnu++11
You can also try C++11 instead of gnu++11. Hope this works.