The Leading Linux Desktop Platform Issues Of 2018

[Weasel]

Global symbol namespace was added to ELF.

Big mistake then. Sounds like the moment ELF became retarded, when did this happen? I want to mark it as a dark time in history of Linux (Unix).

Thing you are missing KnownDLLs and Global symbol namespace is both to address the same problem. When you need 1 version of a particular symbol you want the resolve to get down to 1 this is what the Global symbol namespace and KnownDLLs attempts todo. Now when you have application declaring everything in the global namespace and declaring nothing in the local namespace(STT_FILE) you are playing with fire. Distributions shipping all their own built applications have no need for the STT_FILE local name space. Most of the time they have only 1 version of libraries they want loaded.

Nope it's not the same.

With a KnownDLL, you can't load another DLL with the same name.
With global namespace for symbols, you can't load another SYMBOL with the same name.

With a KnownDLL, you can import the symbol called HeapAlloc from any other library and it won't conflict with kernel32.dll's HeapAlloc, as they are separate symbols. What you can't do, though, is load a DLL name kernel32.dll, which is a completely different thing.

I blame ELF not because you can't load two libs with same name (that's useless), but because you can't load libfoo's HeapAlloc at the same time as kernel32's HeapAlloc (note libfoo is called libfoo, not kernel32, i.e. different names).

Once again, we're talking in circles. For the love of whatever is holy, please make the difference between the NAME of the module and the SYMBOL.

If you still can't grasp this I'm afraid I'm really done with this cause it's getting tiresome repeating it over and over again.

Don't be too sure on this one. We are seeing ebpf be extended in more and more ways. So I would not be surprised if anti cheat systems end up using ebpf hooks in kernel space.

Remember totally fix ELF systems could take 10 to 15 years.

Reality is Weasel you did not know what original dynamic loaded elfs looks like. The original dynamic loaded elfs would be quite nice to third party developers.

Well I don't care about the original in Solaris. I'm talking about Linux and Linux's ELF always suffered from this problem. But thanks for the history lesson (no sarcasm).

[oiaohm]

Big mistake then. Sounds like the moment ELF became retarded, when did this happen? I want to mark it as a dark time in history of Linux (Unix).

Problem is its not a single time. SunOS 4/ Solaris OS 1.0 this is 1991. This sees STT_FILE relegated to a compatibility shim. Intel Binary Compatibility Standard version 2 for Linux was used by Wordperfect/coral in 1994 also still had STT_FILE in their IBCS2 loader for Linux. Then in the 2004 you see a developer making a stub loader you can embedded in your application for LSB compadiblity also bring STT_FILE back and since that project failed to be funded we have not seen anyone else since bother.

With a KnownDLL, you can't load another DLL with the same name.
With global namespace for symbols, you can't load another SYMBOL with the same name.

You should be questioning this. How can glibc/Solaris versioned symbols work. As long as the symbol has different version information glibc loader will allow you to load another symbol of exactly the same name even from different .so files.

Its the introduction of versioned symbols that start seeing STT_FILE falling out of favour.

Version symbols are using the global namespace for symbols. STT_FILE entries in the .dynsym also can reach out and filter information stored in the global name space.

This is the warped catch the global namespace has stored the file the symbol comes from this is why dlsym can perform a search for multi symbols of the same name.

Get the point yet STT_FILE support is like 90 percent implemented in the glibc default loader the important 10 percent that it works is missing.

I blame ELF not because you can't load two libs with same name (that's useless), but because you can't load libfoo's HeapAlloc at the same time as kernel32's HeapAlloc (note libfoo is called libfoo, not kernel32, i.e. different names).

If the HeapAlloc has different version information(works with default glibc loader/interpreter) or you are using a ELF loader/interpreter than supports STT_FILE entries in .dynsym it will work to-do this.

Well I don't care about the original in Solaris. I'm talking about Linux and Linux's ELF always suffered from this problem. But thanks for the history lesson (no sarcasm).

This is that you don't know the history. Linux ELF has not always suffered from this issue. Its really simple to forget for a while you could run binary that targeted Unix in general in the early time frame of Linux. These where elf binaries and did have STT_FILE support in their loader/interpreter .

