Hello everyone.
I have a side project I am working on, which is a port of a game engine. This creates a SObj library (.so) and an executable that uses it.
I managed to build everything, but as soon as I ran the executable, this crashes with a complaint about accessing a symbol.
I believe that the problem is because of mixing shared and static libraries, some of them might not be compiled with -fPIC. I might need to rebuild all the libraries with -fPIC just to be sure, but...
I tried different things and I still get the same error. The last thing I tried was to build the .so library with all the needed libraries linked statically, and then use that with the main executable linked dynamically. When I did that, it still required some of the other libraries to be linked again, so I did that dynamically. And then I got the same error.
My questions are:
1. Does it make sense to try and create the .so with the required libraries statically linked?
2. Do you have any other ideas to solve that issue?
Do you mean it complains about missing symbols from a *.so that's missing? Or something else? Theoretically, if all needed *.so libraries are present, then the OS should dynamically link them on startup. The error requester should tell you what it's looking for. If a *.so is present but missing certain symbols, then it may be the wrong version.
I don't have enough experience with *.so libraries on AmigaOS to give specific suggestions on how to solve this.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
Thank you Hans so much for your reply.
The error I get from the ELF is the following
Basic_string is part of the C++ standard library, so you're having trouble with libstdc++.so. The one in SOBJS: is very old, and won't work with newer versions of GCC. Try including the libstdc++.so from the compiler version you're using in an sobjs/ subdirectory next to your compiled binary (i.e., PROGDIR:sobjs/libstdc++.so).
Each libstdc++.so really should be in SOBJS: with a version number appended so that each program can load the right one. However, I have no idea if our shared object system will automatically load the right one.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
Thank you Hans for your reply. For sure I will check this out and see how I can make it work.
I think that's a good thing to have, even with a basic soft link. But I am not sure the programs will use it automatically.
As much as I understand by the documentation I read all the previous days and what I have seen is that when a program is linked with a specific version of an .so library, then it will look only for that and won't automatically choose an other one. So, if the app is linked with libstdc++.so.x.x.x it won't use automatically another version in case the previous one is not found. And it will fail without saying anything.
For example, the engine I am working on was linked by me with the latest libfreetype.so.21, but it was failing to start because when I was executing it couldn't find that specific version in SObjs. And the error it showed was "The file is not executable" which is really misguiding. As soon as I linked that library in SObjs, the app could run. The thing is that in SObjs I have libfreetype.so and libfreetype.so.18, but none of them was used.
What is usually done is that the developers link with the generic non-versioned library file and it is on the user or an update system to create a link to the latest version. There are exceptions in cases where your app works only with the v1 of the library and not with v2, so it is recommended to link with that.
Since the whole versioning of these libraries is left into the filenames, a lot of times this brought compatibility issues in the past. I had one with the GemRB which denied to start with newer versions of some specific libraries.
Thank you again for your recommendation. I will check this out and let you know how it goes.
I recall something about SO and statics not being able to mix in a binary. I don't recall where. Does an SDK doc mention this?