The Leading Linux Desktop Platform Issues Of 2018

[Weasel]

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

I don't get bullshit, no.

[oiaohm]

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.

When the failure is because the conformance test is missing a mainfest file so it picking up what ever random version of library? For application compatibility stupid enough the last added to the SXS under windows comes the default if you don't have the manifest. These failure disprove point that windows gets by without versioning.

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.

Please note CRT is your core libc. Really it would be possible to have a single gtk library with all gtk versions. This is what versioned in elf offers if developers wish to use it. That some library developers decide not to that is not a problem.

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.

Except that is not what your program imported when it built computer. MSVC complier imported foo1.lib, foo2.lib, abc.lib and mingw import foo1.a, foo2.a and abc.a. Go back to a old Linux or solaris with .la files. Do foo1.la, foo2.la, abc.la guess what it works.

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.

Good old .la by solaris did something nice and evil. Added to versioned the soname at start of the .la symbols versions..

#include <stdio.h>
__asm__(".symver new_fputs,fputs@GLIBC_2.2.5");
int new_fputs(const char *s, FILE *stream);
int main(){
fputs("hi\n",stdout);
new_fputs("hi\n",stdout);
}

Yes you can bend stuff insanely with ELF. .symver with correct header defines allows you bend your imports.

gcc main.c foo1.la, foo2.la, abc.la
Main.c using .symver on solaris can in fact access the conflicting function names in foo1, foo2 and abc here. All three could have a function called init. You use .symver to give those init new unique function name for main.c to use.
__asm__(".symver foo1_init,init@foo1");
__asm__(".symver foo2_init,init@foo2");
__asm__(".symver abc_init,init@abc");
void foo1_init();
void foo2_init();
void abc_init();
Yes the soname in version add there was added in the solaris la create process when solaris added versioned symbols.

Now try doing that to windows PE format. Yes the constructor/destructor is hidden in all those .la files.

.la files had the imported symbols local to module.

There is a documented method to block out "ELF's global symbol namespace" it involves making la files. That method allows handling of a module that needs to import the perfect conflit of the same soname/dllname and function but different library paths. Its just tweaking the versioned bit in the la library..

Versioned was added to ELF to do a few things.
Versioned allowes .so file to contain multi versions of symbols.
Versioned allows multi versions of symbols also to be declared and used inside 1 module the second usage is missed a lot.

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.

Does not apply with .la libraries and does not have to do "LIBRARY_IDIOTIC_PREFIX_init" as elf format has way of dealing with this.

Funny enough this init having library prefix happens on windows libraries as well. Why to deal with C language limitation. This rant is not a elf limitation.

There are very interesting flags in ELF. __attribute__((constructor)) and __attribute__((destructor)) yes these do work in static and dynamically linked elf libraries. __attribute__ ((visibility ("hidden"))) and other visibility works be the static of dynamic binaries. Yes the fun of constructor/destructor with elf there is a special table entry for them so the function names don't have to appear in the global name-space.

Please note .la does not in fact contain the functions it just a wrapper to dlopen/dlmopen and dlsym the .so file containing the functions and use local to module symbols for those imports.

[Weasel]

When the failure is because the conformance test is missing a mainfest file so it picking up what ever random version of library? For application compatibility stupid enough the last added to the SXS under windows comes the default if you don't have the manifest. These failure disprove point that windows gets by without versioning.

First, yes if the test is missing the manifest file, then it's the test's fault, obviously? What kind of logic would argue otherwise?!?

Secondly, who said Windows gets by without versioning? In fact, one of the beauties of DLLs is that you can load two versions of one library (if you need to) without conflicts even if they share symbols. But it's not limited to just "versions". It can be two arbitrary DLLs exporting the same symbols like "init" (generic name) and it will work fine, even if they have nothing to do with each other.

Please note CRT is your core libc. Really it would be possible to have a single gtk library with all gtk versions. This is what versioned in elf offers if developers wish to use it. That some library developers decide not to that is not a problem.

You don't get it. I do not want a monolithic library with all versions. That's the whole point. You should be able to load multiple libraries which export the same symbols. Multiple, not 1.

Except that is not what your program imported when it built computer. MSVC complier imported foo1.lib, foo2.lib, abc.lib and mingw import foo1.a, foo2.a and abc.a. Go back to a old Linux or solaris with .la files. Do foo1.la, foo2.la, abc.la guess what it works.

