The Leading Linux Desktop Platform Issues Of 2018

[carewolf]

You don't have to be careful at all, you just don't have to be a retard to free a pointer with your own library allocated by another library.

libcapsule is only needed on Linux due to how ELF is a retarded braindead fucking piece of hot garbage designed format. In fact what libcapsule does is impossible on DLLs unless the app specifically targets libcapsule (which means recompilation). It's not even needed on DLLs.

Your "correct solutions" are only solutions to a problem created by a shit design of ELF in the first place. Don't act like Windows suffers from the same garbage.

Only with ELF.


Here's a better solution: Either use DLLs on Linux (like Wine does), or REMOVE THE FUCKING GLOBAL SYMBOL NAMESPACE from ELF.

That is a link time option with ELF. I made it default for plugin loading in Qt because it solves the problem of plugins linking to incompatible libraries. Though I would not have it be a normal linking default as that would lead to too many copies of the same library in standard cases.

[carewolf]

Can you prove the existence of namespaces in executable formats? You are the only one who talks about namespaces, so I am not sure.

If it is true that ELF uses a global namespace, is it possible to work around this problem from ld-linux.so/ld-2.28.so? (the library that does dynamic linking and stuff)

I believe he means symbol resolution is usually global so that all libraries gets the same library and codepoint for the same symbols. That's the default, but at least with dlopen it can be configured.

[carewolf]

I believe he means symbol resolution is usually global so that all libraries gets the same library and codepoint for the same symbols. That's the default, but at least with dlopen it can be configured.

It should be noted though that this is C limitation. No API based on C can fix this because imports in C are just header files declaring the symbol exists globally, you don't even need a header file, you could write the same in your source file before using the imported symbol, C has a global symbol namespace.

I believe the C++20 modules standard might be one solution of fixing that side of it, but otherwise conflicting symbols can only be handled by runtime linking (like OpenGL or plugins)

[oiaohm]

That is a link time option with ELF. I made it default for plugin loading in Qt because it solves the problem of plugins linking to incompatible libraries. Though I would not have it be a normal linking default as that would lead to too many copies of the same library in standard cases.

Yes that option exists and as you said it has downsides. You have to allow for memory duplication. The copies in memory is not the problem.

http://widefox.pbworks.com/w/page/8042318/Process

Some of the windows process start up time is so bad is the resolve of all the link maps. Works out between x6 to x10 slower at starting processes than Linux. Populating all the link-maps does not come cheep.

https://git.collabora.com/cgit/user/vivek/libcapsule.git/tree/README

libcapsule if you hard got a plugin that was incompatible without relinking it you can put a shim around it and have it work.

Libcapsule is also working on including ways of reducing duplication between private link map and the global link map. But still you would not want to use this any more than what was required.

I believe he means symbol resolution is usually global so that all libraries gets the same library and codepoint for the same symbols. That's the default, but at least with dlopen it can be configured.

libcapsule overrides dlopen and redirect it own for contained to fix this problem.

It should be noted though that this is C limitation. No API based on C can fix this because imports in C are just header files declaring the symbol exists globally, you don't even need a header file, you could write the same in your source file before using the imported symbol, C has a global symbol namespace.

I believe the C++20 modules standard might be one solution of fixing that side of it, but otherwise conflicting symbols can only be handled by runtime linking (like OpenGL or plugins)

https://clang.llvm.org/docs/Modules.html#problems-modules-do-not-solve

At this stage C++20 modules still says when you get to library runtime linking it does nothing to help you.

Binary distribution of modules: Headers (particularly C++ headers) expose the full complexity of the language. Maintaining a stable binary module format across architectures, compiler versions, and compiler vendors is technically infeasible.

Yes they are down right clear they are not even going to attempt to try. You what cross compiler libraries C and posix standard it is(that does not help you on windows).

C++ has never provided a proper solution to a runtime linking problems. Instead every single time it like this we will leave it to the compilers and hope they do the right thing.

The only solution I can see to these problems for Linux is the libcapsule route working on adding the features into the posix libc standard in time.

Modules are just going to bring more C++ breakages. Yes modules in C++20 are not even promised to match between llvm and gcc on Linux. Those who have hope that it will make creating plugins better it not going to.

[carewolf]

At least in C++ we can use language namespaces, that solves it by making it different names. It just isn't backwards compatible, when you switch to it.

[Weasel]

There are such things as global free. On Linux platforms you will find most libraries due to being design with posix standard in mind are using a common memory management system.