There has been 3 universal things.
1) Never made it into glibc provided elf dynamic loader/interpreter .
2) Required brutal bashing of gcc/binuntils to get it to produce binaries with the feature.
3) The developer who made elf loader with the feature of STT_FILE end up out of a job and was not paid by his employer to make it anyhow.

Windows to heavily mess with the loader you have to go into kernel space.

With Linux the loader is a static elf binary. So you can in fact ship your application with your own loader.

This is why your arguement that I could not talk about kernel mode stuff is so bull when you are talking about functionality open to application developers to have the equal you have to cover the windows cases where applications modify the loaders. Why because under Linux you are free to ship a static binary with your own application replacing the system wide loader. NixOS that is a Linux distribution made patchelf so they could change the loaders on binary elf files.

ELF format is not the problem. Linux ELF binaries from different points of history had the feature.

The combination of symbol versions with STT_FILE gives something way more powerful than PE format has.

So the question is more who is going to pay to have STT_FILE support implemented and merged into the glibc and made practical for developers to use from compiler side.

[Weasel]

You should be questioning this. How can glibc/Solaris versioned symbols work. As long as the symbol has different version information glibc loader will allow you to load another symbol of exactly the same name even from different .so files.

That's like having two different symbols, and yes I did say that versioned symbols should be MANDATORY and enforced. Because almost nobody uses them, except for libc and stdc++ and a few others I'm not aware of.

That's exactly why I said to remove the global namespace.

If the HeapAlloc has different version information(works with default glibc loader/interpreter) or you are using a ELF loader/interpreter than supports STT_FILE entries in .dynsym it will work to-do this.

Sigh. The point is that in DLL you can't exclude the "versioned information" because it has no global namespace. With ELF, the fact that it's possible to not supply versioned information is the problem. Also it's the default (?).

ELF format is not the problem

It is, because it has the global symbol namespace.

[oiaohm]

That's like having two different symbols, and yes I did say that versioned symbols should be MANDATORY and enforced. Because almost nobody uses them, except for libc and stdc++ and a few others I'm not aware of.

Yes you are a idiot requesting mandatory enforced versioned symbols you fail to understand the downside.
https://stackoverflow.com/questions/...-glibc-version
If versioned symbols are enforced you have less cross distribution compatibility. Us doing cross distributions binaries attempt to avoid versioning where ever possible. You really don't want to version your libc functions so that you only run on exactly 1 version of libc when your program is quite happy running on any version of libc. Yes there are times when request to global is the correct thing.

Versioned is not 100 percent solution. As you are allowed to place multi versions of the same function inside the same .so this is how glibc does backwards compatibility with only 1 .so file installed.

Versioned deals with a particular problem of allowing newer library to be used in place of older library and provide program expecting older library with compatible functions.

You strictly need something like the STT_FILE feature. That versioned will work across multi .so files loaded by the application says the framework is there to support STT_FILE just it not implemented.

That's exactly why I said to remove the global namespace.

The reason why two symbols with two different versions can load into program at the same time from two different .so files is in fact a feature of the global name-space as per ELF specification written by SUN. That specification also mandates recording what file functions comes from this is so STT_FILE could work.

Sigh. The point is that in DLL you can't exclude the "versioned information" because it has no global namespace. With ELF, the fact that it's possible to not supply versioned information is the problem. Also it's the default (?).

Versioned is a feature dll lacks this leaded to a growing number of libraries that are basically the same.
https://github.com/wine-mirror/wine/...d3dcompiler_33
Yep all the dllname_(number).dll you are seeing under windows is working around that they don't have a version system. Yes this is wasteful on ram and disc space when you don't particular need to.

By the way versioned has it downside. You want to know why you might want to be able to just use a global and not give a stuff about version.

Like glibc libc contains [email protected]@GLIBC_2.27 and [email protected]_2.2.5 that is the same symbol twice.

[email protected]@GLIBC_2.27 is the one you would get if you requested with no version this will also resolve to being the most current version. So inside a ELF .so file you may have more than 1 version of a symbol.

With versioned symbols it would be great to have something like windows did with SXS with a manifest file where you could state symbol versions and exact paths for dependencies for compatibility reasons. The loader does have $ORIGIN so it knows where your binary is.

