Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for June 20, 2013
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
The case for the /usr merge
Posted Jan 27, 2012 14:20 UTC (Fri) by mpr22 (subscriber, #60784)
The sanity or otherwise of that approach is so wildly variable that it can only be evaluated on a case-by-case basis. dlopen() adds a significant comprehensibility overhead compared to just invoking the library's API directly, and may well preclude sane-and-convenient use of the normal programming model for the library in question.
(The latter effect becomes particularly severe when you're writing a C++ program using C++ libraries, of course.)
Posted Jan 27, 2012 14:51 UTC (Fri) by RobSeace (subscriber, #4435)
Posted Jan 27, 2012 16:45 UTC (Fri) by dashesy (subscriber, #74652)
Posted Jan 27, 2012 17:00 UTC (Fri) by RobSeace (subscriber, #4435)
Just run gentoo :-) n/t
Posted Jan 28, 2012 12:22 UTC (Sat) by Wol (guest, #4433)
Posted Jan 29, 2012 21:55 UTC (Sun) by elanthis (guest, #6227)
However, why should the library be directly dlopen'd? Why not put a plugin architecture into wpa_supplicant itself, with the plugin linking against the library normally, and with only a very narrow and plugin-friendly interface being shared across that dlopen boundary? This even makes it trivial to have the package manager intelligently support the package dependencies by putting the plugin in its own package; users who need the feature install the plugin and get all dependencies pulled in, and users who don't will not need those. There's then a case to be made that the network configuration tools in Anaconda and the desktop tools need to be made aware of feature package dependencies to pull these things in automatically, but that's a polish thing (not FOSS's strength, but not out of the realm of possibility by any stretch).
[*] There's an argument to be made -- especially in the FOSS world where the source is available and modifiable by anyone and everyone -- that libraries should offer the kinds of interfaces their clients prefer, rather than client applications making "not our fault" claims when library interfaces don't allow features users want (like moving dependencies from compile-time to run-time).
Posted Jan 30, 2012 2:30 UTC (Mon) by HelloWorld (guest, #56129)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds