Announcement

Collapse
No announcement yet.

GNU C Library 2.36 Released With New Functions, More Optimizations

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

  • #41
    Originally posted by NobodyXu View Post
    With musl libc, I can create a statically linked executable that works on anywhere.
    by bundling shared libraries and dynamic linker i can create dynamically linked executable that works on anywhere(with recent enough kernel, but static linking shares same limitation)

    Comment


    • #42
      Originally posted by sinepgib View Post
      Yes, backwards compatibility on glibc is a mess
      you are replying to example showing lack of forward compatibility. backward compatibility works in other direction(if you build on old system, it will run on new one)
      Last edited by pal666; 03 August 2022, 10:11 PM.

      Comment


      • #43
        Originally posted by coder View Post
        We have good solutions to number 1
        package management doesn't provide solution for customers with distros older than your build system. you have to restort to bundling or use devtoolset(which isn't universally available and lags a bit). the ultimate bundling/packaging solution is flatpak

        Comment


        • #44
          Originally posted by F.Ultra View Post
          Code:
          __asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
          But atleast it's doable.
          unless you or your dependencies reference symbol missing from old version

          Comment


          • #45
            Originally posted by coder View Post
            Easier solution is just to build against an older version
            with older compiler and older language standard

            Comment


            • #46
              Originally posted by pal666 View Post
              by bundling shared libraries and dynamic linker i can create dynamically linked executable that works on anywhere
              Isn't that essentially appimage except you also bundle the libc?
              That will make it more universal, but then you also have to bundle other libraries as well.

              Or flatpak/snap where u bundle dynlibs + data.

              Originally posted by pal666 View Post
              (with recent enough kernel, but static linking shares same limitation)
              Musl libc supports any kernel newer than and including 2.6.39
              It would even work on 2.4 for simple singlethread program.



              Not sure about the min kernel requirement for bundling dynlib.
              If ur glibc support old kernel, then it should work fine.

              But still, depending on how u bundle it, it will have stricter requirements.

              For example, appimage requires fuse support, flatpak/snap requires namespace support (4.9 or sth like that).

              Though if the user is willing to manually untar, then it would only depend on ur linc bundled in it.
              Last edited by NobodyXu; 03 August 2022, 10:38 PM.

              Comment


              • #47
                Originally posted by pal666 View Post
                you are replying to example showing lack of forward compatibility. backward compatibility works in other direction(if you build on old system, it will run on new one)
                Yes, I mixed up the terms, sorry.

                Comment


                • #48
                  loads of y2038 changes in this release too. much more than i've seen listed in any of the last half dozen releases.

                  Comment

                  Working...
                  X