Announcement

Collapse
No announcement yet.

Google Still Doesn't Trust Linux GPU Drivers Enough To Enable Chrome Video Acceleration

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by oiaohm View Post
    Weasel you are the Retard the xonotic. binary is not statically linked its a dynamic binary. The developers has built it a particular way.
    Lol there's no difference.

    If you use dlopen/dlsym you are using the exact same behavior as DLLs and bypassing ELF's retarded global symbols.

    Thanks for, yet again, proving my point even more. Idiot.

    Originally posted by oiaohm View Post
    No xonotic cross platform application build pulls off the same stunt wine does without using dlopen/dlsym.
    Which demand you to specify a library to import a symbol from. Sounds like DLLs.

    xonotic sounds like it does "manually" what DLLs do "automatically".

    Yes this definitely proves ELF is so well designed for idiots like you that you have to painstakingly do it manually and avoid its normal bullshit loader.

    Originally posted by oiaohm View Post
    This means you never looked. Wine tells a interest story.

    Please note dlopen/dlsym is just a method without having to build shims to build against not to have version information on the symbols you are linked against.

    Using dlopen does not prevent conflict between two libraries using different versions of C++. To avoid symbol conflit you need to use dlmopen wine does not because that thing has been nastily buggy. Please note you can have dlmopen used on your library at load by specifying when you are build that its a audit library under Linux or Solaris. Please note historic glibc has had stupid issues like a max of 16 link maps per program and no shared libraries added to the new link map no matter what function you use. This is the same as what you get when you build a win32 nt native binary that purely depends on ntdll or uses direct kernel syscalls(under windows that is insane).

    nt native exists for debug subsystem parts like kernel32.dll while not depend on them. So if kernel32.dll happened to have a bug that caused everything running kernel32 to crash you would not want your debugger depending on kernel32.dll right. Of course you still want means to load libraries.

    When you use loadlibrary in kernel32 under windows you get a common library. libcapsule basically gives you kernel32 loadlibrary. dlmopen historically when it works gives you like loading libraries using ntdll functions good for debugging/auditing so not much to application developer as they automatically create split brain and are designed to do exactly that and is a useful debugging feature.
    Can you just shut up about dlopen/dlsym?

    I never complained about those. Those work *exactly* like DLLs and LoadLibrary/GetProcAddress. Why would I complain about them?

    Stop changing the subject and being so desperate.

    To me the fact that they are literally your only argument just proves you already lost any argument you had about ELF not being retarded with global symbol namespace.

    Now you say "see ELF is not so bad it can be like DLLs if you load symbols manually" when the point was the loader not using dynamic lookup in code.

    And the best part? Nothing of what you said makes DLLs any worse. It's just you trying to desperately hack your way through with shitty ELF just to end up with the functionality of a DLL. dlopen/dlsym are testament to that.
    Last edited by Weasel; 10-11-2018, 08:09 AM.

    Comment


    • Originally posted by Weasel View Post
      xonotic sounds like it does "manually" what DLLs do "automatically".
      No xonotic does not do it manually. Only thing when gcc of llvm links you dynamic binary it must see .so files that don't contain version information or they annoy set version information so ruining your cross platform.

      You can have visual studio get creative and auto populate you manifest with unrequited version restrictions as well. Issue here is the linkers on Linux lack a good easy to use off switch to say yes I want this .so file but I don't want you to include version information on the symbols.

      The dynamic loader only cares about symbol version if version information is in the program. Lot of glibc symbol not defined not that the glibc on the system does not have a suitable version of that symbol. But that there was some fault in that symbol that could cause a security issue and and it was revised slightly altering its operation. Like 99.9 percent of the time application not going to have a issue with the old buggy version of that symbol.

      Originally posted by Weasel View Post
      I never complained about those. Those work *exactly* like DLLs and LoadLibrary/GetProcAddress. Why would I complain about them?
      dlopen places all the libraries you have requested in the same link map. LoadLibrary does not in fact do that. You find this out when you load 2 libraries with confliting runtimes. So like something that requires two different versions of libstdc++ library
      A.so requires libstdc++ version A
      B.so requires libstdc++ version B
      You dlopen A.so version A libstdc++ is now loaded into link map.
      you dlopen B.so it now gets version A libstdc++ and you application fails because B happened to be incompatible with version A of libstdc++.

      This would not happen right if you use LoadLibrary right.
      dlmopen give can use a different link map is totally not populated by anything.
      http://man7.org/linux/man-pages/man3/dlmopen.3.html
      You can read it here LM_ID_NEWLM
      https://linux.die.net/man/8/ld-linux
      Read down and start cursing.
      LD_AUDIT
      There is a group of librarys loaded into its own NEWLM.
      So for you application you can two link maps just using what the default loader provided. One problem fairly much totally disconnected from each other.

      So yes glibc developers gave themselves means to run libraries to diagnostics in own link map. But then application developers were not given that feature as a link flag. The fact that the loader can do it for audit diagnostics means it not a ELF format problem. Its a loader implementation problem. Remember version on ELF symbols are a glibc extension. There is no reason why version information could not include this library should be loaded in own link map.

      Loadlibrary is in fact like libcapsule. That is a unique link map per so/dll and common shared so/dlls. It shims provides a nice proxy for existing applications.

      Remember issues libcapsule are fixing in dlmopen are really required before should expose option from loader because there are libraries that need to be shared when you split a library off into its own link map.

      Originally posted by Weasel View Post
      Now you say "see ELF is not so bad it can be like DLLs if you load symbols manually" when the point was the loader not using dynamic lookup in code.
      The problem is not the format. ELF format allows you to define your own loader in .interp. Gcc own include loader at times does load 2 more more link map.

      One of the LSB developers did make a over wrapper for the glibc loader that provide this feature as well. But he got funding to do this work and he end up giving up on it. I am really thankful to valve for funding libcapsule this time around.

      Audit interface is not fun for application developers to say the least. Its not that ELF format cannot have .so files loaded in different link maps. Its that the most common ELF loaders don't give you the feature for anything other than Audit.

      LD_AUDIT libraries are loaded in to their unique link map by using dlmopen.

      Comment


      • Originally posted by oiaohm View Post
        No xonotic does not do it manually. Only thing when gcc of llvm links you dynamic binary it must see .so files that don't contain version information or they annoy set version information so ruining your cross platform.
        dlopen/dlsym and other things you do in code is exactly what manual means. Isn't that what you said it uses? So yes, that's exactly what I mean by "manually". You have to embed extra binary code for it.

        Originally posted by oiaohm View Post
        You can have visual studio get creative and auto populate you manifest with unrequited version restrictions as well. Issue here is the linkers on Linux lack a good easy to use off switch to say yes I want this .so file but I don't want you to include version information on the symbols.
        Those aren't code so no, it doesn't matter what the linker does.

        What matters is that with CODE (dlopen/dlsym) you BYPASS ELF's normal loader since they're just APIs -- proving it's complete shit.

        Originally posted by oiaohm View Post
        dlopen places all the libraries you have requested in the same link map. LoadLibrary does not in fact do that. You find this out when you load 2 libraries with confliting runtimes. So like something that requires two different versions of libstdc++ library
        A.so requires libstdc++ version A
        B.so requires libstdc++ version B
        You dlopen A.so version A libstdc++ is now loaded into link map.
        you dlopen B.so it now gets version A libstdc++ and you application fails because B happened to be incompatible with version A of libstdc++.
        This has nothing to do with dlopen. This is because of ELF's retarded global symbol namespace, which is EXACTLY the point of all of this.

        dlopen simply loads the library. If A.so used dlopen on libstdc++ version A, and B.so likewise used dlopen on libstdc++ version B, then there would be no issue. Of course it's gonna fail if it uses ELF's global namespace retardation, thanks for showing EXACTLY MY POINT of why it sucks!

        dlopen just in YOUR app is not enough, you need dlopen on EACH AND EVERY dependency, along with dlsym, to have sane behavior like with DLLs. In your example A.so and B.so use the retarded global namespace and that's **EXACTLY** why it fails.

        dlsym's first parameter is the MODULE from dlopen, so if you load version A and look up a symbol in it, it will NOT load it from version B, so you can have BOTH loaded in the same process. This is sane, and guess what? It works exactly like DLLs.

        And by that I don't mean GetProcAddress (which also works the same). I mean even the normal, automatic, DLL imports work exactly that way.

        Conclusion: ELF is retarded, DLL is sane.



        ELF is retarded no matter how you look at it. If you think the global namespace is good, then dlopen/dlsym must be retarded since they are like DLLs, so ELF is retarded due to this asymmetry.

        And if you think (like me) that the global namespace is retarded, then well... ELF is still retarded.

        You can't win with ELF. DLLs have only one (right) way to import, so you can win with DLLs.
        Last edited by Weasel; 10-12-2018, 08:23 AM.

        Comment


        • Originally posted by Weasel View Post
          ELF is retarded no matter how you look at it. If you think the global namespace is good, then dlopen/dlsym must be retarded since they are like DLLs, so ELF is retarded due to this asymmetry.
          Did not read Weasel
          LD_AUDIT libraries are loaded in to their unique link map by using dlmopen.
          Do you know what LD_AUDIT .so files do.

          These these load before you application in fact loads and takes control of the glibc/solaris dynamic loader.

          Originally posted by Weasel View Post
          This has nothing to do with dlopen. This is because of ELF's retarded global symbol namespace, which is EXACTLY the point of all of this.
          There is a off switch to ELF global symbol namespace. Happens to be there is one
          LD_AUDIT=thirdpary.so yourprogram

          Using the link header and a audit library you can bend the dynamic loader in glibc or solaris around your little finger.

          So with the right library in LD_AUDIT basically equal to subsystem in windows PE header.

          When a library is loaded in your program by the dynamic loader default chooses dlopen that puts everything in default link map. Using a LD_AUDIT library you get to use if libraries get opened with dlopen or dlmopen.

          Solaris by sun has LD_AUDIT .so files used for application compatibly.

          Yes glibc mostly support this. So you attempt load libarchive.so.12 you have a LD_AUDIT library loaded it gets informed of that request and is able to change it to libarchive.so.13 or any other number required.

          Comment


          • Originally posted by oiaohm View Post
            Did not read Weasel
            LD_AUDIT libraries are loaded in to their unique link map by using dlmopen.
            Do you know what LD_AUDIT .so files do.

            These these load before you application in fact loads and takes control of the glibc/solaris dynamic loader.
            And what has this to do with loading 3rd party libs with the same symbol names for different functions?

            Originally posted by oiaohm View Post
            There is a off switch to ELF global symbol namespace. Happens to be there is one
            LD_AUDIT=thirdpary.so yourprogram

            Using the link header and a audit library you can bend the dynamic loader in glibc or solaris around your little finger.

            So with the right library in LD_AUDIT basically equal to subsystem in windows PE header.

            When a library is loaded in your program by the dynamic loader default chooses dlopen that puts everything in default link map. Using a LD_AUDIT library you get to use if libraries get opened with dlopen or dlmopen.

            Solaris by sun has LD_AUDIT .so files used for application compatibly.

            Yes glibc mostly support this. So you attempt load libarchive.so.12 you have a LD_AUDIT library loaded it gets informed of that request and is able to change it to libarchive.so.13 or any other number required.
            You know this proves that ELF is retarded right? That you need workarounds when calling your app.

            I don't want to use any environment variables, sandboxes, or other crap that can easily break. Those things only exist because ELF is retarded. This should be done automatically, forcefully, and safely, enforced by ELF's format, so that the loader has no choice.

            I mean, kind of the whole point of this was: ELF is retarded and Linux userland is retarded as a consequence; so much so that you need hacks like flatpak or other bullshit redirections/environment variables.

            Hacks are always needed due to poor design in the first place. Proper design = no hacks needed.

            Comment


            • Originally posted by Weasel View Post
              And what has this to do with loading 3rd party libs with the same symbol names for different functions?
              Simple you have loaded a audit library before you application you can load 3rd party libraries with conflicting symbols if the audit library direct those libraries to be dlmopen instead of dlopen conflicts can be hidden the same exact way Windows does in windows subsystem modes for your dll files. But also note windows is not that nice in nt native mode. Basically the first versions of libcapsule existed on solaris as LD_AUDIT libraries.

              [QUOTE=Weasel;n1053958You know this proves that ELF is retarded right? That you need workarounds when calling your app.[/QUOTE]
              Sun developers designed ELF. They also designed LD_AUDIT for application diagnostics and compatibility.

              Originally posted by Weasel View Post
              I don't want to use any environment variables, sandboxes, or other crap that can easily break. Those things only exist because ELF is retarded. This should be done automatically, forcefully, and safely, enforced by ELF's format, so that the loader has no choice.
              Safety is not forced by PE format either. PE loaded in NT native subsystem does not have to be safe either.

              The loader of PE and ELF define it safety and in some cases proxy loaders.

              Windows NT is just as retarded when you look under the hood

              Remember solaris is the source of ELF. The need to use environment variables is that a flag is not implemented by glibc to define LD_AUDIT from the elf file itself. Solaris version ELF has this. Its like the --audit flag not work as well. There are many parts of glibc ELF support that are not complete because there has not been the investment to complete them.

              Dlmopen you find is completely missing on bsd, musl and android platforms because not enough applications have been using that feature so have gone in their loaders with pure global only.

              So the reality here is the Sun documentation of the ELF format details quite a few more features you should have. Issues is implementation incompleteness.

              The idea that ELF is retarded is wrong. Saying glibc implementation of ELF is retarded in places is right. But its less retarded than the freebsd, android.... libc replacements.

              Really Weasel you are calling ELF retarded without having a clue what features ELF format says should exist and was designed to support. ELF format is in fact designed to allow loading libraries with conflicting requirements. This is why libcapsule developer has been shocked by how easy it is. ELF structures and operations are ready for it. Issue is have loader with all those feature implemented.

              Comment


              • Originally posted by oiaohm View Post
                Simple you have loaded a audit library before you application you can load 3rd party libraries with conflicting symbols if the audit library direct those libraries to be dlmopen instead of dlopen conflicts can be hidden the same exact way Windows does in windows subsystem modes for your dll files. But also note windows is not that nice in nt native mode. Basically the first versions of libcapsule existed on solaris as LD_AUDIT libraries.
                I don't want to hide them, I want to load both. And if you neede a lib for it (libcapsule) it only shows how broken ELF is.

                Originally posted by oiaohm View Post
                Safety is not forced by PE format either. PE loaded in NT native subsystem does not have to be safe either.
                You're mixing concepts. It's the same format, so yes it's "safe" and will NEVER have symbol clashes. Never. The subsystem is irrelevant.

                I'm guessing you found your new buzzword to throw around from the other thread, so here's the deal: the argument in the other thread was about kernel32 always being the same function (HeapAlloc). That's it.

                This has nothing to do with symbol clashes.

                Originally posted by oiaohm View Post
                The loader of PE and ELF define it safety and in some cases proxy loaders.

                Windows NT is just as retarded when you look under the hood

                Remember solaris is the source of ELF. The need to use environment variables is that a flag is not implemented by glibc to define LD_AUDIT from the elf file itself. Solaris version ELF has this. Its like the --audit flag not work as well. There are many parts of glibc ELF support that are not complete because there has not been the investment to complete them.

                Dlmopen you find is completely missing on bsd, musl and android platforms because not enough applications have been using that feature so have gone in their loaders with pure global only.

                So the reality here is the Sun documentation of the ELF format details quite a few more features you should have. Issues is implementation incompleteness.

                The idea that ELF is retarded is wrong. Saying glibc implementation of ELF is retarded in places is right. But its less retarded than the freebsd, android.... libc replacements.

                Really Weasel you are calling ELF retarded without having a clue what features ELF format says should exist and was designed to support. ELF format is in fact designed to allow loading libraries with conflicting requirements. This is why libcapsule developer has been shocked by how easy it is. ELF structures and operations are ready for it. Issue is have loader with all those feature implemented.
                You realize that needing an extra library means that it is retarded, right? ELF is not ready for it, not until it ditches the global symbol namespace forever.

                Comment


                • Originally posted by Weasel View Post
                  I don't want to hide them, I want to load both. And if you neede a lib for it (libcapsule) it only shows how broken ELF is.
                  Really you do need to hide them. Libcapsule is superior to the default windows solution once you understand why I said hide when loading both.

                  Originally posted by Weasel View Post
                  You're mixing concepts. It's the same format, so yes it's "safe" and will NEVER have symbol clashes. Never. The subsystem is irrelevant.
                  PE you can in fact have symbol clashes.
                  https://limbioliong.wordpress.com/20...the-same-name/

                  Using a link map as libcapsule does or using LD_AUDIT compatibility libraries do in fact allows you to have imports on the .so files be the same name but different versions and be loaded at the same time. This is because you have used hide as give out proper link maps.

                  Remember how you are anti dlopen. So this means you are anti LoadLibrary for working around limitations as well.

                  https://en.wikipedia.org/wiki/Rpath
                  DT_RPATH and DT_RUNPATH are also not part of the PE format. So you don't have the means to say this library will use libraries from X path different to applicatiohn.

                  You implement the solaris method of link maps when you are wanting to load both libraries in any conflicting case including library name and symbol name match. Yes dropping to NT native subsystem and taken control of the dynamic loader you can pull this off under windows NT as well but you cannot pull this off inside normal windows subsystems.

                  Originally posted by Weasel View Post
                  You realize that needing an extra library means that it is retarded, right? ELF is not ready for it, not until it ditches the global symbol namespace forever.
                  Windows dyamnic loader has its own set of retard problems due to the way it was chosen to work around this issue. Think all the application in debian build with global symbol namespace. So there is no need to ditch it.

                  Why does windows have a subsystem for command line applications and a subsystem for graphical applications and a subsystem called native for when you want full control of stuff this is also very retard. Those flag for graphical and cli can end up loading libraries into your application that your application never uses.

                  libcapsule does not show how broken ELF is. It shows how broken the default dynamic link loader is. Things that libcapsule can pull off also show the windows dynamic link loader as broken as well.. Nothing in the ELF specifications says that a loader could not be intelligent.

                  Weasel global symbol namespaces provides application diagnostic advantages. There is no point throwing the baby out with the bath water. Just because global symbol namespace has caused you some problems does not mean they are absolutely useless.

                  Really would you even care if the dynamic loader was a little smarter so that libraries loaded from your applications DT_RUNPATH are in your application link map and libraries used to resolve the host libraries called were in host libraries link map. This would not have the windows per .dll link map but would also cure most of the problems. This dynamic loader smarts could treat third party parts this way and keep on treating distribution provide as 1 global link map avoiding overhead.

                  ELF is in fact the more flexible format. We do have some issues where link map usage in dynamic loader for ELF have not be implemented fully.

                  Also libcapsule is something you can do on older distributions without requiring them to update their old glibc or dyanmic loader to versions containing new features. Fixing these problems sometimes require a short term work around.

                  Comment


                  • Originally posted by oiaohm View Post
                    Really you do need to hide them. Libcapsule is superior to the default windows solution once you understand why I said hide when loading both.
                    No you don't. Symbol "foobar" from "libfoobar" is completely separate from symbol "foobar" from library "libxyz". It is, literally, like having two different names. That's how sane DLLs are designed.

                    Originally posted by oiaohm View Post
                    PE you can in fact have symbol clashes.
                    https://limbioliong.wordpress.com/20...the-same-name/
                    This proves just how much you really don't understand even BASICS.

                    If you think a DLL's *name* is a *symbol* then there's really no hope for explaining anything to you.

                    Please document yourself on what an exported symbol is first before wasting people's time with irrelevant links.

                    And as usual, your link crushes all of your arguments and you think it's the contrary, see this exerpt:
                    you will notice that the first parameter is the HMODULE of the target DLL from which you want to search for a particular function name (the second parameter).

                    3.3 This implies that you can use 2 different HMODULEs to obtain 2 function address from 2 different DLLs using the same function name.

                    3.4 Extrapolating this, you can in fact use multiple HMODULEs to obtain multiple function addresses from multiple DLLs using the same function name.

                    3.5 Hence not only can you load multiple DLLs of the same name, you can also load multiple exported functions (of the same name) from each of these DLLs.
                    I'm not sure what else you want when even your links prove the opposite of your claims here. See point 3.5 (last line).

                    This is something that you CANNOT DO with ELF *unless* you resort to dlopen/dlsym, which is why it is garbage.

                    Originally posted by oiaohm View Post
                    Remember how you are anti dlopen. So this means you are anti LoadLibrary for working around limitations as well.
                    No, I'm anti-dlopen for the purpose of obtaining mandatory symbol dependencies.

                    LoadLibrary is used for resolving OPTIONAL symbols, or OPTIONAL libraries, such as PLUGINS. If LoadLibrary fails to load, your app should still run (albeit with missing features).

                    If you use dlopen/LoadLibrary for any other reason, it's proof how retarded ELF is.


                    Originally posted by oiaohm View Post
                    libcapsule does not show how broken ELF is. It shows how broken the default dynamic link loader is. Things that libcapsule can pull off also show the windows dynamic link loader as broken as well.. Nothing in the ELF specifications says that a loader could not be intelligent.
                    It doesn't matter how intelligent it is. The loader may be broken, but I don't care about it. ELF (the format) simply lacks the necessary INFORMATION by default (as most people build, i.e. without versioned symbols) so the loader won't know what to do with the symbols and which library they are from. They get resolved after libs are loaded already.

                    Originally posted by oiaohm View Post
                    Weasel global symbol namespaces provides application diagnostic advantages. There is no point throwing the baby out with the bath water. Just because global symbol namespace has caused you some problems does not mean they are absolutely useless.
                    No global symbol namespace is an artifact of a lack of design, and of "developer convenience" in the early days. It's an archaic monstrosity.

                    Because (the original) ELF is built around the assumption that you compile everything on the same machine environment. It's not for "distribution", it was made to be a simple "build" environment format, that's why it exposes so much of the underlying source code quirks. In short, it was designed by programmers to get a quick job done for development.

                    The most lazy form of development with no upfront design, like most of open source libraries, but just "code first, design never" mantra. Which is why you see them change their major version as often as their shitty developers probably change their socks.

                    This is obvious in the design, and that's why it's so retarded. It lacks proper distribution design. It's literally just a simple extension to static libraries (which are 100% for development).

                    ELF is "sane" from a design perspective only in a world of source-code distribution, like Gentoo or other such distro, where you build everything yourself. That's how pathetic it is.
                    Last edited by Weasel; 10-14-2018, 08:31 AM.

                    Comment


                    • Originally posted by Weasel View Post
                      No you don't. Symbol "foobar" from "libfoobar" is completely separate from symbol "foobar" from library "libxyz". It is, literally, like having two different names. That's how sane DLLs are designed.
                      That is not how fully implemented elf is designed.

                      DT_RPATH and DT_RUNPATH are also not part of the PE format. So you don't have the means to say this library will use libraries from X path different to application.
                      Lets ignore this bit right Weasel.

                      Symbol foobar from libfoobar in two different paths but load is in the original specification.


                      Originally posted by Weasel View Post
                      Because (the original) ELF is built around the assumption that you compile everything on the same machine environment. It's not for "distribution", it was made to be a simple "build" environment format, that's why it exposes so much of the underlying source code quirks. In short, it was designed by programmers to get a quick job done for development.
                      LD_AUDIT/link.h is part of the first operating system by Sun and AT&T with the ELF format. Yes it had the presume third part applications would start with "LD_AUDIT=/lib/libthirdpary.so application"

                      LD_AUDIT/link.h controlling the dynamic link loader was put outside the ELF specifications. Has not been helped that gnu debugger historically will not debug audit libraries.

                      So its not the original ELF that has the problem. Yes the original has dlmopen as well.

                      Also the interpretation of symbolic mode in the ELF standard has altered from the first version.

                      Originally posted by Weasel View Post
                      It doesn't matter how intelligent it is. The loader may be broken, but I don't care about it. ELF (the format) simply lacks the necessary INFORMATION by default (as most people build, i.e. without versioned symbols) so the loader won't know what to do with the symbols and which library they are from. They get resolved after libs are loaded already.
                      This is not true. ELF format has something really useful STT_FILE symbol only used on Solaris.
                      http://refspecs.linuxbase.org/elf/ga...h4.symtab.html

                      STT_FILE exists in the symbol table to be able to specify what .so the following functions are from.

                      So its not that the elf format lacks the means to store the necessary information but that current day linkers of elf opt out on providing it and current day dynamic
                      link loaders are not process it.

                      So in a full blown old school sun/at&t unix. You could have program a loading "foobar" from "libfoobar" from RUNPATH=/lib/one then application loads library xzy also using "foobar" from "libfoobar" from RUNPATH=/libtwo no dlopen/dlsym this would be just normal elf dynamic linker resolve. So yes you could load a library name and symbol name pairs more than once referencing different libraries . This is just having a good ELF dynamic loader that proper supports the STT_FILE symbol. Yes if you have not worked out STT_FILE was triggering private link map.

                      What most people build is a ELF binary that is in fact not 100 percent to specification being run by a dynamic loader not 100 percent to specification.

                      GNU comes along and implements there libc clone of unix stuff they do ELF but doing link maps is hard stuff it lets not have dlmopen working as Solaris has and lets skip out on STT_FILE and let skip out on the RUNPATH effects as well.

                      Basically the elf format specification hides system many time superior to the PE one. Problem is lack of implementation.

                      Of course we now have to design a solution that will work on top of the broken stack with incorrectly made elf files and incorrectly made elf dynamic loader. libcapsule will.

                      Really the symbol table of a elf is not meant to be without entries saying what .so file the symbol should come from. ELF and PE is not that different once you look at specifications. PE is the weaker format on paper. ELF has big implementation problems.



                      Comment

                      Working...
                      X