[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: