Gtreamer Application compiles but fails e with error

I am trying to create a gstreamer application, starting from the very basic Hello world gstreamer tutorial.
The application compiles without problems, both locally and remotely but when I try to execute that application I get the following error:

Inside NvxLiteH264DecoderLowLatencyInitNvxLiteH264DecoderLowLatencyInit set DPB and MjstreamingFATAL: cannot locate cpu MHz in /proc/cpuinfo

The line used to compile the code is locally is:

g++ tutorial1.c -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0/ -I/usr/include/libxml2/ -I /usr/lib/arm-linux-gnueabihf/glib-2.0/include/ -lglib-2.0 -lgstreamer-0.10 -o tutorial1

For remote compilation I made a remote cuda project. Then I tried to execute the file locally.
Has anybody come across this problem before, or maybe knows whats wrong with it? Thanks in advance.

I don’t remember where, but I believe the cpu MHz is not only an old and common issue (not a Jetson issue, but related because it isn’t an issue on many other platforms), but also was solved and marked for some future release. I just don’t remember where I saw that there is a solution which will be available (just not yet in Jetson’s version). Some web research might find a patch you could use temporarily.

The cpu Mhz is in an old issue. Its typical in the arm architecture. Most reports I found indicate that this is a jackd issue and the current jackd tree has a fix which has not propagated yet to the ubuntu tree. I tried to recompile jackd with a patch but this did not fix the issue. I even uninstalled jackd and this made no difference (I expected some form of dependancy but there was none). This is why I asked in case someone has come across the file which tries to parse /proc/cpuinfo and fails. The video I tried had sound. When I tried a video without sound everything worked as expected.
What is amazing is that even the most basic gstreamer tutorial fails. Maybe the problem is only with gstreamer0.10, but I need to write a plugin that uses opencv and for some reason if I try to install streamer-1.0-plugins opencv gets uninstalled!!!
And yes I did spend a couple of hours before I posted this question. I will resolve the issue but I thought I could save sometime. But as with all the other questions I posted in this forum I ended up solving the problem myself. What amazes me is how unstable this distribution is and how fast it deteriorates (it was more stable a month ago). It seems nvidia is using this chip just to create hype (the 64 bit version is another story). For instance, the documentation does not contain even one example how to interface a csi 2 camera, let alone more complex stuff. Probably because it does not work. And yes I could use a usb camera but that has a huge speed penalty and latency.
So its a good toy but thats about it. I am not going to waste any more of my time on it.

Are you using opencv4tegra by any chance? There’s an issue with gstreamer plugins dependencies if you do.
I’m installing a dummy package after opencv4tegra to avoid these problems:
https://devtalk.nvidia.com/default/topic/779315/embedded-systems/jetson-tk1-opencv-and-ros/

The fatal error is probably coming from the JACK audio server. The packaged jack2 that comes with L4T/Ubuntu has a problem on newer ARM processors. Any application that is “jack aware” can hit this. I ran into this with a number of audio applications I wanted to install and use on my Jetson.

To get around this you will need to build jack2 from the latest source code and install it.

(1) Download some dependencies:

sudo apt-get install libasound2-dev libsamplerate0-dev libsndfile1-dev

(2) Git the latest jack2 code:

git clone git://github.com/jackaudio/jack2.git

(3) Build and install jack over top of the distributed package:

cd jack2
./waf configure --alsa --prefix=/usr --libdir=/usr/lib/arm-linux-gnueabihf
./waf build --jobs=5
sudo ./waf install

I opted to overwrite the original files (the --prefix and --libdir args) because installing them in /usr/local still resulted in the old ones being picked up. I think there is a search order problem when looking for .so files.