What? You're talking about static libraries.

I'm talking about dynamic libraries.

Doesn't matter what compiler imports. What matters is the resulting binary because it will NOT RUN on the same environment as where you built it -- Microsoft realized it, whoever "designed" ELF didn't.

In this case, the binary file format basically says "I want to load foo1.dll with the following symbols: init; I also want to load foo2.dll with the following symbols from it: init; same with abc.dll".

You can construct a DLL purely by hand with a hex editor, or with an assembler that outputs straight to binary (bypassing any linking). Compiler nor linker has nothing to do with this. Static libraries have nothing to do with it, either.

With ELF it's more like asking "I want to load the following libraries: foo1.so, foo2.so, abc.so; then I want to resolve the following symbols: init" (oops, from where is init? all 3 of them export it).

Adding stuff like "[email protected]" as suffix is more like a hack just to be closer to DLLs.

Good old .la by solaris did something nice and evil. Added to versioned the soname at start of the .la symbols versions..

#include <stdio.h>
__asm__(".symver new_fputs,fputs@GLIBC_2.2.5");
int new_fputs(const char *s, FILE *stream);
int main(){
fputs("hi\n",stdout);
new_fputs("hi\n",stdout);
}

Yes you can bend stuff insanely with ELF. .symver with correct header defines allows you bend your imports.

gcc main.c foo1.la, foo2.la, abc.la
Main.c using .symver on solaris can in fact access the conflicting function names in foo1, foo2 and abc here. All three could have a function called init. You use .symver to give those init new unique function name for main.c to use.
__asm__(".symver foo1_init,init@foo1");
__asm__(".symver foo2_init,init@foo2");
__asm__(".symver abc_init,init@abc");
void foo1_init();
void foo2_init();
void abc_init();
Yes the soname in version add there was added in the solaris la create process when solaris added versioned symbols.

Now try doing that to windows PE format. Yes the constructor/destructor is hidden in all those .la files.

.la files had the imported symbols local to module.

There is a documented method to block out "ELF's global symbol namespace" it involves making la files. That method allows handling of a module that needs to import the perfect conflit of the same soname/dllname and function but different library paths. Its just tweaking the versioned bit in the la library..

Versioned was added to ELF to do a few things.
Versioned allowes .so file to contain multi versions of symbols.
Versioned allows multi versions of symbols also to be declared and used inside 1 module the second usage is missed a lot.

That's symbol versioning which you already brought up before. And what you described is the same thing as DLLs (but uglier than DLL since it's part of the symbol's name as a suffix).

The problem is that it's not enforced. And I don't mean exact versioning. I simply mean appending the ELF's name & major version to the symbol. If it were enforced, it would be uglier than DLLs, but it would work the same, so it would be fine.

So yeah, remove global symbol namespace.


Also, you can *easily* do that with PE format, ever heard of def files? It's in fact much more elegant since you don't even have to use inline asms.

Funny enough this init having library prefix happens on windows libraries as well. Why to deal with C language limitation. This rant is not a elf limitation.

No, you can use def files on Windows to assign the symbols to arbitrary tokens / function names. You can even assign them to mangled C++ names (but they'll be exported with a simple name).

Like I said, stop exposing language specific internals in the output. That's the problem with ELF.

Yes, a lot of libraries use stupid prefixes on Windows too. It's due to laziness and has nothing to do with format limitations, but with the programmer (often Microsoft's own!) being lazy to map the symbols to something more sensible. Most open source libraries don't even use def files cause they're lazy and assume the whole world works like that stupid ELF exposing their language internals/limitations.

Example:

LIBRARY foo1
EXPORTS
init=some_really_annoying_longass_name_to_avoid_stupid_clashes_like_on_ELF

When you GetProcAddress (dlsym) you need to specify "init" so it's short and simple.

If you inspect the DLL with a hex editor, you see just "init". The long function name is NOWHERE to be found, as it should be: separate the fucking implementation details from the binary. That long-ass function name is a C-specific quirk, and should stay where it belongs: in C source code, not in the binary.

In your C code you can use stupid crap like "some_really_annoying_longass_name_to_avoid_st upid _clashes_like_on_ELF" but the binary doesn't care about your code. In fact, with GetProcAddress, you can do the same, call the pointer however you want.

[oiaohm]

