| |||||||||||||
The case for the /usr mergeThe case for the /usr mergePosted Jan 27, 2012 14:51 UTC (Fri) by RobSeace (subscriber, #4435)In reply to: The case for the /usr merge by mpr22 Parent article: The case for the /usr merge
True enough... But, if it's just some obscure rarely used feature, I'd think it makes sense anyway... Even if you don't want to indirect all API calls through dlsym() and such, what you could do is separate out all the code that interacts with that library into a sort of plug-in library of its own, needing just one simple call into that lib from the main app to do everything... The separate lib can still directly call all functions from the system library with no confusing indirection, and even be linked against it if you want... (Or, the main app can just dlopen(RTLD_GLOBAL) it prior to dlopen()'ing this separate lib...)
(Log in to post comments)
The case for the /usr merge Posted Jan 27, 2012 16:45 UTC (Fri) by dashesy (subscriber, #74652) [Link]
While the whole plugin approach is nice, it is not worth it just to save a few bytes. It might even produce bigger binaries, and the additional complexity will bring more errors.
The case for the /usr merge Posted Jan 27, 2012 17:00 UTC (Fri) by RobSeace (subscriber, #4435) [Link]
I didn't think the idea was to reduce app size, but rather to reduce dependencies required for rarely-used features... So that one could choose NOT to install the plugin and its required system library, and still be able to use all the more common features of the app, and merely lose the ability to use the obscure feature...
Just run gentoo :-) n/t Posted Jan 28, 2012 12:22 UTC (Sat) by Wol (guest, #4433) [Link]
Cheers,
Wol
|
|||||||||||||