@wawa

Quote:

if a so. library has to be loaded separately for every application, then what the hell is the reason not to link this library statically at compile time, if the application in question is proven working well with available library version?

I see no reassons to not make static bins. I can say more - static bins are better, and use sobjes need only when its _really need_ (for plugins, or for some heavy apps which just fully based on .so usage). Making a libs or games which want tons of sobjs imho just bad (and the same say Rogue in that post).

Quote:

im just a little puzzled, what is the real advantage of .so against link libraries.

The real advantages that you can make and use .so when its really necesary: plugins and some heavy apps. As rogue say in his post:

Quote:

Shared Objects are primary intended for porting of programs from other systems. Any sufficiently large or complex program from Linux or Windows will, in one way or the other, rely on shared code, for various reasons. Usually, this type of code sharing does not translate very well (if at all) to the AmigaOS shared library model. Using shared objects for such projects is almost mandatory.

There is nothing like ".so now are replace classic libs", or like ".so will be next evolution of amiga libs" or kind. Introducing of sobjes just help us to port heavy stuff easy. And that is good, because while one will borking with writing something "only amiga", other one will just port some programm with plugins and just use it.

For example, with QT port its almost unpossible (of course everything possible, just will be a bit, or very, hard) to add support of classic amiga libs instead of .so, because:
Quote:

About the .library thing it is a combination of being way too much work and probably impossible to do. There is no way to import code into an amiga .library, as when subclassing Qt objects with virtual functions. So therefore no.

I assume also that for FF port, .so introducing helps as well. Can't be sure if FF code use some ".so only" code, and if it easy to have it working with .so , but i assume is it.

Last edited by kas1e on 30-Jun-2011 at 06:36 PM.
Last edited by kas1e on 30-Jun-2011 at 06:32 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@wawa

Quote:

wawa wrote: if a so. library has to be loaded separately for every application, then what the hell is the reason not to link this library statically at compile time, if the application in question is proven working well with available library version?

I suppose you could do that.

Suppose several programs are ported to the OS for compatibility with the mainstream
that use the same .so lib. Then, some time later a new function is added to its lib
in the other world.

If a static link is used then all OS programs using that object should be recompiled,
or just change the object and leave the programs alone.

DVplayer for example uses AVcodecs. If a new codec comes along it's just added to
the lib, not a new program version.

That's the way I see it anyway.

@Mechanic

You say now the same pluses of any kind of libs, and classic amiga libs, and sobjs libs and dlls, and any possible libs (except, that classic amiga libs have versioning, and avoid "dll hell" ). I think wawa mostly ask why need to use .so at all , and what advatages it give in compare with plain classic amiga libs.

But anyway, if new function added to library (.library, or .so, does not matter), but programm which use that libs/so not use those functions, then it will have nothing. The only matter and good side of libs, its that new version will be optimized, they will have new (and better) realisations of the same functions which programm already use.

In other words, static linking its just better for end users. Except some cases when statically linked library are very buggy, and everyone wait for new version, so yes, then libs/so usage will be good.

Last edited by kas1e on 30-Jun-2011 at 07:04 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@wawa

Quote:

if a so. library has to be loaded separately for every application, then what the hell is the reason not to link this library statically at compile time, if the application in question is proven working well with available library version? you avoid the so called .so hell of version bugs and incompatibilities for the price of some extra room on a hard disk, that costs nothing today. there is no advantage in loading time against statically linked apps for what i know. and if an application isnt working well with a current version of library which is expected to be fixed in future then it shouldnt be released yet, right?

It's .so true.

@kas1e

Quote:

Quote: I think it just isnt possible share dynamically linked objects. I am not deep in it, but as unix/linux do, so why not. Of course with some workorounds as usuall , but imho pretty possible.

Sharing object code would require remapping variable data to different memory locations. With plain .so this cant be done.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@wawa

Quote:

wawa wrote: ok, guys. i have already admitted not to read this through. i wonder, if there was some answer to such a question: if a so. library has to be loaded separately for every application, then what the hell is the reason not to link this library statically at compile time, if the application in question is proven working well with available library version? you avoid the so called .so hell of version bugs and incompatibilities for the price of some extra room on a hard disk, that costs nothing today. there is no advantage in loading time against statically linked apps for what i know. and if an application isnt working well with a current version of library which is expected to be fixed in future then it shouldnt be released yet, right? im just a little puzzled, what is the real advantage of .so against link libraries.

