Stuck with twitcurl - c++

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

Related

Can't compile glew when using it via my own library : CodeLite

I have edited out a lot of my original situation to try keep things simple; it can be seen in the revisions.
Basically I have been following a tutorial in which a game engine is being created.
Most of the code has been separated into its own CodeLite project and successfully compiled into a static library (libbengine.a using mingw32 via TDM-GCC-32).
(For the record, the code compiled fine before separation)
Back in the main game code (main.cpp, etc) the compiler knows the relevant include and lib directories and compilation can at least locate the necessary headers and lib.
However, I get this error: undefined reference to '__glewCreateProgram'
Any ideas as to what is getting lost in translation (so-to-speak)?
I have been reading around all over the place; researching compilation, static libraries, ar.exe, but am having no luck (I am still looking).
If you want any more pertinent information, I will happily provide it; for now I shan't clog up the post any further.
Cheers
To give a basic idea of the error in CodeLite:
Main project linker settings:
bengine project linker settings (compiled as static lib.a):
It seems the problem was solely with linking order. As can be seen in the second image in my question (Main linker setting) - "Bengine" should have been at the top of the list, not the bottom.
This may be mingw32 specific; I am not sure.
Well, after all those hours, I feel somewhat foolish...
At least I have learned some things along the way.

problems with dynamically linked libraries

Problem:
When I try to open some applications I get errors from the linker like this:
/usr/lib/x86_64-linux-gnu/libpoppler-qt5.so.1: undefined symbol: _ZN6QDebugD1Ev
Some applications affected are
texstudio shows
/usr/lib/x86_64-linux-gnu/libpoppler-qt5.so.1: undefined symbol: _ZN6QDebugD1Ev
IPython's qtconsole shows
/usr/lib/python3.5/site-packages/PyQt5/QtCore.so: undefined symbol: _ZNK12QStorageInfo11displayNameEv
konsole (KDE's terminal emulator - I'm using Unity though) shows
/usr/lib/x86_64-linux-gnu/libKF5ItemViews.so.5: undefined symbol: ...
granatier (a KDE game), KSysguard and KAddressbook also show errors in KF5 libraries
VLC seems to be affected too since it says there is something wrong with Qt 4 (see below). However it doesn't ecplicitely say it's a linking problem.
It seems to be a problem with dynamic linking and I my guess would be that the problem is in the libraries
Qt
all of this errors seem to come from Qt linked libraries ("Qt" appears in most filenames and most symbol names). AFAIK KDE ist baed on Qt, which would explain why all KDE applications fail.
It seems to affect both Qt 4 and 5
I also had a similar problem with ssl but it went away eventually (maybe an update).
I'm using ld 2.25
Why I'm asking here
I realize that my Question is not about programming. The help center states that
Questions about general computing hardware and software are off-topic for Stack Overflow unless they directly involve tools used primarily for programming.
This seems to be a problem with the linker / the dynamic libraries so I would say it kind of involves programming tools.
If you disagree please spare the downvotes and write a comment explaining you POV.
Okay, this kind of problems happen a lot if you switch to 'unstable'.
What you need to do is downgrade all of your packages back to 'stable'. Modifying sources.list wouldn't be enough, you also need to change priorities.
Look this thread: https://unix.stackexchange.com/questions/117122/how-to-get-back-from-testing-to-stable-kernel-downgrade
Ok, so it seems the source of the problem was that I had Qt linked libraries like libQt5Core.so.5 in /usr/local/lib. When I remove them everything worked again.
I've read that the package manager doesn't put any libraries there, so it was probably me who did a dumb mistake. It looks like it wasn't a programming problem at all in the end.

Why can't I compile SDL on Mac for x86_64 using C++?

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

link error __stack_chk_fail (using libs with xcode)

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.

CMake link stage question

I am currently building a rather large application, using cmake to generate cross platform build scripts. During this process of putting together the cmake build scripts, I have discovered the pain of gcc link line ordering.
The basic issues is that including static libraries in the wrong order leads to unused library symbols being thrown away that then cannot be found by subsequent dependent libraries.
Thus, I am in the situation where cmake generates a visual studios build system that compiles just fine, but the unix makefiles throw all kinds of "undefined symbol" errors. I have figured out a work around for this - in the add_executable command, I am including the static libraries twice.
My hope is that there is a more standard/better way to deal with this issue. Being that I am not the only developer, and that the majority of regular development is done in windows, I really want a link-order agnostic CMake script. The windows developers just don't deal with this link order issue. On top of that, figuring out the correct order would be very difficult - I do not have that information readily available and there are a lot of static libraries (70 or so).
After searching the internet, I did learn about the -static and -dynamic flags, but getting CMake to include them is non-obvious and gcc complains about not being able to find the dynamic libraries.
Anyway, I welcome suggestions on how to do the right thing.
Did you try disabling the strip? Maybe with something like cmake -DCMAKE_STRIP=/bin/true ..? Maybe that will stop the symbols being thrown out.
I think this is less of a CMake issue, and more of a GCC behavior. This question/answer should help out a bit:
Linker order in GCC
You will have to bite the bullet and modify your CMakeLists.txt files to link properly on Linux. Since the Windows developers don't care, you shouldn't disturb them.
Best,
-dan