ELF design is good. We do need a few things implemented in the glibc implementation
1) STT_FILE would be great.
2) Means to specific version and source file information for imported symbols into .so and executable without in fact modify them as like a libfoo.so.imports for compatibility reasons.(basically something like the windows.exe.mainfest) This way when building applications you could just build them all using global systems and then when there are compatibility problems provide simple overrides. Problems do come when it rebuild binary to fix. This is something that would work as a work around for legacy applications without needing to make shim .so files.

Nothing stated required altering the ELF format. Number 2 option could nuke the need for STT_FILE support at all. The route ELF format has been taking with global symbols is not wrong all the information is records and if elf loaders are fully to specification everything third party application developers could want in the ELF format is there. Now add on of something like a mainfest that the loader processes would most likely be even better for third party application makers.

[Weasel]

Yes you are a idiot requesting mandatory enforced versioned symbols you fail to understand the downside.
https://stackoverflow.com/questions/...-glibc-version
If versioned symbols are enforced you have less cross distribution compatibility. Us doing cross distributions binaries attempt to avoid versioning where ever possible. You really don't want to version your libc functions so that you only run on exactly 1 version of libc when your program is quite happy running on any version of libc. Yes there are times when request to global is the correct thing.

So it means that even versioned symbols are much more retarded than DLLs.

Thanks for shooting yourself in the foot. Again.

STOP USING ARGUMENTS THAT ARE **WORSE** THAN DLLs.

You brought versioned symbols up, DESPITE the fact they are clearly worse than DLLs.

It's YOUR problem.

Idiot.

You strictly need something like the STT_FILE feature. That versioned will work across multi .so files loaded by the application says the framework is there to support STT_FILE just it not implemented.

Cool story, so remove the fucking global namespace and add STT_FILE or whatever.

I don't give a fuck if Sun had it or whatever other history bullshit. Enforce this in Linux. Period.

I don't care, as long as it works like DLLs, then it's the solution to aim for.

But if it has any drawbacks that DLLs don't have, stop wasting my time with your bullshit "suggestions" that DLLs don't have problems with.

The reason why two symbols with two different versions can load into program at the same time from two different .so files is in fact a feature of the global name-space as per ELF specification written by SUN.

Oh really? So which part is enabled by global namespace exactly?

Because DLLs don't have it and can load 5 million different DLLs with same symbol names without an issue.

[oiaohm]

So it means that even versioned symbols are much more retarded than DLLs.

No it means versioned symbols in ELF format has a very much intended usage. You run into the same problem if you SXS everything under windows.

STOP USING ARGUMENTS THAT ARE **WORSE** THAN DLLs.

Version symbols would mean that Visual Studio runtime could be single set of dll files with shared memory allocation if designed properly.. glibc is designed properly this is why 1 version of glibc runs applications built against multi older versions of glibc.

Problem is you are not wanting to listen to the issues with DLL. Not having versioned symbols that results in not being able to stack you libraries.

Cool story, so remove the fucking global namespace and add STT_FILE or whatever.

This would result in shattering glibc universal allocation Basically you would have to implement STT_FILE + something equal to knowndlls.

I don't give a fuck if Sun had it or whatever other history bullshit. Enforce this in Linux. Period.

SUN put the stuff in the specification and different loaders on Linux at different times enforced it.

II don't care, as long as it works like DLLs, then it's the solution to aim for.

Problem is DLL is not exactly what you want to copy.

Because DLLs don't have it and can load 5 million different DLLs with same symbol names without an issue.

But you cannot do this if the dll have the same name right because knowndlls and the like gets in way.

ELF I can load the same symbol name with 2 different versions for the 1 so file. This is part of ELF. This is what gives glibc is multi version compatibility. But there is a problem that you cannot edit these symbol versions without rebuilding executable..


STT_FILE + RPATH= in being able to load multi dlls of the same name with function of the same name . This is something in libcapsule class.

Its something people overlook of the ELF design. Executable and .so files in elf have RPATH to change the location per file where libraries are looked for.

SXS under windows gives you manifest files.
https://en.wikipedia.org/wiki/Side-b...bly#Advantages
Yes this gives you the ability to have multi versions of the same dll name used in different applications. This is not in the same class as libcapsule or STT_FILE. That allows you to have multi versions of the same named so file inside the one application.

