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 <[email protected]>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: *[email protected] > *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 > <[email protected]> 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 > > [email protected] > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > -- > ------------------------------- > °v° Donald Carr > /(_)\ Vaguely Professional Penguin lover > ^ ^ > > Cave canem, te necet lingendo > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > [email protected] > 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)
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
