libproxy crashes Qt5 applications due to KDE libraries incompatibility

[GoogleCodeExporter]

I tried to prototype a Qt5-based multimedia player using GStreamer. Libproxy 
always crashes my application because it tries to interface with kdelibs which 
are built against Qt4. I originally believed it was a KDE issue so I reported a 
bug there, for details with backtrace and MWE see 
https://bugs.kde.org/show_bug.cgi?id=323407.
At this point libproxy cannot be used by applications built against Qt5 on 
systems where libproxy tries to use kdelibs.

Original issue reported on code.google.com by madcatxs...@gmail.com on 30 Aug 2013 at 3:50

[GoogleCodeExporter]

If the KDE guys would know about symbol versioning, they would probably not run 
into such issues.

I'm afraid this will be only one of the cases where crashes a like will happen; 
will be an interesting challenge I'm afraid :(

Original comment by dominiqu...@gmail.com on 3 Sep 2013 at 12:10

[GoogleCodeExporter]

I have same issue and found this article.
Can you allow users to make libproxy ignore proxy setting and just return given 
address with an environment variable like LIBPROXY_IGNORE_PROXY?
With px_proxy_factory_new() Qt5 app crashes, so the controllable variable 
should be set before call any function of libproxy and I think environment 
variable is proper.

Original comment by darkli...@gmail.com on 11 Oct 2013 at 2:00

[GoogleCodeExporter]

Another issue is discovered. When resolve libkdecore, the locale is changed 
from KDE side.
https://github.com/mpv-player/mpv/issues/279
A method to disable to try to resolve libraries with dlopen is really and 
urgently required.
Of course you may think if someone does not want to such behaviour, he or she 
should not use libproxy.
However, in both case of mine and mpv's, they do not depend on libproxy 
directly. They use a library(libquvi) which dpends on libproxy and similar 
situation could exist with other combinations.

Original comment by darkli...@gmail.com on 12 Oct 2013 at 3:56

[GoogleCodeExporter]

The best solution would probably be to parse the KDE config files manually, 
without loading KConfig.

Original comment by kevin.ko...@gmail.com on 7 Dec 2014 at 4:30

[GoogleCodeExporter]

I started a branch where libproxy (the lib linked into apps_) won't be more 
than a dbus client to the newly introduced libproxyd - and libproxyd doing the 
lifting and configuration parsing.

The advantage is that we do never load any framework libraries as indirect 
loads by libproxy - the only libs left libproxy will be pulling into the 
application space will be dbus related

Work in progress... but, in progress

Original comment by dominiqu...@gmail.com on 4 May 2015 at 5:06