You don't get it. I do not want a monolithic library with all versions. That's the whole point. You should be able to load multiple libraries which export the same symbols. Multiple, not 1.

Those wanting to do embedded and server do want monolithic library with all versions to improve memory efficiency.

Doesn't matter what compiler imports. What matters is the resulting binary because it will NOT RUN on the same environment as where you built it -- Microsoft realized it, whoever "designed" ELF didn't.

Microsoft did no realise at all. .la files predate ELF they come from Coff systems. .def generated .lib/.a is based on Coff .la. Since there was a system there was no need to reinvent the wheel. libtool early on generated Coff compatible .la files latter on they broke that no one complained then they started shipping without .la at all.

Example:

LIBRARY foo1
EXPORTS
init=some_really_annoying_longass_name_to_avoid_stupid_clashes_like_on_ELF

When you GetProcAddress (dlsym) you need to specify "init" so it's short and simple.

If you inspect the DLL with a hex editor, you see just "init". The long function name is NOWHERE to be found, as it should be: separate the fucking implementation details from the binary. That long-ass function name is a C-specific quirk, and should stay where it belongs: in C source code, not in the binary.

Really you must not read what you wrote. The = in the def file only works with GetProcAddress if the dll was built with that .def file and it has a real entry in the dll.

My example was dealing with the conflict without rebuilding the .so/.dll thank you very much.

__asm__(".symver foo1_init,init@foo1"); This is not a modification to imported library. This is a modification to what imported library export is called to C and other languages gcc/llvm supports on elf platforms.

That's symbol versioning which you already brought up before. And what you described is the same thing as DLLs (but uglier than DLL since it's part of the symbol's name as a suffix).

No its you dllname.symbol written backwards.
If you attempted to call init@foo1 without .symver declare you would get this does not exist. The stuff before the @ is in name in dynamic table the stuff after the @ is in the symbol version table.
.symver real, name@version .symver real, name@@version Real is what the program language sees the name@version/name@@version is what the real is in fact resolved from. After you have optimised and stripped symbols with ELF files the real here has pulled the magical disappearing act.

So its is nothing strange for a elf symbol table to have multi symbols with exactly the same name and having to reference the version table to get the right one. The usage of @ as separator is a convention from coff.

Both STT_FILE and versioned symbols allowed mappings so that you could keep C specific quirks inside your C files. Yes linker directives so that the linker know what function name C has used to link to what .so symbol.

The old school static .la file was way to add symbol versions to .so files that had failed to have symbol versions and you had a conflicting problem. STT_FILE in if support by dynamic loader was another and there was another special way to declare and map the symbol in case of conflict again with a linker directive.

I will agree not having STT_FILE and having to do it with static libraries and forced versioning or dynamic stubbing with versioning like libcapsule is a pain.

Please note abusing forced versioning is something a third party application developer could do today.

This time GetProcAddress is off limits so is .def or anything else modifying the dll. You have two dlls both with the function init and you must access them from 1 C file under windows Weasel basically shut up until you can or admit you have underestimated the flexibility of ELF. I have given you 1 C file using init in 3 different .so files I am only asking for you to pull off 2.

[Weasel]

Those wanting to do embedded and server do want monolithic library with all versions to improve memory efficiency.

I don't care. We're talking about desktop. God dammit, look what thread you're into.

Really you must not read what you wrote. The = in the def file only works with GetProcAddress if the dll was built with that .def file and it has a real entry in the dll.

WTF? View the fucking DLL in a hex editor. Or use CFF Explorer. Really you have NO FUCKING IDEA what you're saying.

All it exports will be "init". That's it. And its address will point to the code of the long ass function name (relative virtual address obviously).

My example was dealing with the conflict without rebuilding the .so/.dll thank you very much.

You don't need to rebuild anything just change the mapping.

__asm__(".symver foo1_init,init@foo1"); This is not a modification to imported library. This is a modification to what imported library export is called to C and other languages gcc/llvm supports on elf platforms.

No this has nothing to do with C, it's just an assembler directive that maps the symbol, which happens during assembly stage (which is way after the C compiler has ran its course). It's no different than the mapping that happens with a .def file or .lib file for the linker.

No its you dllname.symbol written backwards.
If you attempted to call init@foo1 without .symver declare you would get this does not exist. The stuff before the @ is in name in dynamic table the stuff after the @ is in the symbol version table.
.symver real, name@version .symver real, name@@version Real is what the program language sees the name@version/name@@version is what the real is in fact resolved from. After you have optimised and stripped symbols with ELF files the real here has pulled the magical disappearing act.

Yeah well here it's obvious you've no clue how things actually work at the lowest level (bytes, literally) so no point explaining since you won't get it anyway.

Both STT_FILE and versioned symbols allowed mappings so that you could keep C specific quirks inside your C files. Yes linker directives so that the linker know what function name C has used to link to what .so symbol.

Yeah, so why does the global namespace exist? Take it out. Really man, I'm not arguing against STT_FILE or symbol versioning. I'm arguing against the global namespace, which shouldn't exist. Full stop.

This time GetProcAddress is off limits so is .def or anything else modifying the dll. You have two dlls both with the function init and you must access them from 1 C file under windows Weasel basically shut up until you can or admit you have underestimated the flexibility of ELF. I have given you 1 C file using init in 3 different .so files I am only asking for you to pull off 2.

Sure? Use the IMPORTS keyword in .def file. WTF are you even babbling about. So clueless.

.def doesn't "modify" the DLL any more than the entire linking process "modifies" the DLL, It's literally part of the DLL build process just like your fucking object files are. It's like a command to the linker, no different than any other command (including which object files to link together), or even linker scripts (GNU ld).

So let's say you have an app that wants to load foo1.dll, foo2.dll and abc.dll, all of them export "init". In your code, you call them "foo1_init" "foo2_init" and "longass_name", but in the DLL they are all called "init". Do the reverse of the export .def file, map it for imports.

Create a .def file in your app's project containing this at the end:

IMPORTS
foo1_init=foo1.init
foo2_init=foo2.init
longass_name=abc.init

Problem solved? Now when you call longass_name in C/C++ code, you actually refer to abc's "init" symbol, as if you used GetProcAddress and assigned it to a longass_name pointer.

Can't be easier and more logical than this. Get over it.

Here some links to educate yourself, less bullshit would be nice:

http://docwiki.embarcadero.com/RADSt...ORTS_Statement
https://sourceware.org/binutils/docs...le-format.html -- even MinGW/binutils supports it.

I might have gotten the syntax wrong for IMPORTS, never used it personally, but I deal daily with EXPORTS def files.

[oiaohm]

I don't care. We're talking about desktop. God dammit, look what thread you're into.

Most distributions are funded by Servers and Embedded. Reason they want the ablity to have multi versions in 1 .so is to improve memory effectiveness. Memory effectiveness is a problem for Desktop users as well.

Create a .def file in your app's project containing this at the end:

IMPORTS
foo1_init=foo1.init
foo2_init=foo2.init
longass_name=abc.init

Problem solved? Now when you call longass_name in C/C++ code, you actually refer to abc's "init" symbol, as if you used GetProcAddress and assigned it to a longass_name pointer.

I told you not to do this. So I take it there is no way in the windows design todo this.

I might have gotten the syntax wrong for IMPORTS, never used it personally, but I deal daily with EXPORTS def files.

Its shows. Because your redirected inits will need a declare in C so they are usable.

.symver was created by sun as a asm directive because they thought about this problem. So you are able to declare the import connections and the program language header file requirements in the same file.

ftp://ftp.gnu.org/old-gnu/Manuals/ld...ode/ld_25.html
The fun of elf. .symver is for imported and exported symbols. You can integrate this into your headers or you can do it as asm file make a .o that you link into your program and library.

Yeah, so why does the global namespace exist? Take it out. Really man, I'm not arguing against STT_FILE or symbol versioning. I'm arguing against the global namespace, which shouldn't exist. Full stop.

Global namespace when you don't have conflict having the ability to preload to override stuff is useful.

Is there anything that says third party developers could not use version scripts on all their bundled libraries. The answer is no there is not. In fact when do this you run into another problem. A problem that also effects PE.

What do you do when foo.init appears twice. This is the libstdc++ problem. You have the host libstdc++ and the version in steam runtime libstdc++ this is like having kernel32.dll twice.

https://github.com/ValveSoftware/steam-runtime/issues/13

Yes this explode here. Yes the distribution and steam runtime have both provided a file named libstdc++.so.6.

STT_FILE and Versioned symbols only get you so far.

