So, the reason for creating gthr_amigaos_(native|single|pthread).o is so that at link time the user can choose which threading implementation to use via the -athread option. This is my first assertion. I am aware of: #128 , #115 and probably more.
I am finding the following issue with a port: During runtime a shared object is loaded via dlopen. This shared object, itself, relies on other shared objects - as is often the case. Eventually, the elf.library tries to resolve one of the symbols that are marked as UND (undefined, in the readelf -s output of libstdc++.so) which belong to _gthr_amigaosnative.o and fails to do so.
Does this mean that I should also create a shared object version of _gthr_amigaosnative.o (having compiled with -fPIC) and load that so that it can be resolved. Or, should I somehow read in _gthr_amigaosnative.o, instead, so that I can load the function?
Hi, @sba1
So, the reason for creating gthr_amigaos_(native|single|pthread).o is so that at link time the user can choose which threading implementation to use via the -athread option. This is my first assertion. I am aware of: #128 , #115 and probably more.
I am finding the following issue with a port: During runtime a shared object is loaded via dlopen. This shared object, itself, relies on other shared objects - as is often the case. Eventually, the elf.library tries to resolve one of the symbols that are marked as UND (undefined, in the readelf -s output of libstdc++.so) which belong to _gthr_amigaosnative.o and fails to do so.
Does this mean that I should also create a shared object version of _gthr_amigaosnative.o (having compiled with -fPIC) and load that so that it can be resolved. Or, should I somehow read in _gthr_amigaosnative.o, instead, so that I can load the function?