64bit libraries issues

i just attended a of-workshop and couldnt get codeblocks to build any example app. after noodeling around with theo we ended at the point where we tried to run a build from his linux dist. and it keeps on having troubles loading libraries. so our suggestion is that it tries to load 32bit shared libraries while i run 64bit os.

anybody run into this before? anybody has a 64bit collection of the libs of dependence on?


*replying myself*

i want to start to collect all libraries… is it enough to have the *.so? can may be someone give me a hint on this? some folders also contain *.a and *.h and *.hpp etc. are these really needed? is it an idea to install all libs and copy the *.so from my os? i did this for swfmill once.



I’m really sorry about the troubles. can you post the error messages from with codeblocks as a text file – I will take a look.

likely, you will need to download the sources and compile all of the necessary libs.

I see three avenues to solve this (but forgive me, because I am super new to linux, so I’m asking so more advanced folks to chime in on this):

a) run a 32 bit environment in 64 bits, this is what the adobe people
recommend. (I’m not sure what this means, to be honest, but see
I have no idea if this is helpful, but I imagine there is good info about 32 bit apps on 64 bit systems.

b) make a banch of OF that ditches our system of local linking and come
up with an install script that puts everything global as opposed to
local. then it should work on just about any hardware that has those necessary libraries (freeglut, freeimage, freetype, v4l) working on it. some folks (like javier candiera) have pushed vocally for this, so happy if that can help allow 64 bit folks to compile, run. we can do local stuff for 32 bit systems (and it’s just easier for people getting started w/ linux) but have a seperate branch of OF that is more like an official linux package.

c) assemble 64 bit versions of the same .so/.a libraries in OF, and
package them. this could be done by someone knowledgeable, and
perhaps even on a 32 bit machine (w/ the right compiler flags).

hope those thoughts help, and I’ve notified some knowledgable linux heads about this thread, so hopefully some more informed info soon -

take care,

hey zach.

no apologizes needed. being on 64bit is tricky when leaving the road. i cant run some rare apache 32bit plugins neither… till now.

may be this helps:

having all *.so as 64bit might be nice for you guys… you could offer a 64bit version of openframeworks.


we’d be happy to offer that.

thanks for the info… we are going to work with some folks to offer something more akin to a package in linux, as an alternative to our local linking, which might be cool too (make it easier to get it working on different chipsets, etc). we envision that you could develop your app, and when you want to export it (make sure it can run on another linux machine, you can package it with the shell script / .so files that are needed and it should just work if the cpu types are the same).

about 6 months ago, somone predicted we might have to buy about 6 machines for testing :slight_smile:

thanks for being patient and please let us know what you discover or get stuck with - I will ask the linux OF folks to push with the packaging in the meantime.

take care!

hey zach.

yeah, if you wonna have *.so for diffent cpus. what are the big ones?
x86 32 and 64 bit?
intel and amd?

i have a mac intel 2 core duo. that offers me a machine that is capable of running:
winxp (32bit/ 64bit), vista (32bit/ 64bit), osx (tiger=32?/ leopard=64?), debian (32bit/ 64 bit + dists as gentoo, ubuntu), redhat (32bit/ 64bit + dist fedora) … i wouldnt be surprised if (open)suse, (free)bsd and opensolaris will run on it too. thats a hell of a lot testing environments!

of course its a hell to install everything and i never did it! :smiley:
i know someone who did this shit for fun on weekends but he know moved to kabul.
i only use ubuntu and have osx installed on extern hd (wonna do the same for windows).


I’m triying to compile of 0.04 in ubuntu 64 bits. I have all libraries compiled, but when I try to compile any of the examples I get this error in the linking phase:

obj/ofSoundStream.o: In function `ofSoundStreamListDevices()':  
ofSoundStream.cpp:(.text+0x208): undefined reference to `RtAudio::RtAudio(RtAudio::RtAudioApi)'  
obj/ofSoundStream.o: In function `ofSoundStreamSetup(int, int, ofSimpleApp*, int, int, int)':  
ofSoundStream.cpp:(.text+0x58d): undefined reference to `RtAudio::RtAudio(RtAudio::RtAudioApi)'  
ofSoundStream.cpp:(.text+0x5d5): undefined reference to `RtAudio::openStream(int, int, int, int, unsigned long, int, int*, int)'  
obj/ofSoundStream.o: In function `RtAudio::getDeviceCount()':  
ofSoundStream.cpp:(.text._ZN7RtAudio14getDeviceCountEv[RtAudio::getDeviceCount()]+0x14): undefined reference to `RtApi::getDeviceCount()'  
obj/ofSoundStream.o: In function `RtAudio::getDeviceInfo(int)':  
ofSoundStream.cpp:(.text._ZN7RtAudio13getDeviceInfoEi[RtAudio::getDeviceInfo(int)]+0x21): undefined reference to `RtApi::getDeviceInfo(int)'  

I’ve managed to compile applications compiling openframewors as a static library first and including it as library in the linking of the apps, if I include rtAudio, fobs or GLee before openframeworks lib, it returns the undefined reference error, if I include openframeworks first and then this libs, it compiles without problem. These are the only libs I’ve compiled, the other ones are taken from the system but they are not installed.

Any ideas?

I’m not that familiar with 64 bit issues, but it might be in the way you have built the libs that prevent them being linked against. I am super curious.

can you try compiling a simple test instead of compiling them into OF. For example, one of the rtAudio test apps (with main() ) etc with the compiled rtAudio. since it’s smaller, it might be easier to see what’s wrong and how to fix it.


ups! my fault…

I’ve downloaded rtAudio from the web without noticing that they’ve changed to version 4. I changed the .o file but not the includes so some functions that have changed with the last vesrion weren’t really defined. It’s now working.