So you don't have 1 million different implementations. Its not the same as mixing functions. fclose(abc) is to kernel function for a file. Allocation of memory is a libc wrapped kernel function on Linux. Linux is posix based this means you malloc and free should be a application wide solution.

POSIX has nothing to do with it. POSIX mandates what the interface is, and what it should do (i.e. its contract to the outside world). It doesn't mandate what the IMPLEMENTATION should be.

Is it really so hard for you to understand that free() can be implemented in an infinite amount of ways, with incompatible data structures compared to another malloc? Seriously dude? What the fuck is so hard.

Show me where a specification tells you exactly what internal data structure to use and how to layout the memory and so on -- internally. Obviously, a malloc needs some data before the allocated pointer, to know its length at least and other stuff, which free uses.

This is not about standard libraries this is about platform standards. Part of Unix/Posix standards are global free parts that should just work. You should be able to malloc in 1 library and free in a different one. Please note you open a file in 1 .so file you close it in another heck it could be closed in a complete different process because it got passed over. Yes due to different runtimes under windows closing files in different dll to where they were open can fail badly as well.

Ok, since you're retarded, I'll give you a real example instead of an analogy.

When you write an application, free() does not exist. When you write a library, free() does not exist. You have to import it. Same with malloc.

You don't write the library, and you don't have its source code, so you can't control what the library links against in this example. It links against "libc-foobar-version" with its own malloc/free implementation and data structures.

But you, on the other hand, link to normal libc. So you get totally different malloc and free. The point is that THERE IS NO GLOBAL FREE BECAUSE IT DEPENDS ON WHAT YOU IMPORT. Now shut the fuck up. You don't mandate what everyone should link against.

In this case of course we assume ELF doesn't suffer from global symbol clashes.

Really this is because you fail to think.

Each DLL has it own look up table this sounds like it could be faster. Lets say each dll uses malloc and free from runtime. You have 10 dlls you have just perform relocation 20 times to fill in the link-maps of the dlls. Yet when you have a global link-map that gives you your global symbol namespace the malloc and free relocation would have been performed only once.

The search of the link-map is not that expensive. Costly is relocation calculations. This relocation record cost comes from coff so there is no real difference here between PE and ELF. Difference is implementation.

Windows loader just creates a link-map per dll. So Windows have higher relocation calculation costs because windows is calculating more relocation. Also each duplicate link-map consumes ram.

Please note this is called dynamic linking.

I have no idea what kind of technobabble crap I just read. You have 10 dlls as opposed to 10 ELF .so or what? I don't understand your point at all. And you only have to relocate 10 times in this case, not 20 times, what the FUCK are you talking about. On x86-64 the amount of relocation is insignificant due to RIP-relative addressing enabling efficient position-independent code.

Oh right, you don't code, and you talk as if you know anything... Lol.

If you mean that you have 10 different DLL runtimes, then that's not fault of DLL at all, it's having 10 different runtimes. Having 10 different ELF runtimes isn't just "slow", it will fucking crash, and idk about you but I'd take slow over a crash anyday.

What you compare is ONE LIBC of ELF with 10 different DLL runtimes. That's just bullshit. You can have ONE runtime with DLLs too, if that's the bullshit you want to enforce.

So basically you whine that DLL gives you flexibility in having 10 different runtimes than being FORCED to use ONE libc only. Splendid point! /s

When you make a static binary you make a link map. You have a total of 1 link map for symbols. Link-maps is your limitations when you are linking dynamically or staticly. So static linking does have symbols when its linking those are stripped from final binary.

And your point is...? We're obviously talking about binary software end result, which needs ABI not API stability.

If you are making applications than can be dynamically linked or static linked as lots of Linux programs are you have to see that static linking you have only 1 global symbol namespace that is static solved. So having 1 global symbol namepace/link-map when dynamically loading for performance also makes sense.

I will say having only 1 functional link-map when dynamic linking has caused problems. Having a link-map for your application code and a different one for host would be great for portable binary. Also having a link-map per plugin would also be great.

Having a link map per dll is over kill it costing cpu time and memory. The usage of link map should be planned because its not a free item.

More technobabble nonsense.

But you know, we're talking about BINARY applications here. Static linking symbols have zero point in this discussion. You don't have the source code or object files available. Deal with it.

[Weasel]

It should be noted though that this is C limitation. No API based on C can fix this because imports in C are just header files declaring the symbol exists globally, you don't even need a header file, you could write the same in your source file before using the imported symbol, C has a global symbol namespace.

