Anybody aware of an assembly written ELF64 program interpreter (with libdl?).

Do you mean an interpreter like /lib/ld-linux.so.2?

You want to write your own version in assembly?

good luck, sylware
what is disapoint windows users in linux standart interpreter:
1. I don`t know how to import 2 symbols with same name from 2 different libraries(assume libraries are plugins, of course imports are same named) at compile time via standart interpreter functional (may be it is possible)
2. In linux there are libraries garbage(I mean versioning, version is not inside of file, it is in file name), and no ability to load imports (again in compile time) from library by mask name (library should be in system directory, it must have symbols in order declared in mask, (optional it must contain requested imports), in case of multiple matchs grab library with highest version).
imports in compile time - assumed that interpreter will resolve symbol table etc/ and will be no code in executable itself to resolve that dynamicaly at run time.

@revolution, yep, I have finished my bootstrap kernel code with the hardware tracer and I was about to start porting linux code in much bigger quantity, but I identified some really trash/evil behavior from the glibc devs: hardcore abuse of GNU symbol versioning without any means to mitigate/override this versioning in the dynamic loader. Not to mention the trash glibc code which requires almost the last gcc version.

@prominick, I am not targetting compile-time ELF support but runtime ELF support: /lib64/ld-linux-x86-64.so.2 and libdl.so.2

I'll try, don't know if I'll get something usable (like able to deal with the worst, for instance valve client and games).

And if anybody is aware of any already coding effort...

That is not appropriate. Just because it is the latest version doesn't imply that all the apps are compatible with it. Apps must specify the libraries and the associated versions they need.

Regressions, new bugs, deprecations, removals, spec changes, behaviour changes, etc. can cause old apps to fail if you blindly start using a new version. Sometimes an app is relying on an old bug (perhaps without knowing) for it to work.

program that requires specific version must request specific version but why other software have to suffer for it and had no ability request not specific version but any version that fit in requested filename mask. Suppose thou software compatibable with every version of some library - so why thou have to customize builds for every environment, instead of declaring filename mask? why end user have to load dependancies while for example would be enought to patch requested lib to existing in OS version?

If the app is compatible with all version of a library then by definition it doesn't matter which version you choose. But an app today can't predict what happens to a library tomorrow. If it proudly declares it can work with all versions then that is a recipe for future problems.

But we appear to be in agreement about requesting a particular version when needed. I just suggest that an app cannot predict when it is needed, so best to just say I tested with version X, so give me version X, and none of those future unknowns.

Years ago, I was really interested in ELF DSOs. I played with FASM macros and made it generate complete ELF libraries with all mandatory and optional segments, sections, hash tables with different lookup speed optimization levels, etc. And of course, in the process I read the "Process initialization" section of the ELF specification. At the time the idea that dynamic linking can be done entirely in user space was completely new for me, so I've become fascinated and for some time was considering writing my own ld-linux/libdl implementation.
The thing that stopped me was the lack of potential practical applications for my code. On modern UNIX systems libc, libpthread, libdl and the dynamic linker form a tightly integrated ecosystem, and I am not sure one can replace a component without jeopardizing stability of the entire system. With a homemade dynamic linker on linux you will likely be limited to libraries and programs you've wrote/compiled yourself. Even a library that does not use any libc function still contains by default a DT_NEEDED entry with "libc.so.6" because gcc without --nostdlibs adds it automatically.
Also, I would argue that the GNU symbol versioning mechanism is a good thing. Actually, it is the ELF alternative to importing symbols from a specific library, that PromMINIck misses in Linux. I mean, DT_VERNEED section directly links version strings referenced in the object to specific libraries where they can be found. Thus, for every versioned external symbol there is only one library where it is allowed to be found, and the linker does not need to check every loaded DSO.
No idea why glibc constantly reassigns symbol versions of its functions without changing their binary interface, though.
But if you want a dynamic linker without symbol versioning, musl authors claim their dynamic linker can only pick a symbol with default version (if I understand their wording correctly). And musl has a special utility to run applications compiled against glibc.
Hovewer, if I have not misunderstand you, you have a set of programs compiled against different versions of glibc and you want to run them using an older one. If we forget for a moment that we are speaking about glibc, which actually tends to change symbol versions without a clear reason, we are getting a situation where you have potentially binary incompatible modules and you want to make them run together by bypassing safety checks. That does not sound right. Maybe updating glibc/recompiling the modules/using flatpack would be a better solution?[/url]

@weyowe, read my previous posts where I explained why glibc is a liability. I already started to write it. I am slow and I have no idea if I'll get something actually working for valve stuff and games (this is the only usage of the glibc on my system, without games and valve stuff, glibc->trash where it belongs).

I just wanted to warn you that writing a generic ELF loader and writing an ELF loader capable of loading and resolving glibc libs are two different problems. In the second case you have to take into account internal logic of other glibc components. You should not treat libdl as a self-sufficient library that exists separately from libc. You can find here a description of some problems libc developers meet. In particular, they mention "interaction between pthreads and ldso for TLS storage for dynamic libraries". And this interaction is handled through a private libc interface.
Try checking dynamic symbols of the ld-linux-x86-64.so. You will see a dozen of GLIBC_PRIVATE symbols with 'tls', 'rtld', 'exception' in the name.

To be honest, recently I was thinking about writing my own libdl implementation again. The problem is, to do so I will have to reimplement the majority of libc as well. And of course, no existing binary will be able to run without recompilation/faking glibc initialization.

libdl is only the "public API" of ld-linux-x86-64.so.2. Of course, you have a private interface between those two. TLS deals with threads, hence pthtread, but a lot is driven by the SYSV ABI for instance the dynamic __tls_get_addr() ABI function.

And no, I am not expecting glibc devs to do a technically fair and neutral job: how would you trust them when they hardcode their "C code" for a recent gcc, come on.

I'll try to balance the little brain time (I know I am slow) I have between this and my kernel (some kind of linux) project. I don't have the thousands of billions of $ of blackrock and vanguard, then real life can put an end to this. Oh well, we'll see, I know it is one of the right things to code as porting between different modern ISA is not that hard, not to mention that for long term system software component, coding time is actually neglictible, even with a coding time 10 times longer than "short term" coding.