Versioned can get around this problem if libstdc++.so.6 in both cases is uniquely versioned then you force preload both libraries and every would work but in the steam case the host and steam have build with the same version style why because third party game providers wanted to reuse their prebuilt binaries. Yes you can force with LD_PRELOAD two libraries with matching soname and matching file name to be loaded into the link map.

Of course historic STT_FILE will not save you either in this problem because they are the same file name in fact there is no chance with STT_FILE that you can make it work. STT_FILE using LD_PRELOAD would never work around the problem. With this nightmare is there any chance PE will dig you out of it answer is again no. This is what you call totally worst case.

Is there a solution in the historic documentation to this nightmare. Yes the old .la files that force versioning. These are stubbing. What libcapsule is doing is about your only solution to the nightmare of same symbol name , same library name, same symbol version. Yes dlmopen was put into the load specification by SUN to particularly deal with this nightmare. We have the problem where glibc implementation of dlmopen has been levels of broken.

If you don't go the stub library route for this problem you will need means to modify import of binaries so that you can add versions or change file name(PE) programs that checksum self modify the binary itself it out PE you have just hit failure. Why I said this problem to fix it without stubs would require adding program.import and be able to alter the imports adding versioned symbols as required.

Please note versioned or by dll/so name does not prevent absolute conflict from happening.

Also note libcapsule is only able to pull of the trick as good as it can because of the global namespace its able to reach-out and override dlopen and dlsym globally across each link map segment. Yes global symbols are like global variables and when you get into particular levels of hell they are a very good thing.

Some symbols should be globally defined like the loader ones because if you are override them they are a special case problem.

Please note libcapsule has a application start up cost and a minor memory cost but no runtime performance cost. A third party that is not linked to any distribution could make a set of stub .so libraries that have all the require smarts of searching though the different so names distributions use.

With the way gtk is going someone at some point will need to make a stub library for it. Stub libraries have not been done in volume for 20+ years.

You said libcapsule is hack but it handles a problem your PE format does not. Absolute conflict is nasty problem .

[Weasel]

Most distributions are funded by Servers and Embedded.

And nobody cares in a thread titled "Leading Linux Desktop Platform Issues". I guess you're officially retarded to not be able to understand this simple fact.

It's like going to a truck company that advertises itself as "racing capable" (like desktop distros do), complaining about the pathetic speeds that their trucks have...

...and then you get a moron like yourself starting with bullshit like "but trucks make us do truck things and give us money!"

NO SHIT. The guy complained about your trucks' RACING POTENTIAL and SPEEDS, he doesn't give a shit what the trucks are currently used for.

If you don't like it then don't fucking label your trucks as "racing capable".

In other words, get rid of all desktop oriented distros and admit to the public that you don't give a shit about the desktop and that they're bad for the desktop. just like a truck company would admit they don't give a shit about racing.

But stop using retarded arguments. This thread is complaint ABOUT THE DESKTOP, so talking about servers says nothing other than the fact that you are a retard grasping for straws.

Reason they want the ablity to have multi versions in 1 .so is to improve memory effectiveness. Memory effectiveness is a problem for Desktop users as well.

This is absolute bullshit, as usual you literally have no idea what you are talking about and just use random buzzwords like other retards on this forum.

Did you know that libraries are mapped into memory so only the pages you actually access get loaded into memory?

However, even if that were not the case, loading a giant library would be even WORSE, because you'll be forced to load the entire thing even if you use only 1 version of the functions, so actually even in your dreamland you have it completely backwards.

I told you not to do this. So I take it there is no way in the windows design todo this.

No you said not to use GetProcAddress. This has NOTHING to do with it.

It's just a linker "script" that tells the linker how the functions in your code should be imported from the DLL. Effectively keeping your functions an implementation detail, as they SHOULD be, because they are part of SOURCE CODE. A binary has no business with the source code and should expose literally zero about the source.

.def files don't "modify" the DLL any more than a makefile "modifies" the DLL. They're commands on how to build the DLL. They're not part of the source code. They don't modify an EXISTING DLL, they just tell you how to BUILD one. (or an app)

Once you HAVE the DLL with "init" export, you do NOT need a .def file to import it. The .def file happens IN YOUR FUCKING APP that imports the DLL, not in the DLL.

Just to be extra clear because you obviously lack something up there: The .def file that IMPORTS the init functions is part of *YOUR* app, not the DLL. You don't need to "modify" any shit from the DLL. I mean, it's fucking logical, I don't even KNOW how you can think otherwise.