There is, or at least there was, a fixed limit on how big a single ELF executable can be on OS4, which for example has blocked for a while the first Firefox porting attempt. Also, if a version of a library has some known problems and there's a bugfixed version of that library available, you don't need to recompile every software that uses it as well. There are other advantages listed here too, in the "How it works" chapter.

Varthall

_________________
AmigaOne XE - AmigaOS 4.1 - Freescale 7457 1GHz - 1GB ram

In my opinion, slightly too much is made of the ".so hell". It just isn't as bad as people make out, after all, it works perfectly well for the vast majority of linux distros. Most have adopted a sensible naming scheme for versioning, that whilst nowhere near as handy as having a version string embedded (not that you couldn't if you wanted to put one in, it's just a string at the end of the day) that seems to work and most allow multiple versions of the same .so file to exist at once for those occasions where a major version number is not compatible with it's predecessor.

I think the problem is that people just don't see the point of .so files because they are focusing too much on the word "shared" in the same sense that AmigaOS libraries are shared and in that respect, .so files are no substitute at all.

The main impetus for .so files is not to have an alternate library system (.library files are perfectly good for that), nor to save disk space (though they do to an extent), but to provide an alternative to static linking for executables. The reason for providing that ought to be perfectly obvious. A statically linked executable is basically set in stone and unless the maintainer provides a newer version, no improvements to any library (not .library) components it made use of can be leveraged by any end user.

Of course, it's possible to put an incompatible .so file in there and break an application but you can just as easily do that with an incompatible .library update too, so that's not really an argument against, since in both cases you can just revert to a working version and in both cases, you can have libraries installed locally with the application rather than in a shared location like LIBS: or SObjs:.

I wouldn't be surprised if a "Not Invented Here" attitude towards .so files is a factor for some, but then ELF wasn't invented here either but we're all happy enough with those nowadays and let's face it, .so files are just part of the ELF repertoire.

_________________
Doing stupid things for fun...

@Karlos
Quote:

It just isn't as bad as people make out, after all, it works perfectly well for the vast majority of linux distros.

Really bad example. Linux distros tend to break binary compatibility, in each of their releases, and almost all apps are always compiled from source for each release. And the binary-only stuff on Linux either has a compilable wrapper, or staticly linked, down to the level of bare kernel syscalls.

Otherwise, I think the problem is as bad as people make it. Anyone who tends to install every random release and random libraries will probably run into issues. People with a clean usage pattern and a smaller set of apps will be less likely to experience problems.

_________________
MorphOS, classic Amiga, demoscene, and stuff
"When a bridge is not enough, build a Viaduct!"
"Strip the Amiga community of speculation and we can fit every forum on a 720k floppy" (by resle)

@itix

I think, one would need to implement something like this:
http://www.codesourcery.com/public/docs/sh-fdpic/sh-fdpic-abi.txt

ciao

Last edited by mausle on 01-Jul-2011 at 12:27 AM.

yes, one of the things i miss on .so is embedded version string that prevents part of problems, even if not all, since every such feature can be circuumnavigated or misused. though this is clearily one of remaining adavantages of amiga system, that i have a version information of a file available on practically any occasion (if carefully provided) and i wouldnt resign on such a feature if implementing for instance .so.

from what kas1e writes, even though most of it is obvious even to me, the advantage of .so is allowing plugin usage. what i interprete as introducing oo/c++ programming practices to an os environment otherwise based on plain c. this might in fact be helpful porting such application as firefox and apparently aim exactly such projects, i understand. i also understand the general advantages and handicaps of shared libraries against hard linked. im not completely convinced we have to follow closely linux world but well, at least i understand now why hyperion put such an accent on it, to the point of writing such long posts about. thanks.

Last edited by wawa on 01-Jul-2011 at 12:27 AM.

@mausle

It can not be retrofitted to existing object code but to new code it (or similar approach) can be used.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@Chain-Q

Quote:

Really bad example. Linux distros tend to break binary compatibility, in each of their releases, and almost all apps are always compiled from source for each release. And the binary-only stuff on Linux either has a compilable wrapper, or staticly linked, down to the level of bare kernel syscalls.

I must just be really lucky then than all the binaries (dynamically which link against several .so libraries) I compiled on my Fedora Core 5 installation several years ago all just continue to run on Ubuntu 10 and 11 then.

_________________
Doing stupid things for fun...

@Karlos

Quote:

I must just be really lucky then than all the binaries (dynamically which link against several .so libraries) I compiled on my Fedora Core 5 installation several years ago all just continue to run on Ubuntu 10 and 11 then.

