symbol hiding

[Mike Hearn]

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!) ...

> 4. 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 ...

> 5. 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 :)