what are the executable ELF files respectively for static linker, dynamic linker, loader and dynamic loader?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












In Linux, what are the executable ELF files respectively for



  • static linker

  • dynamic linker

  • loader

  • dynamic loader?

Which of them are invoked



  • by execve()

  • by dlopen()?

How are them invoked by execve() or dlopen(), to solve the chicken-egg problem that execve() or dlopen() are used for invoking executable files?



Thanks.










share|improve this question



























    up vote
    0
    down vote

    favorite












    In Linux, what are the executable ELF files respectively for



    • static linker

    • dynamic linker

    • loader

    • dynamic loader?

    Which of them are invoked



    • by execve()

    • by dlopen()?

    How are them invoked by execve() or dlopen(), to solve the chicken-egg problem that execve() or dlopen() are used for invoking executable files?



    Thanks.










    share|improve this question

























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      In Linux, what are the executable ELF files respectively for



      • static linker

      • dynamic linker

      • loader

      • dynamic loader?

      Which of them are invoked



      • by execve()

      • by dlopen()?

      How are them invoked by execve() or dlopen(), to solve the chicken-egg problem that execve() or dlopen() are used for invoking executable files?



      Thanks.










      share|improve this question















      In Linux, what are the executable ELF files respectively for



      • static linker

      • dynamic linker

      • loader

      • dynamic loader?

      Which of them are invoked



      • by execve()

      • by dlopen()?

      How are them invoked by execve() or dlopen(), to solve the chicken-egg problem that execve() or dlopen() are used for invoking executable files?



      Thanks.







      linux dynamic-linking load linker dynamic-loading






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 7 mins ago









      Stephen Kitt

      151k23337405




      151k23337405










      asked 28 mins ago









      Tim

      24.2k67233424




      24.2k67233424




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          1
          down vote













          I take it you’re using Jeff Darcy’s definitions:



          • static linking involves resolving symbols at compile time, whereas dynamic linking involves resolving them at run time;

          • static loading involves mapping executables and libraries at load time, whereas dynamic loading involves mapping libraries after the process has started.

          It doesn’t really make sense to try to split everything up; instead, you should consider the pairs of features:



          • static loading, static linking: the linker is /usr/bin/ld typically, along with static libraries (.a); the loader is the kernel;

          • static loading, dynamic linking: the linker is /usr/bin/ld again, but with shared libraries (.so); the loader is the binary’s interpreter, e.g. /lib64/ld-linux-x86-64.so.2 (which maps to /lib/x86_64-linux-gnu/ld-2.24.so currently) on Debian 9 on 64-bit x86, itself loaded by the kernel, which also loads the main executable;

          • dynamic loading, static linking: this isn’t used on Linux as far as I’m aware;

          • dynamic loading, dynamic linking: the loader is a library such as libdl; the linker is split between the library and the program calling libdl.

          Perhaps some more explanation is called for in relation to the last point. When a program uses libdl to load a library, it calls dlopen, which loads the named library, along with any of its dependencies which aren’t already available in the process, and links the named library with its dependencies. Thus libdl performs both loading (of the necessary libraries) and linking (of the libraries only, not the calling program). When the calling program needs to use a symbol from the named library, it calls dlsym which returns the address of the requested symbol (if it can find it). Thus the calling program performs part of the linking.



          There is no chicken-and-egg problem with regards to execve or dlopen. Programs compiled to use execve are compiled with the appropriate references to libc (which contains the wrapper most programs actually use) and the execve symbol (strictly speaking, the aforementioned wrapper). Those references are resolved either at compile-time (for statically-linked programs) or at load-time (for dynamically-linked programs); after that, the symbol is available for use and the program can call execve. The same goes for dlopen: programs which want to use dlopen are compiled with the appropriate references to libdl and dlopen. The dynamic linker itself is a static binary, so the kernel can load it without the help of the dynamic linker. You’ll find lots more detail on this topic in How programs get run and How programs get run: ELF binaries.



          (Note that in all cases of dynamic linking, if lazy binding is enabled, linking can happen just-in-time, and not necessarily at load time.)





          share






















            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "106"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f476780%2fwhat-are-the-executable-elf-files-respectively-for-static-linker-dynamic-linker%23new-answer', 'question_page');

            );

            Post as a guest






























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            1
            down vote













            I take it you’re using Jeff Darcy’s definitions:



            • static linking involves resolving symbols at compile time, whereas dynamic linking involves resolving them at run time;

            • static loading involves mapping executables and libraries at load time, whereas dynamic loading involves mapping libraries after the process has started.

            It doesn’t really make sense to try to split everything up; instead, you should consider the pairs of features:



            • static loading, static linking: the linker is /usr/bin/ld typically, along with static libraries (.a); the loader is the kernel;

            • static loading, dynamic linking: the linker is /usr/bin/ld again, but with shared libraries (.so); the loader is the binary’s interpreter, e.g. /lib64/ld-linux-x86-64.so.2 (which maps to /lib/x86_64-linux-gnu/ld-2.24.so currently) on Debian 9 on 64-bit x86, itself loaded by the kernel, which also loads the main executable;

            • dynamic loading, static linking: this isn’t used on Linux as far as I’m aware;

            • dynamic loading, dynamic linking: the loader is a library such as libdl; the linker is split between the library and the program calling libdl.

            Perhaps some more explanation is called for in relation to the last point. When a program uses libdl to load a library, it calls dlopen, which loads the named library, along with any of its dependencies which aren’t already available in the process, and links the named library with its dependencies. Thus libdl performs both loading (of the necessary libraries) and linking (of the libraries only, not the calling program). When the calling program needs to use a symbol from the named library, it calls dlsym which returns the address of the requested symbol (if it can find it). Thus the calling program performs part of the linking.



            There is no chicken-and-egg problem with regards to execve or dlopen. Programs compiled to use execve are compiled with the appropriate references to libc (which contains the wrapper most programs actually use) and the execve symbol (strictly speaking, the aforementioned wrapper). Those references are resolved either at compile-time (for statically-linked programs) or at load-time (for dynamically-linked programs); after that, the symbol is available for use and the program can call execve. The same goes for dlopen: programs which want to use dlopen are compiled with the appropriate references to libdl and dlopen. The dynamic linker itself is a static binary, so the kernel can load it without the help of the dynamic linker. You’ll find lots more detail on this topic in How programs get run and How programs get run: ELF binaries.



            (Note that in all cases of dynamic linking, if lazy binding is enabled, linking can happen just-in-time, and not necessarily at load time.)





            share


























              up vote
              1
              down vote













              I take it you’re using Jeff Darcy’s definitions:



              • static linking involves resolving symbols at compile time, whereas dynamic linking involves resolving them at run time;

              • static loading involves mapping executables and libraries at load time, whereas dynamic loading involves mapping libraries after the process has started.

              It doesn’t really make sense to try to split everything up; instead, you should consider the pairs of features:



              • static loading, static linking: the linker is /usr/bin/ld typically, along with static libraries (.a); the loader is the kernel;

              • static loading, dynamic linking: the linker is /usr/bin/ld again, but with shared libraries (.so); the loader is the binary’s interpreter, e.g. /lib64/ld-linux-x86-64.so.2 (which maps to /lib/x86_64-linux-gnu/ld-2.24.so currently) on Debian 9 on 64-bit x86, itself loaded by the kernel, which also loads the main executable;

              • dynamic loading, static linking: this isn’t used on Linux as far as I’m aware;

              • dynamic loading, dynamic linking: the loader is a library such as libdl; the linker is split between the library and the program calling libdl.

              Perhaps some more explanation is called for in relation to the last point. When a program uses libdl to load a library, it calls dlopen, which loads the named library, along with any of its dependencies which aren’t already available in the process, and links the named library with its dependencies. Thus libdl performs both loading (of the necessary libraries) and linking (of the libraries only, not the calling program). When the calling program needs to use a symbol from the named library, it calls dlsym which returns the address of the requested symbol (if it can find it). Thus the calling program performs part of the linking.



              There is no chicken-and-egg problem with regards to execve or dlopen. Programs compiled to use execve are compiled with the appropriate references to libc (which contains the wrapper most programs actually use) and the execve symbol (strictly speaking, the aforementioned wrapper). Those references are resolved either at compile-time (for statically-linked programs) or at load-time (for dynamically-linked programs); after that, the symbol is available for use and the program can call execve. The same goes for dlopen: programs which want to use dlopen are compiled with the appropriate references to libdl and dlopen. The dynamic linker itself is a static binary, so the kernel can load it without the help of the dynamic linker. You’ll find lots more detail on this topic in How programs get run and How programs get run: ELF binaries.



              (Note that in all cases of dynamic linking, if lazy binding is enabled, linking can happen just-in-time, and not necessarily at load time.)





              share
























                up vote
                1
                down vote










                up vote
                1
                down vote









                I take it you’re using Jeff Darcy’s definitions:



                • static linking involves resolving symbols at compile time, whereas dynamic linking involves resolving them at run time;

                • static loading involves mapping executables and libraries at load time, whereas dynamic loading involves mapping libraries after the process has started.

                It doesn’t really make sense to try to split everything up; instead, you should consider the pairs of features:



                • static loading, static linking: the linker is /usr/bin/ld typically, along with static libraries (.a); the loader is the kernel;

                • static loading, dynamic linking: the linker is /usr/bin/ld again, but with shared libraries (.so); the loader is the binary’s interpreter, e.g. /lib64/ld-linux-x86-64.so.2 (which maps to /lib/x86_64-linux-gnu/ld-2.24.so currently) on Debian 9 on 64-bit x86, itself loaded by the kernel, which also loads the main executable;

                • dynamic loading, static linking: this isn’t used on Linux as far as I’m aware;

                • dynamic loading, dynamic linking: the loader is a library such as libdl; the linker is split between the library and the program calling libdl.

                Perhaps some more explanation is called for in relation to the last point. When a program uses libdl to load a library, it calls dlopen, which loads the named library, along with any of its dependencies which aren’t already available in the process, and links the named library with its dependencies. Thus libdl performs both loading (of the necessary libraries) and linking (of the libraries only, not the calling program). When the calling program needs to use a symbol from the named library, it calls dlsym which returns the address of the requested symbol (if it can find it). Thus the calling program performs part of the linking.



                There is no chicken-and-egg problem with regards to execve or dlopen. Programs compiled to use execve are compiled with the appropriate references to libc (which contains the wrapper most programs actually use) and the execve symbol (strictly speaking, the aforementioned wrapper). Those references are resolved either at compile-time (for statically-linked programs) or at load-time (for dynamically-linked programs); after that, the symbol is available for use and the program can call execve. The same goes for dlopen: programs which want to use dlopen are compiled with the appropriate references to libdl and dlopen. The dynamic linker itself is a static binary, so the kernel can load it without the help of the dynamic linker. You’ll find lots more detail on this topic in How programs get run and How programs get run: ELF binaries.



                (Note that in all cases of dynamic linking, if lazy binding is enabled, linking can happen just-in-time, and not necessarily at load time.)





                share














                I take it you’re using Jeff Darcy’s definitions:



                • static linking involves resolving symbols at compile time, whereas dynamic linking involves resolving them at run time;

                • static loading involves mapping executables and libraries at load time, whereas dynamic loading involves mapping libraries after the process has started.

                It doesn’t really make sense to try to split everything up; instead, you should consider the pairs of features:



                • static loading, static linking: the linker is /usr/bin/ld typically, along with static libraries (.a); the loader is the kernel;

                • static loading, dynamic linking: the linker is /usr/bin/ld again, but with shared libraries (.so); the loader is the binary’s interpreter, e.g. /lib64/ld-linux-x86-64.so.2 (which maps to /lib/x86_64-linux-gnu/ld-2.24.so currently) on Debian 9 on 64-bit x86, itself loaded by the kernel, which also loads the main executable;

                • dynamic loading, static linking: this isn’t used on Linux as far as I’m aware;

                • dynamic loading, dynamic linking: the loader is a library such as libdl; the linker is split between the library and the program calling libdl.

                Perhaps some more explanation is called for in relation to the last point. When a program uses libdl to load a library, it calls dlopen, which loads the named library, along with any of its dependencies which aren’t already available in the process, and links the named library with its dependencies. Thus libdl performs both loading (of the necessary libraries) and linking (of the libraries only, not the calling program). When the calling program needs to use a symbol from the named library, it calls dlsym which returns the address of the requested symbol (if it can find it). Thus the calling program performs part of the linking.



                There is no chicken-and-egg problem with regards to execve or dlopen. Programs compiled to use execve are compiled with the appropriate references to libc (which contains the wrapper most programs actually use) and the execve symbol (strictly speaking, the aforementioned wrapper). Those references are resolved either at compile-time (for statically-linked programs) or at load-time (for dynamically-linked programs); after that, the symbol is available for use and the program can call execve. The same goes for dlopen: programs which want to use dlopen are compiled with the appropriate references to libdl and dlopen. The dynamic linker itself is a static binary, so the kernel can load it without the help of the dynamic linker. You’ll find lots more detail on this topic in How programs get run and How programs get run: ELF binaries.



                (Note that in all cases of dynamic linking, if lazy binding is enabled, linking can happen just-in-time, and not necessarily at load time.)






                share













                share


                share








                edited 2 mins ago

























                answered 8 mins ago









                Stephen Kitt

                151k23337405




                151k23337405



























                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f476780%2fwhat-are-the-executable-elf-files-respectively-for-static-linker-dynamic-linker%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    How to check contact read email or not when send email to Individual?

                    Displaying single band from multi-band raster using QGIS

                    How many registers does an x86_64 CPU actually have?