I can't compile google test which telling linker input unused (macOS) - c++

I have downloaded the google test with below command.
wget https://github.com/google/googletest/archive/release-1.8.0.zip
and I run the following command to install the libraries to my macOS 10.13.5
unzip release-1.8.0.zip
cd googletest-release-1.8.0
mkdir build
cd build
cmake ..
make
sudo make install
and i try to compile the test as below code with command g++ -c -std=c++11 -stdlib=libc++ -lgtest -lgtest_main -pthread -o cpptest test.cpp.
#include <iostream>
#include <gtest/gtest.h>
TEST(firstTest, abs)
{
EXPECT_EQ(1, abs( -1 ));
EXPECT_EQ(1, abs( 1 ));
}
int main(int argc, char **argv) {
std::cout << "Running main() from testmain.cc\n";
testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
but i get below warnings
clang: warning: -lgtest: 'linker' input unused [-Wunused-command-lin-argument]
clang: warning: -lgtest_main: 'linker' input unused [-Wunused-command-line-argument]
Does anyone can fix this problems?

g++ -c is used to compile a source file to an object file. This stage does not link an executable, i.e. it does not use linker, thus linker flags -lgtest -lgtest_main are not used. If you want to compile an executable the proper compand will be without -c:
g++ -std=c++11 -lgtest -lgtest_main -pthread -o cpptest test.cpp
Note, I have removed not required use of -stdlib.

Related

g++ - Python.h: No such file or directory

I'm trying to make a C++ script that will run some simple Python code:
// t.cpp
#include <Python.h>
int main(int argc, char* argv[])
{
Py_Initialize();
PyRun_SimpleString("print('TEST PASSED')");
Py_Finalize();
return 0;
}
Upon running g++ t.cpp, I get the error:
t.cpp:1:20: fatal error: Python.h: No such file or directory
compilation terminated
I've found many similar questions, all specific to an IDE or other development software, or were solved by installing python3-dev. The python3-dev package is already installed, and I even tried manually including the header when attempting to compile:
g++ t.cpp -I ~/.virtualenvs/MainEnv/include/python3.5m/Python.h
g++ t.cpp -I /usr/include/python3.5m/Python.h
Neither changes anything.
How can I fix this error?
UPDATE: I found that using g++ t.cpp -I /usr/include/python3.5/ seems to include the header, but then it runs into more errors:
t.cpp:(.text+0x10): undefined reference to `Py_Initialize'
t.cpp:(.text+0x1f): undefined reference to `PyRun_SimpleStringFlags'
t.cpp:(.text+0x24): undefined reference to `Py_Finalize'
collect2: error: ld returned 1 exit status
I've set up a similar example on my github
g++ t.cpp is missing a few things:
Tell g++ where the headers are for cpython (by -I/path/to/headers/)
Tell g++ to link against libpython (by -lpython3.5m)
You can also retrieve these flags with pkg-config
$ pkg-config python-3.5 --libs --cflags
-I/usr/include/python3.5m -I/usr/include/x86_64-linux-gnu/python3.5m -lpython3.5m
Your commandline should look something like g++ -I/usr/include/python3.5m t.cpp -lpython3.5m
#include <...> is for includes that come with the compiler.
Use #include "Python.h" for any other includes.
Run the following commands to compile your code:
mytest.cpp:
#include <Python.h>
int main(int argc, char* argv[])
{
Py_Initialize();
PyRun_SimpleString("print('TEST PASSED')");
Py_Finalize();
return 0;
}
Compile:
$ g++ mytest.cpp `pkg-config python3-embed --libs --cflags` -o mytest
$ ./mytest

How do I use Vulkan with MinGW? (R_X86_64_32 error)

I am trying to setup a bare bones program to use Vulkan. I installed the LunarG SDK. I have a tiny program that basically just calls vkCreateInstance. I compiled with this line:
g++ -std=c++11 -I/c/VulkanSDK/1.0.3.1/Include -L/c/VulkanSDK/1.0.3.1/Bin main.cpp -lvulkan-1
I get this compiler error using 64-bit mingw (MSYS2):
relocation truncated to fit||R_X86_64_32 against symbol `__imp_vkCreateInstance' defined in .idata$5 section in C:\VulkanSDK\1.0.3.1\Bin/vulkan-1.lib(vulkan-1.dll.b)|
What do I do? Am I linking against the right library?
I was able to compile a simple program, with just a call to vkCreateInstance with MinGW-64.
Maybe the error you're getting is related to the -m64 flag.
Follow bellow my configuration:
Windows 8.1
NetBeans IDE 8.1
Vulkan SDK 1.0.3.1
gcc version 5.3.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)
With g++:
Compile:
g++ -m64 -std=c++11 -c -g -I/C/VulkanSDK/1.0.3.1/Include -MMD -MP -MF "build/Debug/MinGW-Windows/main.o.d" -o build/Debug/MinGW-Windows/main.o main.c
Link:
g++ -m64 -std=c++11 -o dist/Debug/MinGW-Windows/vulkanfirsttest build/Debug/MinGW-Windows/main.o -L/C/VulkanSDK/1.0.3.1/Bin -lvulkan-1
With gcc:
Compile:
gcc -m64 -c -g -I/C/VulkanSDK/1.0.3.1/Include -std=c11 -MMD -MP -MF "build/Debug/MinGW-Windows/main.o.d" -o build/Debug/MinGW-Windows/main.o main.c
Link:
gcc -m64 -o dist/Debug/MinGW-Windows/vulkanfirsttest build/Debug/MinGW-Windows/main.o -L/C/VulkanSDK/1.0.3.1/Bin -lvulkan-1
Source code:
#include <stdio.h>
#include <stdlib.h>
#include <vulkan/vulkan.h>
int main(int argc, char *argv[]) {
VkInstanceCreateInfo vk_info;
VkInstance inst = 0;
VkResult res;
vk_info.sType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO;
vk_info.pNext = NULL;
vk_info.pApplicationInfo = NULL;
vk_info.enabledLayerCount = 0;
vk_info.ppEnabledLayerNames = NULL;
vk_info.enabledExtensionCount = 0;
vk_info.ppEnabledExtensionNames = NULL;
res = vkCreateInstance(&vk_info, NULL, &inst);
if (res != VK_SUCCESS) {
// Error!
printf("Error %d\n", res);
return 1;
};
printf("Device created: %p\n", inst);
vkDestroyInstance(inst, NULL);
return (EXIT_SUCCESS);
}
Output:
Device created: 0000000000534FD0
You guys were both more lucky than me, but then again, I was trying to build the cube example. I kept getting the relocation truncated problem and after some digging, managed to connect it to an old bug report/support request: https://sourceforge.net/p/mingw-w64/support-requests/19/
My solution was to use dlltool and extract the symbols from vulkan-1.dll (another old howto - http://www.mingw.org/wiki/createimportlibraries). This didn't work fully as it couldn't extract any symbols so I had to manually fill them in (luckily, gcc outputs 1 line per undefined symbol). Basically, here's the beginning of my vulkan-1.def file (append your functions, one per line to the end of it):
LIBRARY vulkan-1.dll
vkAllocateCommandBuffers
vkAllocateDescriptorSets
vkAllocateMemory
; add functions as needed, one per line
After preparing this file, run
dlltool -d vulkan-1.def -l libvulkan-1.a
Now you can use -L. -lvulkan-1 and avoid the relocation issues. My full gcc command line is:
gcc -g cube.c -o cube.exe -I /c/VulkanSDK/1.0.8.0/Include/ -D_WIN32 -DVK_USE_PLATFORM_WIN32_KHR -L . -lvulkan-1 -mwindows
And voila, cube works.
Note: I also needed to replace wcstombs_s to wcstombs for it to compile. The resulting line is now:
numConverted = wcstombs(argv[iii], commandLineArgs[iii], wideCharLen + 1);
Instead of using -lvulkan-1 or going through the trouble with ddltool, you can try explictly listing the vulkan-1.dll and it should resolve the symbols.
gcc -std=c99 -m64 -g -Wall -Ic:\VulkanSDK\1.0.39.1\Include\vulkan vktest.c -o vktest c:\Windows\System32\vulkan-1.dll
I was able to get it working with TDM-GCC 64-bit by copying vulkan-1.dll to the current directory, and linking it to that. The -m64 doesn't seem to be necessary, but if vulkan-1.dll is not in current working directory, ld.exe crashes.
CMake configuration:
...
FIND_PACKAGE(Vulkan REQUIRED)
IF(WIN32 AND NOT MSVC)
GET_FILENAME_COMPONENT(Vulkan_LIBRARY_DIR ${Vulkan_LIBRARY} DIRECTORY)
IF(NOT "${Vulkan_LIBRARY_DIR}" STREQUAL "${CMAKE_BINARY_DIR}")
MESSAGE(WARNING "If linking to Vulkan fails, try copying vulkan-1.dll to the ${CMAKE_BINARY_DIR} and then set Vulkan_LIBRARY to ${CMAKE_BINARY_DIR}/vulkan-1.dll")
ENDIF(NOT "${Vulkan_LIBRARY_DIR}" STREQUAL "${CMAKE_BINARY_DIR}")
ENDIF(WIN32 AND NOT MSVC)
TARGET_LINK_LIBRARIES(myprogram ${Vulkan_LIBRARY} ... )
...

undefined reference to `pthread_key_create' (linker error)

I have downloaded gtest 1.7.0 sources from here:
https://code.google.com/p/googletest/downloads/list
and build the gtest .a files (lib files) on ubuntu 13.10:
Linux ubuntu 3.11.0-15-generic #23-Ubuntu SMP Mon Dec 9 18:17:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
and the resulting lib is called: libgtest.a. In my main.cpp file Have:
#include <iostream>
#include "gtest/gtest.h"
int main(){
std::cout << "Test \n";
int argc = 2;
char* cp01;
char* cp02;
char* argv[] = {cp01, cp02};
testing::InitGoogleTest(&argc, argv);
return 0;
}
From a terminal I build with:
g++ main.cpp -I/home/user/gtest-1.7.0/include -L/home/user/gtest-1.7.0/lib/.libs -lpthread -lgtest
which gives the following errors:
/home/user/gtest-1.7.0/lib/.libs/libgtest.so: undefined reference to `pthread_key_create'
/home/user/gtest-1.7.0/lib/.libs/libgtest.so: undefined reference to `pthread_getspecific'
/home/user/gtest-1.7.0/lib/.libs/libgtest.so: undefined reference to `pthread_key_delete'
/home/user/gtest-1.7.0/lib/.libs/libgtest.so: undefined reference to `pthread_setspecific'
collect2: error: ld returned 1 exit status
Based on this:
error during making GTest
I have also tried -pthread instead of -lpthread but gives same error:
g++ main.cpp -I/home/user/gtest-1.7.0/include -L/home/user/gtest-1.7.0/lib/.libs -pthread -lgtest
EDIT: I have also tried to specifying -pthread as the last argument:
g++ main.cpp -I/home/user/gtest-1.7.0/include -L/home/user/gtest-1.7.0/lib/.libs -lgtest -pthread
same error
What am I doing wrong?
You need to specify -pthread after -lgtest. The linker takes libraries in order, and only takes as much as it needs to resolve references which are undefined at that point.
Nope, the problem is with Gtest's build.
If you build it using the standard configure approach, it isn't supplying the -lpthread correctly to create libgtest.so. Hence, when you try building a final shared library that actually uses the pthread capability it fails.
Instead, use the Cmake approach:
cd gtest-1.7.0
mkdir build
cd build
cmake -DBUILD_SHARED_LIBS=ON ..
make
And then manually install these into /usr/lib/
This version correctly links in libpthread into libgtest.
The option -lgtest is attempting to link the dynamic library libgtest.so. You
wish to link the static library /home/user/gtest-1.7.0/lib/.libs/libgtest.a.
Instead of:
g++ main.cpp -I/home/user/gtest-1.7.0/include -L/home/user/gtest-1.7.0/lib/.libs -lgtest -pthread
use:
g++ main.cpp -I/home/user/gtest-1.7.0/include /home/user/gtest-1.7.0/lib/.libs/libgtest.a -pthread
Note that your commandline supplies no name for the resulting executable, which will default
to a.out. If you want it called, e.g. mytest, then do:
g++ -o mytest main.cpp -I/home/user/gtest-1.7.0/include /home/user/gtest-1.7.0/lib/.libs/libgtest.a -pthread
Use -pthread instead of -lpthread (for linking with pthread-library), while you using gtest in your executable.
OR
Move the -lpthread after libgtest.a (sequence matters).
To answer we probably need more information, are you on a 64 bit machine and downloaded a 32 bit library?

Using exit() in c++

For one reason or another, I am messing around with the exit() function in c++. I am getting all kinds of strange errors from my mac running lion (64 bit). I am compiling using g++ -o -g -Wall.
Exhibit A:
#include <iostream>
int main(int arc, char *argv[]){
exit(1);
}
The Terminal output looks like this
$ g++ -o -g -Wall test main.cpp
ld: in test, can't link with a main executable for architecture x86_64
collect2: ld returned 1 exit status
but $ g++ -o test main.cpp compiles fine.
using #include<stdio.h> or #include<stdlib.h> result in the same compilation error.
I am just wondering if anyone might be able to see immediately what is going on here?
test is the name of the binary to produce, your first argument list should be:
> g++ -g -Wall -o test main.cpp
^^^^^^^ -o has test for an argument
-o is meant to be followed immediately by the name of the output file. It is probably trying to use your old binary 'test' as a source file, incorrectly.
Try this:
g++ -o test -g -Wall main.cpp

Embed python code in C++ (Windows + minGW + Python 2.7.2 + Eclipse)

I'm trying to embed python code in C++ (Windows 7 + minGW + Python 2.7.2 + Eclipse Indigo with CDT and PyDev).
So, this is the simple code:
#include <Python.h> //Python.h
#include <iostream> //iostream
using namespace std;
int main(int argc, char *argv[])
{
Py_Initialize();
PyRun_SimpleString("from time import time,ctime\n"
"print('Today is', ctime(time()))\n");
Py_Finalize();
return 0;
}
And I couldn't understant what am I doing wrong.
I include dirrctories C:\Python27\include and C:\Python27\libs but I can't build my project.
1) When I trying to build my project I got this error:
**** Internal Builder is used for build **** g++
-IC:\Python27\include -IC:\Python27\libs -O0 -g3 -Wall -c
-fmessage-length=0 -o main.o ..\main.cpp g++ -o testpy2.exe main.o
main.o: In function `main':
C:\Users\const\workspace\testpy2\Debug/../main.cpp:7: undefined
reference to `_imp__Py_Initialize'
C:\Users\const\workspace\testpy2\Debug/../main.cpp:9: undefined
reference to `_imp__PyRun_SimpleStringFlags'
C:\Users\const\workspace\testpy2\Debug/../main.cpp:10: undefined
reference to `_imp__Py_Finalize'
collect2: ld returned 1 exit status
Build error occurred, build is stopped Time consumed: 1507 ms.
2) And if I change current toolchain in Eclipse from "minGW" to "CrossGCC" .. I got this error:
**** Build of configuration Release for project testpy ****
make all Building file: ../main.cpp Invoking: Cross G++ Compiler g++
-I"C:\Python27\include" -I"C:\Python27\libs" -O3 -Wall -c
-fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o "main.o"
"../main.cpp" Finished building: ../main.cpp Building target:
testpy.exe Invoking: Cross G++ Linker g++ -o "testpy.exe" ./main.o
-l"C:/Python27/libs/libpython27.a" -l"C:/Python27/libs/python27.lib"
c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe:
cannot find -lC:/Python27/libs/libpython27.a
c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe:
cannot find -lC:/Python27/libs/python27.lib collect2: ld returned 1
exit status make: *** [testpy.exe] Error 1
**** Build Finished ****
Could anybody tell me what's wrong with my code or settings or something else?
Thank you
That is a linker error, not a compiler error. You need to link to the python. As you can see, with the "CrossGCC" toolchain you are almost there:
-lC:/Python27/libs/libpython27.a
You need to change this to
-LC:/Python27/libs -lpython