Need help testing pacman 6.0.2 debug packages
Yo! With the release of pacman 6.0.2 we have now support for debug packages through `debugedit` as opposed to the awk hack used previously. https://gitlab.archlinux.org/pacman/pacman/-/commit/ae2f506ddfd1 This should resolve several issues we have had with the existing debug packages and I want people to test this support. Please recreate your build chroots and/or reinstall base-devel locally. Enable debug in a diverse set of packages you maintain. And help validate the current assumptions: * Debug packages for Rust, Go* and Julia should work * Weird /build directories should not exist * We should have header files * The source files should be located in `/usr/src/debug/${pkgbase}-${pkgver}` You can list them easily with `bsdtar -tf *.pkg.tar.zst` Note pacman is currently in [testing]. In the case for Go we need to disable compressed dwarf headers with `-ldflags=-compressdwarf=false`. It should be the case for any binaries with these headers as well. They can be recognized with the weird "DWARF version 0 unhandled" error string during stripping. Please report back if things look good, or you are looking at weird debug package structures :) If everything looks fine I intend to write an RFC for blanket enabling debug packages in devtools! -- Morten Linderud PGP: 9C02FF419FECBE16
Thanks for your work on this! From a quick test it seems much faster than the previous implementation.
* The source files should be located in `/usr/src/debug/${pkgbase}-${pkgver}`
That doesn't seem to be the case. The entire ${srcdir} is installed directly under /usr/src/debug. This can potentially cause conflicts, especially with out-of-tree cmake/meson builds.
On 6/10/22 01:03, Antonio Rojas wrote:
Thanks for your work on this! From a quick test it seems much faster than the previous implementation.
* The source files should be located in `/usr/src/debug/${pkgbase}-${pkgver}`
That doesn't seem to be the case. The entire ${srcdir} is installed directly under /usr/src/debug. This can potentially cause conflicts, especially with out-of-tree cmake/meson builds.
Can you provide more details? Anything that uses {C,CXX,RUST}FLAGS should work. A
El jueves, 6 de octubre de 2022 1:58:46 (CEST) Allan McRae escribió:
* The source files should be located in `/usr/src/debug/${pkgbase}-${pkgver}`
That doesn't seem to be the case. The entire ${srcdir} is installed directly under /usr/src/debug. This can potentially cause conflicts, especially with out-of-tree cmake/meson builds.
Can you provide more details? Anything that uses {C,CXX,RUST}FLAGS should work.
As far as I can see, source files are being copied to /usr/src/debug [1][2]. No ${pkgbase}-${pkgver} subdir is even created [1] https://gitlab.archlinux.org/pacman/pacman/-/blob/v6.0.2/scripts/libmakepkg/... [2] https://gitlab.archlinux.org/pacman/pacman/-/blob/v6.0.2/scripts/libmakepkg/...
On Thu, Oct 06, 2022 at 09:28:36AM +0200, Antonio Rojas wrote:
El jueves, 6 de octubre de 2022 1:58:46 (CEST) Allan McRae escribió:
* The source files should be located in `/usr/src/debug/${pkgbase}-${pkgver}`
That doesn't seem to be the case. The entire ${srcdir} is installed directly under /usr/src/debug. This can potentially cause conflicts, especially with out-of-tree cmake/meson builds.
Can you provide more details? Anything that uses {C,CXX,RUST}FLAGS should work.
As far as I can see, source files are being copied to /usr/src/debug [1][2]. No ${pkgbase}-${pkgver} subdir is even created
[1] https://gitlab.archlinux.org/pacman/pacman/-/blob/v6.0.2/scripts/libmakepkg/... [2] https://gitlab.archlinux.org/pacman/pacman/-/blob/v6.0.2/scripts/libmakepkg/...
I was apparently confused and missed this when I originally wrote the patch. I submitted a fix for this: https://lists.archlinux.org/archives/list/pacman-dev@lists.archlinux.org/thr... -- Morten Linderud PGP: 9C02FF419FECBE16
On 05/10/2022 16:28, Morten Linderud wrote:
Yo!
With the release of pacman 6.0.2 we have now support for debug packages through `debugedit` as opposed to the awk hack used previously.
https://gitlab.archlinux.org/pacman/pacman/-/commit/ae2f506ddfd1
<SNIP> I removed my testing chroot in /var/lib/archbuild and rebuild arch-rebuild-order. TL;DR it does not seem to work for me. Checking arch-rebuild-order-debug-0.3.1-1-x86_64.pkg.tar.zst arch-rebuild-order-debug W: ELF file ('usr/lib/debug/usr/bin/arch-rebuild-order.debug') is unstripped. arch-rebuild-order-debug W: Directory (usr/src/debug) is empty arch-rebuild-order-debug E: Missing custom license directory (usr/share/licenses/arch-rebuild-order-debug) arch-rebuild-order-debug E: Symlink (usr/lib/debug/.build-id/0c/043fb6cf6cc61237c605819d0075e240415306) points to non-existing ../../../../bin/arch-rebuild-order Seems the source is missing: drwxr-xr-x root/root 0 2022-10-06 13:29 usr/lib/ drwxr-xr-x root/root 0 2022-10-06 13:29 usr/lib/debug/ drwxr-xr-x root/root 0 2022-10-06 13:29 usr/lib/debug/.build-id/ drwxr-xr-x root/root 0 2022-10-06 13:29 usr/lib/debug/.build-id/0c/ lrwxrwxrwx root/root 0 2022-10-06 13:29 usr/lib/debug/.build-id/0c/043fb6cf6cc61237c605819d0075e240415306 -> ../../../../bin/arch-rebuild-order lrwxrwxrwx root/root 0 2022-10-06 13:29 usr/lib/debug/.build-id/0c/043fb6cf6cc61237c605819d0075e240415306.debug -> ../../usr/bin/arch-rebuild-order.debug drwxr-xr-x root/root 0 2022-10-06 13:29 usr/lib/debug/usr/ drwxr-xr-x root/root 0 2022-10-06 13:29 usr/lib/debug/usr/bin/ -rwxr-xr-x root/root 3829992 2022-10-06 13:29 usr/lib/debug/usr/bin/arch-rebuild-order.debug drwxr-xr-x root/root 0 2022-10-06 13:29 usr/src/ drwxr-xr-x root/root 0 2022-10-06 13:29 usr/src/debug/ Testing with rust-gdb: rust-gdb --args arch-rebuild-order opencolorio Reading symbols from arch-rebuild-order... Reading symbols from /usr/lib/debug/usr/bin/arch-rebuild-order.debug... (gdb) b find_package_anywhere Function "find_package_anywhere" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (find_package_anywhere) pending. (gdb) r Starting program: /usr/bin/arch-rebuild-order opencolorio This GDB supports auto-downloading debuginfo from the following URLs: https://debuginfod.archlinux.org Enable debuginfod for this session? (y or [n]) y Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". opencolorio openimageio openshadinglanguage krita krita-plugin-gmic blender [Inferior 1 (process 324620) exited normally] My local cargo build works fine with the same commands: Reading symbols from target/debug/arch-rebuild-order... (gdb) b find_package_anywhere Breakpoint 1 at 0x3cb50: file src/lib.rs, line 19. (gdb) s The program is not being run. (gdb) r Starting program: /home/jelle/projects/arch-rebuild-order/target/debug/arch-rebuild-order opencolorio This GDB supports auto-downloading debuginfo from the following URLs: https://debuginfod.archlinux.org Enable debuginfod for this session? (y or [n]) y Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Breakpoint 1, arch_rebuild_order::find_package_anywhere (pkgname="opencolorio", pacman=0x7fffffffb580) at src/lib.rs:19 19 let dbs = pacman.syncdbs(); Not sure, what's going wrong with the debug build. Greetings, Jelle
On Thu, Oct 06, 2022 at 01:42:32PM +0200, Jelle van der Waa wrote:
On 05/10/2022 16:28, Morten Linderud wrote:
Yo!
With the release of pacman 6.0.2 we have now support for debug packages through `debugedit` as opposed to the awk hack used previously.
https://gitlab.archlinux.org/pacman/pacman/-/commit/ae2f506ddfd1
<SNIP>
I removed my testing chroot in /var/lib/archbuild and rebuild arch-rebuild-order. TL;DR it does not seem to work for me.
What happens if you remove `--release` from cargo? Or what would we need to do for debug packages on Rust? What does Fedora/SUSE do? -- Morten Linderud PGP: 9C02FF419FECBE16
Short update, On 06/10/2022 13:42, Jelle van der Waa wrote:
On 05/10/2022 16:28, Morten Linderud wrote:
Yo!
With the release of pacman 6.0.2 we have now support for debug packages through `debugedit` as opposed to the awk hack used previously.
https://gitlab.archlinux.org/pacman/pacman/-/commit/ae2f506ddfd1
<SNIP>
I removed my testing chroot in /var/lib/archbuild and rebuild arch-rebuild-order. TL;DR it does not seem to work for me.
Checking arch-rebuild-order-debug-0.3.1-1-x86_64.pkg.tar.zst arch-rebuild-order-debug W: ELF file ('usr/lib/debug/usr/bin/arch-rebuild-order.debug') is unstripped. arch-rebuild-order-debug W: Directory (usr/src/debug) is empty arch-rebuild-order-debug E: Missing custom license directory (usr/share/licenses/arch-rebuild-order-debug) arch-rebuild-order-debug E: Symlink (usr/lib/debug/.build-id/0c/043fb6cf6cc61237c605819d0075e240415306) points to non-existing ../../../../bin/arch-rebuild-order
Turns out that one can check this easier in gdb: Reading symbols from arch-rebuild-order... Reading symbols from /usr/lib/debug/usr/bin/arch-rebuild-order.debug... (gdb) list Dwarf Error: Cannot find DIE at 0x1dd49 referenced from DIE at 0x61e94 [in module /usr/lib/debug/usr/bin/arch-rebuild-order.debug] (gdb) info functions Dwarf Error: Cannot find DIE at 0x1dd49 referenced from DIE at 0x61e94 [in module /usr/lib/debug/usr/bin/arch-rebuild-order.debug] So woops! Something is borked... removing --release is not the solution :-) Note that debug symbols seem to work for rg in Fedora, and this is how they build with cargo: [jelle@toolbox][~]%rpm --eval "%cargo_build" /usr/bin/env CARGO_HOME=.cargo RUSTC_BOOTSTRAP=1 RUSTFLAGS='-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Clink-arg=-Wl,-z,relro -Clink-arg=-Wl,-z,now -Clink-arg=-Wl,-dT,/home/jelle/rpmbuild/BUILD/.package_note-%{name}-%{version}-%{release}.x86_64.ld --cap-lints=warn' /usr/bin/cargo build -j8 -Z avoid-dev-deps --release Our RUSTFLAGS should be fine in this regard. Running makepkg, going into src/arch-rebuild-order [jelle@t14s][/tmp/arch-rebuild-order/trunk/src/arch-rebuild-order]%debugedit --list-file /dev/stdout target/debug/arch-rebuild-order | tr '\0' '\n' | less /rustc/1.64.0/library/alloc/src/raw_vec.rs /rustc/1.64.0/library/alloc/src/vec/mod.rs /usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/main.rs /home/jelle/.cargo/registry/src/github.com-1ecc6299db9ec823/structopt-0.3.26/src/lib.rs So this seems good, except the cargo dependencies. Fedora might specify CARGO_HOME for that reason? Ok success, after these changes! The LTO issue seems to be known [1] Index: PKGBUILD =================================================================== --- PKGBUILD (revision 457306) +++ PKGBUILD (working copy) @@ -10,24 +10,26 @@ depends=('glibc' 'libalpm.so') makedepends=('cargo' 'mandown' 'git') groups=('archlinux-tools') -options=('debug') -source=(git+https://gitlab.archlinux.org/archlinux/arch-rebuild-order.git#tag=v$pkgver?s...) -sha512sums=('SKIP') +options=('debug' 'strip' '!lto') +source=(git+https://gitlab.archlinux.org/archlinux/arch-rebuild-order.git#tag=v$pkgver?s... cargo.patch) +sha512sums=('SKIP' + '63b6a57699b4f0db4e8e5a763b5e9baac949567d1fde04914591249d9cd5faf764e9be470fd2b0b8b9aadebc5464b4d7e59bae1e6a46bf7cad9b552a9a96c829') validpgpkeys=("E499C79F53C96A54E572FEE1C06086337C50773E") prepare() { cd ${pkgname} + patch -Np1 -i ${srcdir}/cargo.patch cargo fetch --locked --target "$CARCH-unknown-linux-gnu" } build() { cd ${pkgname} - cargo build --frozen --release --all-features + cargo build --frozen --all-features } check() { cd ${pkgname} - cargo test --frozen --all-features + # cargo test --frozen --all-features } package() { For debugging use: rust-gdb --args arch-rebuild-order opencolorio (gdb) b arch_rebuild_order::find_package_anywhere Breakpoint 2 at 0x14e31: file src/lib.rs, line 19. Breakpoint 1, arch_rebuild_order::main () at src/main.rs:6 6 src/main.rs: No such file or directory. (gdb) So, the source code cannot be found while it is available: tar tvf arch-rebuild-order-debug-0.3.1-1-x86_64.pkg.tar.zst drwxr-xr-x root/root 0 2022-10-07 13:24 usr/src/ drwxr-xr-x root/root 0 2022-10-07 13:24 usr/src/debug/ drwxr-xr-x root/root 0 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/ drwxr-xr-x root/root 0 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/src/ -rw-r--r-- root/root 757 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/src/args.rs -rw-r--r-- root/root 516 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/src/error.rs -rw-r--r-- root/root 6017 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/src/lib.rs -rw-r--r-- root/root 572 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/src/main.rs This all needs some further debugging :) [1] https://github.com/rust-lang/rust/issues/41775
On 07/10/2022 13:35, Jelle van der Waa wrote:
Short update,
So, the source code cannot be found while it is available:
tar tvf arch-rebuild-order-debug-0.3.1-1-x86_64.pkg.tar.zst
drwxr-xr-x root/root 0 2022-10-07 13:24 usr/src/ drwxr-xr-x root/root 0 2022-10-07 13:24 usr/src/debug/ drwxr-xr-x root/root 0 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/ drwxr-xr-x root/root 0 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/src/ -rw-r--r-- root/root 757 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/src/args.rs -rw-r--r-- root/root 516 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/src/error.rs -rw-r--r-- root/root 6017 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/src/lib.rs -rw-r--r-- root/root 572 2022-10-07 13:24 usr/src/debug/arch-rebuild-order/src/main.rs
This all needs some further debugging :)
Basically it needs to go into usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/main.rs That's what debugedit I get from debugedit :)
On 07/10/2022 13:35, Jelle van der Waa wrote:
Short update,
Running makepkg, going into src/arch-rebuild-order
[jelle@t14s][/tmp/arch-rebuild-order/trunk/src/arch-rebuild-order]%debugedit --list-file /dev/stdout target/debug/arch-rebuild-order | tr '\0' '\n' | less
/rustc/1.64.0/library/alloc/src/raw_vec.rs /rustc/1.64.0/library/alloc/src/vec/mod.rs /usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/main.rs /home/jelle/.cargo/registry/src/github.com-1ecc6299db9ec823/structopt-0.3.26/src/lib.rs
So this seems good, except the cargo dependencies. Fedora might specify CARGO_HOME for that reason?
Ok success, after these changes! The LTO issue seems to be known [1]
Index: PKGBUILD =================================================================== --- PKGBUILD (revision 457306) +++ PKGBUILD (working copy) @@ -10,24 +10,26 @@ depends=('glibc' 'libalpm.so') makedepends=('cargo' 'mandown' 'git') groups=('archlinux-tools') -options=('debug') -source=(git+https://gitlab.archlinux.org/archlinux/arch-rebuild-order.git#tag=v$pkgver?s...) -sha512sums=('SKIP') +options=('debug' 'strip' '!lto') +source=(git+https://gitlab.archlinux.org/archlinux/arch-rebuild-order.git#tag=v$pkgver?s... cargo.patch) +sha512sums=('SKIP' + '63b6a57699b4f0db4e8e5a763b5e9baac949567d1fde04914591249d9cd5faf764e9be470fd2b0b8b9aadebc5464b4d7e59bae1e6a46bf7cad9b552a9a96c829') validpgpkeys=("E499C79F53C96A54E572FEE1C06086337C50773E")
cargo.patch is: diff --git a/Cargo.toml b/Cargo.toml index 937e97a..94e426f 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -25,8 +25,3 @@ anyhow = "1.0.52" rstest = "0.12.0" tar = "0.4.38" tempfile = "3.3.0" - - -[profile.release] -lto = true -codegen-units = 1
On 10/7/22 13:35, Jelle van der Waa wrote:
...
This all needs some further debugging :)
Thanks a lot for the detailed info. I've done additional rounds of testing using the latest pacman patches [0]: There are rumors that the pacman patch "strip: fix unique source paths" may have side-effects, but using that one puts rust sources into the correct place: bsdtar tf arch-rebuild-order-debug-0.3.1-0-x86_64.pkg.tar.zst ... usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/args.rs usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/error.rs usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/lib.rs usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/main.rs Also works for none git clones via tarball archives: bsdtar tf dfrs-debug-0.0.7-0-x86_64.pkg.tar.zst ... usr/src/debug/dfrs/dfrs-0.0.7/src/args.rs usr/src/debug/dfrs/dfrs-0.0.7/src/main.rs usr/src/debug/dfrs/dfrs-0.0.7/src/mount.rs usr/src/debug/dfrs/dfrs-0.0.7/src/theme.rs usr/src/debug/dfrs/dfrs-0.0.7/src/util.rs It is important to note that this requires to set DEBUG_RUSTFLAGS to "-C debuginfo=2" as commented in makepkg.conf. The reason for this is that the cargo release profile provides a default of debuginfo=0 which means no debug info at all. That setting is the only real important one out of the release profile as the dev profile pulls in quite a lot of debug behavior that has great influence not just on runtime speed but also on runtime behavior like debug-asserts etc [2]. Either way we would only need to find the correct options to use for the release profile, as all that profiles like dev do is set options. With a local pacman/makepkg that contains patches up to [0] plus using DEBUG_RUSTFLAGS with debuginfo=2, we achieve the correct behavior in gdb without further adjustments in project PKGBUILD's besides setting the correct options=(): rust-gdb /usr/bin/arch-rebuild-order Reading symbols from /usr/bin/arch-rebuild-order... Reading symbols from /usr/lib/debug/usr/bin/arch-rebuild-order.debug... (gdb) b arch_rebuild_order::find_package_anywhere (gdb) r cowfortune Breakpoint 1, arch_rebuild_order::find_package_anywhere (pkgname="cowfortune", pacman=0x7fffffffc0b0) at src/lib.rs:19 19 let dbs = pacman.syncdbs(); ... The current debug package of arch-rebuild-order also seems to contain exactly what is expected: bsdtar tf arch-rebuild-order-debug-0.3.1-0-x86_64.pkg.tar.zst .BUILDINFO .MTREE .PKGINFO usr/ usr/lib/ usr/lib/debug/ usr/lib/debug/.build-id/ usr/lib/debug/.build-id/6e/ usr/lib/debug/.build-id/6e/47e7e3a5651158b1cbf8efde21a08ef379cf04 usr/lib/debug/.build-id/6e/47e7e3a5651158b1cbf8efde21a08ef379cf04.debug usr/lib/debug/usr/ usr/lib/debug/usr/bin/ usr/lib/debug/usr/bin/arch-rebuild-order.debug usr/src/ usr/src/debug/ usr/src/debug/arch-rebuild-order/ usr/src/debug/arch-rebuild-order/arch-rebuild-order/ usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/ usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/args.rs usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/error.rs usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/lib.rs usr/src/debug/arch-rebuild-order/arch-rebuild-order/src/main.rs So far so good :) [0] https://gitlab.archlinux.org/pacman/pacman/-/commit/478af273dfe24ded197ec54a... [1] https://doc.rust-lang.org/cargo/reference/profiles.html#debug [2] https://doc.rust-lang.org/cargo/reference/profiles.html#default-profiles
Just to followup on this abit. 6.0.2-1 was released, but we found a bug as the $pkgbase was not properly added to the /usr/src/debug/ portion of the string. We patched[1] this bug with 6.0.2-2 but it broke several debug packages, but it turns out this actually breaks packages built in sub-directories as we are ignoring some files. λ ~ » gdb /usr/bin/pacman [...] (gdb) list Downloading 0.04 MB source file /usr/src/debug/pacman-6.0.1/pacman-6.0.1/build/../src/pacman/pacman.c 1073 char *cl_text = arg_to_string(argc, argv); 1074 if(cl_text) { 1075 alpm_logaction(config->handle, PACMAN_CALLER_PREFIX, 1076 "Running '%s'\n", cl_text); 1077 free(cl_text); 1078 } 1079 } 1080 1081 /** Main function. 1082 * @param argc (gdb) info source Current source file is ../src/pacman/pacman.c Compilation directory is /usr/src/debug/pacman-6.0.1/pacman-6.0.1/build In gdb we have this weird relative path going on: /usr/src/debug/pacman-6.0.1/pacman-6.0.1/build/../src/pacman/pacman.c Is in theory this absolute path /usr/src/debug/pacman-6.0.1/pacman-6.0.1/src/pacman/pacman.c But gdb explicitly checks for /usr/src/debug/pacman-6.0.1/build existing in the package, which means we need to retain the empty `/build` directory when we make the debug packages. Previous iterations of pacman just omits this, and other distributions has pre-defined build directories which works around this issue a bit. This issue is semi-unique to build systems where we are building in sub-directories (like meson), so things like Go and Rust is going to *probably* work without us patching this. This has been patched (properly this time) with some help from Allan, now we just create all the directories we see, empty or not, and it should hopefully work out :) I have yet to release a new package into testing as I have been travelling. But fetching 6.0.2-2 from the archive to test different ecosystem should still mostly work I think. [1]: https://gitlab.archlinux.org/pacman/pacman/-/commit/478af273dfe24ded197ec54a... -- Morten Linderud PGP: 9C02FF419FECBE16
Yo! pacman version 6.0.2-5 is now in [core] and should have all the patches I messed up the last round :) Thanks anthraxxx<3 I have currently pushed a testing debug package of `delve` to our repositories and everything seems to be working properly! It would be great if people checked that any issues around debug packages they previously has is gone. It is important that people nuke any local chroots and rebuild them as `debugedit` has been added to the `base-devel` group. This is how I envision we progress on debug packages: - Help ensure the ecosystems you are packaging works - Help update any package guidelines for flags and/or important notes I will submit a change to `devtools` to enable the debug option by default this week unless something comes up. Along with patching the Golang package guidelines. Beyond that I intend to submit a patch to `debugedit` so we don't have to disable compressed DWARF headers in our compilers. Once we have all of this sorted out I expect us to publicly push debug package repositories in the near futue :) Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16 Side note: If anyone wants to test: Ensure delve version 1.9.1-2 is installed along with `debuginfo`. Run the delve debugger on itself and list the main function. λ ~ » pacman -Q delve delve 1.9.1-2 λ ~ » dlv exec /usr/bin/dlv Type 'help' for list of commands. (dlv) list main.main Showing /usr/src/debug/delve/delve-1.9.1/cmd/dlv/main.go:14 (PC: 0x55b12a2ec332) 9: ) 10: 11: // Build is the git sha of this binaries build. 12: var Build string 13: 14: func main() { 15: if Build != "" { 16: version.DelveVersion.Build = Build 17: } 18: const cgoCflagsEnv = "CGO_CFLAGS" 19: if os.Getenv(cgoCflagsEnv) == "" { (dlv) exit
devtools version 20230105-1 has been released into [core]! This enable the debug option for all our packages :) I have updated the Go package guidelines with some flags that needs to be present to create proper debug packages with the go compiler. https://wiki.archlinux.org/title/Go_package_guidelines#Supporting_debug_pack... -- Morten Linderud PGP: 9C02FF419FECBE16
On Sat, 14 Jan 2023 at 23:25, Morten Linderud
devtools version 20230105-1 has been released into [core]!
This enable the debug option for all our packages :)
Much nice! Went ahead and purged the debug option from */trunk/PKGBUILD. (If someone thinks the option should stay for a bit, poke me and I'll revert the removals.)
participants (6)
-
Allan McRae
-
Antonio Rojas
-
Evangelos Foutras
-
Jelle van der Waa
-
Levente Polyak
-
Morten Linderud