search

openFrameworks-RaspberryPi / openFrameworks

This repo has migrated into the openFramworks core! Please go to http://github.com/openFrameworks/openFrameworks for the latest!
http://github.com/openFrameworks/openFrameworks
Other
104 stars 11 forks source link

building openFrameworksCompiled hangs on ofColor.cpp #118

Open arneboon opened 11 years ago

arneboon commented 11 years ago

dear of + rpi dev team,

thanks a great deal for your effort making oF hit the Rpi!

i have been testing and trying some stuff last weeks for a new project today i did a git pull to get on track with the latest developments now the oF library in the develop-raspberrypi branch seems no longer to build it hangs on ofColor.cpp also did a clean git clone and followed the wiki instructions again closely

after: $ cd Workspace/openFrameworks/libs/openFrameworksCompiled/project/ $ make

this is the error output:

Compiling ../../../libs/openFrameworks/types/ofColor.cpp mkdir -p obj/linuxarmv6l/Releaselibs/openFrameworks/types g++ -Os -march=armv6 -mfpu=vfp -mfloat-abi=hard -fPIC -ftree-vectorize -Wno-psabi -pipe -DOF_USING_GTK -DOF_USING_MPG123 -DTARGET_RASPBERRY_PI -DSTANDALONE -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE -DSTDC_CONSTANT_MACROS -DSTDC_LIMIT_MACROS -DTARGET_POSIX -DHAVE_LIBOPENMAX=2 -DOMX -DOMX_SKIP64BIT -DUSE_EXTERNAL_OMX -DHAVE_LIBBCM_HOST -DUSE_EXTERNAL_LIBBCM_HOST -DUSE_VCHIQ_ARM -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads -I../../../addons/ofxRaspberryPi/src -pthread -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gstreamer-0.10 -I/usr/include/libxml2 -I/usr/include/gtk-2.0 -I/usr/lib/arm-linux-gnueabihf/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I../../../libs/cairo/include -I../../../libs/cairo/include/libpng15 -I../../../libs/cairo/include/cairo -I../../../libs/cairo/include/pixman-1 -I../../../libs/freetype/include -I../../../libs/freetype/include/freetype2 -I../../../libs/freetype/include/freetype2/freetype -I../../../libs/freetype/include/freetype2/freetype/internal -I../../../libs/freetype/include/freetype2/freetype/internal/services -I../../../libs/freetype/include/freetype2/freetype/config -I../../../libs/kiss/include -I../../../libs/poco/include -I../../../libs/poco/include/CppUnit -I../../../libs/poco/include/Poco -I../../../libs/tess2/include -I../../../libs/openFrameworks -I../../../libs/openFrameworks/communication -I../../../libs/openFrameworks/3d -I../../../libs/openFrameworks/events -I../../../libs/openFrameworks/types -I../../../libs/openFrameworks/math -I../../../libs/openFrameworks/video -I../../../libs/openFrameworks/gl -I../../../libs/openFrameworks/sound -I../../../libs/openFrameworks/app -I../../../libs/openFrameworks/graphics -I../../../libs/openFrameworks/utils -MMD -MP -MF obj/linuxarmv6l/Releaselibs/openFrameworks/types/ofColor.d -MTobj/linuxarmv6l/Releaselibs/openFrameworks/types/ofColor.o -o obj/linuxarmv6l/Releaselibs/openFrameworks/types/ofColor.o -c ../../../libs/openFrameworks/types/ofColor.cpp {standard input}: Assembler messages: {standard input}:24728: Warning: partial line at end of file ignored g++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. make: *\ [obj/linuxarmv6l/Releaselibs/openFrameworks/types/ofColor.o] Error 4

for $make Debug

it ends up in

rks/types/ofColor.o -o obj/linuxarmv6l/Debuglibs/openFrameworks/types/ofColor.o -c ../../../libs/openFrameworks/types/ofColor.cpp {standard input}: Assembler messages: {standard input}:67329: Warning: end of file not at end of a line; newline inserted {standard input}:67987: Error: unrecognized symbol type "gnu_unique_obje" g++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. make: *\ [obj/linuxarmv6l/Debuglibs/openFrameworks/types/ofColor.o] Error 4

wanted to let you know about this issue this way

hope i am not doing something stupidly wrong?

thanks! arne.

bakercp commented 11 years ago

Hey @arneboon an odd bug to be certain. I'm checking into it. You are using the latest Raspbian image?

jvcleave commented 11 years ago

