Skip to main content

Experiences with Tecgraf Libraries

My advisor is always right. So I have decided to take a look at Im lib, from Tecgraf.

As a learner by example, I first tried to compile and run the examples provided with Im lib, but most of their examples came written in lua and I need to write my code in C (or C++). Fortunately there were 6 examples written in C++:
glut_capture.c im_copy.cpp im_info.cpp im_view.c iupglview.c proc_fourier.cpp
But, I wans't use glut (discarted glut_capture.c and iupglview.c)
So I've choosen im_view.c to try to compile, and the torture has started. There wans't any doc, readme or anything which tells something on how to compile the examples. The only clue was the comments written on the source header:
/*
IM 3 sample that shows an image.
Needs "im.lib", "iup.lib", "cd.lib" and "cdiup.lib". Usage: im_view Example: im_view test.tif Click on image to open another file.
*/
Well, I had discovered that I was needing three more libs from Tecgraf to compile this example. So let's get them. With all these four libs I did put them all at /usr/local/tec/include and /usr/local/tec/lib, changed my /etc/ld.so.conf to add /usr/local/tec/lib and had runned the ldconfig command. But now, which GCC parameters I should use?

Issuing a gcc -I/usr/local/tec/include/ -L/usr/local/tec/lib im_view.c
was always resulting on error. Taking a look at imlib dependencies with ldd
# ldd libim.so
linux-gate.so.1 => (0xb7f27000)
libm.so.6 => not found
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7dc9000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c79000) /lib/ld-linux.so.2 (0xb7f28000)
I have discovered that my system was missing the libm.so.6. After googling a little I have figured out that libm is the motif library. With a apt-cache search libmotif:
apt-cache search libmotif
libmotif-dev - Open Motif - development files
libmotif3 - Open Motif - shared libraries
Ubuntu has a package for libmotif3. Installing it the ldd on libim.so din'd show bronken dependencies anymore:
# ldd libim.so
linux-gate.so.1 => (0xb7f27000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7dd4000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7dc9000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c79000) /lib/ld-linux.so.2 (0xb7f28000)
And adding the -l flag to the gcc, I got this output:
gcc -I/usr/local/tec/include/ -L/usr/local/tec/lib im_view.c -liup -lim -lcd
/tmp/ccKdeRAP.o: In function `CreateDialog': im_view.c:(.text+0x634): undefined reference to `cdContextIup'
/usr/local/tec/lib/libim.so: undefined reference to `operator new[](unsigned int)'
/usr/local/tec/lib/libim.so: undefined reference to `operator delete[](void*)'
/usr/local/tec/lib/libim.so: undefined reference to `operator delete(void*)'
/usr/local/tec/lib/libim.
so: undefined reference to `__cxa_pure_virtual'
/usr/local/tec/lib/libim.so: undefined reference to `__gxx_personality_v0'
/usr/local/tec/lib/libim.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'
/usr/local/tec/lib/libim.so: undefined reference to `vtable for __cxxabiv1::__class_type_info'
/usr/local/tec/lib/libim.so: undefined reference to `operator new(unsigned int)'
/usr/local/tec/lib/libim.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info'

collect2: ld returned 1 exit status

Very strange, as im_view.c was suposed to be a C program, not C++. Well the libs must have C++ operations, so let's compile with g++.
g++ -I/usr/local/tec/include/ -L/usr/local/tec/lib im_view.c -liup -lim -lcd
/tmp/cc01yIbF.o: In function `CreateDialog()':

im_view.c:(.text+0xd8): undefined reference to `cdContextIup'
collect2: ld returned 1 exit status
But there still one missing reference. Obviously I had missed -lcdiup, but:
g++ -I/usr/local/tec/include/ -L/usr/local/tec/lib im_view.c -liup -lim -lcd -lcdiup
/usr/bin/ld: cannot find -lcdiup
collect2: ld returned 1 exit status
So what's up.
Fortunately, the project has an on-line history log
http://www.tecgraf.puc-rio.br/cd/en/history.html
And looking at the history, I found this peace of information:
Changed: IMPORTANT - the "cdiup" and "cdluaiup" libraries moved from CD to IUP under the name "iupcd" and "iupluacd". But headers and documentation remains on the CD package. Function names were NOT changed. This change eliminates a cross-dependency that IUP and CD had, now only IUP depends on CD.

So, it wasn't -lcdiup, in stead it was -liupcd. I finally had my g++ command line:
g++ -I/usr/local/tec/include/ -L/usr/local/tec/lib im_view.c -liup -lim -lcd -liupcd
And here is a screenshot of my im_view running:


Im lib looks very promising. Now that I have runned my first example, I hope to learn it soon.

Comments

Popular posts from this blog

uSleep on windows (win32)

I am facing a terrible issue regarding timing on windows.

Googling arround, I've found those infos:
Using QueryPerformanceCounter and QueryPerformanceFrequency APIs in Dev-C++
(http://yeohhs.blogspot.com/2005/08/using-queryperformancecounter-and_13.html)
QueryPerformanceCounter() vs. GetTickCount()
http://www.delphifaq.com/faq/delphi_windows_API/f345.shtml
How to time a block of code
http://www.cryer.co.uk/brian/delphi/howto_time_code.htm
And Results of some quick research on timing in Win32 http://www.geisswerks.com/ryan/FAQS/timing.html
With that I'm trying to write something like a uSleep function for windows:


#include<windows.h>

voiduSleep(int waitTime){
__int64 time1 = 0, time2 = 0, sysFreq = 0;

QueryPerformanceCounter((LARGE_INTEGER *)&time1);
QueryPerformanceFrequency((LARGE_INTEGER *)&freq);
do{
QueryPerformanceCounter((LARGE_INTEGER *)&time2);

// }while((((time2-time1)*1.0)/sysFreq)<waitTime);
}while( (time2-time1) <waitTime);
}

There is also already a nanosleep…

More trickery with gnuplot dumb terminal

In my post "Plotting memory usage on console" the chart doesn't pan the data.
Now, using a named pipe, the effect got a little bit nicer.
First, we have to run the memUsage.sh script to get a file filled with memory usage info:
./memUsage.sh > memUsage.dat &
Then we have to create a named pipe:
mkfifo pipe
Now we have to run another process to tail only the last 64 lines from the memUsage.dat
while [ 1 ]; do tail -64 memUsage.dat> pipe; done &
And now we just have to plot the data from the pipe:
watch -n 1 'gnuplot -e "set terminal dumb;p \"pipe\" with lines"'
And that is it!

Checking auth.log for ssh brute force attacks

As I am letting my personal computer always on, as a homelinux server, I decided to check if someone is trying to breaking in with SSH brute force attacks.

First I did a grep for fail at the /var/log/auth.log. (grep -i /var/log/auth.log)

And I got lots of lines with the string "fail". With [grep -i /var/log/auth.log | wc -l] I figured out that were 1164 fail entries at auth.log

With an [grep -i fail auth.log | cut -d " " -f 6 | sort | uniq] I checked that were two kind of failed attempts:
Failed
pam_unix(sshd:auth):

So I wrote the following line to check with which users they were attempting to log:
grep Failed auth.log | cut -d " " -f 11 | sort | uniq | while read line ; do echo -n $line" "; grep $line auth.log | wc -l; done | sort -n -k 2

Here, the field position (the number 11 at the above command lines [-f 11]) may change in some systems. At my desktop at work, the username came at the position 9.

Here are the "top ten":
root 2922
user 2884