Its shows. Because your redirected inits will need a declare in C so they are usable.

No you don't need SHIT. That is literally JUST FOR THE LINKER YOU FUCKING IDIOT. C/C++ are compilers, which happen way before linking. It's to tell the linker "map the stupid compiled source function name to this when building the imports table". C/C++ don't build DLLs, the linker does.

The linker maps C/C++ names to anything it wants to, as you tell it via .def files or scripts (GNU ld). It can even map them to symbols with spaces in their names (GNU ld), which is not allowed in C/C++. DLLs are a binary format, like ELF, they should have NOTHING to do with a specific language.

You don't even know the difference between compiling (and languages) and linking it's just such a waste of time to talk sense into you.

You can even remap symbols like this with GNU ld scripts if you want and even use spaces in symbol names as I said (which is not allowed in C/C++), but of course not like you even know what GNU ld scripts are, either.

Heck with DLLs you can even use no symbol names at all and just use ordinals. Without GetProcAddress or any EXTRA CODE. GetProcAddress is obviously extra code, so that's out.

.def files are NOT CODE, they're commands for the LINKER. They're not part of C/C++ files, not part of the makefile to compile, part of the makefile to LINK.

Unlike your shitty examples with ELF that require asm statements in CODE so that's extra code indeed.

[oiaohm]

Did you know that libraries are mapped into memory so only the pages you actually access get loaded into memory?

That the problem. When you have multi versions in 1 library the same pages get shared in memory make memory usage lower.

So lets say you have two dll/so files with the same function. These when loaded into memory come two set of pages. If you have merged that into a single .so using versioned those functions are 1 set of pages. So yes version libraries do in fact end up using less memory than using multi libraries todo the same thing as you start loading programs using multi versions of those libraries.

However, even if that were not the case, loading a giant library would be even WORSE, because you'll be forced to load the entire thing even if you use only 1 version of the functions, so actually even in your dreamland you have it completely backwards.

Yes moron as you stated only the pages used are loaded into memory means a multi version library is more memory effective than using multi single version libraries. Why because if you are only using 1 version of functions out the multi versioned library it only takes up little more memory with dynamic loaded libraries than if you used a single version library. As soon as you have used 2 versions from that multi version library you are normally head due to duplication reduction.

Take glibc in most distributions if you converted it into individual versions you are talking 20 times bigger at least in disc space. Yes versioned is basically doing 20 to 1 compression quite impressive really. Versioned is something you serous-ally don't want to lose.

Versioned inside static libraries have no final binary overhead at all as this is solved out at link time.

Really its about time you give up your bad language Weasel. It has no effect on me and more bad language you are the more your post is wrong.

This is absolute bullshit, as usual you literally have no idea what you are talking about and just use random buzzwords like other retards on this forum.
So Weasel nice to know you are a retard by the way. Explains your stupidity. Versioned provides advantages.

Heck with DLLs you can even use no symbol names at all and just use ordinals.

That is not a difference. You only think its a difference because you have limited understand of elf.

https://blogs.oracle.com/solaris/inside-elf-symbol-tables-v2

Name (Optional: Not all symbols need a name, though most do)<< Notice no symbol name at all is in fact supported by ELF format.
STT_FILE when supported has ordinal support what is called indexed with the same defects as DLL ordinal. Of course this has fallen out of favour particularly when versioned came in. Having to keep exported functions in exactly the same order can be problematic with ordinal/indexed. You use to see this problem turn up with MFC42.dll under windows as well where different versions had changed ordinal/index arrangements then programs attempted to use ordinal value. Yes you can versioned symbols with no symbol name in elf(rare that you see this but it legal ELF).

Weasel you have not addressed Absolute conflict.

https://docs.microsoft.com/en-au/windows/desktop/Dlls/dynamic-link-library-search-order#search_order_for_desktop_applications

If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
The reality is Windows DLL implementation are not designed to deal with Absolute conflict.

Stubs, Versioned and link maps in the SUN design of ELF exist to allow method around Absolute conflict and to be memory effective.

https://github.com/ValveSoftware/ste...time/issues/13
This Absolute conflicts you have to deal with. Linux/Unix/BSD world are not one vendor. So you cannot write a hard rule you will not use 2 so of exactly the same so name with exactly the same symbol name with exactly the same version info in your program. Dlmopen was included by sun at the start because this problem was always going to happen. Libcapsule is fairly much just implementing what was planned.

