On 10/27/2013 01:49 AM, Allan Sandfeld Jensen wrote:
On Friday 25 October 2013, Thiago Macieira wrote:
On sexta-feira, 25 de outubro de 2013 16:01:11, Allan Sandfeld Jensen wrote:
I think it is a bit too small to make into a qtlinuxextras library, and
could we even depend on extras? I think
Having realized after some work that QtWebKit is now trying to achieve more
or less the same as QtSerialPort ... how about about the udev resolver to
QtCore now as a private stuff ... like qtlibudev_p.h or similar kind.
Afterwards, QtWebKit could use core-private, so could QtSerialPort. We
would
On sexta-feira, 25 de outubro de 2013 14:12:24, Laszlo Papp wrote:
Having realized after some work that QtWebKit is now trying to achieve more
or less the same as QtSerialPort ... how about about the udev resolver to
QtCore now as a private stuff ... like qtlibudev_p.h or similar kind.
On Friday 25 October 2013, Thiago Macieira wrote:
On sexta-feira, 25 de outubro de 2013 14:12:24, Laszlo Papp wrote:
Having realized after some work that QtWebKit is now trying to achieve
more or less the same as QtSerialPort ... how about about the udev
resolver to QtCore now as a private
On sexta-feira, 25 de outubro de 2013 16:01:11, Allan Sandfeld Jensen wrote:
I think it is a bit too small to make into a qtlinuxextras library, and
could we even depend on extras? I think qudev would fit best in qtbase
because udev is also used by evdev which is in qtbase.
It's just one
: [Development] Removing libudev dependency from binary
packages?
[...]
We agreed with Kai on IRC, when discussing this topic, that we would ask the
udev mailing list for an authoritative reply unless someone can confirm that
on this list just as well.
Actually I just checked the sources, and libudev
To: Sune Vuorela
Cc: development@qt-project.org
Subject: Re: [Development] Removing libudev dependency from binary
packages?
[...]
We agreed with Kai on IRC, when discussing this topic, that we would ask
the udev mailing list for an authoritative reply unless someone can
confirm
On quinta-feira, 24 de outubro de 2013 13:33:10, Oswald Buddenhagen wrote:
the lgpl does not limit how *we* can build and distribute our packages,
because we ship the sources anyway.
the ones who'd have a problem would be our customers.
but why is everyone talking about static linking,
libudev dependency from binary
packages?
On quinta-feira, 24 de outubro de 2013 13:33:10, Oswald Buddenhagen
wrote:
the lgpl does not limit how *we* can build and distribute our
packages, because we ship the sources anyway.
the ones who'd have a problem would be our customers.
but why
On quinta-feira, 24 de outubro de 2013 13:46:39, Koehne Kai wrote:
I just asked, it seems not to be possible:
http://www.marshut.com/yiqmk/can-apps-ship-their-own-copy-of-libudev.html
So we're back to either moving the libudev dependency to a plugin that
qtserialport tries to load (huh),
https://bugreports.qt-project.org/browse/QTBUG-34329
On Thu, Oct 24, 2013 at 4:36 PM, Knoll Lars lars.kn...@digia.com wrote:
Sounds like dlopen¹ing is the way to go. Sucky, but at least it¹ll work.
And according to the post below most things should be compatible between
udev0 and udev1.
Actually having thought a bit about this, and written the change more or
less, my personal opinion is that it would be better to get distribution
packages (via OBS or any other kind) correctly in the future...
udev, and probably other libraries might not guarantee binary compatibility
for
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[...]
After this, my opinion is that the preferred way to go should be to think more
in native package system for Linux. For example, Clang is shipping nightly
builds through the package system:
On quarta-feira, 23 de outubro de 2013 07:23:22, Alejandro Exojo wrote:
Isn't exactly the same situation as with Qt? When the next version of Qt
4.8 breaks binary compatibility, libqt5 is introduced. You link against
either one or the other, and generally, both could be available for you to
On 2013-10-21, Thiago Macieira thiago.macie...@intel.com wrote:
Anyway, my suggestion thus:
- QtSerialPort: statically link to libudev
btw, does anyone know how close the libudev version should match the
udev-daemon version? are there any library/daemon protocol stability
guarantees?
What
On 22/10/13 19:00, Thiago Macieira wrote:
On terça-feira, 22 de outubro de 2013 15:51:56, Philip Ashmore wrote:
Sounds like you need a generic plug-in framework that allows you to ask
for a udev component that you ask for an IUDev interface.
Oh wait, I've written one, called v3c-dcom,
On terça-feira, 22 de outubro de 2013 06:05:13, Hausmann Simon wrote:
I think the problem is shipping binaries that accommodate the fact that
every distro ships libudev in a different major version. That means you
can't reliably use dynamic linking
Right.
There are two major versions of
On 22.10.13 09:24, Thiago Macieira thiago.macie...@intel.com wrote:
On terça-feira, 22 de outubro de 2013 07:01:22, Knoll Lars wrote:
There are two major versions of libudev in use in major distros:
libudev.so.0
and libudev.so.1. The new one has been in use for about a year, so we
can
expect
-bounces+laszlo.agocs=digia@qt-project.org
[development-bounces+laszlo.agocs=digia@qt-project.org] on behalf of Koehne
Kai [kai.koe...@digia.com]
Sent: Monday, October 21, 2013 4:29 PM
To: development@qt-project.org
Subject: [Development] Removing libudev dependency from binary packages
Hi guys,
e.g. related to QtSerialPort we can try to rewrite the libudev linking
dynamically.. I'm think..
Probably we will be in time to 5.2... :)
Best regards,
Denis
22.10.2013, 11:28, Knoll Lars lars.kn...@digia.com:
On 22.10.13 09:24, Thiago Macieira thiago.macie...@intel.com wrote:
On
On terça-feira, 22 de outubro de 2013 07:27:50, Knoll Lars wrote:
So much for Linux distributions keeping binary compatibility. Not
providing the package means you break every 3rd party app that needs
libudev and doesn't come as part of the package management.
Distros have never promised
On 22 October 2013 12:35, Laszlo Papp lp...@kde.org wrote:
PS.: But yes, so much for Linux distributions keeping binary compatibility.
:/
PS: there is no such concept for non-LSB software. For those, you just
need to compile it against the distribution itself; binaries produced
by other means
On 22/10/13 15:42, Thiago Macieira wrote:
On terça-feira, 22 de outubro de 2013 11:39:30, Pau Garcia i Quiles wrote:
What about dlopen/dlsym?
I hate that option. I hate where we use it and I'd rather we didn't.
In particular, since we're trying to locate one of two major versions, we
On terça-feira, 22 de outubro de 2013 15:51:56, Philip Ashmore wrote:
Sounds like you need a generic plug-in framework that allows you to ask
for a udev component that you ask for an IUDev interface.
Oh wait, I've written one, called v3c-dcom, available in SourceForge.
We have it too: it's
El Martes, 22 de octubre de 2013, Knoll Lars escribió:
So much for Linux distributions keeping binary compatibility.
Isn't exactly the same situation as with Qt? When the next version of Qt 4.8
breaks binary compatibility, libqt5 is introduced. You link against either one
or the other, and
Hi there,
In the latest Linux binary packages for 5.2 libQt5Webkit depends on
libudev.so.0, which isn't installed (or at least not in this version) on a lot
of distributions:
https://bugreports.qt-project.org/browse/QTBUG-34176
The easiest fix would be to configure Qt with -no-libudev /
Hi Kai,
I can say only about the QtSerialPort.
The QtSerialPort module is used the libudev ((more precisely - the libudev
devel is required !!!) as preferred way (for the QSerialPortInfo class) to
detect a names and other info about present serial ports.
The support of libudev will detected
On segunda-feira, 21 de outubro de 2013 14:29:27, Koehne Kai wrote:
Hi there,
In the latest Linux binary packages for 5.2 libQt5Webkit depends on
libudev.so.0, which isn't installed (or at least not in this version) on a
lot of distributions:
On 2013-10-21, Thiago Macieira thiago.macie...@intel.com wrote:
But what distributions are those that don't have libudev.so.0?
Most modern ones I think.
http://git.kernel.org/cgit/linux/hotplug/udev.git/tree/Makefile.am
Note that udev in general is built from systemd source tree, even for
On segunda-feira, 21 de outubro de 2013 23:07:25, Thiago Macieira wrote:
- libqgtk2: fix, it doesn't need libudev
The fix for libqgtk2 can probably be:
linux: QMAKE_LFLAGS += -Wl,--as-needed
Can anyone check if the other plugins linking to QtPlatformSupport also have
the udev dependency?
30 matches
Mail list logo