@arneboon I am curious if you did the memory_split instructions in the wiki. I am wondering if you are running out of RAM and the gcc is getting killed

bakercp commented 11 years ago

@jvcleave @arneboon The memory issue is my current conclusion as well. I just re-ran the current core make on the git repo and it worked without issue.

bakercp commented 11 years ago

The other issue could be related to a corrupt memory card (which can happen due to inadequate power, etc) -- I just ran into my first card corruption issue which was leading to all sorts of strange issues.

arturoc commented 11 years ago

does it always happens with ofColor? it might be related with the additions @ofzach did recently adding lot's of statics it could be that the file is so big that on the rpi crashes because of not having enough ram. even if ofColor doesn't seem that big, being a templated class the amount of generated code can be really big

can you try putting this lines at the end of ofColor.cpp:

template class ofColor_<char>;
template class ofColor_<unsigned char>;
template class ofColor_<short>;
template class ofColor_<unsigned short>;
template class ofColor_<int>;
template class ofColor_<unsigned int>;
template class ofColor_<long>;
template class ofColor_<unsigned long>;
template class ofColor_<float>;
template class ofColor_<double>;

in different files, ie: leave the first one in ofColor.cpp and then move template class ofColor; to ofUnisgnedCharColor.cpp, template class ofColor; to ofShortColor.cpp ...

or even to test just delete a few of them

arturoc commented 11 years ago

actually moving those to a different file won't work, so just try commenting a few of them, your programs will of course not link but just to see if the issue is memory related

bakercp commented 11 years ago

I just ran it all again, and it did take unusually long to compile ofColor, which would make sense of the memory + color defs theory. I am currently compiling on a RPi 512MB with most of that memory available to the CPU.

arneboon commented 11 years ago

thanks for all your quick responses! great!

in reply:

would it make sense to increase the memory split in favour of the CPU for testing? let's say 200 / 56? will give that a try

also tried the 3 current different branches just before i went home, all show the same behaviour hanging when building ofColor

thanks again for your responses, get back asap when have some tests done

best regards, arne.

jvcleave commented 11 years ago

@arneboon I would do the default memory split, 64 for the GPU

arneboon commented 11 years ago

hi

just now it did:

then the building progess outputs loads of errors like this: ../../../libs/openFrameworksCompiled/lib/linuxarmv6l/libopenFrameworks.a(ofColor.o): In function ofColor_<unsigned int>::operator/(float const&) const': ofColor.cpp:(.text._ZNK8ofColor_IjEdvERKf[ofColor_<unsigned int>::operator/(float const&) const]+0x60): undefined reference toofColor::ofColor(float, float, float, float)' ofColor.cpp:(.text._ZNK8ofColorIjEdvERKf[ofColor::operator/(float const&) const]+0x74): undefined reference to ofColor_<unsigned int>::ofColor_(ofColor_<unsigned int> const&)' ofColor.cpp:(.text._ZNK8ofColor_IjEdvERKf[ofColor_<unsigned int>::operator/(float const&) const]+0x7c): undefined reference toofColor::~ofColor()' ofColor.cpp:(.text._ZNK8ofColorIjEdvERKf[ofColor::operator/(float const&) const]+0x84): undefined reference to ofColor_<unsigned int>::ofColor_(ofColor_<unsigned int> const&)' ofColor.cpp:(.text._ZNK8ofColor_IjEdvERKf[ofColor_<unsigned int>::operator/(float const&) const]+0x90): undefined reference toofColor::~ofColor()'

giving messages like this for many files that includes an ofColor call: ofGraphics.cpp, ofPixels.cpp, ofMesh.cpp, ofColor.cpp etc it ends with: collect2: ld returned 1 exit status make: *\ [bin/raspberrypi_hello_world] Error 1

no successful build

then i tried the raspberrypi_hello_world_gles2 with $make Debug this compiled successfully! (yeaah)

compiling raspberrypi_hello_world using $make Debug turned out to also work!

i checked in libs/openFrameworksCompiled/project to hit $make and it told me Done! so, the core was build for release and debug both already

now there still seems to be an issue with compiling the $make oF core Release on rpi 256mb (on 192/64gpu)

i edited the boot/config.txt back to cpu/gpu 128/128 mb, did a reboot and tried compiling the release $make and debug $make Debug after a $make clean. this was not successful: run into the ofColor stuff again.

so this issue seems to be memory related, so far to be hacked around with $make Debug with the edit /boot/config.txt gpu_mem=64 setting.

