On Fri, 2004-05-14 at 23:58 +0900, Dmitry Timoshkov wrote:
ELF versioning is just another attempt to hide problems instead of fixing the source of it IMHO. Exactly for this reason even simple 'Hello World' program compiled under RH 9.0 will not run under RH 6.2.
What exactly are the problems? As for running RH9 binaries on RH6.2, there are two issues:
1) Using newer libraries that aren't available on the older distro. You can statically link these, ship them with the app etc - exactly the same as on Windows.
2) glibc symbol versions. You can select the versions you want at compile time though most people don't realise it. For instance, the apbuild tool will do this for you. You miss out of a few features like thread-scoped locales, but really it's not a big deal for desktop apps.
So yes you can do a simple hello world program that runs on 6.2, you just have to be careful about it.
Actually PE format hasn't changed since NT 3.1 introduction.
Unless you count .NET or the GetProcAddress PLT-style jumptables (i think they were introduced in later versions of Visual C++, not even an OS feature!) ...
- be well supported on the OS system level API (as you can do with PE:
find a PE header in memory, find import/export table, intercept an API using simple code patch and guarantee that such a program will work on all next version of the OS)
Well, this is certainly possible, you can traverse _DYNAMIC to find the headers of the file you want then patch the GOT, but to intercept APIs overriding them with LD_PRELOAD is usually easier. This part of ELF is stable and has not changed for a long time. The parts that have changed are mostly for new technologies like prelink, execshield etc ...
- let a developer create a custom section and easily (I say easily!)
access it at run-time.
OK, I'll give you that one, you have to use a binary array compiled in. But we don't seem to suffer from its lack in practice.
I guess we'll have to agree to disagree on this one :)