You was lucky :) sobjs hell on linuxes are much worse that any kind of problems with .so on amigaos. Of course when you just use some modern distrib which are precompilled with all the stuff its ok, but if you will start to download some apps (bins) manually, then there is possible to have all kind of problems. And with sobjes versions, and with kernels, and with different versions of libc and so on. On amigaos we at all not have any kind of "kernel/libc.so" problems, and so, only versioning are missed for end user. And i agree, its not "that bad", as everyone say. After versioning will be added, it will be just the same as classic amiga libs.

Its just some programmers use miliions of libs (.library or .so does not matter) in all their prods. Like for example some games on os4depot, for running, want 10 sobjes ! Holy crap, for what need to do that ? Static linking, and that all.

In other words, we can't blame amigaos that it have some kind of .so support, which help programmers when its need. But if someone start to use sobjest all the time everythere and where it need and not need (and the same as libs), and trying to put sobjes to the sys:sobjs, its the same bad as if anyone will make a programm which want 10 libs, and will ask user to copy all those libs to his sys:libs.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Quote:

Its just some programmers use miliions of libs (.library or .so does not matter) in all their prods. Like for example some games on os4depot, for running, want 10 sobjes ! Holy crap, for what need to do that ? Static linking, and that all.

You can't mix shared and static linking so if a app /game needs to use it then all libs have to be sobjs. That's why you get more shared libs than you expect or like.

Shared objects that are only required by one particular app should go in PROGDIR:sobsj and not the global SOBJS: directory.

Last edited by broadblues on 01-Jul-2011 at 10:53 AM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

"DLL hell" was practically introduced on Amiga by MUI and nobody seemed to complain, so what?

_________________
Proud Amigan since 1987
Owner of various Commodore and a SAM440ep\OS4.1FE
See them on http://retro.furinkan.org/

@broadblues

Quote:

You can't mix shared and static linking so if a app /game needs to use it then all libs have to be sobjs. That's why you get more shared libs than you expect or like.

I talk about games and apps which no need sobjes at all as necessary parts, but still, they use it. I.e. to make them fully static. In general, the only apps which need (really need) sobjs, its QT, Blender, LodePaint and few others which i do not remember.

Also i mix static and shared linking all the time and it works (of course, when .so used not for plugins, but just because someone want to use sobjs).

My point are the same as rogue say in his post: no need use sobjes where that no need. I.e. in games for example.

Quote:

Shared objects that are only required by one particular app should go in PROGDIR:sobsj

Sure.

@Nibunnoichi
Quote:

"DLL hell" was practically introduced on Amiga by MUI and nobody seemed to complain, so what?

:) Almost : because they have version numbering as well (while sobjs for now don't). And some ppls just fear that it will be forced to the same problems as on linux someday.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@Nibunnoichi

Quote:

Nibunnoichi wrote: "DLL hell" was practically introduced on Amiga by MUI and nobody seemed to complain, so what?

It's hell when it's happens elsewhere. But great when happens on Amiga.

@broadblues
Quote:

You can't mix shared and static linking

i didnt know that.
in this case supporting usage of .so practically enforces converting os4 completely to linux philosophy in a matter of time.

@Nibunnoichi
Quote:

"DLL hell" was practically introduced on Amiga by MUI and nobody seemed to complain, so what?

you can always return to c64 style coding.

besides, you can claim the above about just any dynamic/shared library system.

@wawa

Quote:

besides, you can claim the above about just any dynamic/shared library system

He mean "why everyone start to worry about .sobjs, while the same (almost) ideas already done many times everythere (and on amigaos/morphos/aros as well, and mui as example)"

Quote:

i didnt know that.

As i say, i mix sobs with static libs with no problems (but yeah, hyperion say that its bad idea).

Quote:

in this case supporting usage of .so practically enforces converting os4 completely to linux philosophy in a matter of time.

The same as win32 with supporting of : QT, Gtk, cygwin, .so (as well) also enforced to linux philosophy.

Common ,, the more support of different stuff on the OS - the better for users. I want to see also QT, Grk, WxWidgets and all possible ports to our os as well. And its no mean any linux phylosophy. Everyone feel free to make "amiga only" apps. The only problem is : where those programmers who will write firefox from scratch, all those video editors, and so on ?

Last edited by kas1e on 01-Jul-2011 at 11:32 AM.
Last edited by kas1e on 01-Jul-2011 at 11:29 AM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites