Qt3 breakage since 1.5.19

[René Berber]

Yaakov S (Cygwin Ports) wrote:

>>>Running Scribus with the debug enabled cygqt-mt-3.dll the program
>>>works fine with no mutex failure message and using the latest Cygwin
>>>snapshot.  As mentioned in my reply to Brian, under gdb there are many
>>>SIGSEGV signals received but continuing results in the same behaviour
>>>as above: no problem.
>>>
>>>So there seems to be no regression, there must be something different
>>>btw. the original build environment and my PC.  I used the code (build
>>>script, patches and original code) downloaded using setup.exe.
> 
> 
> OK, we need to get back to this.  Now that cygwin-1.5.19-4 is out, I'm
> seeing the same breakage with qt3-3.3.4:
> 
> $ scribus
> Mutex init failure: Device or resource busy
> [splashscreen shows, gets as far as loading plugins, then:]
> Mutex init failure: Invalid argument
> [exits silently]

Yep, exactly my original problem.

> $ convertall
> [this is a PyQt app.  It exits silently also.]
> 
> But not everything is affected apparently:
> 
> $ xxdiff file1 file2
> Mutex init failure: Device or resource busy
> [works, just like before]
> Mutex lock failure: Invalid argument
> Mutex unlock failure: Invalid argument
> Mutex destroy failure: Invalid argument
> 
> 1) Something changed between 1.5.18 and the 20051207 snapshot to break
> qt3 threading.

Or the change exposed a bug in Qt.

> 2) It should not be necessary to have a debug library in order for
> ordinary programs to work.

The library is as close as it gets to a regular library, I separated the debug
info, it's just not optimized.

It would be interesting to test a rebuilt regular library, have you done that?

> 3) A threaded Qt is required for many packages, including KDE, so
> disabling threading is not a viable option.
> 
> Ideas?

All those "mutex lock failure" point to the threads implementation.  If you want
to go from "what changed in Cygwin's dll" forward, it has to be something in
threads.

Going the other way, what I tried is using gdb trying to look at what breaks the
program.  The worst part is that under gdb they run fine many times, then break
(with the debug library).

Yet another approach could be to do the porting of the newer 3.x/4.x version.
-- 
René Berber


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/