<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/81787>81787</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Request to build llvm-symbolizer in the official clang releases against zlib
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            clang
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          mknyszek
      </td>
    </tr>
</table>

<pre>
    Currently, the releases at https://releases.llvm.org/ for linux-amd64 (Ubuntu) aren't built against zlib.

In the Go project's build infrastructure, we want to build against clang. We currently avoid baking clang into our CI Linux images via https://apt.llvm.org packages, because managing more images increases our maintenance overhead, and makes it harder for us to test against multiple versions of clang. Instead, we take the official LLVM releases and download them onto our CI jobs on-demand.

Unfortunately, these releases don't build against zlib, so I've temporarily modified some of our ASAN tests against clang (specifically disabled just the parts that check for correct symbolization) because llvm-symbolizer fails to decompress a Go binary's DWARF info. (https://github.com/golang/go/issues/65606)

This is basically a formal request made out of the discourse thread here, https://discourse.llvm.org/t/clang-14-warning-cannot-compress-debug-sections-zlib-not-installed-wdebug-compression-unavailable-while-using-address-sanitizer/62506/2, where it seemed like it might be reasonable from the LLVM project's perspective to require a zlib installation to use the official clang releases.

I'm hoping that the LLVM project is willing to modify its release processes to include building llvm-symbolizer against zlib. Of course, if the resolution is that that isn't possible, or is sufficiently undesirable, we'll have to figure something else out. But so far this approach has worked nicely for us, with this being the only issue we ran into.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJx8VU9z27gO_zTyBSOPw8hxfPAhbcdvMtP33kx3uz1DImyhpkgtQdrrfvodULYT59BLYo1A6IffHxBFeO-JNtXyU7X8MsOc-hA3w8Gf5RcdZm2w583nHCP55M6V-QypJ4jkCIUEMEGf0ijV40tltpXZXt_MnTsO8xD3ldnCLkRw7PM_NQ72qYHKPH9vs0-5MmvASL4yqwRtZpcA98heEvxy3M6rxZdq8TL9ffXl0_8JMMbwk7pUmZWUQxbY7yJKirlLOZKiPBGc0CdI4VJy7ds59Ps5_CDorlMBHgNbaPHAfj8VAPsUIOQIn1_hq0IHHnBPAkfGDyPjmG7TwojdQesUQ0sdZiEY0ONeWw8h0rUP-y5OHOpXBmSfyKPvCMKRYk9otQV6CwMetD5Bj9FSLGxm0ckSyRthQ3aJR0dwpCgcvEDYXad99ZIuHU8ECQ9UuAy7HXeMDr5-_eu_70T1Fmw4eRfQat0A4R0bP0MrEHxtaUBv7yT67nchpuwx0c0r8s4tNrwpbe-U1mIJ8FqZ1ZEg0TCGiJHdGYZgecdkQcKgiAuMlz9e_leml3td1VkyUsc77tC5M1gWbB1Z-JkllZlHjEkg9Zig66k7FDq7ECN1CeQ8tMHxL0ysUNc3CVXf-vpWNUB2RQJLXRjGSCKA6s2WPcZzseaXHy_ftmrNMFdc96bZc-pzO-_CoA9BwZcfldmySFYDbZ-WT4unyqzfU_xnzwIs0KJcRkSdYEAHkf7OaogBLUHIScnSiS1LF3IU1TwSWuhpysg9olvZ--imymwLs_VDU58wevb7ukPvQ6qvg9eW2ryvhTplTWrVs9YC1QWdI1ufppLrCQ6-zh6PyE7VqU89O6qzaHO0tjQV9JyUayXCLJWIrSkGVvgaByEayILjQ3kceN8naNVuKMFrY9jFMBQOisHf742RoholsdotFO44EmBxI1yQFxvo6ywfAjO57bbs7vZUZVYD9GHUxBeffQSg-p3YuVIQJoefgZNcG2phR6KRSUE3hcuWptTomY9mvFuZ8P8dTDoqWby77GsJLpdpWK6gUIFMgRyDCLeuHAlRaySXUaf9mL0l4YiXihNVZuUc9DiRt-N9jlQCmnoFSE6KA-fwKSfN9Q4jJHUujmMM2PXQo8ApxANZ8NyRO1_WWunPqZ_KW5pIJAjenaEkQzdYRF829HxmN492_bjGGW0eVovVumlM08z6jTHLZrF7eFoucdUh2SU2iIvmuV22S1wuzYw3ZmGahXlozGK5Ms18scBHbJo1Lu26MfhUNQsakN0tDrPy-c3zw-p5NXPYkpNyaxrTTfE1eoHGTZGnzXupmoVjSW934SxxcrT5dgnq7W76KCj737ntTu9Zjm7zm9WirS__6pv_31ZMGebfAAAA__8JU8y3">