Also you statement to use versioned mode everywhere look at application use of manifest files programmers don't state versions of every dll they import because if they do it brings about exactly the same nightmare.

Windows manifest you have to version by DLL because PE format does not support version symbols in DLLs.
Yes you do want to be able to use versioned symbols.

Basically step back weasel. Global namespace is not bad. Yes you run into trouble because of global namespace. Same way you run into trouble on Windows before you had SXS with application using the same name dll. Microsoft did not remove dll name uniqueness to fix this problem right.

If you look closely what you really want is a mainfest file. Yes mainfest for SXS can be embedded inside application or put next to application.

Nothing about the global symbol system in ELF prevents loading multi versions of the same symbol from different libraries into memory this is why dlsym can search for this. There is a issue declaring in application binary what one you want.

Remember program.exe with program.exe.mainfest in the same directory results in the mainfest file in program.exe being overridden. The mainfest file under windows is a file that allows you to control the loader.

Application built for current debian testing running on current debian testing is not going to be fine with the global namespace right.

Attempting to use a application built on one distribution on another you run into trouble. Now this is not one problem.

1) soname/dll name changes/conflicts. This does effect windows before SXS so again not a Linux unique problem.
2) symbol versioned wrong. You see this a lot with glibc where program refuses to run because symbol was versioned automatically because the symbol was updated a X version of glibc to fix a problem even that that problem is not going to effect the program. You also see this under windows were a program refuses to run because of mainfest file. So this is not a unique linux problem.
3) final is symbol conflits but these are really no different to dll name conflicts under windows.

Could this be addressed by a import/mainfest file yes it could.

Problem comes who is going to pay for the work to be done.

Import would not be a super complex format file required.
[sofiles]
(sonameinprogramimport) (sonametouse) (optional local/global statement) (optional path to .so file)
[symbols]
(symbol+version in elf import) (replacementsymbol+version) (optional local/global statement) (optional soname) (optional path to .so file to use for this symbol)

Yes the ELF format allows for local, global symbol declares that is what STT_FILE is meant to be about so the loader knows what libraries should be set to global or not.

Something like this would be able to fix 99% of the problems. Its not like distributions are going to magically come stable over night. Yes it would be possible to ship installer script that based on what distribution user is using what file is placed next to the executable. It would also provide fairly straight forwards tool for end users to work around problems. Heck this import format would allow using 2 so files instead of one. Like gtk changes to a new version dropping particular symbols instead of shipping a full old gtk just ship a library with the removed symbols and redirect to the new version.

libcapsule I see as practical in the short term because the work is being paid for.

Dropping global symbol name space will not fix distributions and upstream renaming libraries or made it easier to deal with removed symbols or incorrectly versioned symbols.

My biggest problem is who would pay for this work.

Remember distributions make money selling support. They don't make money in most cases from third parties having their applications work. So there is no money reason for Distributions to fix this. Valve is going the libcapsule route. This leaves who else do you think is going to reach into their pockets to implement STT_FILE or even better like my import. Reality is most developers don't want to go into the loader code.

[Weasel]

No it means versioned symbols in ELF format has a very much intended usage. You run into the same problem if you SXS everything under windows.

No, SxS doesn't give you a fixed version, it falls back if needed. And SxS is barely needed to begin with for most situations: Wine barely uses it and works fine in most cases. All Wine tests also work (on Windows), usually without SxS, proving behavior is the same (again, on Windows). If a test fails on Windows, then it's wrong. So please don't start with failures. I'm talking about running the conformance tests on Windows.

Version symbols would mean that Visual Studio runtime could be single set of dll files with shared memory allocation if designed properly.. glibc is designed properly this is why 1 version of glibc runs applications built against multi older versions of glibc.

But that's poor programming practice anyway so it doesn't matter in the least.

Problem is you are not wanting to listen to the issues with DLL. Not having versioned symbols that results in not being able to stack you libraries.

DLLs have issues alright. They're not perfect. But ELF also have those same issues and many more. There's nothing that DLL suffers from that ELF doesn't, typically ELF is much worse in anything.

