Re: Signal 11 compiling qt33

On Thu, 12 Aug 2004, Michael Nottebrock wrote:

> Maybe. Maybe there are some software related factors there, too (qt isn't
> generally more sensitive to typical scenarios of ports-based installations
> being inconsistent in a way that makes stuff break - like the mixed threads
> libraries example. The difference is, qt very often just fails in a rather
> undescriptive way, and as it seems, way more often in some places than others
> (uic)).

uic and dcopidl crashes are indicative of crossed thread libraries. I
know, I went through the same problem :)  If you ldd them you'll see
libc_r and libpthread both getting pulled in, which is fatal.  Both uic
and dcopidl pull in libqt, which will usually be the lagggard since its
using options saved by qmake, and doesn't get updated frequently enough
for it to get rebuilt during a kde/qt upgrade.

You want to rebuild stuff in this order:

1. XFree86-libraries (or the xorg equivalent)
2. qmake (everyone forgets this -- qt uses it to get compile and link
options, including the thread library!)
3. qt33
4. qt dependencies (kde, etc.)

It took me a week to get this straightened out on my dual 600 current
builder.  Really understood the problem and solutions afterward through :)

You can use the libmap hack, but that will only bite you in some hidden
way later when the libraries change again.

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite_at_gumbysoft.com          |  www.FreeBSD.org