Bug 19403 - Error during ./configure on kde applications
Error during ./configure on kde applications
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kdelibs (Show other bugs)
7.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-19 16:32 EDT by Jarin Satterlee
Modified: 2007-04-18 12:29 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-10-20 07:41:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jarin Satterlee 2000-10-19 16:32:41 EDT
When I try to compile kde applications I get the following results:

[~/kftp-0.6.1]$ ./configure
creating cache ./config.cache
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for ranlib... ranlib
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking for main in -lcompat... no
checking for main in -lcrypt... yes
checking for the third argument of getsockname... socklen_t
checking for dnet_ntoa in -ldnet... no
checking for dnet_ntoa in -ldnet_stub... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for killpg in -lucb... no
checking for Qt... libraries /usr/lib/qt-2.2.0/lib, headers
/usr/lib/qt-2.2.0/include
checking if Qt compiles without flags... no
checking for moc... /usr/lib/qt-2.2.0/bin/moc
checking for rpath... yes
checking for bool... yes
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for a C-Compiler... gcc
checking whether the C compiler (gcc -g -O2 ) works... yes
checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking how to run the C preprocessor... gcc -E
checking for a C++-Compiler...
checking for g++... g++
checking whether the C++ compiler (g++  -s) works... yes
checking whether the C++ compiler (g++  -s) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ static flag -static works... -static
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking command to parse /usr/bin/nm -B output... yes
checking how to hardcode library paths into programs... immediate
checking for /usr/bin/ld option to reload object files... -r
checking dynamic linker characteristics... Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for objdir... .libs
creating libtool
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for KDE... libraries /usr/lib, headers /usr/include/kde
checking for extra includes... no
checking for extra libs... no
checking for kde headers installed... yes
checking for kde libraries installed... configure: error: your system fails
at linking a small KDE application!
Check, if your compiler is installed correctly and if you have used the
same compiler to compile Qt and kdelibs as you did use now

I use tcsh as my shell..

It looks like it finds the libraries it needs...  Is this a problem with
ld?  I have not had this problem before.  The compiler configure is trying
to use appears to be gcc.  I tried forcing this to another compiler and 
got the same results.
Comment 1 Jakub Jelinek 2000-10-20 07:41:26 EDT
Depends on whether the application is KDE1 or KDE2. I'm forwarding this to the KDE guys
which will tell you details.
Comment 2 Bernhard Rosenkraenzer 2000-10-20 08:06:49 EDT
You are trying to compile a Qt 1.4x application with Qt 2.2.0.

To compile KDE 1.x applications, run

konfigure --whatever

rather than

./configure --whatever

as mentioned in the release notes.

We set QTDIR to qt-2.2.0 by default because Qt 2.x is really much much better than 1.x.
Comment 3 Jarin Satterlee 2000-10-20 14:11:46 EDT
This is the first time I have heard of konfigure...  I have compilied other
kde application according to the INSTALL file.  Having been a unix sys admin for
several year I do know a thing or two.  I noticed that there was both qt1.45 and
qt2.2 on my system.  Before trying to configure, I set my LD_LIBRARY_PATH to
have the qt1.45 path first in the list.  Does the values in the ld.so.conf
take precedent over the env variable?  Does the order of the library in the
load path matter?  

Why is there a separate command for compiling kde1 apps and do I use konfigure 
for all kde apps?  Is the INSTALL files going to be updated to reflect this?

Thanks.
Comment 4 Bernhard Rosenkraenzer 2000-10-20 14:38:27 EDT
The konfigure program is specific to Red Hat Linux 7.
It is basically a wrapper around the normal configure script (take a look at the file for details, it's a shell script).
Setting LD_LIBRARY_PATH takes precedence over ld.so.conf, but has nothing to do with the problem: The configure script can't find the Qt 1.x include files.
You need to set QTDIR.

Also, since we've compiled Qt 1.x and kdelibs 1.x with egcs 1.1.x (they work fine with 2.96, but since kde 1.x is provided primarily for backwards compatibility, we're trying to be really backwards compatible), it's a good idea to use egcs 1.1.x for compiling KDE 1.x applications, which konfigure takes care of, as well.

The INSTALL files won't be updated because they're not ours; but the (our) release notes mention you should always use it instead of ./configure for KDE 1.x applications.

Note You need to log in before you can comment on or make changes to this bug.