[Weasel]

oiaohm Ok, I actually realized how much of a waste of time fighting your endless sea of bullshit is. So I wrote this post, to prove you wrong, VERIFIABLY by anyone with half a brain on their own computers, and maybe also misguided puppets like brrrrttttt who think you know anything when in fact all you parrot are random buzzwords so maybe they can feel embarrassed. Like I said, I don't "get" bullshit, and I will prove it, tough for you.

I wrote this because I will bookmark it and link to it everytime another idiot will keep talking about DLLs and PE when he has no fucking clue like oiaohm, who don't code and clearly have zero idea and still parrot bullshit after bullshit.

This post is aimed at *ANYBODY* who wants to verify for himself that, yes, indeed, Weasel is the only one who is right here and oiaohm is full of shit. I know I'm insulting, so please, let actions speak louder than words. You don't have to trust anybody's word at all (yes, you, the person reading this!), just execute the following steps yourself. What more easy than verifying it yourself? Go ahead and disassemble the resulting .exe file if you want to (objdump or anything) or view it in a Hex Editor. Anything you want!

We will build an app.exe simple Windows executable that calls three functions in order from 3 different DLLs. Each function is imported and their symbol names is just "init". ELF would totally crap-out with 3 symbol conflicts here due to that degenerate "global symbol namespace".

In code, of course, we'll call them something else since C can't disambiguate by DLLs. But that's okay, C is an implementation detail, while a DLL is a sane binary output format.

Keys of note:

• You will call "init" symbols from foo1.dll, foo2.dll and abc.dll in your app, in that order. Each has a different prototype, so it's completely different (to prove this is EASILY possible).
• All you know about the DLLs is that they export those 3 symbols and their function prototypes (which you write yourself). You don't even *HAVE* those DLLs on your build machine!!! I repeat, you DO NOT NEED to have the DLLs, so don't worry, we will NOT build any DLL, contrary to what oiaohm "the parrot of bullshit" said.
• Basically, you have NOTHING about those DLLs other than *KNOWLEDGE*. You don't need a .lib, or a header, or anything at all. Just information in your HEAD.
• You will need MinGW, but in this example I will build it on Linux (cross-compile), so no, you do NOT need Windows to build this.

First step, go and install MinGW-w64 with your package manager. We need it to build Windows executables. We still use Linux though, and this app can be used in Wine (but it will fail to load since the DLLs are fictional and don't exist, that's okay though -- it's just an example -- but the .exe file will exist, and if you make those DLLs, it will actually load and work).

So it's perfectly useable under Linux with Wine. We don't need Windows for anything. Proving DLLs are simply superior to ELF -- even on Linux.

First, let's create our small C example file:

/* Normal function declarations, nothing to do with DLLs */
/* Use declspec(dllimport) if you want better code generated, but it's not necessary */
void foo1_init(int);
void foo2_init(int, int);
int longass_name(int, int, char);

/* Normal exe entry point without stdlib, nothing to do with DLLs */
void mainCRTStartup()
{
    foo1_init(42);
    foo2_init(7, 11);
    longass_name(1, 2, 3);
}

Save this as app.c. Yeah, that's literally it.

Let's compile it now. We don't have the .def file or anything, but that's okay, since the .def file is part of the LINKING process (again, to disprove oiaohm's bullshit), so right now C/C++ don't give a shit what we're building. All they know is a perfectly normal C program like the above.

declspec(dllimport) is entirely optional at this point. It doesn't have anything to do with our DLL. What it does is it tells the C compiler to generate

call QWORD PTR [function]

instead of

call function

the latter which will be replaced by a stub by the linker (because it is 5 bytes, and won't fit in 6 bytes like the former). Which is only slightly less efficient. Again, this has nothing to do with our .def file.

So let's compile it as-is without declspec(dllimport), just to avoid oiaohm's further bullshit on the matter. Simply execute:

x86_64-w64-mingw32-gcc -c app.c -o app.o -Werror

Cool stuff, now we have app.o object file.

Now that we have compiled it, you can even remove app.c if you want, we won't touch the source code at all nor the C compiler (again, to disprove oiaohm's bullshit).

