1. 27

    1. 4

      This post gives more context.

      I hope the author can sell enough to fund the development effort.

      1. 2

        Does the AGPL prevent corporations from using mold as a normal command line program without sharing their own source code? I don’t think it does and if not I don’t understand what the motivation would be to purchase a license for the majority of companies. As long as the code of mold itself is not linked with their own product (the most likely use case), they are under no obligation to do anything.

        I think Rui has a few practical options here:

        1. Sell “support contracts” This would allow companies to make special requests of Rui and to add special features.
        2. Sell “special features” Keep advanced features that are likely to be needed by customers out of the open source version and only license their usages to customers.
        3. Relicense all of mold under a more restrictive license. I.e. only for hobbiest/non-commercial usage (not GPL) and sell licenses for commercial use.

        Personally I would go with 2). This is the route that sqlite went. Keep mold core light and sufficient for hobbiest application development and keep a treasure trove of advanced extensions for customer who want to pay. For instance, only support x86-64-{linux,mac,windows} and maybe ARM64 in the open source version (desktop platforms) yet make embedded platform support paid (ARM32, RISCV32, hex output etc.).

        My $0.02 I wish Rui all the best.

        1. 2

          Cppcheck is another software development tool that went to #2 last year with the launch of Cppcheck Premium.

        2. 2

          I am curious about the use cases of these linkers.

          Given that the big issue seems to be GNU gold, I’d think if linking speed becomes a problem the logical step would be using LLVM’s lld. That’s a huge improvement, while mold, etc. seem to only bring a comparatively small improvement - still more than double the speed of LLVM lld, but not the 5-15 times improvement of the jump from GNU to LLVM, depending on the project.

          LLVM lld is using a modified (more permissive) Apache 2.0 License (currently dual licensed with UIUC which is effectively BSD/MIT license).

          I mostly ask, because in huge code bases (Chrome, Clang, Firefox) according to the mold benchmark this is only about 3-10 seconds that are being saved in comparison.

          1. 2

            As a command-line linker, I don’t see any value in mold, but the design is interesting because of the things that it may enable in other situations. A typical linker waits for all object files to be ready and then processes them. That’s not a problem when there’s a low-latency intermediate store (local disk with a big RAM cache). I can imagine mold much better in a cloud-build model, where all of the compile steps run in parallel and stream their output to the linker as soon as it’s ready. FaaS offerings charge per megabyte-second of RAM, so being able stream required things in the output directly to a blob and discard anything that isn’t needed early on would be quite useful at scale.

            1. 1

              Apple ld64 has adopted parallel input scanning as well (https://www.wwdcnotes.com/notes/wwdc22/110362/ -all_load makes archives scanning parallel). But I am unsure that it leverages parallelism as well as mold, e.g. parallel symbol resolution may not be done.

              (I made another comment upthread which you may be interested in as well.)

            2. 1

              still more than double the speed of LLVM lld, but not the 5-15 times improvement of the jump from GNU to LLVM, depending on the project.

              I think “more than double” is very rare considering all types of build types and all kinds of software.

              lld has improved as well (e.g. https://maskray.me/blog/2022-09-05-lld-15-elf-changes) (be aware to use a fast malloc implementation with lld, e.g. -DCMAKE_EXE_LINKER_FLAGS=path/to/Dev/mimalloc/out/release/libmimalloc.a). 1.5x speed is probably still common with no-debug-info builds or –threads={16,32,…}. The gap is lower with a debug-info build or when the number of threads is smaller (below 16).

              Tip: for a “edit,compile,link,test” cycle, just use -Wl,-O0. It makes ld.lld significantly faster. See https://maskray.me/blog/2021-12-19-why-isnt-ld.lld-faster#shf_merge-duplicate-elimination

              I am interested if someone can help me identify issues with (a) parallel SmallVector::reserve in relocation scanning (https://lobste.rs/s/lak4ny/lld_15_elf_changes) (b) splitSections/MergeNoTailSection::finalizeContents (unfortunately llvm-project does not provide a concurrent hash map, so we are using a poor man’s parallelism trick).

              % cat /usr/local/bin/ld
              LD_PRELOAD=$HOME/Dev/mimalloc/out/release/libmimalloc.so ~/Stable/bin/ld.lld -O0 --threads=8 "$@"
            3. 1

              Very cool. I’d love to try and get this in at work.

              Note to @ruiu there’s a typo on https://bluewhale.systems/


              1. 3

                Ah, thanks. Fixed.

                1. 1

                  I’m curious what process you went through on the re licensing. The git history shows other contributors and I don’t see a CLA. Was it difficult to get their permission to allow you to change the license? Will you add a CLA to mold to simplify this going forward?

                  1. 1

                    All patches are requested to be released under MIT/AGPL before being merged. https://github.com/rui314/mold/blob/main/CONTRIBUTING.md

                    1. 1

                      Thanks. The dual licensing but must have involved some fun conversations with your lawyer (I’ve had two lawyers tell me exact opposite interpretations of that kind of clause). I hope it works well for you.