NetBeans interpret weird my code. In main function I have code:
SequenceAlignment align;
align.Alignment( local, seqs, argv[4], matrix)
But NetBeans show:
cpp:91: undefined reference to `SequenceAlignment::Alignment(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, char*, ScoreMatrix&)'
To be honest I do not know what to think. It works before, but now suddenly it doesn't.
This is a linker error indicating that the linker can't find an implementation for SequenceAlignment::Alignment. Check to see that you indeed have an implementation of this function and that the code containing that implementation is indeed being compiled and linked.
Related
Windows 10 Anniversary Update came out a couple of months ago, and I'm trying out the new "Bash on Ubuntu on Windows" feature.
I used it to compile some of my previous projects (finished on a normal Ubuntu machine), and while most of them were successfully built, a few of them received multiple undefined reference to ... (std::__cxx11::... errors when building the entire project (after compilations on separate files are done without errors).
I tried switching to g++-4.8, g++-4.9, g++-5.4 and g++-6.2 and all of them came down to the same result. I also tried adding compiler option -D_GLIBCXX_USE_CXX11_ABI=0/-D_GLIBCXX_USE_CXX11_ABI=1 in Makefile and still ended up with the same errors.
Here are parts of these error messages:
> building cirTest...
../../lib/libcmd.a(cmdCommon.o): In function `HistoryCmd::exec(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
cmdCommon.cpp:(.text+0xb3): undefined reference to `myStr2Int(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&)'
../../lib/libcmd.a(cmdCommon.o): In function `HelpCmd::exec(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
cmdCommon.cpp:(.text+0x91d): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)'
../../lib/libcmd.a(cmdCommon.o): In function `UsageCmd::exec(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
cmdCommon.cpp:(.text+0xd5c): undefined reference to `myStrNCmp(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)'
cmdCommon.cpp:(.text+0xdb9): undefined reference to `myStrNCmp(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)'
cmdCommon.cpp:(.text+0xe68): undefined reference to `myStrNCmp(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)'
../../lib/libcmd.a(cmdCommon.o): In function `QuitCmd::exec(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
cmdCommon.cpp:(.text+0x1190): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_first_not_of(char, unsigned long) const'
cmdCommon.cpp:(.text+0x126f): undefined reference to `myStrNCmp(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)'
cmdCommon.cpp:(.text+0x1320): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_assign(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
Since most of my projects did build successfully, I wonder if it's possible to solve the problem by toggling some settings without jumping to the conclusion that this is simply a result of "Bash on Ubuntu on Windows" still being a "beta" feature.
I am trying to follow the answer to my previous question and use boost::locale::conv::between to get a UTF-8 string from vector<char> containing UTF-16 data. My code is pretty much as in the answer (with some differences in how I get the char *:
char in[length + 1];
//... populate in with my source data
in[length] = '\0';
std::string out = boost::locale::conv::between((const char*)in, std::string("UTF-8"), std::string("UTF-16"));
This compiles fine, but during linking I get error
In function `boost::locale::conv::between(char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::locale::conv::method_type)':
/usr/local/include/boost/locale/encoding.hpp:186: undefined reference to `boost::locale::conv::between(char const*, char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::locale::conv::method_type)'
This doesn't look right to me. On possibility I could think of is that I had boost 1.50 installed, so I installed latest 1.55 release - yet I get the same error.
Boost locale is not a header-only library, it has an actual library that you need to link with.
Adding following flag to LDFLAGS helps:
-lboost_locale
I have encountered the same problem. I think you should use the dynamic library instead of the static library.
I have a project I am working on where I have some strange behavior with the std maps.
I had my own typedef map defined which mapped strings to a pointer of a custom type. The application crashed anytime that I excess the map after I add the first pair to the map.
After a lot of messing around I changed the map to a and moved it to the first call in my application and it still crashes. I have no idea what could be going on. Any help would be appreciated.
Here is the code that crashes at the moment.
LoggerPtr syslogger(Logger::getLogger("CISInterface"));
int main(int argc, char *argv[])
{
typedef std::map<string, string> MyMapDef;
MyMapDef tmpString;
tmpString.insert(MyMapDef::value_type("0000", "d"));
tmpString.insert(MyMapDef::value_type("1111", "d")); //Crashes here.
tmpString.insert(MyMapDef::value_type("2222", "d"));
// std::string configFile;
// int c;
// if(argc < 2)
// {
// //Must have c option
// std::cout << "Usage -c configFileName" << std::endl;
// exit(EXIT_FAILURE);
// }
//Rest of main commented out.
...
And here is the stack trace -
CISInterface Debug [C/C++ Application]
gdb/mi (10/31/12 6:02 PM) (Suspended)
Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)
6 std::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const() 0x00000032fd49c416
5 std::operator< <char, std::char_traits<char>, std::allocator<char> >() basic_string.h:2317 0x0000000000417ec7
4 std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::operator() stl_function.h:230 0x000000000041706f
3 std::_Rb_tree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_M_insert_unique() stl_tree.h:1170 0x0000000000415d00
2 std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::insert() stl_map.h:500 0x00000000004150eb
1 main() CISInterface.cpp:29 0x000000000041916d
gdb (10/31/12 6:02 PM)
/home/cillian/workspace/CISInterface/Debug/CISInterface (10/31/12 6:02 PM)
What other areas should I be looking at that could be causing problems. Could it be in the libraries that I'm linking with? I have created a second project with just these lines of code that links with the same libraries (but doesn't have any code that calls into them.) and it doesn't crash.
Problem solved.
Thought I'd add it here on the off chance anyone else ever does the same thing.
I slowly removed files in my project to try and find the offending file. I was thinking that it must be something defined in a header file that was causing issues (like a static). It took a long time but I think I've found it. I had a header file that defines a number of structs. These are serialized to the wire so I had them 1 byte aligned using #pragma pack (push) which I put at the top of the file and #pragma pack (pop) at the bottom. But I then added a couple of #include statements after the first #pragma definition meaning that these includes were aligned incorrectly and caused some nondeterministic behavior. Thanks everyone that had a look. Should probably use the attribute syntax and I wouldn't had the problem. Offending code is below for completeness.
#pragma pack (push)
#pragma pack (1)
#include <string> //Wrong place for includes!
#include <Units.h>
typedef struct
{
....
}
#pragma pack (pop)
Thanks to everyone who had a look at initial problem.
In my development environment, I'm compiling a code base using GNU C++ 3.4.6. Code is under development, and unfortunately crashes now and then. It's nice to be able to run the traceback through a demangler, and I use c++filt 3.4. The problem comes when functions have a number of STL parameters. Consider
My_callback::operator()(
Status&,
std::set<std::string> const&,
std::vector<My_parameter*> const&,
My_attribute_set const&,
std::vector<My_parameter_base*> const&,
std::vector<My_parameter> const&,
std::set<std::string> const&
)
{
// ...
}
When this function is in the traceback, the mangled output on my platform is:
(_ZN30My_callbackclER11StatusRKSt3setISsSt4lessISsESaISsEERKSt6vectorIP13My_parameterSaISB_EERK17My_attribute_setRKS9_IP18My_parameter_baseSaISK_EERKS9_ISA_SaISA_EES8_+0x76a) [0x13ffdaa]
c++filt kindly demangles it to
(My_callback::operator()(Status&, std::set<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::vector<My_parameter*, std::allocator<My_parameter*> > const&, My_attribute_set const&, std::vector<My_parameter_base*, std::allocator<My_parameter_base*> > const&, std::vector<My_parameter, std::allocator<My_parameter> > const&, std::set<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)+0x76a) [0x13ffdaa]
This is the same problem as compiler errors encountered when using templates. However, the STL is a fairly regular and recognizable package of templates. So what I'm hoping is that someone out there has created an enhanced version of c++filt which would dump something closer to the original function signature. Any hints?
STLFilt simplifies and/or reformats long-winded C++ error and warning messages, with a focus on STL-related diagnostics. The result renders many of even the most cryptic diagnostics comprehensible.
Maybe I should still be in bed. I woke up wanting to program. At any rate, now I'm getting some linker errors that I'm baffled over. What do you make of all this? I hope I'm not posting too much of it. I was going to post just a piece, but that didn't feel right. I checked some of the header files mentioned in the errors, but I didn't see Split anywhere. Oddly enough it started out named split, but I got similar errors to this.
/home/starlon/Projects/LCDControl/WidgetIcon.h:59: multiple definition of `LCD::Split(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)'
LCDControl.o:/home/starlon/Projects/LCDControl/WidgetIcon.h:59: first defined here
QtDisplay.o: In function `LCD::Split(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)':
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/new:101: multiple definition of `LCD::Split(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)'
LCDControl.o:/home/starlon/Projects/LCDControl/WidgetIcon.h:59: first defined here
DrvQt.o: In function `LCD::Split(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)':
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_deque.h:79: multiple definition of `LCD::Split(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)'
LCDControl.o:/home/starlon/Projects/LCDControl/WidgetIcon.h:59: first defined here
LCDText.o: In function `LCD::Split(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)':
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/new:101: multiple definition of `LCD::Split(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)'
LCDControl.o:/home/starlon/Projects/LCDControl/WidgetIcon.h:59: first defined here
Property.o: In function `LCD::Split(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)':
/usr/include/QtCore/qatomic_i386.h:125: multiple definition of `LCD::Split(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)'
LCDControl.o:/home/starlon/Projects/LCDControl/WidgetIcon.h:59: first defined here
moc_QtDisplay.o: In function `LCD::Split(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)':
/home/starlon/Projects/LCDControl/WidgetIcon.h:59: multiple definition of `LCD::Split(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char)'
LCDControl.o:/home/starlon/Projects/LCDControl/WidgetIcon.h:59: first defined here
Here's Split:
std::vector<std::string> Split(const std::string &s, char delim) {
std::vector<std::string> elems;
return elems; //Split(s, delim, elems);
}
A usual cause for multiple definitions errors like this is when you define the function in a header file without the inline keyword. Also, if the Split function you posted is from a LCD class the signature is missing the LCD:: part.
More than one object file is providing the implementation for LCD::Split. This is because the definition is in a header file.
Inlining, or making the function static, will restrict the visibility to each object file that uses it, and prevent clashes. However this will mean that each and every object file will contain the implemenation for that function if it's used. Furthemore, inlining will increase the amount of generated binary at every callsite. Making the function static, will create a single copy of LCD::Split for each object file.
The best solution is to put the implementation for LCD::Split, in its own source file, so that the implementation is present in a single object file after compilation.
Furthermore, you may want to ensure that your header contains an include guard, such as #pragma once, to prevent compile time conflicts for multiple declarations.