On 11/11/11 10:59, Kevin Crowe wrote:
Hello,
Say we put a library into Userland and we build it as-is from the source
archive available from the community. Then imagine sometime later we want to
optimize some routines in it especially for our own benefit - but for some
reason the community does not want those optimizations.
I see two possible scenarios unfolding from this:
1) community doesn't take our optimizations, our build of that component now
diverges some amount from the publicly available version and we just
build/package what we have with our optimizations and anyone that installs that
package gets our optimizations - for better or worse.
2) if (for whatever reason) the optimized library works good for us but in
general isn't the best one for most folks to use: we maintain 2 different
versions of the library, one with optimizations and one without and we
build/package both of them
Scenario 1 is easy (except for the fact that it may make upgrades a real pain
to merge in/re-code our optimizations.) But can we deal with scenario 2 somehow
in Userland? I know we've talked about having multiple versions of other
components where one lives as the default and the other (newer or older) is
made available as a choice, but can that be done with a library? I think with
multiple versions of a component (i.e. Python) theres something specific in the
path that indicates which version you run. I don't know if libraries have
another way to deal with this?
This is just a hypothetical question and I might be worrying for nothing,
however I want to know if I can deal with scenario 2 if it occurs. Unless
there's another way to handle such a problem?
Thanks,
Kevin.
Hi Kevin,
I don't think the linkers can help you out of a situation where
two libraries have the same name, and interfaces, but incompatible
behavior. That's something you should strive to avoid at all costs.
It depends on the sort of optimizations you're talking about.
If it boils down to optimizing for specific hardware (i.e. compiler
flags), then you could look into making use of the "capabilities"
features of the Solaris linkers:
http://linkers.us.oracle.com/OSLLG/s11/html/p5.html#chapter2-19
These let you build different variants of a given library with
different platform/hardware optimizations. It can be a lot of work
to do this --- we use them in libc and few other places in Solaris,
but not generally. I don't think we have any examples of this in
Userland currently --- It can be difficult to use these with FOSS
packages because they come with their own build systems, which are
generally brittle, hard to understand, and not worth changing.
Anyway, it doesn't sound like the sort of optimizations you're talking
about fall into that category --- these would be compatible differences
(same interfaces, compatible performance differences), so I mention it
just for completeness.
To manage incompatible differences, I can think of a couple alternative
strategies, each with some advantages, and some disadvantages:
- Put the optimized version in a "secret" location, rather
than /usr/lib, and then ship the standard one in the standard
location. Applications that need the optimized version can link
against the secret place.
You'll get into trouble here if a program relies on two libraries,
one of which relies on the standard one, and the other on the
optimized one. There's precedent in Solaris, both for using this
strategy, and for getting into trouble with it... Buyer beware... :-)
- Give the optimized library a new unique name, and ship both versions.
You've effectively forked the community version, so why not? Don't
expect anyone outside our little Solaris world to know what it is
though. The obvious downside is that no one will use it, since
they don't know what it is, or what guarantees it comes with. Even
with this approach, there are ways in which the "2 libraries" scenario
I mentioned in the previous point can bite you, unless you're using
direct binding in the libraries.
Bottom line: You'll save yourself and everyone else a lot of trouble
if you avoid any incompatible changes to any public libraries. It's rarely
worth the optimization.
If you'd like to discuss more specific concerns, please ask those questions
and we'll do our best to help.
- Ali
_______________________________________________
userland-discuss mailing list
userland-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