jvcleave commented 11 years ago

Sounds like we know what it is. Thanks for testing @arneboon. I am going to remove the line in the wiki concerning the memory split for now

bakercp commented 11 years ago

So what's the latest on this? Can we close it? @arneboon would you be able to add your thoughts to:

https://github.com/openFrameworks-RaspberryPi/openFrameworks/wiki/Raspberry-Pi-Troubleshooting

arneboon commented 11 years ago

hi @bakercp just added some lines on the troubleshooting page about the workaround

bakercp commented 11 years ago

Super. Would you consider this issue closed then?

arneboon commented 11 years ago

hi christopher

the issue came up after updating to the lastest developments, before that time everything would compile on rpi256mb even with the 128/128 mb memory split, using $make and $make Debug.

now the $make for release does not compile and the ofColor seems to be too heavy for the rpi256mb.

so i guess i would be a good thing see whether ofColor can be made lighter for compatibility with rpi256mb.

for now i think the issue needs some attention, or decide that this is it for now and just keep focussing on the rpi512mb.

danzeeeman commented 11 years ago

I can see moving the memory back to the CPU from the GPU while compiling but running an app you should really give the GPU has much ram as possible.

We should talk about trimming down ofColor, even though it is nice to have lots of colors pre-defined.

On Fri, Jan 18, 2013 at 3:28 PM, Christopher Baker <notifications@github.com

wrote:

So what's the latest on this? Can we close it? @arneboonhttps://github.com/arneboonwould you be able to add your thoughts to:

https://github.com/openFrameworks-RaspberryPi/openFrameworks/wiki/Raspberry-Pi-Troubleshooting

— Reply to this email directly or view it on GitHubhttps://github.com/openFrameworks-RaspberryPi/openFrameworks/issues/118#issuecomment-12439582.

"I believe in science. Unlike mathematical theorems, scientific results can't be proved. They can only be tested again and again, until only a fool would not believe them.

I cannot prove that electrons exist, but I believe fervently in their existence. And if you don't believe in them, I have a high voltage cattle prod I'm willing to apply as an argument on their behalf. Electrons speak for themselves."

-- Seth Lloyd: Quantum Mechanical Engineer, MIT

/.

jvcleave commented 11 years ago

@danthemellowman have you ran into issues with OF where it needed more than the default 64?

pikilipita commented 11 years ago

I'd like to share my experience: after some failed attemps to compile the of lib on my raspberry pi 256 Mo, I found a working solution. It's seems the issue is indeed related to a lack of available RAM. When I compile within the X environement, it fails on the 'ofColor.cpp' process. But when I compile from the start-up screen ( the "full screen terminal") then it worked :) I could later succesfully compile & run the hello world example.

vade commented 11 years ago

Hello. Just as a datapoint, I ran into this issue today as well. Compiling with the default memset (as of this posting - 128MB) without X env running, just SSH'ed to the system, had the ofColor compliation errors.

Memset to 64 solved the issue for me, with no code or linker changes required.

danzeeeman commented 11 years ago

thanks vade!

On Thu, Jun 13, 2013 at 4:33 PM, vade notifications@github.com wrote:

Hello. Just as a datapoint, I ran into this issue today as well. Compiling with the default memset (as of this posting - 128Mb) without X env running, just SSH'ed to the system, had the ofColor compliation errors.

Memset to 64 solved the issue for me, with no code or linker changes required.

— Reply to this email directly or view it on GitHubhttps://github.com/openFrameworks-RaspberryPi/openFrameworks/issues/118#issuecomment-19423095 .

vade commented 11 years ago

Oh, and to be clear, I have a Model B, so im not sure if the issue is relegated to Model A , 256 MB ram.

My Model B has 256MB.

danzeeeman commented 11 years ago

It depends on when it was made. If it is an early Model B it might be the 256 MB ram version. I think after this summer every model B has 512 mb...but the early ones don't

On Thu, Jun 13, 2013 at 4:36 PM, vade notifications@github.com wrote:

Oh, and to be clear, I have a Model B, so im not sure if the issue is relegated to Model A , 256 MB ram.

— Reply to this email directly or view it on GitHubhttps://github.com/openFrameworks-RaspberryPi/openFrameworks/issues/118#issuecomment-19423242 .

vade commented 11 years ago

Hey look at that. Meminfo confirms on on a Model B but with 256. Well spotted. Edited above comment for clarity.