View Single Post
BAILOPAN
Join Date: Jan 2004
Old 10-30-2005 , 08:37  
Reply With Quote #2

Interesting, it's a nice article in its own right for showing some details about entities (I don't really know too much about the HL2 with regards to the "enginey" stuff).

However, I'd like to make a few points. I assume what you're talking about is the fact that Linux binaries have lazy loading. For those who don't know, on Linux, symbols can be resolved at runtime rather than at compile time. In Windows the import table must have a known mapping at compile time. The laziest Windows gets in this regard is that DLLs can have .lib files, which allows no mapping at compile time, and at run time Windows will try to load the corresponding DLL to resolve the imports (which will fail if the imports or DLL are not found).

In my opinion, Linux dynamic linking is a hack, and one that causes many problems. Ultimately in this scenario it means you're relying on the fact that the symbol table is completely intact; something Valve could easily change. The fact that Linux will randomly attach one library's import to another library's completely unrelated but exposed symbol is nightmarish.

A more cross-platform compatible approach would be to do signature/byte pattern scanning, like NemoD does. Granted, it's a lot more work, but it's almost fail-safe.

Lastly, I would write that GCC-3.4 be required as a minimum. They're not ABI compatible and I've had plugins crash because they mismatch with SourceMM's compiled version.

If it does indeed segfault, I would throw it in a debugger. Because the symbol table is intact on Linux builds, you might be able to see why.

(BTW! - God forbid if a mod ever deviate from the base SDK. This sort of thing would surely fall to pieces, which is quite unfortunate from independent modders' point of view).
__________________
egg
BAILOPAN is offline