It's not a C limitation. Because what matters is the binary end result and its distribution, not the source code (yes, even for open source software, 99% of people do NOT compile it).

ELF is built around this SHIT IDEA that the build environment IS THE SAME as the runtime environment. That's just a load of crap and that's why it's so pathetically designed.

Build environment is TOTALLY SEPARATE from distributed runtime environment. Once oiaohm understands this simple fact, you realize why ELF is just terribad.



Also there's nothing in C standard that says the imported symbol names must match the function names. In DLLs, you can use .def files to define what name a function in C should map to. As it should be. This enforces proper design.

For example you can have "some_function" map to "someReallyLongPrefixHere@@ even spaces yes @@ some_function" as the symbol name if that's your thing.

But I forgot ELF is all about exposing the internals of the source code to the binary directly, that's why it's such a pathetic format.

[Weasel]

Modules are just going to bring more C++ breakages. Yes modules in C++20 are not even promised to match between llvm and gcc on Linux. Those who have hope that it will make creating plugins better it not going to.

Obviously once again you show just how out of loop you are and think you know what you're talking about, while in reality you don't know shit.

Nobody distributes modules to the end user, nor static libraries. That's like distributing LTO-compiled object files, which break on any other version of GCC. You just don't do that.

The reality is that the END USER's machine and environment is TOTALLY SEPARATE from the developer's machine, and in this case, the developer is the one who does the compilation and the linking. User doesn't even have a compiler or linker installed. Comprehende?

What the end user receives is a binary that cannot be linked nor compiled, as it should be. None of your babbling is relevant to this point. That's what the desktop user wants.

[carewolf]

It's not a C limitation. Because what matters is the binary end result and its distribution, not the source code (yes, even for open source software, 99% of people do NOT compile it).

ELF is built around this SHIT IDEA that the build environment IS THE SAME as the runtime environment. That's just a load of crap and that's why it's so pathetically designed.

Build environment is TOTALLY SEPARATE from distributed runtime environment. Once oiaohm understands this simple fact, you realize why ELF is just terribad.



Also there's nothing in C standard that says the imported symbol names must match the function names. In DLLs, you can use .def files to define what name a function in C should map to. As it should be. This enforces proper design.

For example you can have "some_function" map to "someReallyLongPrefixHere@@ even spaces yes @@ some_function" as the symbol name if that's your thing.

But I forgot ELF is all about exposing the internals of the source code to the binary directly, that's why it's such a pathetic format.

Listen dumbass. It is one thing that you are ludicrously wrong, but don't also be offensively wrong.

Just stop.

C has a global name space, and adding import renaming doesn't change that, nor is it a flaw in system if it doesn't force you to do symbol renaming, you are trying to make a virtue of a flaw in dlls when it is just a flaw, and you can do similar renaming in any other linking framework

[ssokolow]

He has a point about applications being portable and installable to other mediums. You can in theory put a flatpak on another drive but its not exposed in a friendly way.

True, but that's to be expected. Flatpak has been taking a very measured approach to things:

First, stabilize the spec and core stuff, so desktops can start buying in.

Second, work on getting all the portals supported by desktops with basic, minimum functionality so packagers can start buying in.

Third, once flatpak'd applications work well with defaults, start working on things like easy non-default install locations, end-user overrides for sandboxing policies, etc.

I don't know what are you talking about, nowadays most windows apps(that I use, and I'm a developer) or they automatically update(downloading by themselves the latest version and installing it automatically) or provide a notification of a new update with a convenient link to the download page(so there's no need to keep in mind to check for updates and search for the download link).

I don't know about you, but, when I was using Windows, I considered outdated applications more acceptable than a task manager full of resource-wasting single-application/single-vendor "update helpers" and I generally turned off in-application update checks as too annoying if they stopped at "open the download page in the browser".

They don't compete.
If I'm on a machine where I don't have administrative permissions, I have no way of using flatpak or snap. I can, however, simply download an AppImage and run it. IMHO that's exactly what OSX does right in regards to application handling.

To quote KDE's Flatpak HOWTO:

All flatpak commands (such as remote-add and install) accept a --user option to install things at the user level, without being prompted for the sudo password every time.

Sure, that still requires the administrator to have flatpak itself installed, but that's very different from inherently requiring administrative privileges for each install. (Not to mention that the end goal is to have Flatpak as part of the default system image and it's not as if administrators who would remove Flatpak can't also prevent Appimage's from functioning.)