I'm working on a Ubuntu 16.04 and Netbeans 8.0.2
I deleted a source file and the corresponding header file, because I had no use for it anymore.
When I want to compile my code (clean + build), I get the following error:
make[2]: *** no rule to make target source_files/SolveODEwithAST.cpp“,
benötigt von „build/Debug/GNU-Linux-x86/source_files/SolveODEwithAST.o“, zu erstellen. Schluss.
-> My makefile is still looking for the deleted file.
I started to search in the makefile for the command to compile this deleted file:
I found the following:
in
Makefile-Release:
${OBJECTDIR}/source_files/SolveODEwithAST.o: source_files/SolveODEwithAST.cpp
${MKDIR} -p ${OBJECTDIR}/source_files
${RM} "$#.d"
$(COMPILE.cc) -O2 -MMD -MP -MF "$#.d" -o ${OBJECTDIR}/source_files/SolveODEwithAST.o source_files/SolveODEwithAST.cpp
and it is defined in the OBJECTFILES variable.
I deleted these lines of code, but the lines reappear after building the code.
So how can I change my makefile to make my code work again?
For all files in the projects /nbproject directory I searched for the deleted filenames.
$ls
configurations.xml Makefile-Debug.mk Makefile-impl.mk Makefile-Release.mk Makefile-variables.mk Package-Debug.bash Package-Release.bash private project.xml
It is important to delete the corresponding lines in the .xml files.
When I just delete the corresponding lines in the Makefiles, the lines reappear.
Related
So I was following one of the Makefile by example tutorials (cause I'm fairly fresh) and thats how I ended up here.
files = src/main.cpp src/compiler.cpp
all: $(files)
%.cpp:
echo $#
And this for some reason produces this
echo src/compiler.cpp
src/compiler.cpp
echo all.cpp
all.cpp
g++ -c -o all.o all.cpp
cc1plus: fatal error: all.cpp: No such file or directory
compilation terminated.
make: *** [<builtin>: all.o] Error 1
I don't see any refrences to g++ at all and for some reason it's getting called. The idea here was to use it to compile all my stuff from /src to .o files in /obj then produce a binary. Any ideas on how to do that or explanations on how to not call g++ without even referencing it in the makefile is highly appreciated.
It's being called because you have created a target all, and you haven't given make any recipe to build that target. So, make looks through its built-in rules and it sees that it knows how to build a program x given a prerequisite x.cpp. Well, make knows how to build a all.cpp, because you provided a rule that tells it how to build any .cpp file.
So first it runs the rule to build all.cpp, then it runs its built-in rule to build a target all from that all.cpp (which doesn't exist because your rule that told make how to build %.cpp doesn't actually create that target).
If you don't actually want to build a target all, then you should declare it to be a phony target:
.PHONY: all
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?
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?
When I compile the sources from just a directory it's OK. But if I do it from dmg image I got this:
$ make
"/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/i386-pokysdk-darwin/usr/bin/i586-poky-linux/i586-poky-linux-g++" -std=c++11 -Wall -O2 --sysroot="/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux" -c -MD main.cpp -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1 -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1/i586-poky-linux -o main.o
"/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/i386-pokysdk-darwin/usr/bin/i586-poky-linux/i586-poky-linux-g++" -std=c++11 -Wall -O2 --sysroot="/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux" main.o -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1 -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1/i586-poky-linux -lopencv_core -lopencv_highgui -lopencv_imgproc -lzmq -o aaa.bin
collect2: fatal error: cannot find 'ld'
compilation terminated.
make: *** [aaa] Error 1
After this error I unpack contents from *.dmg then run it and compilation completes successful.
Why and what I need to do to make it work from dmg?
My *.dmg contains an application and a cross-compiler. Source files for compilation are outside and created by this application. It is simple IDE.
Finaly I find out the cause of this problem. It is two bug-or-features one in macdeployqt and one in g++.
When I wrote my building script I thought it will be good to get dmg image in same directory from which I run my script. And I added a command with absolute path:
macdeployqt /Users/me/develop/macos_build_script/myApp/myApp_Release/myApp/myApp.app -dmg
The image was built and my app ran well. But. Silently macdeployqt made a name for dmg mount point from absolute path. The absolute path became a single directory name with colons instead slashes:
:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp. The root of dmg did not contain this directory, it only appears when dmg image is mounted.
Then this directory with colons will be part of variables of makefile.
Cross-compilator i586-poky-linux-g++ builds an object files when paths with colons present. And I thought it's all ok with g++ if it using this coloned paths for object files. I thought the cause somwhere in other place. But I was wrong.
Backslashing of colons din't help.
In some moment I builded the dmg image by hands from a directory in which myApp.app bundle subdirectory placed with this short command:
macdeployqt myApp.app -dmg
And the problem is gone. The mount point of dmg image now is just /Volumes/myApp. I do nothing except jump to dir where myApp.app is and making the relative path.
I am writing a code for MRI scanner where all calculation is being done on a Windows machine, while waveforms are being played using linux.
Inside my code, when I declare
#include <vector>
and try to compile it on linux, I start getting errors like this:
ccpentium: FLASH.cpp: No such file or directory
ccpentium: No input files
Any help would be appreciated.
More detailed error:
export PATH=z:/n4_fsp/tornado/i86/host/x86-win32/bin:C:/WINDOWS/system32:C:/WINDOWS:C:/WINDOWS/system32/Wbem; z:/n4_fsp/tornado/i86/host/x86-win32/bin/ccpentium.exe -O1 -Wall -DTOOL_FAMILY=gnu -DTOOL=gnu -ansi -DVXWORKS -DUNICODE -D_UNICODE -mcpu=pentium -march=pentium -fvolatile -nostdlib -fno-builtin -fno-defer-pop -DCPU=PENTIUM -malign-double -D_CONSOLE -DCEST_OffsetSeries -DBUILD_SEQU -DBUILD_CEST_OffsetSeries -Iz:/n4/pkg -Iz:/n4/tool -Iz:/n4_prod/i86/prod/include -Iz:/n4_deli_vb15a/i86/del
ivery/include -Iz:/n4/x86/prod/include -Iz:/n4/x86/delivery/include -Iz:/n4/pkg/MrServers/MrMPCUSystem/Tornado_i86/target/h -Iz:/n4_extsw/x86/extsw/include -o FLASH.oi86 -c FLASH.cpp
In file included from z:/n4_fsp/tornado/i86/host/x86-win32/lib/gcc-lib/i586-wrs-vxworks/2.9-PentiumIII-010221/include/syslimits.h:7,
from z:/n4_fsp/tornado/i86/host/x86-win32/lib/gcc-lib/i586-wrs-vxworks/2.9-PentiumIII-010221/include/limits.h:11,
from z:/n4_fsp/tornado/i86/host/x86-win32/include/g++-3/stl_algobase.h:49,
from z:/n4_fsp/tornado/i86/host/x86-win32/include/g++-3/algobase.h:36,
from z:/n4_fsp/tornado/i86/host/x86-win32/include/g++-3/vector.h:30,
from FLASH.cpp:33:
z:/n4_fsp/tornado/i86/host/x86-win32/lib/gcc-lib/i586-wrs-vxworks/2.9-PentiumIII-010221/include/limits.h:117:60: limits.h: No such file or directory
ccpentium: FLASH.cpp: No such file or directory
ccpentium: No input files
ccpentium: FLASH.cpp: No such file or directory
ccpentium: No input files
ccpentium: FLASH.cpp: No such file or directory
ccpentium: No input files
idea_make: *** [FLASH.oi86] Error 1
20:03:23 ERROR sde::fDos: <idea_make.exe --unix -f CEST_OffsetSeries.mk i86Release> failed with status=2
20:03:23 ERROR sde idea_make.exe --unix -f CEST_OffsetSeries.mk i86Release failed
20:03:23 INFO sde Copying \n4\i86\prod\lib\CEST_OffsetSeries.i86 to c:\Temp\CEST_OffsetSeries.i86
1 Datei(en) kopiert.
The error is caused by the combination of
-nostdlib
flag which asks the compiler not to use its standard linking environment and missing files from your include paths.
From very recent experience, I was missing two files from the include:
-Iz:/n4/pkg/MrServers/MrMPCUSystem/Tornado_i86/target/h
Eventually, I manually copied them from an updated version, but I do not know whether this is a bug or a 'feature' of the older version, so it still remains to be tested whether the compiled code does not break the scanner.