this must have been answered a million times, yet I cannot find a suitable solution.
I have defined a free function in sensor.cpp:
std::string printTargetGasName(enalu::CombThreshold::TargetGas){}
Then I have declared the prototype of the function
in sensor.hpp
std::string printTargetGasName(enalu::CombThreshold::TargetGas);
Then I include sensor.hpp in core_enose.hpp and try to use the function in core_enose.cpp (enalu is just a namespace).
I get undefined reference linking error
core_enose.cpp:284: undefined reference to `enalu::printTargetGasName(enalu::CombThreshold::TargetGas)'
the linking instructions in the make file seem correct, i.e. the sensor.opp comes after the core_enose.opp:
g++ -g -Wall -Wextra -pedantic -std=c++11 [...] obj_dbg/core_enose.opp [...] obj_dbg/sensor.opp [...]
I also checked to see if the symbol correctly exists in the sensor.opp file:
$> nm obj_dbg/sensor.opp | grep printTarget
$> 000000000000cc9c T _Z18printTargetGasNameN5enalu13CombThreshold9TargetGasE
I have tried desperate late night measures as well, such as extern , or re including the sensor.hpp directly in the core_enose.cpp file. Nothing helps and at this point I am frustrated at the simple answer that eludes me.
Note that I am not providing code because sensor.?pp files are rather big containing a few classes that I have also been using in my program. What I describe above are the exact steps I followed to add this free function to an otherwise working application.
Could you help me?
Because your link error is about enalu::printTargetGasName, I suspect that you declared the function in your header within the enalu namespace, but the corresponding C++ doesn't have the namespace enclosure. This might fix you in the sensor.cpp file.
namespace enalu
{
std::string printTargetGasName(enalu::CombThreshold::TargetGas){}
};
Related
I'm trying to compile a CPP application (an open source project) in the latest cygwin64 environment using g++ 6.4.0 and I get the following error:
error: 'posix_memalign' was not declared in this scope
now posix_memlign can be found in stdlib.h if you compile the most simple CPP "hello world" application there wouldn't be a problem calling posix_memlign.
The make file of the project report the following setup for the compilation
g++ -DHAVE_CONFIG_H -I. -Wall -Wnon-virtual-dtor -I. -I./include -g -O3 -std=c++0x -g -O3 -std=c++0x -MT lib/rectangular_binary_matrix.lo -MD -MP -MF lib/.deps/rectangular_binary_matrix.Tpo -c lib/rectangular_binary_matrix.cc -DDLL_EXPORT -DPIC -o lib/.libs/rectangular_binary_matrix.o
so it doesn't look like it override the default include path. Any ideas?
p.s.
I was able to build the code on Linux (Redhat) without a problem.
posix_memalign is not part of the C Standard Library or the C++ Standard
library and the cygwin GCC compilers do not provide it, although other
compilers may do so, including GCC compilers from other builders.
You might consider using instead the C Standard function aligned_alloc, if you feel comfortable to edit your project source. It is provided in <cstdlib> for C++ compilation in cygwin g++ 6.4.0
Later
I do see the function in C:\cygwin64\usr\include\stdlib.h...
The fact that you can find the function declaration in the header file
does not mean that the compiler can see it after preprocessing. The same
source header may be used by many builders, exposing different
declarations to the compiler depending on the builder's settings of implementor
macros. In this case, the declaration is concealed from your compiler by
the fact that __POSIX_VISIBLE >= 200112 is false. Identifiers beginning __ are reserved for implementors.
See the explanation of this macro
and note the comment:
* The following private macros are used throughout the headers to control
* which symbols should be exposed. They are for internal use only, as
* indicated by the leading double underscore, and must never be used outside
* of these headers.
[SOLUTION FOUND]
Hello (I'm posting this on 2 threads regarding the same problem).
I'm here because I had the "POSIX_VISIBLE >= 200112" and the "posix_memalign was not declared in this scope" issue, which was halting the compilation of a program.
I'm not a programmer and tried various fixes on my own for a couple hours. Then finally Googled & came upon this site. The solutions here did not work for me, but I'll describe what did work:
The "posix_memalign" text was in a "stdlib.h" file that was being included into the code. The first problem was that in my "cygwin" directory, I have 25 instances of "stdlib.h"! Which one of those was being included?! I'm all new to this, but I finally found that
echo | gcc -E -Wp,-v -
might at least give an idea of which directory the files were being "included" from. This narrowed down the number of "stdlib.h" files to 4. Out of 4 such files, only one had the "posix_memalign" text. I tried changing the filename of that stdlib.h to see if it would cause an error--and confirm that it was the stdlib.h in question. However, this didn't effect the program. So I searched for a "stdlib.h" file in the next directory higher. THAT "stdlib.h" file also had the "POSIX" text in it. So when I changed THAT stdlib.h filename, the program DID error out. So that was the stdlib.h to deal with.
I saw that the "POSIX_VISIBLE >= 200112" instruction effected only the ONE line of code with "posix_memalign" in it. (In other words, the "POSIX_VISIBLE" instruction was not being used for the whole file.) I considered "commenting" it out, or deleting it. But then non-programmer me got the ingenious idea to simply change the ">=" to a "<". So I now had "POSIX_VISIBLE < 200112". I saved the file, ran the "configure" and "make" routine again, and boom, all was well. Program compiled properly.
Moral of the story, if you can determine the file (containing the POSIX statement and the posix_memalign) which is being accessed by your code, you may be able to solve your problem by just changing that one POSIX_VISIBLE operator as I did. (And you may want to switch that operator back after your compiling is done, in case that stdlib.h library file needs to be used by other programs in the future.)
I am doing an example drill in the textbook I am using to learn from. All I need to do is compile, link and run the following 3 files:
//file my.h
extern int foo;
void print_foo();
void print(int);
my.h is a simple header file that declares the two functions and a 'global' int foo, with no initial value.
//file my.cpp
#include "my.h"
#include "std_lib_facilities.h" //not included but not source of error
void print_foo()
{
cout << foo << endl;
}
void print(int i)
{
cout << i << endl;
}
my.cpp contains the implementation of the functions included from my.h. std_lib_facilities.h is a file from the textbook, and is not the source of error (according to g++). I can edit it into the body of the question if needed.
//file use.cpp
#include "my.h"
#include <iostream>
int main() {
foo = 7;
print_foo();
print(99)
char cc; cin >> cc;
return 0;
}
use.cpp serves as the main implementation file in this program, and tries to use all three declared & defined objects.
I took the two step command approach to build using g++. First, I compiled both .cpp files:
g++ -c my.cpp use.cpp
which created two object files, my.o and use.o. I used the following command to link them:
g++ -o myprog my.o use.o
giving me this error:
Undefined symbols for architecture x86_64:
"_foo", referenced from:
print_foo() in my.o
_main in use.o
(maybe you meant: __Z9print_foov)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I have tried putting
int foo;
into my.h instead of
extern int foo;
which gave me the same error.
I have tried using the
-std=c++11
flag as well which resulted in the same error.
I am using a MacBook Pro with the latest macOS (just updated in fact), if that helps with interpreting the error message.
I have tried to initialize foo, which didn't change anything.
In addition, I have tried updating the command line tools, same error.
From what I understand, the error is telling me that, even though my.h is included in both files, neither one can actually implement any function using the foo variable (which it calls _foo), despite it being explicitly declared in my.h. My guess is that the linker is using the wrong names under the hood, which make it impossible to link into an executable. This comes from the fact that the error mentioned a
__Z9print_foov
which exists nowhere in any of the files.
It almost seems like a g++ or macOS/Command Line Tools bug at this point. I don't want to add the declarations each time, because that creates duplicate symbol errors anyway. Putting my.cpp and use.cpp into one file would probably link properly, but I need to make sure that I can actually link multiple cpp files, because I will eventually (hopefully) be working with multiple cpp files that need to be linked. Any help is appreciated!
Here you declare a variable:
extern int foo;
and you use the variable:
cout << foo << endl;
but you did not define the variable anywhere. The linker error says that the linker could not find the variable's definition. To fix this, put int foo; at file scope in one of the .cpp files.
In the question you say that changing extern int foo; to int foo; gives the same error. However if you look more carefully at the error message I think you will find that it gives a different one, about multiple definitions.
I suggest to compile in two commands g++ -Wall -c my.cpp (that gives a my.o) and g++ -Wall -c use.cpp (giving use.o), then link a program with g++ my.o use.o -o myprog. Actually you should write a Makefile (see this for inspiration) and simply run make
Your translation units my.cpp and use.cpp are both declaring some extern int foo; variable which is never defined. So you need to define it in one single file (but not in others!), probably by adding (into my.cpp alone for example)
int foo;
(without the extern) or even with some explicit initial value e.g. int foo = 34;
This comes from the fact that the error mentioned a __Z9print_foov which exists nowhere
It is a mangled name, which is referenced (but not defined) in both object files (see also this).
It almost seems like a g++ or macOS/Command Line Tools bug at this point
You are very unlikely to find bugs in compiler tools (both GCC & Clang/LLVM are extremely well tested; since they are multi-million lines free software, they do have residual bugs, but you have more chances to win at the lottery than to be affected by a compiler bug). I'm coding since 1974, and it happened to me only once in my lifetime. A more realistic attitude is to be more humble, and question your own code (and knowledge) before suspecting the compiler or build chain.
BTW, always compile first with all warnings and debug info (e.g. g++ -Wall -g and perhaps also -Wextra). Use the gdb debugger. When you are convinced that your code has no bugs, you might benchmark it by asking the compiler to optimize (so use g++ -Wall -O2 perhaps also with -g to compile).
Read also the linker wikipage. Dive into your C++ textbook (see also this site and the C++11 standard, e.g. n3337 draft) to understand the difference between declaring and defining some variable or function. You generally declare a global extern variable in some common header (included in several translation units), and define it once somewhere else, but the good practice is to avoid having lots of global variables. See also C++17 new inline variables.
Believe me, I've been through several posts on here, but none of them addressed the issue I'm having. I have this 2-year-old program that used to run. I'm kind of reviving it, but for some reason now it does not run.
Clearly, I'm having multiple definitions (too many of them):
============================ TERMINAL OUTPUT =============================
build_files/LinkedStack.o: In function `LinkedStack':
/home/owner/workspace/opencv-galaxies/utilities/structures/LinkedStack.cpp:12: multiple definition of `LinkedStack::LinkedStack()'
build_files/LinkedStack.o:/home/owner/workspace/opencv-galaxies/utilities/structures/LinkedStack.cpp:12: first defined here
... and so on, and so forth, ... and it all ends with:
collect2: ld returned 1 exit status
make: *** [executables/Assignment3.out] Error 1
========================================================================
Strangely, the linker does not indicate any errors throughout the extensive list of warnings, not to mention that these aren't true multiple definitions. Note that each warning in a "multiple...-first defined... " pair refers to the same line. Now I don't know what to do.
I'm wondering if it has something to do with the rather busy syntax of our makefile (though it looks really good to me):
=============================== MAKEFILE =================================
CFLAGS = -g -Wno-deprecated
OBJECTS = utilities/basic/image.h build_files/image.o build_files/ReadImage.o build_files/ReadImageHeader.o build_files/WriteImage.o build_files/LinkedStack.o build_files/unsortedList.o build_files/region.o build_files/Main.o
executables/Assignment3.out: $(OBJECTS)
g++ $(OBJECTS) -o executables/Assignment3.out build_files/*.o $(CFLAGS) -lncurses
...
build_files/LinkedStack.o: utilities/structures/LinkedStack.h utilities/structures/LinkedStack.cpp
g++ -c $(CFLAGS) utilities/structures/LinkedStack.cpp -o build_files/LinkedStack.o
...
clean:
rm build_files/*.o executables/Assignment3.out
=========================================================================
So, these are my questions: 1) why did the linker see an error and 2) why am I having so many multiple definitions?
If you want a clarification, let me know even if you kind of have an idea of what's going on.
============================== CODE EXAMPLE ==============================
Here's the full example function (I don't want to make this too long):
//constructor
LinkedStack::LinkedStack()
{
topPtr = NULL; //set top pointer to null
}
========================================================================
Most likely you are including a header which implements methods non-inline in multiple translation units. The Makefile has nothing to with it. You'll need to find the definition of the methods and see how they end up being included into multiple files. If they are actually in a header file the easiest fix is probably to make them all inline.
The compiler doesn't see that you are including the header into multiple translation units as it always only processes one at a time. When the linker sees the various object files, it just see many definitions of the same thing and complains. I would have thought that the linker pointer at the location of the definition, though.
Given the info you provided, it is hard to even guess what the problem is. However, make sure that
a) you do not include any cpp file in another cpp/h file.
b) any implementation you define in h file, is inline-ed.
(I would guess b is your problem)
I'm trying to build a simple unit test executable, using cpputest. I've built the cpputest framework into a static library, and am now trying to link that into an executable. However, I'm tied into a fairly complicated Makefile setup, because of the related code.
This is my command line:
/usr/bin/qcc -V4.2.4,gcc_ntoarmle_acpp-ne -lang-c++ -O2 -g -g -o Application/UnitTests/Tests/symbols/UnitTestExe -Wl,--start-group Application/UnitTests/Tests/../.objs/main.o Application/UnitTests/lib/libcpputest.a -Wl,--end-group -lm
I'm getting many errors like the following:
Application/UnitTests/lib/libcpputest.a(CommandLineTestRunner.o): In function `CommandLineTestRunner::parseArguments(TestPlugin*)':
Application/UnitTests/cpputest/src/CppUTest/.objs/../CommandLineTestRunner.cpp:114: undefined reference to `operator new(unsigned int, char const*, int)'
I can't figure out what's causing this. Don't I get operator new for free with C++?
You probably need to link with the C++ support runtime library. This happens automatically when you invoke g++. On Linux, this is achieved by adding the -lstdc++ flag to the linker. You have to figure out how to do the same on your platform.
Maybe you're calling gcc, the C compiler instead of g++, which is the C++ compiler.
There's very little information in your question to work from, but it looks like some code uses some form of placement new, and while that special operator new is declared (the compiler finds it and compiles the code using it), the linker can't find its definition.
(Since this old answer of mine seems to still get attention: See here for an extensive discussion on declaration vs. definition.)
You need to rebuild your code from scratch, including the library. I got this error because I inadvertently copied object files compiled on another machine (with the rest of the source) to my machine. Most likely this disturbs the linking step since there are now two types of object files, native (for modified source files) and non-native (all others). I am guessing here, but the operator 'new' means slightly different things on different architectures and that's why you are getting this error.
p.s. I know this is way too late for a useful answer but I'm still posting this for the record.
For QNX 6.5.0 I have specified flag -lang-c++ for qcc (gcc) to avoid the error.
Like the original post, in my case this error happened while trying to link a software using CppUTest framework.
In my case, the source of the problem seems to be related to the fact I disabled the MEMORY_LEAK_DETECTION compile option of CppUTest. I enabled it again, which solved the problem.
Sometimes adding -lstdc++ is not enough. You should add it to the right place. For example I had list like this, not working:
target_link_libraries(cfr2 pthread m stdc++ "${CMAKE_SOURCE_DIR}/compressor/libcompressor.a" )
But this one works fine:
target_link_libraries(cfr2 pthread m "${CMAKE_SOURCE_DIR}/compressor/libcompressor.a" stdc++)
It'd be great if someone explained it in the comment section.
I'm getting these errors while linking, both messages have to do with the same object file.
CALL16 reloc at 0x5f8 not against global symbol
and
could not read symbols: Bad value
The 2nd message seems to be the reason I'm getting the CALL16 error, but the file compiles just fine.
Any tips on fixing this?
FYI, I'm cross compiling for a MIPS target and using gcc 4.1.2
EDIT: No luck so far:
Here are my flags used:
-fPIC,-Wl,-rpath,-Wl,-O1
I've also tried the following without success:
-mno-explicit-relocs
-mexplicit-relocs
-mlong-calls
-mno-long-calls
-mxgot
-mno-xgot
Meanwhile, I'll go back to the source at this point and investigate more.
Aha!
Thanks to a colleague of mine, we found the issue.
Here was the issue:
There was a forward declaration/prototype of a function.
void FooBarIsBest(void);
Later on in the file the function was defined.
static void FooBarIsBest(void)
{
// do the best
}
The issue here was that in the prototype the keyword static was left out. So it was like a whole new function was being defined.
The CALL16 reference is used by gcc for relocatable code. The assembly code of the file showed that CALL16 was being used on this function... Which is wrong, as this function is local.
Interestingly, this code used to compile & link just fine with an older version of gcc (3.2.2).
Another lessoned learned. :)
Try -mlong-calls flag to the compiler.
Also see the manual for more specific MIPS options.