libgcc.soo problem

When trying to install glExcess-1.2-EGL wrapper I get the following installation error:

Unable to resolve symbol __gthread_once in AmigaOS:SObjs/libgcc.so

Any Ideas? - is it a softlink problem or what?

/Frandsen

@NPFrandsen

Because your different version of libgcc.so linked to the same name. libgcc.so, so replace libgcc.so with newer one, you get a problem like this.

Yes its softlink problem its important to have soft link, to prevent that happens, when compile.
so its linked to libgcc.x.y.z.so instead.

Unlike Amiga libraries that should always be replaced, the .so file that is deprecated should be kept, unless it has security hole, in some encryption or some, issue allow some execute a script local you on your computer by simply typing in URL in your web browser.

@LiveForIt

There should be a big red warning sign telling to *always* provide an app dependant sobjs/ drawer whenever shared objects are used.

The can of worms here is the can that is not provided

@Raziel

Not much sharing of anything if per application.
You might as well just statically link everything, at last then it loads faster.

Perhaps it should be possible to make .so files resident, so they don’t need to be loaded from disk all the time. Starting web browsers on AmigaOS4.x is so boring. If they can be loaded from extmem that be great.

Spacking about can of worms.

This can become really messy now with different versions of clib and newlib and so on, that can be multiple versions of the same .so file for different clibs.

@LiveForIt
Soft links are not required nor should they be used on AmigaOS for shared objects!
Unlike on Unix on AmigaOS there are 2 different directories for the shared objects: The SObjs: Assign which is used when loading executables using shared objects, with something like libgcc.so.2.95.3 (GCC 2.95.3 newlib), libgcc_clib2.so.2.95.3 (GCC 2.95.3 clib2), libgcc.so.4.0.4 (GCC 4.0.4 newlib), etc. and the compiler directories with the different compiler versions, C libraries, etc. in which all versions have the same file name libgcc.so and which are used when linking executables.
The versions in the compiler/C library directories have to be built with something like "-Wl,-soname libgcc.so.2.95.3" to work and load the correct version from SObjs: when the executable is loaded.

@joerg

But wouldn't you end up with loads of libraries this way, dozens of differing libgccxxx.so...one for every game someone compiled years ago?

I think having a sobjs drawer for the app you've compiled it for, is fine...user knows that these are the libraries that were used and are working for the specific app.

@LiveforIt

In my case, ScummVM grew so big that my 2 GB of RAM isn't enough anymore and the linker will crash while it runs out of memory.
Having the solution with "plugins" (shared objects/engines) makes it a piece of cake to build it locally/natively again...

Cross-Compile is a no-no for me, i'd rather drop out of AmigaOS completely

ExtMem...yeah, that i won't live to see (be it sdk/compile chain or user-wise).
It will come eventually i believe, together with multi-core (not for X1000 users anymore, obviously), but again, that, i also won't live to see

When using DOpus5 the version information is dud. It works on my A5000/20 but not on my A5000/40 ... strange .. I might have scrambled my development environment while trying to get more familiar with the programming intricacies using WebGL and SDL ... just trying - I'll find an earlier version and see if that works - as suggested. Thx- for reposts
/Frandsen

@Raziel
Quote:"Only" 2 versions for each GCC version, one for newlib and one for clib2.

If you put the SOs in PROGDIR:SObjs instead you have one copy for every single program using it, i.e. much more copies, and not not only different but identical copies of the SOs in different directories.

However, a big problem is, or at least was, that none of the clib2 maintainers so far understood how shared objects work on AmigaOS and ignored all bug reports about it, continued to built them without -soname resulting in incompatible shared objects...
And I wouldn't be surprised if the current newlib maintainer builds the newlib SOs with similar bugs, without using -Wl,-soname, as well.

@joerg

Who would the current maintainers be?
Hyperion?
Or is that stuff on github?

Did someone already alerted the responsible partys?
I mean, if such a "simple" fix (like you described) would cure another bunch of .so crashes i'm getting, i'd be happy to use a fixed version