Why can't Rust figure out dynamic linking? Serious replies only, no sexual fetish posters who don't program.


Warning: Attempt to read property "comment_date" on null in /var/www/wptbox/wp-includes/comment-template.php on line 1043

Warning: Attempt to read property "comment_date" on null in /var/www/wptbox/wp-includes/comment-template.php on line 1043

Warning: Attempt to read property "comment_date" on null in /var/www/wptbox/wp-includes/comment-template.php on line 1043

Why can't Rust figure out dynamic linking? Serious replies only, no sexual fetish posters who don't program.

  1. 2 months ago
    Anonymous

    because gender is not dynamic

  2. 2 months ago
    Anonymous

    Maintainers expire too quickly.

    • 2 months ago
      Anonymous

      because gender is not dynamic

      Good news, everyone! I've invented a completely memory safe programming language. Everyone, please meet the maintainer, *miss* Emi- *ack!*

      *sighs*

      oh well back to work

  3. 2 months ago
    Anonymous

    Dynamic linking has nothing to do with the Rust Programming Language.

    Linking happens after the Rust compiler has done its job anyway.

    Rust just prefers static linking massively, since it significantly reduces the dependency headache about having the correct version of a bunch of shared libraries installed.

    It also helps with the fact that Rust programs make heavy use of polymorphism (generics), which can be monomorphised at compile time when statically linked against the generic functions in your library.
    When Rust is made to dynamically link such a library, it cannot compile the library to monomorphic code, and the DLL/SharedObject has to contain the actual implementation/AST (abstract syntax tree) for the entire function serialised within the object file.

    • 2 months ago
      Anonymous

      You could have distilled this down to "generics"
      C++ has the same problem

      • 2 months ago
        Anonymous

        C++ can be dynamically linked tho even when you use templates.

        • 2 months ago
          Anonymous

          With extra special linker magic, yes
          Linkers are sorcery and there's no reason to make them more complicated but Bjarne finds a way

        • 2 months ago
          Anonymous

          Rust does not have a problem with dynamic linking. If you want to create a dynamic link library with Rust, you can instruct rustc to create a dylib or cdylib crate. If you want to link against a dynamic link library, you should use the link-arg flag in rustc or your Cargo.toml file.

          So why does Rust prefer static linking by default? Because Rust's .rlib format stores information that cannot be stored in standard .dll or .so formats. This includes things like type information, or generic functions, but also may store the AST for functions that are intended to be always inlined.

          C++ can be dynamically linked in the same way that Rust can. But that doesn't mean you can dynamically link templates. There's a reason why C++ templates tend to be put in header files. And yes, there is a such thing as precompiled headers, but those aren't dynamically linked.

        • 2 months ago
          Anonymous

          isnt it just that you have to explicitly declare template instantiations to export

          • 2 months ago
            Anonymous

            Pretty sure you just use precompiled headers... which are doing more or less what .rlib is doing for Rust.

    • 2 months ago
      Anonymous

      I have no clue.
      My DLL call test in C looks like that:
      #include <stdio.h>

      void main(void)
      {
      Hello();
      system("PAUSE");
      }

      and the command to compile:
      C:MinGWbingcc -c main.c
      C:MinGWbingcc main.o -o out.exe -L./ -lDll_out

      The code for the DLL itself is:
      #include <stdio.h>

      int Hello(void)
      {
      printf("Hello world !n");
      return 0;
      }

      And compile:
      C:MinGWbingcc -c Dll_main.c
      C:MinGWbingcc -shared Dll_main.o -o Dll_out.dll

      No .h or anything, the C just "finds" the entry point.
      Why couldn't Rust do the same?
      Am I missing something?

      The Rust ABI isn't stable yet, as the language is still changing, so there are no guarantees that a dll/so/dylib compiled in some version of Rust will work in a program compiled with a different version. If you know that a library is guaranteed to be compiled with a compatible version, then you could do this.

      The solution right now is to use the C ABI, which is practically guaranteed to never change.
      It's more constraining, because it lacks a lot of Rust features, but it works.

      To dynamically load a library in Rust, there are crates designed for this purpose.
      libloading seems to be the most popular option (I've looked into this in the past but decided it was better to just use a different design for now, like static linking or IPC).

      t. Rust has been my main language for 4 years

      Thank you for the nice answers.

      • 2 months ago
        Anonymous

        >uncaught return value
        uuuuuuuuuuh

        • 2 months ago
          Anonymous

          >system("PAUSE");
          Please never use this in any program, ever again.

          I wrote that code 7 years ago.
          But you are both right, whatever the age of the code, I am sharing it and should have cleaned it up before.
          I now don't use system() and correctly document and use return values, fortunately.

          That being said, am I missing something?
          How the hey the C program knows where is the "Hello()" function in the DLL, and that the argument types are correct?
          Bonus question, why Linux and Windows (and probably mac too) don't use the same kind of dynamic libraries?
          Is it possible to force the use of one in an other system?

          • 2 months ago
            Anonymous

            >How the hey the C program knows where is the "Hello()" function in the DLL, and that the argument types are correct?
            Well, the DLL has a symbol table, so your linker can look for the symbol "Hello". As for why it assumes the types are correct... I think that question is addressed in

            you're taking advantage of implicit declarations here. If C sees a function call you haven't declared, it just silently assumes it returns "int". If the function Hello returned a double instead, you would be fucked. You need the .h file (or just copy/paste the declaration into main.c) to do it safely.

            . In most use cases, you should generally forward declare all functions, whether they're in a DLL or not.
            >Bonus question, why Linux and Windows (and probably mac too) don't use the same kind of dynamic libraries?
            The file format for shared libraries tends to be the same file format used for executables. Windows, Linux, and MacOS all settled on different containers (PE, ELF, and Mach-O respectively), and there wasn't much reason to build in loaders for the other formats.
            >Is it possible to force the use of one in an other system?
            Kind of. This is more or less what WINE does. Take an .exe and all .dlls it's supposed to link against, copy them into executable memory, and forget. The thing that becomes tricky isn't really loading the executable, as much as it is pretending to be the other OS. This task is actually easier for running Windows programs on Linux and MacOS than the other way around. Windows' syscall interface is unstable, so the standard way to make a system call is to invoke some function inside of kernel32.dll or some similar system DLL. That DLL will then invoke the syscall instruction with the correct parameters. Wine simply provides its own implementation of kernel32.dll and several other DLLs, and uses it to talk to Linux. Making things even easier for Linux is the fact that implementing CreateProcess with fork and exec is trivial, while the reverse is not so easy. Using these types of techniques, you can theoretically run any user mode program from one OS to another... unless of course that user program needs to install a driver. Then you're fucked.

      • 2 months ago
        Anonymous

        >system("PAUSE");
        Please never use this in any program, ever again.

      • 2 months ago
        Anonymous

        you're taking advantage of implicit declarations here. If C sees a function call you haven't declared, it just silently assumes it returns "int". If the function Hello returned a double instead, you would be fucked. You need the .h file (or just copy/paste the declaration into main.c) to do it safely.

      • 2 months ago
        Anonymous

        >system("PAUSE");

  4. 2 months ago
    Anonymous

    >dynamic linking
    >poorfag got filtered by disk space

    • 2 months ago
      Anonymous

      >turns on deduplication

  5. 2 months ago
    Anonymous

    The Rust ABI isn't stable yet, as the language is still changing, so there are no guarantees that a dll/so/dylib compiled in some version of Rust will work in a program compiled with a different version. If you know that a library is guaranteed to be compiled with a compatible version, then you could do this.

    The solution right now is to use the C ABI, which is practically guaranteed to never change.
    It's more constraining, because it lacks a lot of Rust features, but it works.

    To dynamically load a library in Rust, there are crates designed for this purpose.
    libloading seems to be the most popular option (I've looked into this in the past but decided it was better to just use a different design for now, like static linking or IPC).

    t. Rust has been my main language for 4 years

  6. 2 months ago
    Anonymous

    It nullifies the point of using the language since dynamic linking is unsafe. Also it's garbage for lots of other reasons and no one should ever do it. A proper operating system wouldn't have such a terrible anti feature.

  7. 2 months ago
    Anonymous

    >no header files
    >generics
    >unstable abi
    there is also a trend to ditch dynamic linking in favor of static linking because of ~~*user's convenience*~~

    • 2 months ago
      Anonymous

      >because of ~~*user's convenience*~~
      It is convenient for users though. They don't need to worry about installing dependencies. You just get one executable that contains everything it needs.

      • 2 months ago
        Anonymous

        installing dependencies undoubtedly cause a fuckload of headaches and waste millions of humanities hours, but saving space is a kind of convenience too.

      • 2 months ago
        Anonymous

        Isn't this completely insecure? If your dependency is vulnerable to malware, but your rust program doesn't get updates anymore or doesn't get them fast enough to matter, how can you force the program to use your up-to-date and secure system-wide shared dependency rather than the one that comes with your program?

        • 2 months ago
          Anonymous

          It's not insecure, it's just more of a pain to update. Essentially, the developer of the program will need to recompile with an updated library, and ship out a patch to all users. And every developer using that library will need to do the same thing.

          On one side, the user will need to download a lot of patches. On the other side, it is possible that some programs will not need to be patched at all, because they are not using an affected version of the library. Suppose versions 2.5 and 2.6 are affected, but not 2.4 and 2.7. If you were using a shared system wide library, you would have all versions of the program using 2.6, and need to update to 2.7. If, however, one version were compiled with 2.4, it would not need to be recompiled at all.

  8. 2 months ago
    Anonymous

    Because Unix trannies were unable to do it so they complained about it nonstop until some people thought it was bad, kind of like those same people are doing about Rust.

  9. 2 months ago
    Anonymous

    It can, but like C++, you have to go through a C ABI because the C++ and Rust ABIs are not stable. Additionally, Rust and C++ make heavy use of monomorphization through generics and templates, which require duplicating source code, and arent possible to dynamically link.

  10. 2 months ago
    Anonymous

    because it's not really theirs to figure out
    shared library formats are shit, resolving them is shit, patching them is shit, because every platform took the worst aspects of the other
    modules should be self describing, modules should have metadata, modules should be able to represent complex object models without resorting to flattening them to a c style functions
    COM, then .NET, and the Windows Runtime all tried to take steps to fix it
    COM with registered self describing components, standardized behaviors and expectations, and assembly manifests like five or fix different thread and/or process local calling contexts that can hook, detour, and sandbox shit
    .NET by finally introducing a unified binary interface bridging code and data instead of just lmao x86 and metadata format through which applications can communicate

    WinRT takes all that, and brings it back to the realm of the native, adds metadata, but uses a gimped runtime based on xbox and comes with so much baggage no one uses it
    but unnoticed UWP essentially completely does away with all the problems of .dll hell through finally adding package management, and not just any package management
    package management that can target some of causes of the problem because it's onecone not win32 - like the simplicity of import tables
    UWP applicatons package management capabilities let you do shit letting you suspend your main process (which never actually exits) and use your dedicated dependency management process completely rewrite your whole dependency tree programmatically at runtime enabling things like seamless addition of optional features

    now the WindowsAppSDK opens that up to some degree to useful programs going both ways
    and while i would hardly say it's my ideal solution, it's limited by the fact that it pretends to respect the old way, it is the first one that's comprehensive and actually acknowledges that code needs to be treated as data

  11. 2 months ago
    Anonymous

    statically linked programs are faster

Your email address will not be published. Required fields are marked *