when bulding qt, make exits

[ariell]

Hi, I'm new to mandrake (I once sticked with the enemy from Redmond *smile*).
Nevertheless, I am NOT new to C/C++.

I've got a serious problem compiling the trolltech qt-sources. The make process exits in stage 2 because of:
"error while loading shared libraries..
libstdc++.so.3 ...
no such a file or directory...

Somebody mentioned that I need to register my "libc" with the environment. I searched my system for libstdc++.so.3. It resides under /usr/lib. I added /usr/lib to the $PATH var, but still the make process wouldn't succeed.

Without qt, there's a lot of stuff I cann not setup on my machine (such as dev-c++, quanta, and so on...).

Any help available?
I'd really appreciate some serious advice.
Ariell.

[Stuka]

The Linux equivalent to registering dlls on MS systems is ldconfig. If the shared library is in /usr/lib, then try running /sbin/ldconfig (you must run it as root), and then try to build the Qt sources again. (ldconfig updates the list of shared libraries, and ldd uses it's output to find shared libraries, so that's probably what's causing the error you're getting).

[bwkaz]

One other thing is, $PATH is for executables only, not shared libraries (libstdc++ is a shared library). It would probably be a good idea to remove /usr/lib from your PATH. The /etc/ld.so.conf file lists all the directories that shared libraries reside in (I believe that /usr/lib and /lib are always searched regardless of this file, but I could be wrong as I always put those paths in ld.so.conf anyway). Running ldconfig updates the cache of which shared libs are where, based on the directories listed in ld.so.conf.

If an ldconfig doesn't help, then can you post the last 10 lines or so of the make output?

[ariell]

Thanks a million for your help-

unfortunatley, ldconfig didn't fix my prob, too.
Maybe I need to mention that in /usr/lib there's a file libstdc++-libc6.2-2.so.3 that POINTS to libstdc++.so.3.
If I use "Find File" from the file manager's tools menu, libstdc++-libc6.2-2.so.3 is the result displayed...

The funny thing is that building and installing gcc/g++ itself was a pretty easy task, taking fourty-five minutes, or so.

Anyway, again, thank you guys,
ariell.

As requested, here's what GNU make outputs before exiting:

g++ -c -I/usr/X11R6/include -I/usr/local/bin/qt/include -I/usr/X11R6/include -pipe -O2 -fPIC -DQT_BUILTIN_GIF_READER=1 -DQT_NO_IMAGEIO_JPEG -DQT_NO_IMAGEIO_MNG -DQT_XFT -I/usr/local/bin/qt/src/3rdparty/zlib -I/usr/local/bin/qt/src/3rdparty/libpng -o tools/qutfcodec.o tools/qutfcodec.cpp
g++ -c -I/usr/X11R6/include -I/usr/local/bin/qt/include -I/usr/X11R6/include -pipe -O2 -fPIC -DQT_BUILTIN_GIF_READER=1 -DQT_NO_IMAGEIO_JPEG -DQT_NO_IMAGEIO_MNG -DQT_XFT -I/usr/local/bin/qt/src/3rdparty/zlib -I/usr/local/bin/qt/src/3rdparty/libpng -o kernel/qpsprinter.o kernel/qpsprinter.cpp
/usr/local/bin/qt/include/qintdict.h: In member function `void
QIntDict<type>::deleteItem(void*) [with type = void]':
/usr/local/bin/qt/include/qintdict.h:51: instantiated from here
/usr/local/bin/qt/include/qintdict.h:82: warning: deleting `void*' is undefined
/usr/local/bin/qt/bin/moc kernel/qthread_unix.cpp -o kernel/qthread_unix.moc
/usr/local/bin/qt/bin/moc: error while loading shared libraries: libstdc++.so.3: cannot open shared object file: No such file or directory
make[2]: *** [kernel/qthread_unix.moc] Error 127
make[2]: Leaving directory `/usr/local/bin/qt/src'
make[1]: *** [sub-src] Error 2
make[1]: Leaving directory `/usr/local/bin/qt'
make: *** [init] Error 2
[root@localhost qt]# echo $PATH
/usr/lib:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin
[root@localhost qt]# echo $LD_LIBRARY_PATH
/usr/local/bin/qt/lib
[root@localhost qt]#

[Stuka]

So where is libstdc++.so.3 actually located? If you can add THAT path to ld.so.conf, and rerun ldconfig, that OUGHT to do it...

[ariell]

Hi there,

first of all, the two of you really helped me a lot! Thank you!

I changed /etc/ld.so.conf after realizing that libstdc++.so.3 actually resides in /usr/local/lib.
I ran ldconfig using the conf-file.
I changed bash.profile to delete any unnecessary hints to pathes.
Logging off, loggin on, starting the build process...
Here's my results:
g++ -L/usr/local/bin/qt/lib -Wl,-rpath,/usr/local/bin/qt/lib -o ./xmlquotes main.o quoteparser.o richtext.o moc_richtext.o -lqt
make[4]: Leaving directory `/usr/local/bin/qt/examples/xmlquotes'
make[3]: Leaving directory `/usr/local/bin/qt/examples'
make[2]: Leaving directory `/usr/local/bin/qt/examples'

The Qt library is now built in ./lib
The Qt examples are built in the directories in ./examples
The Qt tutorials are built in the directories in ./tutorial

Note: be sure to set $QTDIR to point to here or to wherever
you move these directories.

Enjoy! - the Trolltech team

make[1]: Leaving directory `/usr/local/bin/qt'
[root@localhost qt]#

So, it finally worked out, thanks to your assistance.

Some personal comment: I studied computer science at UCLA, Southern California, from 1986 thru '89/90.
That was my "last-time-unix". Companies that later hired me (in Germany) sticked with windows. No chance to convince those guys of security-lacks, and so on- I don't even need to mention it, you probably know best.
Anyway, I thus "specialized" on COM, Microsoft's Component Object Model- you might call it a "CORBA-like" approach to provide support for distributed applications, at least a trial to do so.
Well, that was my story.
The day before yesterday (I'm not working there anymore) I decided to "switch back".
Then there was that problem to embed qt. Then there was help. IMMEDIATLEY. How can I say? It feels like coming home after a long, long, long time.

I'm happy to be back.

Best to all,
ariell.

[ariell]

Originally posted by Stuka
The Linux equivalent to registering dlls on MS systems is ldconfig. If the shared library is in /usr/lib, then try running /sbin/ldconfig (you must run it as root), and then try to build the Qt sources again. (ldconfig updates the list of shared libraries, and ldd uses it's output to find shared libraries, so that's probably what's causing the error you're getting).

[bwkaz]

Ah, glad you got it. :)

I, too, have used some COM at work (and a bit on my own -- DirectX 6 -- before I discovered SDL, OpenGL, and Linux). Not much (it's ... mmmph ... ugly), but I do know the basics.

Glad you decided to come back! ;)