But you cannot do this if the dll have the same name right because knowndlls and the like gets in way.

KnownDLLs are system DLLs. You'd be stupid to try to name something after them (and lately Microsoft started adding long names like api-ms-win-blahblah so potential to clash with it is infinitesimal).

STT_FILE + RPATH= in being able to load multi dlls of the same name with function of the same name . This is something in libcapsule class.

Its something people overlook of the ELF design. Executable and .so files in elf have RPATH to change the location per file where libraries are looked for.

SXS under windows gives you manifest files.
https://en.wikipedia.org/wiki/Side-b...bly#Advantages
Yes this gives you the ability to have multi versions of the same dll name used in different applications. This is not in the same class as libcapsule or STT_FILE. That allows you to have multi versions of the same named so file inside the one application.

Also you statement to use versioned mode everywhere look at application use of manifest files programmers don't state versions of every dll they import because if they do it brings about exactly the same nightmare.

Windows manifest you have to version by DLL because PE format does not support version symbols in DLLs.
Yes you do want to be able to use versioned symbols.

Basically step back weasel. Global namespace is not bad. Yes you run into trouble because of global namespace. Same way you run into trouble on Windows before you had SXS with application using the same name dll. Microsoft did not remove dll name uniqueness to fix this problem right.

If you look closely what you really want is a mainfest file. Yes mainfest for SXS can be embedded inside application or put next to application.

Nothing about the global symbol system in ELF prevents loading multi versions of the same symbol from different libraries into memory this is why dlsym can search for this. There is a issue declaring in application binary what one you want.

Remember program.exe with program.exe.mainfest in the same directory results in the mainfest file in program.exe being overridden. The mainfest file under windows is a file that allows you to control the loader.

Application built for current debian testing running on current debian testing is not going to be fine with the global namespace right.

Attempting to use a application built on one distribution on another you run into trouble. Now this is not one problem.

1) soname/dll name changes/conflicts. This does effect windows before SXS so again not a Linux unique problem.
2) symbol versioned wrong. You see this a lot with glibc where program refuses to run because symbol was versioned automatically because the symbol was updated a X version of glibc to fix a problem even that that problem is not going to effect the program. You also see this under windows were a program refuses to run because of mainfest file. So this is not a unique linux problem.
3) final is symbol conflits but these are really no different to dll name conflicts under windows.

Could this be addressed by a import/mainfest file yes it could.

Problem comes who is going to pay for the work to be done.

Import would not be a super complex format file required.
[sofiles]
(sonameinprogramimport) (sonametouse) (optional local/global statement) (optional path to .so file)
[symbols]
(symbol+version in elf import) (replacementsymbol+version) (optional local/global statement) (optional soname) (optional path to .so file to use for this symbol)

Yes the ELF format allows for local, global symbol declares that is what STT_FILE is meant to be about so the loader knows what libraries should be set to global or not.

Something like this would be able to fix 99% of the problems. Its not like distributions are going to magically come stable over night. Yes it would be possible to ship installer script that based on what distribution user is using what file is placed next to the executable. It would also provide fairly straight forwards tool for end users to work around problems. Heck this import format would allow using 2 so files instead of one. Like gtk changes to a new version dropping particular symbols instead of shipping a full old gtk just ship a library with the removed symbols and redirect to the new version.

libcapsule I see as practical in the short term because the work is being paid for.

Dropping global symbol name space will not fix distributions and upstream renaming libraries or made it easier to deal with removed symbols or incorrectly versioned symbols.

My biggest problem is who would pay for this work.

Remember distributions make money selling support. They don't make money in most cases from third parties having their applications work. So there is no money reason for Distributions to fix this. Valve is going the libcapsule route. This leaves who else do you think is going to reach into their pockets to implement STT_FILE or even better like my import. Reality is most developers don't want to go into the loader code.

I don't even know what you're trying to argue at this point.

I don't care about the version of a symbol. All I care about is the module it is from.

For example, imagine prefixing symbols with "ELFname.symbol", so for example gtk2 would be "gtk2.foobar" and gtk3 would have "gtk3.foobar". Is that so fucking difficult for you to grasp? There's no version (other than major version, part of the library's name though).

I don't care about ANYTHING else

