I have a shared library on MacOS written in FPC. It needs to be loaded multiple times, that is each time with its own set of global (dylib) variables. On Linux I would use dlmopen with LM_ID_NEWLM, but MacOS doesn't have dlmopen and dlopen doesn't have LM_ID_NEWLM. I can create a copy of the dylib on the fly and load the copy. But then the OS will complain about ObjC/ObjPascal namespace collisions, even when loading with RTLD_LOCAL.

One wonders how operating systems can be designed that brainlessly.

Of course, I could write my own Mach-O loader, but I have other things to do.

Another idea is to prevent all use of global variables in the dylib. Before I do that, my question is if implicit compiler global variables (for the dylib code, not for the FPC runtime lib) would spoil that idea ?

Regards,

Adriaan van Os

Hi,

Adriaan van Os wrote

On Linux I would use dlmopen with LM_ID_NEWLM, but MacOS doesn't have dlmopen and dlopen doesn't have LM_ID_NEWLM.

(...)

One wonders how operating systems can be designed that brainlessly.

"Reality doesn't support the assumptions around I designed my code, therefore reality is wrong."

dlmopen is a Sun/Solaris extension, that isn't POSIX, and other systems implement it if and as they wish. It's also not available on a number of other Unix systems. For example it's not supported by Android's bionic libc, and that's on Linux...

It only got implemented in GNU Libc 2.3.4, in 2005. I guess before that, even GNU/Linux was brainlessly designed... *rolls eyes*

Charlie