I am trying to take the TRI DDS example code. It is all setup to build with MSVS2012 and comes with MSVS2012 proj/solution files.
However I want to try to build this using Cygwin and g++/gcc. I have got so far and then hit issues.
My cpp/h files are taken from their example - the user code is basic c++ but the generated files / RTI DDS files I think are causing an issue.
The basic source files are:
Hello.cpp
HelloPublisher.cpp/h
HelloSubscriber.cpp/h
HelloWorld.idl
RTI-DDS generator uses HelloWorld.idl to generate further files (.cxx/h files). I am not expecting to change any of the RTI-DDS files and the code within the 4 source files are fairly vanilla, so I can compile them if I hack out all the calls to RTI-DDS.
The area I want to focus on is the makefile / environment. Here are the pertinent parts of my makefile (note the linker parts are not complete because I have not got that far yet - the compile still fails):
note NDDSHOME = c:\Program Files\rti_connext_dds-5.3.0 as an env var.
# Setup minimal "un-polluted" paths to try to avoid any conflicts
makePaths=/usr/local/bin:/usr/bin:$(NDDSHOME)/bin
export PATH := $(makePaths)
#Include Paths
INCLUDES = -I. -I"$(NDDSHOME)/include" -I"$(NDDSHOME)/include/ndds" -I"$(NDDSHOME)/include/ndds/hpp"
#Compiler / options:
DEFINES = -DRTI_WIN32 -DRTI_STATIC -DWIN32 -D_WIN32_WINNT=_WIN32_WINNT_WIN7
CC = g++
CC_FLAGS = -std=c++11 -Wall -Wextra -lWS2_32
EXEC = run
# C++ files
SOURCES = $(wildcard *.cpp)
OBJECTS = $(SOURCES.cpp=.o)
# Main Target
$(EXEC): $(OBJECTS)
# Don't do linking yet - compile not working!
%.o: %.cpp
$(CC) $< -o $# -c $(DEFINES) $(CC_FLAGS) $(INCLUDES)
I know the INCLUDES paths are working because I get different errors when they are not (can't find...)
But the error I get at the moment is:
/usr/include/w32api/winsock2.h:1004:68: error: conflicting declaration of c function 'int gethostname(char*, int)'
:
:
/usr/include/sys/unistd.h:268:6 note: previous declration 'int gethostname(char *, size_t)'
note I have to copy this by hand from my other PC... so I have abbreviated the complete message.
I thought I was close to solving this by looking at other questions with similar errors, but I can't quite make the connection to fix this. I have tried adding other defines to specify the windows version, but that did not fix it. I know there is a linker option that we need to use for things like mingw that is what the -lws2_32 flag is set for - but I have not got to the linker stage yet :(
I guess either the unistd.h or the winsock2.h should not really both be included, but I can't quite figure out what define (or other) I need to add...
Any ideas?
Related
I am using Intel Pin to compile a C source and header file along with my c++ pintool. To do so I have added the following makefile rules in my makefile.rules file -
# Build the intermediate object file.
$(OBJDIR)testcpp$(OBJ_SUFFIX): testcpp.cpp
$(CXX) $(TOOL_CXXFLAGS_NOOPT) $(COMP_OBJ)$# $<
# Build the intermediate object file.
$(OBJDIR)test$(OBJ_SUFFIX): test.c test.h
$(CC) $(TOOL_CXXFLAGS) $(COMP_OBJ)$# $<
# Build the tool as a dll (shared object).
$(OBJDIR)testcpp$(PINTOOL_SUFFIX): $(OBJDIR)test$(OBJ_SUFFIX) test.h
$(LINKER) $(TOOL_LDFLAGS_NOOPT) $(LINK_EXE)$# $(^:%.h=) $(TOOL_LPATHS) $(TOOL_LIBS)
testcpp.cpp is my pintool in C++ , test.c and test.h are my C source and header files.
I am using the rules mentioned in this link - https://software.intel.com/sites/landingpage/pintool/docs/97438/Pin/html/index.html#MAKEFILES
I removed this option from the file makefile.unix.config -
TOOL_CXXFLAGS_NOOPT += -fno-rtti
as this option is specifically for C++ and C does not use it. Since I am compiling both of them using the same compiler options, removing the option seemed better than adding a new rule for C and C++
I am able to make my program using the command "make". It generated a directory obj-intel64 with the object files test.o and testcpp.so, so my compiling worked fine.
For executing my program I use the following command -
$PIN_ROOT/pin -t obj-intel64/testcpp.so -- my_application_program
I get the following output -
E: Unable to load obj-intel64/testcpp.so
The file testcpp.so is present in the obj-intel64 directory, yet I am unable to load it.
Any hints as to where I am going wrong?
What I'm trying to do is create a c++ file from an object file but I cannot figure out a way to do so.
INCLUDEDIR = ../headers
CXXFLAGS = -std=c++11 -I $(INCLUDEDIR) -Wall -Wfatal-errors -O2
all:primeFactors.o
primeFactors.o: primeFactors.cpp $(INCLUDEDIR)/primeFactors.h
g++ $(CXXFLAGS) -c $< -o $#
When I try to build this I get
make: *** No rule to make target 'primeFactors.cpp', needed by
'primeFactors.o'. Stop.
which I understand but when I take out the primeFactor.cpp argument I then get told there is nothing to be done with the make file. So is there a way to do this?
In general; no, you cannot do that. An object file (.o file) is the result of the code passing through the compiler front-end (to parse the language) the optimizer (to make it run fast) and the compiler back-end (to produce code that will run on your CPU).
This process is not reversible. You cannot go from compiled code back to source.
can you create a c++ file from an .o object file with makefile?
A makefile will allow you to do that only if you have an underlying tool to do it. make, which uses makefiles to do its job, does not have any built-in mechanisms to pull that off.
Your makefile has a rule for building primeFactors.o.
primeFactors.o: primeFactors.cpp $(INCLUDEDIR)/primeFactors.h
It says that primeFactors.cpp and $(INCLUDEDIR)/primeFactors.h are needed to build primeFactors.o. If you don't have those files, or no rules to build them, there is no way for make to build primeFactors.o.
I generated a makefile out of a codeblocks project (written in c++11), so I can use Atom as IDE. But it does not update the object files when I i.e. change the default constructors parameter in the header file, which is really annoying. It just links the existing object files again. But even if I make a little change to the .cpp file, it recompiles the object without recognizing the changes in the header file. The only quick fix I found is to delete the object file manually, so it really generates it completely new. The header part I currently often change looks like this:
VRParticles(): VRParticles(123){}
The whole makefile is available here (generated using cbp2make): https://github.com/Pfeil/polyvr/blob/master/Makefile
(Please note that I am just a fairly new contributor and not responsible for the way this is programmed ;) )
I use the makefile mostly with one of those two commands:
make -j 3 build_debug
make debug
Note that everything compiles fine when I delete VRParticles.o or do make clean and make debug.
Please note that my experience with makefiles is very low. The makefile basically works like this (remember the link to the full version above):
OBJ_DEBUG = # all object files
build_debug: before_debug out_debug after_debug
debug: before_build build_debug after_build
out_debug: before_debug $(OBJ_DEBUG) $(DEP_DEBUG)
$(LD) $(LIBDIR_DEBUG) -o $(OUT_DEBUG) $(OBJ_DEBUG) $(LDFLAGS_DEBUG) $(LIB_DEBUG)
$(OBJDIR_DEBUG)/src/addons/Bullet/Particles/VRParticles.o: src/addons/Bullet/Particles/VRParticles.cpp
$(CXX) $(CFLAGS_DEBUG) $(INC_DEBUG) -c src/addons/Bullet/Particles/VRParticles.cpp -o $(OBJDIR_DEBUG)/src/addons/Bullet/Particles/VRParticles.o
I'd really like give more information, but I have no idea what else could be important, so please ask if you need more. My question basically is how I need to modify the makefile (I guess this file contains the issue) so the object files get updated if needed. Without recompiling everything.
I'm on Linux (Ubuntu 14.04 LTS).
If we look at your dependencies for VRParticles.o:
VRParticles.o : src/addons/Bullet/Particles/VRParticles.cpp
You are telling make that the object file only depends on VRParticles.cpp. So when you update VRParticles.h, that doesn't matter - you never listed VRParticles.h as a dependency! Thankfully, gcc can generate those dependencies for you automatically:
$(CC) $(other flag stuff) -MP -MMD -MF $(#:.o=.d) -o $# -c $<
That will create a file VRParticles.d which will have make-style rules for dependencies, in this case something like:
VRParticles.o : VRParticles.d
So at that point, all we need is to include them:
DEPENDENCY_FILES = $(....)
-include $(DEPENDENCY_FILES)
I'm setting up Autotools for a large scientific code written primarily in C++, but also some CUDA. I've found an example for compiling & linking CUDA code to C code within Autotools, but I cannot duplicate that success with C++ code. I've heard that this is much easier with CMake, but we're committed to Autotools, unfortunately.
In our old hand-written Makefile, we simply use a make rule to compile 'cuda_kernels.cu' into 'cuda_kernels.o' using nvcc, and add cuda_kernels.o to the list of objects to be compiled into the final binary. Nice, simple, and it works.
The basic strategy with Autotools, on the other hand, seems to be to use Libtool to compile the .cu files into a 'libcudafiles.la', and then link the rest of the code against that library. However, this fails upon linking, with a whole bunch of "undefined reference to ..." statements coming from the linker. This seems like it might be a name-mangling issue with g++ vs. the nvcc compiler (which would explain why it works with C code), but I'm not sure what to do at this point.
All .cpp and .cu files are in the top/src directory, and all the compilation is done in the top/obj directory. Here's the relevant details of obj/Makefile.am:
cuda_kernals.cu.o:
$(NVCC) -gencode=arch=compute_20,code=sm_20 -o $# -c $<
libcudafiles_la_LINK= $(LIBTOOL) --mode=link $(CXX) -o $# $(CUDA_LDFLAGS) $(CUDA_LIBS)
noinst_LTLIBRARIES = libcudafiles.la
libcudafiles_la_SOURCES = ../src/cuda_kernels.cu
___bin_main_LDADD += libcudafiles.la
___bin_main_LDFLAGS += -static
For reference, the example which I managed to get working on our GPU cluster is available at clusterchimps.org.
Any help is appreciated!
libtool in conjunction with automake currently generates foo.lo (libtool-object metadata) files, the non-PIC (static) object foo.o, and the PIC object .libs/foo.o.
For consistent .lo files, I'd use a rule like:
.cu.lo:
$(LIBTOOL) --tag=CC --mode=compile $(NVCC) [options...] -c $<
I have no idea if, or how, -PIC flags are handled by nvcc. More options here. I don't know what calls you are making from the program, but are you forward declaring CUDA code with C linkage? e.g.,
extern "C" void cudamain (....);
It seems others have run up against the libtool problem. At worst, you might need a 'script' solution that mimics the .lo syntax and file locations, as described on the clusterchimps site.
I've been working on a c++ project for a while now, but would like to port it over to my arm processor. I already have all of my cross-compile tools (I'm using CodeSourcery) and thought I could just change my makefile to point to that compiler. It compiles fine using the default g++, but When try a make pointing to the cross-compiler I get relocation errors:
/home/oryan/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.2/../../../../arm-none-linux-gnueabi/bin/ld: ServerSocket.o: Relocations in generic ELF (EM: 3)
ServerSocket.o: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [simple_server] Error 1
It seems like I don't have a proper link set up or it's pointing to a wrong location. I'm not that familiar with makefiles and am probably missing something obvious. The makefile I've been using is from http://tldp.org/LDP/LG/issue74/tougher.html with the client side removed:
# Makefile for the socket programming example
#
simple_server_objects = ServerSocket.o Socket.o simple_server_main.o
all : simple_server
simple_server: $(simple_server_objects)
/home/matt/CodeSourcery/bin/arm-none-linux-gnueabi-g++ -o simple_server $(simple_server_objects)
Socket: Socket.cpp
ServerSocket: ServerSocket.cpp
simple_server_main: simple_server_main.cpp
clean:
rm -f *.o simple_server
Right now I am manually compiling each file and it works great, but I'd like to further my understanding here.
Thanks!
The problem is you've set your makefile up to link with the new g++ but you haven't changed the compiler you're using to build the objects in the first place.
The easiest way to fix this is to set environment CXX to the next compiler, i.e.
export CXX=/home/matt/CodeSourcery/bin/arm-none-linux-gnueabi-g++
or just set it for a given make by adding CXX=... to the command line.
You'll need to make clean first but you'll then use the correct compiler for both the compile and link.
You could also specify a new how-to-compile-C++ files rule in your makefile to specify the new compiler but the environment variable is easier:
.cc.o:
/home/.../g++ $(CPPFLAGS) $(CXXFLAGS) -c
The problem is because of these three rules:
Socket: Socket.cpp
ServerSocket: ServerSocket.cpp
simple_server_main: simple_server_main.cpp
First of all, the left-hand side of the rule should be the object file I guess, so should have the .o suffix.
The second problem, and most likely the root of your problem, is that there is no command to compile the source files, which means that make will use the default compiler and not your cross-compiler.