New package: expert-0.1.4

[velrest]

Testing the changes

• I tested the changes in this PR: YES

New package

• This new package conforms to the package requirements: PARTIALLY as this uses a pre-built binary

Why this uses pre-built binaries:
Building from source is currently not feasible. The build tool (Burrito) requires Zig 0.15.2, but void-packages currently ships Zig 0.13.0 and there is a PR open to go directly to 16 here. The pre-built binaries are official upstream releases with verified checksums. Coverage is limited to x86_64 and aarch64 glibc; musl is not supported.

Local build testing

• I built this PR locally for my native architecture, (x86_64)

[hellodhruvin]

readelf -dW shows no dynamic section, and readelf -lW shows there’s no INTERP segment

So there is no hard dependency on glibc. I had a musl install before I reinstalled void with glibc (ran into some issues with liblwjgl not working with my launcher), and expert binary was working fine.

Here are the outputs of readelf -dW and readelf -lW if that helps:

> readelf -Wd ./expert_linux_amd64

There is no dynamic section in this file.

eadelf -lW ./expert_linux_amd64

Elf file type is EXEC (Executable file)
Entry point 0x344e690
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000001000040 0x0000000001000040 0x0001f8 0x0001f8 R   0x8
  LOAD           0x000000 0x0000000001000000 0x0000000001000000 0x244d688 0x244d688 R   0x1000
  LOAD           0x244d690 0x000000000344e690 0x000000000344e690 0x015353 0x015353 R E 0x1000
  LOAD           0x24629e8 0x00000000034649e8 0x00000000034649e8 0x000000 0x000618 RW  0x1000
  LOAD           0x24629e8 0x00000000034659e8 0x00000000034659e8 0x0000d0 0x001b94 RW  0x1000
  TLS            0x24629e4 0x00000000034639e4 0x00000000034639e4 0x000000 0x000005 R   0x4
  GNU_RELRO      0x24629e8 0x00000000034649e8 0x00000000034649e8 0x000000 0x000618 R   0x1
  GNU_EH_FRAME   0x244b178 0x000000000344b178 0x000000000344b178 0x00064c 0x00064c R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x1000000 RW  0

 Section to Segment mapping:
  Segment Sections...
   00
   01     .rodata .eh_frame_hdr .eh_frame
   02     .text
   03     .got .relro_padding
   04     .data .bss
   05     .tbss
   06     .got .relro_padding
   07     .eh_frame_hdr
   08

TL;DR: Although the package doesn’t explicitly state musl support so the binary has no hard runtime dependency on glibc. I tested it out on musl and it was working. (I've made a PR to your repo that lets the package be installed on musl) Update: I have requested the relevant changes.

[velrest]

Hey @hellodhruvin

Thanks for testing this! Do you know what the general consensus is in void-packages on releasing musl packages which are not officially supported by the application providers? If we release expert-0.1.4 with musl support now and expert-0.1.5 will not be musl supported anymore, there is only limited patching we can do in a binary right?

[hellodhruvin]

I understand, but at the moment the binary does not depend on libc, though it doesn't clearly mention it supports musl, it also doesn't clearly mention that it does not support musl. Should we just neglect that and release only for glibc in this case, even though the package does not say it depends on glibc? As for general consensus, I am fairly new to void linux and never really had to package anything, other than expert.