help configure find qt/gcc3

[Yendor]

Since we now have to compile qt can we change the configure process to not search the system for it and instead assume it is installed in /usr/local/qt-gcc3-2.3.2 (or wherever you all want to specify it as). This will help the different versions of qt coexist more happily. Preferably in a path/name that the seq 3.1.2 search sequence won't find. Yes I am still using 3.1.2 sometimes for logging because I am too lazy to go add it into 4.x myself.

Anyway I just thought it might help resolve some of the install problems. Just an idea.

Yes I know you can specify them on the command line, just trying to make things a tad simpler for folks.

Also a change to look first for gcc3 and g++3 before trying gcc/g++ would be a nice addition as well and would help people who have to run 2 compiler versions. Yes I know how to get around it with configure flags and/or environment variables... again just a suggestion to make things a tad easier and to cut down the basic questions posted to the boards.

Just an idea....

[casey]

heres a better idea,

"./configure CC=gcc3 CXX=g++3 QTDIR=/usr/local/lib/qt-gcc3-2.3.2"

the whole purpose of autoconf is to *not* hardcode things like this.

[Yendor]

No, the point of autoconf is configure the compilation of a package to match site/OS installation. By having it search in /usr/local/qt-gcc3-2.3.2 first (have you looked in acinclude.m4 and see how it searches for qt?) and check g++3 and gcc3 first you eliminate the need for special flags and conditions. The whole point of autoconf. Clearly at one point people agreed with that and hence the entire convoluted search for qt that already exists. Or are we going to go backwards and require the enduser to know more about the system, lets get rid of the entire autoconf process and just have a standard Makefile that people have to modify for their site like in the good 'ol days.

How many times do we need to answer the same questions when we can fix it to not be an issue. I will even create the patch if it would get used (the qt search is trivial is you decide on a default install of qt-gcc3-2.3.2 directory... if not there it will fallback to the original search order and you are no worse off for wear....).

Just my opinion. Apparently no one has agreed with any of my opinions yet, such is life. I would just rather see the message boards filled with genuine bug reports and people discussing new things rather than installation/compilation issues.

I'll shutup if you all like.

[casey]

(have you looked in acinclude.m4 and see how it searches for qt?)

i cant say ive looked too closely at the macro showeq uses, but i do believe it is derived from the KDE macro. I have however *written* an autoconf macro to locate qt-mt.so and determine whether or not it really supports threads based off of the bnv_qtsomething macro, so i'm fully aware of how it works.

While it would save you a good 30 characters of typeing to add your specific path to the search macro (in more than one place), $QTDIR has already been included in all the searches for the purpose of this.

No, the point of autoconf is configure the compilation of a package to match site/OS installation.

yes, but unfortunatly i386-pc-linux-gnu is as specific as the autoconf build target gets for a linux box. pc may be unknown and i386 may be soem other processor, but you get the point. Autoconf does not differentiate between redhat, debian, slackware, etc installs, so all it can determins is that you are linux.

i, for example, have gcc-3.0 and g++-3.0, and my qt is installed in /usr/lib/qtgcc3, should i add my paths into autoconf too?

How many times do we need to answer the same questions when we can fix it to not be an issue.

if people took the time to read the output of ./configure --help it wouldnt be an issue, and if were a choice between letting everone blindly work, or helping people to think for themselves and use some problem solving skills, guess which i choose?

[Yendor]

Actually autoconf can take care of a lot of differences between linux distributions, software installation paths, different libc versions, etc, etc. It's not just building a blind pattern based on predefined platform profiles (like the god awful configure in qt does), it has some search flexibility within those guidelines and I just thought if it we could take advantage of that it would be a good thing.

Anyway I posted a simple addition to configure.in that searches for gcc3/gcc-3.0 (if that is a common name for v3 gcc, saw that you used it and it was simple enough to add).

