Initialization sections not being run in Linux so.

[technomage]

After much investigation and head scratching, I believe that what I want to do with free pascal on linux is just not possible (yet).

Having a seperate memory manager in a .so works fine when you just want to use it from an application, but as soon as you want to use it in other .so's you start to hit problems. What I am doing is a little more difficult becasue I am trying to export classes from the .so's to not only the main application but also to the other .so's.

For example

I have the libcore.so which is my memory manager and logger.

I then have libkernel.so which contains all the platform specific stuff in my case this exports a class which create an SDL window and handles loading images and all the vector maths.

I then has libglrenderer.so which uses the exported window class to get information on the window and actually handles drawing stuff in opengl.

Then there is the libscene.so which is scene management and uses the libglrenderer and the libkernel.

All of this is tied together by the main application.

but it seems that under linux this just won't work. So...where to go from here :?: Abandon linux and MacOSX support? Switch to Kylix (no longer supported and I don't know if it can do what I want either). completely rework the engine so it does not use classes.

frankly I don't know.

[Setharian]

other than manually writing assembly (and thus binding it to a specific CPU), there's no way out...well and of course not using any global variables at all....

[technomage]

I found out the GCC gets round this by exporting

void __attribute__ ((constructor)) my_init(void)
void __attribute__ ((destructor)) my_fini(void)

form the library, these get called before the dlopen and dlclose functions return to the main application. This would be a perfect place to call the shared memory manager.

I don't know if there is any way to support those attributes under free pascal though :?: :?:

[dmantione]

We need to find out what those attributes do to the assembler file. Perhaps I can modify the assembler then to call the initialization of the library.;

[Setharian]

I guess GCC under linux puts the code into the .init/.fini sections in an ELF executable and under windows adds either hidden code into DllMain or it invokes it even before DllMain (somewhere near the entry point) and reacts to PROCESS_ATTACH/PROCESS_DETACH reasons passed as one of the arguments.....but it's a pure guess....

[technomage]

any ideas on how to find out? this is getting a bit out of my experience zone :?

[dmantione]

objdump is the tool... Please try to dump symbols, headers, sections. I'll try to do some investigations myself as well.

[Setharian]

nonetheless it won't help you still....there won't be PIC code, no matter how you substitute the mechanizm :?

even the RTL contains global vars and it uses them....and without PIC the application tries to access the absolute addresses (causing an AV)...under Win all is fine but under Unix-based systems all shared libraries can be relocated at any location in the memory, requring it to access global symbols by relative addresses, offsets from the GOT (Global Offset Table) which is passed by the loader I presume.....under Win, libraries have their imagebase, which is the preffered address at which the dll should be loaded....if it collides (the address is already occupied), the benefits of a dll is lost, all dll code is made private to the process (increasing the memory usage), reallocated at a different address and then loader by using the relocations table patches all the global offsets to reflect the new value...this is one of the reasons why certain programs take quite some time to load if they link with too many dlls which have conflicting image bases...under Unix-based systems there is no rellocation table and the loader does not patch addresses, that's why it requires the code to be PIC-safe and work without relying on its position in the memory....

maybe a bit too much information, but I hope it explains you how it works....

[dmantione]

This is no problem, you can recompile the rtl with PIC. It does work in Linux/i386 without PIC as far as I know, but there is no sharing of memory then.

[technomage]

you don't have to flag a library as shared, I think it's optional under gcc, infact I seem to remember reading somewhere that the init and fini stuff does not work well when compiled shared, i could be wrong though.

I'll try some tests under GCC and see if I can get a dump of the code I'll post it over on this
thread on the free pascsal community site.