kflorek
September 20th, 2006, 03:15 AM
CodeAnalyst is a very cool program. (I know from the Windows XP version.) The most interesting part is that it shows you where the jams and wasted cycles are at the CPU level, by a graphical display of exactly what is happening in the CPUs pipeline. It could be very useful to others beside me to get it to run on Ubuntu AMD64. And I could make progress getting free of Windows. It's not that I dislike Windows especially; it's just that I don't like being chained to anything if I don't have to be.
I've been trying to puzzle through this one for a few days. I can't get past the ./configure errors.
I'm not much of a programmer. Just an amateur who can do enough C++ and x86 assembly language for his own use, mostly in mathematics.
I got past ./configure not finding g++ by creating symbolic links. I got past it not finding qt by adding the switch --with-qt=/usr/share/qt3. Then nothing I have guessed gets past:
checking for QT runtime library... configure: error: no
That's where the output ends. There are no errors output before this.
The configure script is over 400K, so following the whole thing is impossible, and I'm very vague on the scripting language anyway. Fortunately a search through configure narrow to a single spot where "runtime" occurs (on 2 adjacent lines). Unfortunately the chain by which the variables get their values at this point is beyond me to follow.
Within the configure script there are quite a lot of possible switches listed. One of them is --with-qt-libraries, which would seem to be logical, but setting it equal to every lib directory I could find did not produce any different error. The error seems to be at the exact same spot judging by the config.log file, regardless of what I set the switch to.
The last numbered lines in the config.log are
configure:5610: g++ -o conftest -g -02 -I /usr/share/qt3/include -L$/usr/lib64 conftest.cc -L/usr/lib64 -L/usr/share/qt3/ -lqt -lpopt >&5
/usr/bin/ld cannot find -lqt
collect2: ld returned 1 exit status
configure:5616: $? = 1
configure: failed program was:
| /* confdefs.h */
the rest of the program
configure:5636: error: no
Maybe someone familiar with g++, configure scripts, or CodeAnalyst has some clues. I guess that -lqt (and -lpopt ?) are supposed to be set to some library directory in order for the g++ command line to make sense, is that right? My extrasensory perception fails me as to what to set to what. :-({|=
--------------- chapter 2
I see there are fewer than 6 people, other than myself, that even had an interest sufficient to take a look, so this is going nowhere.
I figured out the configure script enough to tell that it was looking for a library named qt. A lead in this forum in the thread about qt got me to where I realized that Ubuntu does not have a library containing qt (which is what -lqt refers to), but only the multi-threaded qt, named qt-mt, the library they say that is practically the only one still used; and so this area of the script will always fail. However, the script will instead look for the library "qt-mt" when there exists a subdirectory named lib64 in the "qt" directory (/usr/share/qt3, that is). Instead of lib64, Ubuntu has the subdirectory lib.(For AMD64, directories named lib seem to default to 64 bits, and symbolic links named lib64 point to the plain lib.) So I made a symlink called lib64 that linked to qt "lib." That got me past a few thousand more lines in the configure script, (about half way through.:cool: ) But the error there looks like a real stopper.
checking for x86-64 architecture... yes
checking for arch/kernel version combination...ok
checking for preempt patch ... yes
configure: error: unsupported kernel configuration CONFIG_PREEMPT
I can can only guess what CONFIG_PREEMPT might be. It might just be to head off (PREEMPT?) a potential insecurity (a crash) if the program were to be used with something that was unknown to the programmer who wrote this, in which case I might disable this part of the script (if I knew how.) OTOH PREEMPT might refer to a kernel type for which no code was written. Or maybe an "include" file for PREEMPT, whatever it is, is not where the configure script can figure out.
I've been trying to puzzle through this one for a few days. I can't get past the ./configure errors.
I'm not much of a programmer. Just an amateur who can do enough C++ and x86 assembly language for his own use, mostly in mathematics.
I got past ./configure not finding g++ by creating symbolic links. I got past it not finding qt by adding the switch --with-qt=/usr/share/qt3. Then nothing I have guessed gets past:
checking for QT runtime library... configure: error: no
That's where the output ends. There are no errors output before this.
The configure script is over 400K, so following the whole thing is impossible, and I'm very vague on the scripting language anyway. Fortunately a search through configure narrow to a single spot where "runtime" occurs (on 2 adjacent lines). Unfortunately the chain by which the variables get their values at this point is beyond me to follow.
Within the configure script there are quite a lot of possible switches listed. One of them is --with-qt-libraries, which would seem to be logical, but setting it equal to every lib directory I could find did not produce any different error. The error seems to be at the exact same spot judging by the config.log file, regardless of what I set the switch to.
The last numbered lines in the config.log are
configure:5610: g++ -o conftest -g -02 -I /usr/share/qt3/include -L$/usr/lib64 conftest.cc -L/usr/lib64 -L/usr/share/qt3/ -lqt -lpopt >&5
/usr/bin/ld cannot find -lqt
collect2: ld returned 1 exit status
configure:5616: $? = 1
configure: failed program was:
| /* confdefs.h */
the rest of the program
configure:5636: error: no
Maybe someone familiar with g++, configure scripts, or CodeAnalyst has some clues. I guess that -lqt (and -lpopt ?) are supposed to be set to some library directory in order for the g++ command line to make sense, is that right? My extrasensory perception fails me as to what to set to what. :-({|=
--------------- chapter 2
I see there are fewer than 6 people, other than myself, that even had an interest sufficient to take a look, so this is going nowhere.
I figured out the configure script enough to tell that it was looking for a library named qt. A lead in this forum in the thread about qt got me to where I realized that Ubuntu does not have a library containing qt (which is what -lqt refers to), but only the multi-threaded qt, named qt-mt, the library they say that is practically the only one still used; and so this area of the script will always fail. However, the script will instead look for the library "qt-mt" when there exists a subdirectory named lib64 in the "qt" directory (/usr/share/qt3, that is). Instead of lib64, Ubuntu has the subdirectory lib.(For AMD64, directories named lib seem to default to 64 bits, and symbolic links named lib64 point to the plain lib.) So I made a symlink called lib64 that linked to qt "lib." That got me past a few thousand more lines in the configure script, (about half way through.:cool: ) But the error there looks like a real stopper.
checking for x86-64 architecture... yes
checking for arch/kernel version combination...ok
checking for preempt patch ... yes
configure: error: unsupported kernel configuration CONFIG_PREEMPT
I can can only guess what CONFIG_PREEMPT might be. It might just be to head off (PREEMPT?) a potential insecurity (a crash) if the program were to be used with something that was unknown to the programmer who wrote this, in which case I might disable this part of the script (if I knew how.) OTOH PREEMPT might refer to a kernel type for which no code was written. Or maybe an "include" file for PREEMPT, whatever it is, is not where the configure script can figure out.