For many packages, there are dbgsym packages. Now it's present mostly for packages built with GCC. I think it will be a good idea to provide dbgsym packages for programs built with FPC. Debian Release: buster/sid 990 testing ftp.by.debian.org 500 unstable ftp.by.debian.org --- Package information. --- Depends (Version) | Installed ====================================-+-================== fpc-3.0.4 (= 3.0.4+dfsg-19) | 3.0.4+dfsg-19 fp-docs-3.0.4 | 3.0.4+dfsg-19 fp-utils-3.0.4 | 3.0.4+dfsg-19 Package's Recommends field is empty. Package's Suggests field is empty. -- --------------------- Alexander Kernozhitsky
Hi Alexander, Thanks for raising this issue. But isn't this an issue for each individual package? What do you expect from the fpc package in this respect? Paul
[Oops, now with submitter in the To:.] Control: tags -1 moreinfo Hi Alexander, Thanks for raising this issue. But isn't this an issue for each individual package? What do you expect from the fpc package in this respect? Paul
Well, does FPC actually support building in a way that allow dbgsym packages? Specifically, with most basic dh(1) debian/rules, I'm getting "dh_strip: warning: Could not find the BuildID in debian/ironseed/usr/libexec/ironseed/main" warnings in sid with fpc 3.2.0+dfsg-8, and resulting -dbgsym file is unusable by gdb. I've tried various compilation options, last one being: fpc -Mtp -g -gl -gv -fPIC -C3 -Ci -Co -CO -O1 -gw -godwarfsets -gt -vewnhiq -Sa -Sy -Sewnh -vm4049 -k-lSDL_mixer -k-lSDL -k-lm -k'-z relro' -k'-z now' -k-pie main.pas that works for debugging with gdb when symbols are not extracted, but not in -dbgsym case. (package is currently at https://incoming.debian.org/debian-buildd/pool/main/i/ironseed/ironseed_0.3.2-2.dsc) Do we have some other packages using fpc, which have working -dbgsym? Or does fpc itself need some changes for it to work?
Answering myself (and other parties interested in fpc/debug packages): fpc 3.2.0 will build -dbgsym packages correctly automatically if "-k--build-id" is added to all fpc invocations (or to /etc/fpc.conf file)
Hi Matija, That looks great, information. I'll try to look how to use it.
Maybe an option is to add this flag to /etc/fpc.cfg, so that it becomes the default way of linking. But not sure if this is the right way to do it. Maybe the build program should use this in their custom build command. Another question is, should we enforce this flag when building FPC itself, so that one can debug the RTL, or do we consider this out of scope of FPC Debian packages (means that who wants to debug RTL should build his own FPC!).
Control: forwarded -1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902887 It seems that upstream is now aware of this issue as it was raised by a user [1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902887
Control: forwarded - 1 https://gitlab.com/freepascal.org/fpc/source/-/issues/39538 It seems that upstream is now aware of this issue as it was raised by a user [1]. [1] https://gitlab.com/freepascal.org/fpc/source/-/issues/39538 -- Cheers, Abou Al Montacir
Control: forwarded -1 https://gitlab.com/freepascal.org/fpc/source/- /issues/39538 It seems that upstream is now aware of this issue as it was raised by a user [1]. [1] https://gitlab.com/freepascal.org/fpc/source/-/issues/39538 -- Cheers, Abou Al Montacir
-k--build-id is an answer to getting dbgsym packages, however I tried it out with c-evo and it is breaking reproducible build. Looks like the build ID is a random string, so the two builds differ. Maybe not a good idea for etc/fpc.cfg ? Cheers, Peter
Does it build reproducibily *without* "-k--build-id"? AFAIR fpc never built packages fully reproducibly for me - checks also complained at least about "captures_build_path" (which should not be related to build-id I think): https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ironseed.html and more detailed look showed even more differences than paths and build-id: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ironseed.html (I'd love it if fpc was able to create reproducable builds, but that seems to be material for another issue...) Relatedly, is "c-evo" packaged in Debian? I cannot seem to find it in the packages.debian.org, nor on mentors.debian.net under that name?
Yes. It passes reprotest locally. End of log is ======================= Reproduction successful ======================= No differences in ./../*.deb a7440e75208155dd247ba540fa29f04107bc44e7ca7dc9cb95cdeb270decd9c8 ./../c-evo-data_1.3.0.418+dfsg-1_all.deb dd0d4a122ace2ba25012bffbdb4019bdfe2d0e09afebf14ac134082f7400d35d ./../c-evo-gtk2_1.3.0.418+dfsg-1_amd64.deb a72a1cacb5bca6c4a797441f69cec15bd61a1c6b83b12f11e5cd52f2d32d6cd1 ./../c-evo-nh_1.3.0.418+dfsg-1_amd64.deb 968995d0363d7dbc5ad50a0b9a95dd6c9aad6a4bae24666bbe06ed497b19d311 ./../c-evo-qt5_1.3.0.418+dfsg-1_amd64.deb e1327cb9cb69b2a66fa2c9aab89ba7c473bed50e4131122ff4f476f057b039da ./../c-evo-stdai_1.3.0.418+dfsg-1_amd64.deb Its mentioned here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968495 It was deleted from mentors after failing to attract a sponsor. Cheers, Peter