I'm trying to compile a C++ app in xcode using gcc 4.0 and and the 10.4u SDK.
I get the following linker error.
"_stack_chk_fail", referenced from:
_read_frame_ in libAudioDecoder.a(stream_decoder.o)
_read_metadata_ in libAudioDecoder.a(stream_decoder.o)
"_stack_chk_guard", referenced from:
___stack_chk_guard$non_lazy_ptr in libAudioDecoder.a(stream_decoder.o)
(maybe you meant: ___stack_chk_guard$non_lazy_ptr)
ld: symbol(s) not found
Other help threads suggest that all I need to do is add...
-fno-stack-protector
...to the 'Other C Flags', which is what I've done, but the problem persists. I've done cleans, rebuilds and even restarted XCode (because it's been known to get confused sometimes), but the problem persists.
Note that libAudioDecoder is my own library that I'm trying to link with. stream_decoder.o is apart of the FLAC library which libAudioDecoder links to.
Essentially my project links with libAudioDecoder which links with libFlac, where libFlac has also been compile using an xcode project.
For each three xcode projects, I'm using gcc 4.0 and and the 10.4u SDK and have 'Other C Flags' and 'Other C++ Flags' set with -fno-stack-protector.
I'm all out of ideas at the moment, so would appreciate some help with this.
Cheers.
Symbol _stack_chk_fail is referenced from symbol _read_frame_ in your libAudioDecoder.a library, not the Xcode project from which you are linking against libAudioDecoder.a. Try to go back and rebuild libAudioDecoder.a with the -fno-stack-protector flag?
It sounds like you may have compiled the library linking against a newer version of libc and are now compiling with an older version, or some other mismatch like that. Searching for "_stack_chk_fail" on StackOverflow will lead you to a ton of other tips.
Related
I want to use some functions of boost::filesystem.
I can include boost/filesystem.hppand boost/filesystem/path.hpp without any problems, but as soon as I use some specific functions as boost::filesystem::current_path() or boost::filesystem::initial_path() I get the following compiler error:
Undefined symbols for architecture x86_64:
"_fchmodat", referenced from:
boost::filesystem::detail::permissions(boost::filesystem::path const&,
boost::filesystem::perms, boost::system::error_code*) in
libboost_filesystem.a(operations.o)
ld: symbol(s) not found for architecture x86_64
I am linking against -lboost-system and -lboost-filesystem and I'm using -std=c++0x as compiler tag.
The version of boost is 1.56.0 installed via homebrew.
Edit: I also tried it using boost 1.57.0 but the error is the same.
Update: This will be fixed in the upcoming Boost 1.60. My fix has already been committed to the Boost.Filesystem develop branch. You can also apply the patch to an earlier version of Boost.
Original answer:
This is a bug in Boost.Filesystem that is tracked as Boost Ticket #10591. I ran into the same problem and developed a patch which I attached to the bug.
It'd be great if you could apply the patch to your copy of the Boost.Filesystem sources and report whether it now works for you.
This looks like a Boost bug to me. There should be no difference between linking statically vs. dynamically against these libraries. Someone posted a fix here but without explaining what's going on.
Note that the problem persists in Boost 1.58, the current version as of this writing.
Obviously Qt Creator linked against libboost-system.a and libboost-filesystem.a. But on Mac OS X it should link against libboost-system.dylib and libboost-filesystem.dylib.
I changed this in the .pro-file by explicitly linking against the .dylib-libraries using LIBS += "path/libboost-system.dylib". This fixed the problem.
When I try to compile a test console application to test some functionality on a static library on the same workspace, i run into problems in the linking stage of the binary, it only happen when I choose to use libc++ standard library.
The missing symbols error is the follow :
Undefined symbols for architecture x86_64:
"std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::empty() const", referenced from:
libtorrent::torrent::replace_trackers(std::__1::vector<libtorrent::announce_entry, std::__1::allocator<libtorrent::announce_entry> > const&) in libLibOFFTorrent-xcode.a(torrent.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
When I choose stdlibc++ in both targets everything compiles ok and it runs OK.
my questions are :
there are some restriction on using libc++ on static libraries?
its a bug in apple/clang++ linker tool?
how can I configure the project to use libc++ with my static
libraries?
why the linker tool does not find the symbols of a standard c++
libraries on a static lib?, (any other lib that depends on is compiled against libc++)
should I forget the idea on using libc++?
notes:
the static library depends on libboost_system, witch i had compiled with libc++ and libstdc++ with the same results
when i run the test with the 'bjam' tool it runs OK, maybe the jam files chooses libstdc++ to compile the files.
I know that changing the standard library fix the linking problem , I only want to know why is that.
UPDATE: when I remove the reference to string::empty in the static lib project, the project that depends on compiles with libc++ fine and runs, but it gets in a infinite loop.
UPDATE 2: removing the string::empty references causes no effect when I compile the whole thing with libstdc++ it runs fine. no loops, this makes me think that is a bug or something like that.
UPDATE 3: when it compiles this is the place where the programs loops indefinitely :
It seems that one of your dependencies (libtorrent) has been built against libstdc++.
Check the namespace : std::__1::basic_string. It has the __1 prefix, usually indicating libstdc++).
I may be wrong but I think you need to rebuild your libtorrent against libc++ if you absolutely want to use this one.
Note that it is pretty common to use the stdlibc++.
Did you by any chance compile libtorrent with a -D_LIBCPP_INLINE_VISIBILITY=""?
The reason I ask is that std::string::empty() isn't in libc++.dylib because it is marked up with "always_inline". And so it should have been inlined into libtorrent when it was used.
An answer to this question made me realize that I need to add -lstdc++ to my "Other Linker Flags" to get my project to compile.
If I compile my code directly into my project, it runs fine. If I build it into a framework and include that framework, it complains:
Undefined symbols for architecture armv7:
"std::terminate()", referenced from: ...
Adding -lstdc++ seems to solve the problem. It's great that it works, but can someone help me understand why I only see this issue when treating my code as framework?
Jerry Coffin's comment was the helpful answer. The compiler was detecting the .mm extension and switching to Obj-C++ for the framework build, but had no indication that the build including the framework should also be compiled this way.
I'm running on a Mac Mini, late 2012 (The latest), 64 bit, Intel Core i7 2.3 gHz HyperThreading x86_64, or so says my computer. I'm also using Code::blocks for the time being because help in Xcode (which I would prefer) is even more sparse because I am using C++. That said, programming language of choice is C++, and will eventually expand into Objective-C++, but that's for another day.
The problem is this: I am trying to compile a program that will do I'm not quite sure what yet (it's a template, let's just say it's a game for now.) using SDL 1.2.15, which I have compiled from source on my Mac. (I did try using SDLmain.m and SDL.h, but that was full of Objective-C code, and as I could find no good information on whether I could code in C++ with these on the internet, I gave up.) The source I compiled seems to work just fine, Code::Blocks can compile it's tutorial just fine and it runs ok. However, I cannot seem to get my game template to work. It compiles fine, with no errors or warnings, but the linker does not do the same. Now, I'm really not sure what ld does, I just know that it links together code. (Anyone want to elaborate on that?) When Code::Blocks gets to it's linking step it fails with this message:
-------------- Clean: Debug in PyroLauncher ---------------
Cleaned "PyroLauncher - Debug"
-------------- Build: Debug in PyroLauncher ---------------
Compiling: App.cpp
Compiling: OnCleanup.cpp
Compiling: OnEvent.cpp
Compiling: OnInit.cpp
Compiling: OnLoop.cpp
Compiling: OnRender.cpp
Linking console executable: bin/Debug/PyroLauncher
Undefined symbols for architecture x86_64:
"_SDL_GetError", referenced from:
App::OnInit() in OnInit.o
"_SDL_Init", referenced from:
App::OnInit() in OnInit.o
"_SDL_PollEvent", referenced from:
App::OnExecute() in App.o
"_SDL_Quit", referenced from:
App::OnCleanup() in OnCleanup.o
"_SDL_SetVideoMode", referenced from:
App::OnInit() in OnInit.o
"_main", referenced from:
start in crt1.10.6.o
(maybe you meant: _SDL_main)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
Which has me seriously confused. I just know that ld can't find for my native architecture x86_64. If anyone can help me, it would be greatly appreciated.
What I think the solutions may be: (I don't know how to do them, however.)
SDL is not compiled for 64 bit, and therefore cannot be compiled against with 64 bit code.
SDL is compiled for Objective-C, and therefore cannot be used with code in C++.
My code is 32 bit, SDL is 64 bit, and they are not compatible.
Do you understand what is happening here? Your code is calling functions which the linker (ld) can't find.
The two main probabilities are that you either need to include some more files in your project, or that you need to define some macros.
Search through the project for the definition of SDL_GetError() (and the others). If you don't find it, then you need to find the file which declares it and include that.
If you do find it, then it will probably be surrounded by #ifdef XXXX and you will have to define xxxx in your project options (not in your code). Most good IDEs (I use NetBeans, with Cygwin for C+ development) will grey out the then contents of an ifdef if it isn't defined, so you can imemdiately see if that is the case.
Btw, have a look around the SDL website for installation instructions. Alternatively, your download might have a file called "Install" or "Install.txt", and may also have a Makefile. If it does, then in your IDE look for an option Project/New ... from existing makefile.
Hope this helps.
You need to add the files SDLMain.m and SDLMain.h to your project. The SDLMain files contain glue code so SDL code can run on Mac OS X. You also need to link the Cocoa framework to your project. The Mac version of SDL is written in Cocoa so you need to link to Cocoa. Linking the Cocoa framework does not force you to use Objective-C. You can write your game in C++.
If you're looking for information on setting up SDL with Xcode 4, read the following article:
Using SDL with Xcode 4
this question has gone back and forth a bit as I have learnt some things about g++ about unix systems (sorry if I messed anyone about).
For a project I am currently trying to finish I would like to get twitcurl running with Xcode and OpenFrameworks. If anyone has managed to do this please share with me this arcane feat.
Below is some of the things I am stuck on:
Regurgitating some of the instructions from their wiki it says to
download the libraries source
build twitcurl library using visual C++ or make (their is also cmake in their).
Include twitcurl.h and curl headers in your twitter application and link to twitcurl.lib and libcurl.lib/libcurl.dll.
This seems simple enough but when I make the library, there is no twitcurl.lib. A different file libtwit.a is produced, which I assume must be what OSX needs (as installing puts it in usr/local/ along with the headers). However then if I try to include the twitcurl.h in a header and make a twitCurl object I then get more undefined symbols
Undefined symbols for architecture i386:
"twitCurl::~twitCurl()", referenced from:
testApp::setup() in testApp.o
"twitCurl::twitCurl()", referenced from:
testApp::setup() in testApp.o
ld: symbol(s) not found for architecture i386
I now am assuming twitcurl makes for a 64bit (I have tried adding CFLAGS=-m32, but it fails), and to my knowledge Openframeworks is only 32 bit currently. This means twitcurl may not be an option for me, but again, if anyone knows how please let me know!
Thanks in advance.
You'd probably do well to recompile twitcurl, last I looked (3 months ago), it was compiled with VC6, which has its own way of mangling C++ symbols, so the lib won't link correctly for g++.
you could then just import it directly as well and then not need to worry about linking to the libs, however it would be a good idea to test in a small demo app, before integrating into an already build system, that way you know if the error is on your side or somewhere else.
Also, when it comes to this type of problem, the exact compiler errors are more helpful than just describing the problem.
The error message you've posted is the linker's longwinded way of telling you that its looking for a definition of the curl_easy_setopt function, which is part of libcurl. Adding -lcurl to your g++ line should fix this (by telling the linker to link in libcurl).
However, twitcurl comes with a Makefile, which already does this. In addition, if you are trying to build a shared library there, you're doing it wrong...
Maybe you can try ofxTwitter, an openFrameworks addon for twitter, to get your twitter functionality. get it here: http://forum.openframeworks.cc/index.php/topic,2750.0.html