The "foobar" symbol, WITHOUT a module specified for it or prefixed for it, must be banned. Disallowed. Made impossible by the format so that no matter what the loader does, it can't load without the module. DLLs do that: no matter what the loader does, it's forced to look at the module name (and table) first before it can even see what symbols are imported from it (it's linked from the table containing the module name). This is in the format, it has nothing to do with the loader. It's not at the loader's whim, it's forced by the format of the DLL. The loader has to obey it.

With ELF that's not the case, so it has to be changed so that it is, literally, illegal (in the FORMAT) to declare symbols without a module. If you think STT_FILE can solve this issue, then make it mandatory and problem solved.

tl;dr: Remove the global namespace for symbols. Each symbol must specify which module it is from (so it's local to that module). That's... literally... it. Anything else you say is so off track it's not even funny.

[oiaohm]

No, SxS doesn't give you a fixed version, it falls back if needed. And SxS is barely needed to begin with for most situations: Wine barely uses it and works fine in most cases. All Wine tests also work (on Windows), usually without SxS, proving behavior is the same (again, on Windows). If a test fails on Windows, then it's wrong. So please don't start with failures. I'm talking about running the conformance tests on Windows.

The claim that windows SXS does not give you fixed versions means you have not worked with it on Windows. Private assembles SXS are a quite cool way to work around libraries missing features in old versions of windows. Also you have not really worked with wine conformance tests closely. There are quite a few failures that when you add a manifest to the wine test suite magically disappear. There are difference in behaviour between different versions of the same named dll.

If a test fails on windows its not always complete wrong. Its sometime partly wrong that for X test you need to specify Y version of Z dll in the manifest. All applications to want that behaviour should have a manifest. Really how well wine works shows you how often you can totally ignore version information it also shows you that you cannot do this all the time.

KnownDLLs are system DLLs. You'd be stupid to try to name something after them (and lately Microsoft started adding long names like api-ms-win-blahblah so potential to clash with it is infinitesimal).

Sorry the potential is a lot closer than infinitesimal. Lets not do the blahblah to hide issue.
A real one is api-ms-win-crt-runtime-l1-1-0.dll
Not only has Microsoft made this insanely long. They have include version number in dll name because they cannot version symbols. So you are now end up with a growing number of incompatible C run-times. Yes crt stands for C runtime. Versioned symbols exists so you don't have to do this stupidity.

Most of the time glibc is perfectly fine running older applications with newer and this is only due to its heavy usage of versioned symbols.

https://github.com/moneymanagerex/mo...ex/issues/1161
Yes you have older versions of windows not being able to run programs because dll are missing. So you need to install runtimes that consume disc space. Lot of windows compadiblity is that is in fact has multi versions of run-times installed next to each other. This does lead to a security auditing nightmare.

I don't care about the version of a symbol. All I care about is the module it is from.

This is not understanding why global symbols are liked. Or how versioned was designed to be exploited.

For example, imagine prefixing symbols with "ELFname.symbol", so for example gtk2 would be "gtk2.foobar" and gtk3 would have "gtk3.foobar". Is that so fucking difficult for you to grasp? There's no version (other than major version, part of the library's name though).

STT_FILE in ELF specification exists for doing exactly that. Its disappeared out of favour. See you are calling for version number as part of library name.

Please note Microsoft has found without versioned symbols for compatibility you need put the full version number in the dll name. Welcome to disc space usage failure.

The "foobar" symbol, WITHOUT a module specified for it or prefixed for it, must be banned. Disallowed. Made impossible by the format so that no matter what the loader does, it can't load without the module. DLLs do that: no matter what the loader does, it's forced to look at the module name (and table) first before it can even see what symbols are imported from it (it's linked from the table containing the module name). This is in the format, it has nothing to do with the loader. It's not at the loader's whim, it's forced by the format of the DLL. The loader has to obey it.

This is lets disable the ability to preload to work around compatibility problems this is saying.

Remove the global namespace for symbols. Each symbol must specify which module it is from (so it's local to that module). That's... literally... it. Anything else you say is so off track it's not even funny.

Problem here is you are windows focused you don't understand why this pattern disappeared when STT_FILE versioned appeared. There is a need for libcapsule to finish off the versioned system off.

Lets say you have like libarchive that appears as multi different sonames how could you stub this under ELF. Simple create a stub ELF .so with a depends on the different name. Yes a stub elf that has a soname and depends on X library no imports, no exports this works because of global symbols. This does not work under PE. This means you don't need to know where the correct named .so only what the correct name is.

This is not the end of the tricks.
https://gcc.gnu.org/onlinedocs/gcc-4...ttributes.html
ifunc ("resolver")
You don't have this under PE either. This is what glibc added STT_GNU_IFUNC instead of STT_FILE. You can perform dlopen/dlmopen and dlsym in the resolver function. Heck you can perform the dlopen/dlmopen in the .so init. This allows you to have highly intelligent shim libraries.

Lets get back to gtk2 and gtk3 foobar. If they are versioned and you access them by version you should be able to access both at the same time. Here comes the good question is gtk2 foobar and gtk3 foobar exactly the same function? If it the same you really only want 1 copy in memory.

If gtk2 foobar and gtk3 foobar are in fact different functions you want the versioned as such.

The reason why libcapsule works it is using functionality that was planned. dlmopen allows you to open a .so hidden and export only the functions the application wants when combined with STT_GNU_IFUNC.

Now we get into the more interesting visibility ("visibility_type") why do we have internal Internal visibility is like hidden visibility, but with additional processor specific semantics. Unless otherwise specified by the psABI, GCC defines internal visibility to mean that a function is never called from another module. Compare this with hidden functions which, while they cannot be referenced directly by other modules, can be referenced indirectly via function pointers. By indicating that a function cannot be called from outside the module, GCC may for instance omit the load of a PIC register since it is known that the calling function loaded the correct value. protected Protected visibility is like default visibility except that it indicates that references within the defining module will bind to the definition in that module. That is, the declared entity cannot be overridden by another module. So you can in fact create a static library to link against your program to be dynamic that contains a stack of functions declared with ifunc("resolver") marked with internal that resolves how ever you shall please using dlopen/dlmopen with dlsym. Yes you can put a unique version tag on all those functions as well. This is basically duplicating STT_FILE entry that is missing.

https://msdn.microsoft.com/en-us/library/0b9xe492.aspx
Under windows you have to build .lib/.a static files to link against .dll files. It funny right that you could get the behaviour you want on Linux if you did the same thing instead of direct linking to the .so file. Interesting enough this route on glibc elf would allow you in the init stage to declare multi different sonames to look for.

Yes someone could make a auto tool to create these static files based off the libcapsule work.

ELF tricks also means it possible preload to replace globally allocated functions.

Please note the IFUNC feature is used in other places.
https://lwn.net/Articles/691932/

ELF is not PE. ELF platforms have their own bags of tricks and those tricks can replicate everything PE does. The problem I have is if no one will fund for their to be a ELF based tool like dlltool(mingw/cygwin) or LIB(MSVC) program to do what you want there is really no money in what you are asking for.

One of the reasons why Valve is so interested in Linux is being able to override global symbols for debugging has allowed them to track down problems when running programs on Linux that were insanely hard to attempt to find on windows being different memory leaks, file leaks.....

Weasel you want to say the problem is impossible so we have to change to be like PE. While complete missing that compilers build PE mostly require you to link against a static proxy library not a dynamic one and then over look that you can do exactly the same thing on ELF platforms and open up a huge stack of new tricks.

ELF is a more flexible than PE but ELF also requires you to think ELF way of solving problems. Yes this does mean using dlopen/dlmopen and dlsym at times.

Lot of ways who is going to invest in having a proper SDK with wrapper libraries.

Yes people on Linux think static or dynamic when they talk about libraries. Completely missing there is the static proxy library to a dynamic library option. By the way solaris and early Linux had a file extension for these static proxy libraries (.la) those files were basically auto generated dlopen/dlsym filling out internal function handle. Yes linked against .so got global symbols linked against the .la got locally to module declared symbols.

There are a few different ways to solve this problem without requiring any change to ELF format. Some you need to improve loader. Some you need to make tools like the tools to feed a .so file in and get a .la out. Yes some cases with .la out you would want dlmopen as option.

ELF loader being in userspace allows programs to change a lot of the rules. The fact no one maintains .la files any more is people building programs stopped using them. Yes you can build .la libraries without GNU IFUNC.

[brrrrttttt]

@oiaohm I don't think he's ever going to get it.

[Weasel]

The claim that windows SXS does not give you fixed versions means you have not worked with it on Windows. Private assembles SXS are a quite cool way to work around libraries missing features in old versions of windows. Also you have not really worked with wine conformance tests closely. There are quite a few failures that when you add a manifest to the wine test suite magically disappear. There are difference in behaviour between different versions of the same named dll.

A failed conformance test ON WINDOWS means that the test itself is WRONG. I'm not sure how many times I have to repeat this before you get it.

If a test fails on windows its not always complete wrong. Its sometime partly wrong that for X test you need to specify Y version of Z dll in the manifest. All applications to want that behaviour should have a manifest. Really how well wine works shows you how often you can totally ignore version information it also shows you that you cannot do this all the time.

Are you retarded? Yes it means that the TEST ITSELF is wrong and has to be rewritten to account for that manifest or whatever other crap you're spewing (btw, proof of that?). The purpose of the test is to prove WINDOWS BEHAVIOR, so if a test fails it means the TEST IS WRONG because it's not what Windows does.

Sorry the potential is a lot closer than infinitesimal. Lets not do the blahblah to hide issue.
A real one is api-ms-win-crt-runtime-l1-1-0.dll
Not only has Microsoft made this insanely long. They have include version number in dll name because they cannot version symbols. So you are now end up with a growing number of incompatible C run-times. Yes crt stands for C runtime. Versioned symbols exists so you don't have to do this stupidity.

They always included version number in CRT dlls. Short ones originally like "msvcp70.dll" and "msvcp90.dll" and so on.

There's nothing wrong with it. In fact, that's sane design. Different library = different symbols (even if they're the same name). The same happens in Linux too. You have gtk2, gtk3, etc. You don't have a single gtk library with symbols from all gtk versions. Idiot.

I don't give a shit about versioned symbols. They're nice, but not necessary, and have NOTHING to do with the problem at hand, which is keeping symbols local to a module.

Most of the time glibc is perfectly fine running older applications with newer and this is only due to its heavy usage of versioned symbols.

Which is nothing more than a hack or workaround the stupid global symbol namespace.

https://github.com/moneymanagerex/mo...ex/issues/1161
Yes you have older versions of windows not being able to run programs because dll are missing. So you need to install runtimes that consume disc space. Lot of windows compadiblity is that is in fact has multi versions of run-times installed next to each other. This does lead to a security auditing nightmare.

Yeah because of course installing missing dependencies is the problem we're discussing (as if that was the problem with ELF, inability to install runtimes, who the fuck complained about it? just you).

Not the fact that you can't load two different libraries that export the same symbol names in the same process.

Nah.


I don't really care what you say at this point. You do nothing but spew bullshit and grasp at straws. You brought up versioned symbols, which I don't give a shit about, and now you use them as argument against what I said, what the fuck is wrong with you?

All that matters is that, given three libraries:

foo1.dll
foo2.dll
abc.dll

All 3 of them can export the SAME FUCKING SYMBOL NAMES and you can load all of them into the same process with ZERO conflicts. NOTHING ELSE MATTERS. NOTHING.


Do that with ELF's global symbol namespace.

BTW versioned symbols are not going to cut it. You see, the libraries are called foo1, foo2, and abc. I DO NOT want all 3 of them to be placed in a single library with "versioned symbols". abc has no relevance to foo1 or foo2 to begin with (in name), it just happens to export the same symbols.

Maybe the symbol they all export is "init" which is a very simple symbol name so obviously it's common for it to clash.

This "init" symbol they all export is completely different in each library. It has a different prototype, does different stuff, etc. So it has nothing to do with another library.

Only in ELF you need retardation like "LIBRARY_IDIOTIC_PREFIX_init" names because otherwise "init" would have way too high chances to conflict with another library. No surprise since they're the same as global variables, i.e. the worst way to code.


Of course, the only way to load these with ELF would be with dlopen/dlsym, since those bypass the retarded global namespace. That kind of proves the point.