Now we want to turn this into an .exe file. But as we know, our 3 DLLs all export a symbol called simply "init". Our object file, however, uses those function names above. Time to create that .def file:

IMPORTS
foo1_init=foo1.init
foo2_init=foo2.init
longass_name=abc.init

Save this as app.def.

Now, to build the app.exe:

x86_64-w64-mingw32-gcc -s -o app.exe app.def app.o -nostdlib

WOW IT WORKED!!!!!! LOOK AT THAT, IT ACTUALLY LINKED?!??!?

YOU DIDN'T EVEN INCLUDE A SINGLE HEADER, OR A SINGLE LIBRARY OR ANYTHING!!!!!!?!?!?!? WOW!!!

Congratulations! You've just been enlightened by one of the few people who knows his shit on this forum. Hopefully, this made you realize just HOW MUCH FULL OF SHIT oiaohm is with his endless sea of verbal diarrhea.

Go on, disassemble the EXE, inspect it with CFF Explorer or a Hex Editor. Please. Make sure that, yes, indeed, the symbols it imports are called "init" from each of the 3 DLLs. Make sure that there's no trace left of the source code's use of "foo1_init" or "longass_name", i.e. they're implementation details, not exposed to the binary.

Blissful and sane design unlike that pathetic ass-backwards ELF.

So kids, that's how you know that Weasel is totally right when he says ELF is garbage and DLLs are simply superior. Because, you know, he's not just empty words like this oiaohm.







Now questions to idiots I argued with:

• At which point did we "modify" the DLLs with .def file? The DLLs don't even exist, how do you modify something that doesn't exist? Fucking moron.
• Where's the massive C language limitation here? I recall someone mentioned that, and that's why global namespace exists... but you see, language is the front-end. It has nothing to do with resulting binary in a sane design like DLLs.
• When will you morons shut the fuck up about stuff you've no clue about and don't even CODE YOURSELF?

Thanks for the pathetic waste of time. This post will be bookmarked so this is hopefully the last time I ever have to explain logic basics to ignorant dumbfucks.

Now shut the fuck up.

[oiaohm]

First, let's create our small C example file:

/* Normal function declarations, nothing to do with DLLs */
/* Use declspec(dllimport) if you want better code generated, but it's not necessary */
void dog_init(int);
void woof_init(int, int);
int longass_name(int, int, char);

/* Normal exe entry point without stdlib, nothing to do with DLLs */
void mainCRTStartup()
{
foo1_init(42);
foo2_init(7, 11);
longass_name(1, 2, 3);
}

Save this as app.c. Yeah, that's literally it.

Now we want to turn this into an .exe file. But as we know, our 3 DLLs all export a symbol called simply "init". Our object file, however, uses those function names above. Time to create that .def file:

IMPORTS
woof_init=foo1.init
dog_init=foo2.init
longass_name=abc.init

Save this as app.def.

See the intentional mistake I have done to your code.

This time GetProcAddress is off limits so is .def or anything else modifying the dll. You have two dlls both with the function init and you must access them from 1 C file under windows Weasel basically shut up until you can or admit you have underestimated the flexibility of ELF. I have given you 1 C file using init in 3 different .so files I am only asking for you to pull off 2.

Weasel read my question it clear .def is off limits. Simple you have used a .def you have failed. I can do the same thing using a linker script using ld on elf as well. Instead you presumed incorrectly I don't know how to do that..

I wanted .symver equal for a reason. See the disaster def is one file your define is another. Human typo sneaks in you now have trouble. Please note .symver as a asm directive is part of the elf format specification. Little nice features like this are missing from PE specification.

Weasel you have not addressed Absolute conflict.

https://docs.microsoft.com/en-au/win...p_applications
If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
The reality is Windows DLL implementation are not designed to deal with Absolute conflict.

Stubs, Versioned and link maps in the SUN design of ELF exist to allow method around Absolute conflict and to be memory effective.

https://github.com/ValveSoftware/ste...time/issues/13
This Absolute conflicts you have to deal with. Linux/Unix/BSD world are not one vendor. So you cannot write a hard rule you will not use 2 so of exactly the same so name with exactly the same symbol name with exactly the same version info in your program. Dlmopen was included by sun at the start because this problem was always going to happen. Libcapsule is fairly much just implementing what was planned.

Weasel really I think you have to use swear words to attempt to cover up the fact you cannot read and are basically illiterate.