[Development] Removing libudev dependency from binary packages?

[Pau Garcia i Quiles]

Hello,

What about dlopen/dlsym?

Due to problems like this, InterSystems ( http://www.intersystems )
resorted to:
a) Distribute third-party dependencies, and
b) dlopen/dlsym *every* third-party dependency in their software (and they
have quite a lot: zlib, OpenSSL, Xerces, Samba, libXSLT, libXML2, ANTLR,
LDAP, libssh2, Xalan, etc)

The dlopen/dlsym method usually works* even if someone is setting
LD_LIBRARY_PATH because he wants/needs to use newer versions of some
library.

* Unless there have been severe changes in API/ABI but if someone is
setting LD_LIBRARY_PATH, he knows what he's risking

Would it be possible to dlopen/dlsym libudev and have a fallback code path?




On Tue, Oct 22, 2013 at 8:05 AM, Hausmann Simon <Simon.Hausmann at digia.com>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 :(
>
>
>  Simon
>
>     *Fra: *Donald Carr
> *Sendt: *07:46 tirsdag 22. oktober 2013
> *Til: *Thiago Macieira
> *Kopi: *development at qt-project.org
> *Emne: *Re: [Development] Removing libudev dependency from binary
> packages?
>
>  God dag,
>
> I still don't follow the need for remove udev support:
>
> http://packages.ubuntu.com/lucid/libudev-dev
>
> There udev is as far back as Lucid. Where is it not present, exactly?
>
> When you remove it from webkit, you remove joypad hotplug detection.
> When you remove it from Qt, you remove the only generalized mechanism
> for hot plugging USB devices on Linux systems. Are we doing this in
> order to facilitate the same package being used from Ubuntu 13.10
> through to Slackware 1.0?
>
> Cheerio,
> moi
>
> On Mon, Oct 21, 2013 at 3:18 PM, Thiago Macieira
> <thiago.macieira at intel.com> wrote:
> > 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?
> >
> > The fix for platforms other than Linux is to split QtPlatformSupport into
> > multiple libraries, one per purpose. At the very least, one library per
> > *external* dependency.
> >
> > Or simply remove the library and let the few files that each plugin
> needs be
> > compiled multiple times (this would also require moving the wayland
> plugin
> > back into qtbase). Not a solution for 5.2, I guess.
> >
> > We may want to investigate turning on --as-needed everywhere. I've been
> > building Qt with that flag for years. However, it might introduce
> problems
> > related to building a new version of Qt when an older version is already
> > present and installed, even though we are apparently already doing what
> we
> > need to do (pass --rpath-link).
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel Open Source Technology Center
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
>
>
>
> --
> -------------------------------
>  °v°  Donald Carr
> /(_)\ Vaguely Professional Penguin lover
>  ^ ^
>
> Cave canem, te necet lingendo
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131022/aa9f6222/attachment.html>