[openbeos] Re: general update tool idea
- From: "Andre' F. Braga" <meianoite@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 20 Jun 2002 09:41:44 -0300
Kobi Lurie wrote:
cool to know that it gets the proper discussion/attention over at GE and
maybe more "standardization" that way.
^_^
ridding of dead .o images is great but i don't understand why shared
libraries would be better suited, as they get update too sometimes.
can u explain more? (while i dig up the net archives :)
It's because .o objects are not useful until they are linked together in
a bigger image (the program) or made a shared library. You can't run
plain .o objects, they are kind of intermediates between the symbolic
code you compiler compiled you source code into, and the final, runnable
program.
ofcourse, if we have more shared libraries (or a gigantic one)
it would probably mean that apps are very small since most of the code
is optimized and existing in the library.
Most likely. But it doesn't mean they will be "optimized" just because
they are on .so's. However this makes it possible to have specific
machine-optimized code in separate .so's, instead of having both Pentium
and AMD-specific code bloating the same library. And, of course, for
people like me who still use a 1st-generation Pentium, there would be
"clean", unoptimized (in the sense that they won't use extended
instructions like SSE and 3DNow!), unbloated libraries ^_^
do u mean so files are better since they get updated less often?
this is not always the case. check out libtracker.so for example.
it's quite big and tracker links against it. IIRC when i last built
tracker, the application was the same, with only the library changing.
It's not that they get updated less often, libraries are updated all the
time, but people usually stick to a version and build their apps around
them. It's very likely that you'll find apps which still work with the
very first M$ MFC libraries, but others require some specific version.
In this case, instead of relying solely on third-party libraries, you
would modularise your app into smaller objects, almost just like it's
done today, but instead of linking all the .o's together, you'd make
them .so's.
This idea still needs some polishing, though.
probably. just wanted to get audience to see the flaws/benefits ratio of
the idea.
That's what the discussion lists are for ^_^
And check GE-talk, there often are cool discussions in there, but it's
kinda silent these days...
--
"No hay banda! Todo esta' grabado!"
Other related posts:
