Microsoft is long known for releasing bug ridden bloatware then charging for the bug fixes. Windows Vista followed by its bug fix Windows 7 and who could ever forget Windows ME? In its defense, Windows ME was not an operating system. It was a task switching GUI running on top of DOS fraudulently sold as an operating system just like 2000, 98, 95, 3.1x, 3.x, 2.x, 1.x and “for workgroups.” Anyone using or writing PC software in those days learned pretty quick “never use a dot zero release from Microsoft.”
Sadly Qt 5.8.0 is suffering a significant case of Microsoft Blues. You can find quite a few discussions on build failures all of which seem to be associated with the new configure executable, at least on Linux, professionals don’t do Windows so I wouldn’t know about compiling on that platform.
Thankfully the new configure executable creates a configure.log file which gives quite a bit of information. Way more than we used to get on the screen. When I was trying to compile I was trying to turn on Postgresql support. One of my tests with the new code was to compile my expense tracker program which Source Forge seems to have purged. There wasn’t any need to update it for many years so I didn’t and it appears Source Forge doesn’t allow stable applications that don’t need modification to exist for very long. I use this program every year to help prepare for taxes so I’m always compiling it when I put on a new Linux distro or new version of Qt.
The current Qt Fiasco
After slamming my head against keyboard repeatedly, I dug into the configure.log file to find out why this version of Qt couldn’t compile in Postgresql support.
looking for library psql
Trying source 0 (type pkgConfig) of library psql ...
+ /usr/bin/pkg-config --exists --silence-errors libpq
=> source produced no result.
Trying source 1 (type psqlConfig) of library psql ...
+ /usr/bin/pg_config --libdir
> You need to install postgresql-server-dev-X.Y for building a server-side extension or libpq-dev for building a client-side application.
=> source produced no result.
Trying source 2 (type psqlEnv) of library psql ...
=> source failed condition.
Trying source 3 (type psqlEnv) of library psql ...
+ cd /home/roland/qt5.8.0/qt-everywhere-opensource-src-5.8.0/qtbase/config.tests/unix/psql && /home/roland/qt5.8.0/qt-everywhere-opensource-src-5.8.0/qtbase/bin/qmake -qtconf /home/roland/qt5.8.0/qt-everywhere-opensource-src-5.8.0/qtbase/bin/qt.conf "CONFIG -= qt debug_and_release $
+ cd /home/roland/qt5.8.0/qt-everywhere-opensource-src-5.8.0/qtbase/config.tests/unix/psql && MAKEFLAGS= /usr/bin/make
> g++ -c -pipe -O2 -std=gnu++11 -Wall -W -fPIC -I. -I/home/roland/qt5.8.0/qt-everywhere-opensource-src-5.8.0/qtbase/mkspecs/linux-g++ -o psql.o psql.cpp
> psql.cpp:40:22: fatal error: libpq-fe.h: No such file or directory
> compilation terminated.
> Makefile:168: recipe for target 'psql.o' failed
You will notice the log is kind enough to show us what command it tried first to locate a required dependency: /usr/bin/pkg-config –exists –silence-errors libpq This is most helpful. I wrote a tiny test program to determine what is going wrong.
#!/bin/bash
/usr/bin/pkg-config --exists libpq
if [ $? -eq 0 ]
then
echo "it exists"
else
echo "not found"
fi
roland@roland-HP-Compaq-8100-Elite-SFF-PC:~$ ./tst.sh
it existsYes, I don’t write many bash scripts so I had to look things up in the on-line documentation. It seems I run into a project every few years where I need to write quite a few shell scripts, then I don’t do it for a long time. Thankfully I’m not too proud to look things up. Our hapless little configure programmer should have looked things up as well, then they wouldn’t have made a Noob (or Newb if you prefer) mistake. They fell victim to a long time design flaw in both C and Unix/Linux. Things returning zero to indicate success. I didn’t dig into the code of configure, but everything I tried to get the new configure program to find like Postgresql, MySQL and fontconfig, it failed at. Little test scripts like the one above prove that it should have found them.
The Flaw
Why do I consider this a design flaw? I’m old and have worked on real platforms. Returning zero to indicate “no error” is just bad form. Noob developers and tired seasoned pros alike will code something like
if (retVal)
// indicate success
else
// indicate failure
Coding the inverse is not a natural act.
if (!retVal)// indicate successelse// indicate failureHumans in general tend to focus on the success of what they do, not the failure. Those who focus on their failures tend to suffer from sever bouts of depression and paranoia so programming is not a good career move.
The fact configure made it out the door like this is a shining example of why Test Driven Development (TDD) should really be banned or at least renamed to The Bug Ridden Bloatware Method. Relying on a programmer to write a test for the module they just coded based on how they “think” it should work given the 5 line story they read is a bit like expecting a corrupt politician to do the right thing with your tax dollars.
View this as a “Microsoft quality” release and wait for a DOT ODD version.
For what it is worth, 5.7.1 built from scratch just fine and both test applications command line compiled then executed flawlessly. In case anyone is wondering, yes, everything needed to find Postgresql was there and then some.
roland@roland-HP-Compaq-8100-Elite-SFF-PC:/$ sudo find -iname libpq*
./usr/lib/postgresql/9.5/lib/libpqwalreceiver.so
./usr/lib/x86_64-linux-gnu/libpq.so
./usr/lib/x86_64-linux-gnu/libpq.a
./usr/lib/x86_64-linux-gnu/pkgconfig/libpq.pc
./usr/lib/x86_64-linux-gnu/libpq.so.5.8
./usr/lib/x86_64-linux-gnu/libpq.so.5
./usr/share/doc/libpq-dev
./usr/share/doc/libpq5
./usr/include/postgresql/internal/libpq
./usr/include/postgresql/internal/libpq-int.h
./usr/include/postgresql/libpq-events.h
./usr/include/postgresql/libpq
./usr/include/postgresql/libpq/libpq-fs.h
./usr/include/postgresql/libpq-fe.h
./var/lib/dpkg/info/libpq-dev.md5sums
./var/lib/dpkg/info/libpq5:amd64.triggers
./var/lib/dpkg/info/libpq-dev.list
./var/lib/dpkg/info/libpq5:amd64.list
./var/lib/dpkg/info/libpq5:amd64.md5sums
./var/lib/dpkg/info/libpq5:amd64.symbols
./var/lib/dpkg/info/libpq5:amd64.shlibs
./var/cache/apt/archives/libpq-dev_9.5.6-0ubuntu0.16.04_amd64.deb
What should exist in Linux
Oh, a bit of follow up on return values and real computers. On OpenVMS we have $STATUS and $SEVERITY. The low order 3-bits of $STATUS are masked off for $SEVERITY.
| 0 | Warning |
| 1 | Success |
| 2 | Error |
| 3 | Information |
| 4 | Severe (fatal) error |
As you can see, odd values are good things, even bad and zero means you should really look at this. This allows us to have a rash of values in the message library for every condition. It also allowed us to do things like this in DCL:
$ if .NOT. $STATUS
$ then
$ my_status = $STATUS
$ goto error_exit
$ endif
$!If the value wasn’t odd, we had an error. Everything works this way.
Don’t get me wrong, I’ve worked with C since the mid 1980s and C++ shortly after it came out. I enjoy working with it, but this “returning zero for success” concept was a biblical step backwards. It doesn’t allow for levels of success and it bit whoever coded the configure program pretty hard. In turn, that bit all of us.
EDIT: Interesting, I could not find “xpnsqt” using the Source Forge search but after logging in I can directly go there from my projects list.
For some more Qt bugs and design flaws, start here. The entire library has become bug ridden bloatware. Since I wrote this the bug database has ballooned to almost 31,000.
Shudder every time you have to go to a hospital because there are medical device companies using Qt.