I will agree with you on qt however. Since QTDIR is defined by the system installed redhat qt package it always would get found first by any search unless the user explicity changes the environment variable or it is passed to configure on the command line. So the best option there seems to be to pass it to configure (the search will still find it if there isn't a system qt installed, which is good enough for me). Though I wonder if there could be any problem with running showeq with a different QTDIR set than it was compiled for?

Just idle thoughts.

[Yendor]

Cassey, you know... I went and tried that configure line you suggested (been using a scripts before to select my development environment), it doesn't work. You can't set environment variables on the configure line like that. But you can use
--with-qt-dir=DIR option for setting the qtdir. So I'd just add my gcc3 search patch and maybe a not in the INSTALL file to use --with-qt-dir if you have multiple versions of qt installed. Just an idea.

[casey]

maybe you need to update your autotools?

i run
automake 1.5
autoconf 2.52
libtool 1.4.2

and i offer my proof

casey@caseybox:~/code/showeq$ ./configure --enable-maintainer-mode CC=gcc-3.0 CXX=g++-3.0 QTDIR=/usr/lib/qtgcc3-2.3.2
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/home/casey/code/showeq/missing: Unknown `--run' option
Try `/home/casey/code/showeq/missing --help' for more information
configure: WARNING: `missing' script is too old or missing
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for gcc... gcc-3.0
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix... 
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc-3.0 accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of gcc-3.0... gcc3
checking whether we are using the GNU C++ compiler... yes
checking whether g++-3.0 accepts -g... yes
checking dependency style of g++-3.0... gcc3
checking how to run the C preprocessor... gcc-3.0 -E
checking for gcc-3.0 option to accept ANSI C... none needed
checking for an ANSI C-conforming const... yes
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets ${MAKE}... (cached) yes
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking how to recognise dependant libraries... pass_all
checking command to parse /usr/bin/nm -B output... ok
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc-3.0 option to produce PIC... -fPIC
checking if gcc-3.0 PIC flag -fPIC works... yes
checking if gcc-3.0 static flag -static works... yes
checking if gcc-3.0 supports -c -o file.o... yes
checking if gcc-3.0 supports -c -o file.lo... yes
checking if gcc-3.0 supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether -lc should be explicitly linked in... no
creating libtool
checking for supported compiler version... yes
checking for supported libc version... yes
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for IceConnectionNumber in -lICE... yes
checking for libXext... yes
checking for extra includes... no
checking for extra libs... no
checking for libz... -lz
checking for libpng... -lpng -lz -lm
checking for Qt... yes
>> Found version.:      2.3.2
>>> Headers......:      /usr/lib/qtgcc3-2.3.2/include/
>>>> Libraries...:      /usr/lib/qtgcc3-2.3.2/lib/
>>>>> Workable...:      -*{ YES }*-
checking for Qt MOC... yes
checking if Qt compiles without flags... no
checking for pthread_create in -lpthread... yes
setting Linux pthread compilation options
checking for pcap_open_live in -lpcap... yes
checking for gdImageCreate in -lgd... no
./configure: havegd: command not found
checking for gdImagePng in -lgd... no
checking for inflate in -lz... yes
checking for gdbm_open in -lgdbm... yes
checking how to run the C++ preprocessor... g++-3.0 -E
checking for ANSI C header files... yes
checking for deque.h... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for size_t... yes
checking whether to build with decryption... yes
checking for ProcessPacket in -lEQ... yes
checking whether to enable debugging code and flags... yes
checking whether to build with optimization enabled... yes
checking whether to build with code inlined... yes
checking whether to build with profiling... no
checking whether to build with Berkeley DB3... no
checking whether to build for use with the test server... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating maps/Makefile
config.status: creating conf/Makefile
config.status: creating conf.h
Success!
Please run:
  make

[Yendor]

/shrug, new feature. missing the point of trying to minimize changes to stock system needed to build seq. but that obviously isn't on the list of anyone's concerns. i just have a different point of view. doesn't matter really.

[casey]

its all relative, for you, the redhat user, you need to make changes to have my command work. Myself, a debian user does not, because my distro stays up to date.

for me the change to showeq was minimal, just downloading qt and compileing it. I took the extra step to package it for the use of others.

but why should showeq be tailored to a specific distributions stock install? And if we do, lets make it debian, my package is out there, do a stock ftp install, install my package, then build showeq, almost no work.

[Yendor]

You would do what many packages do. Develop a configure script that handles the standard installation of all distributions that people contribute fixes for provided the fixes aren't so extensive as to risk breaking other distributions. I am by no means saying that everyone should use rh, i am just saying it wouldn't hurt for configure.in to be able to handle a stock redhat gcc3 install. This is really a minor issue.

If any changes were needed to work with a stock debian gcc3 install then configure.in should work with that.

It's a small thing I just let it get under my skin for a while.

[Fly]

missing the point of trying to minimize changes to stock system needed to build seq. but that obviously isn't on the list of anyone's concerns.

Ya damn right.

its all relative, for you, the redhat user, you need to make changes to have my command work. Myself, a debian user does not, because my distro stays up to date.

Thouroughly owned.

Casey > Yendor
Debian > RedhatE

[Zaphod]

If I could find someplace to host them I have RPMs for Qt 2.3.2 compiled with the stock gcc/g++ 3.x that comes with RedHat 7.2.

Enjoy,
Zaphod (dohpaZ)

[semgin]

I would love to get a copy of that qt rpm you made zaphod. That would certainly solve all the problems i am having with the compile.

Semgin

[Yendor]

Fly,

I'm hurt. Please don't make me cry any more.

[Fly]

Yeah, I felt like being an ass. Sorry.