Project Timberwolf - Firefox for AmigaOS4.1

[Karlos]

Blimey, I go to visit my bro for a few days and miss this? :lol:

[Karlos]

Good! I assume that means it won't be using any of those sloppy SObjs either.

Again, sorry about the negativity. Sincere kudos to the developers for their milestone, but can't we have some Amiga-wide cooperation for once?

Ok, this is off topic but IMHO, supporting shared objects was one of the best new features I've seen from a developer perspective. Existing library/interface methods just don't seem to have what it takes to support shared C++ code. Without them, you end up having to static link C++ object code, making your executables huge.

[Karlos]

As a developer, I think your opinion holds more weight, but, as I've said elsewhere, from a user perspective, they really bring down the parsimony of the system. I really don't like having to maintain both Libs: and SObjs:, especially since every .so I've looked at doesn't have an Amiga version string. It might help if they belonged in Libs: or Libs:SObjs instead of SObjs:, but I'm not sure.

Well, you have to remember, .so files are not really an amiga standard. They've come from glibc. Under linux, the version numbering is usually maintained through symbolic links.

However, there's nothing at all stopping a .so file compiled for OS4 having a static version string that can be read by the version command. The fact that they don't is probably more down to the fact that most .so files are straight ports of libraries from linux.

[Karlos]

They are not shared and C++ dynamic linking libraries stop working when there is new GCC version.

They are not shared presently in memory (in the sense that shared libraries are), but they are shared in the sense that they are not statically linked against the executable.

Also, newer versions of the compiler don't necessarily always break shared objects. After all, I have shared objects on my linux box that span several versions of gcc and they all work fine. Dependencies between shared objects are more likely to cause a problem.

[Karlos]

In other operating systems it is called dynamic linking. Wikipedia article about Windows DLL could be interesting reading to all amigans.

Yes, I know. I have actually written .so files for linux.

[Karlos]

Have you tried writing code that provides properly extensible C++ classes (complete with virtual functions) in an amigaos shared library? It is up to the compiler/linker implementation to decide how virtual function tables work, not the operating system.

[Karlos]

Firefox is a handy application. Sure it is slow and clunky these days, especially compared to webkit based browsers, but then why not have both if both are available?

A few years ago, I bet most of the people now slating firefox were praising it

[Karlos]

True. You cant do that.

I wasted many hours trying to work around it too. In the end, it just isn't possible.

And this is exactly the problem. It is compiler specific and you can not always mix C++ libraries compiled with different GCC versions.

It is compiler specific yes, and no you can't always mix versions, but the .so format has been pretty much standardised these days. There was quite an effort to tidy it up. Since amigaos 4 only has .so files from gcc 4.x, there aren't likely to be quite the problems you got when glibc got upgraded in linux.

If you assume for a moment that .so files on OS4 are primarily for C++ code (they don't have to be, of course, but I wouldn't write a C .so for amigaos when I could write a shared library instead) and that the only C++ compiler on OS4.0/1 is gcc 4, most of the above objections don't really apply.

Of course, if a new version of gcc decides to change .so files dramatically again, then yes, there will be a problem. However, the revamp  in the last major glibc, though necessary to properly make .so files useful for C++ was something nobody is keen to repeat, not even for C++0x. The current .so format should be future compatible for the latter anyway and hence could be around for some time.

[Karlos]

What the hell? Since when is there a giant rule book of what you must do. "Thou shalt not do anything that AmigaOS3.1 didn't offer!". Please.

People going down that road when criticising support for .so files should consider that ELF is not an amiga 3.x standard either, yet I don't see any complaints about the fact it is used in both MOS and OS4. And why not? It's a sensible standard. Likewise .so is a sensible choice, particularly for C++ since quite frankly, there is no other widely accepted, open alternative.

What big mess?

I suppose having 3.x libraries, 4.x interfaces and .so files could be construed as somewhat excessive. However, I rather like .so file support, simply because neither of the others lend themselves to enabling runtime linked C++ code.

[Karlos]

It is not and there were massive flame wars in the Amiga community ten years ago. "ELF is a monster !!!" being the most famous quote from that era.

ELF is a sensible format. It was just very alien to people accustom to the usual hunk format.

C++ sucks anyway ;-)

Yo mamma... (etc)