[evilspy]

.. but gcc-3.x would generate faster code ;9

[evilspy]

Originally Posted by BAILOPAN We already overload new/delete as part of the memory manager.

But it access STL (std::set_new_handler()).

[Anpheus]

And why in particular would statically linking a single module with the STL cause problems so long as no STL classes it instantiates are required by another module?

Let's see, STL gets statically linked (as a library) or included into compilation with the DLL, every time compiler instantiates 'vector', the vector implementation is within the DLL. So if I create a vector<int>, it damn well better work because the code for creating the object is within the module.

So where does the problem arise?

[evilspy]

Originally Posted by Anpheus So where does the problem arise?

RTLD_GLOBAL

[Anpheus]

But, here's the deal...

Why is it so necessary for implementation data already included within the module to become shared with the AMXx core?

AMXx doesn't need to know what version of the STL you used unless it needs to use one of your STL objects and for some reason your version of the STL is incredibly... oh, wrong and somehow the vector doesn't consist of three pointers.

[BAILOPAN]

what


hullu (as always) is correct. The issue isn't with modules specifically interacting with one another, it's got to do with ELF mapping global symbols into the process. In fact this is the current bug with the linux compiler build - the internal error() function in amxxsc32.so is overridden (erroneously) by an internal function in libc.so.6. Crash. Shared libraries on linux are a nightmare like no other.

Specifically, the test case was SourceMM statically compiled against one STL version and a plugin compiled against another. As shared libraries they could not be loaded at the same time because the symbol tables conflicted in a very weird way.

Hey, I didn't write ELF, don't look at me...

[BAILOPAN]

I've fixed the callfunc bug in CVS (as I thought, it was an error left over from the Pawn 3.0 merge).

I made some quick fixes to protect against weird module errors but the bug report wasn't detailed enough to help me understand the problem. If you wish, please start a new bug report that details the problem.

Thanks!

PS! I decided you cannot call "fake natives" by strings.
The reason is that they're not fake natives, they are actual natives, assembled at run time. Only the compiler knows how to generate the correct calling sequence for them, and writing a system to call natives would end up being an unnecessary duplicate of callfunc_*.

The register_native system is for creating natives.
The callfunc system is for making global callbacks.

Use them the right way!