[Bug 59601] New: dlls\kernelbase\debug.c isn't shipping with the debug symbols
http://bugs.winehq.org/show_bug.cgi?id=59601 Bug ID: 59601 Summary: dlls\kernelbase\debug.c isn't shipping with the debug symbols Product: Wine Version: 11.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: mirh@protonmail.ch Distribution: --- So, I'll premise that I really don't know anything about the magic of autoconf. https://forum.winehq.org/viewtopic.php?t=36001#p135416 Still, after much headbanging I come to understand it's a problem on your side (and not Arch's) if that source file isn't getting copied in the debug folder. You can instead see in bug 46010 that when somebody is building wine on their own system, the debugger can find it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59601 --- Comment #1 from Alexandre Julliard <julliard@winehq.org> --- The source files are of course not included in binary packages, that doesn't prevent the debugger from getting a proper backtrace. What results are you expecting here? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59601 --- Comment #2 from mirh <mirh@protonmail.ch> --- Admittedly, other than the "unable to access file" line I'm not seeing any meaningful difference between the runs where I keep all my sources in their original folder and those where I delete them. https://geo.mirror.pkgbuild.com/extra-debug/os/x86_64/wine-debug-11.5-1-x86_... Though after noticing how Arch (unlike you who just ship the build-ids) also included some source files I was thinking there was something missing in the makefiles if, say, avicap32 get to carry v4l.c and netapi32 and many others have unixlib.c and unixlib.h while kernelbase has zero. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59601 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTOURBUG --- Comment #3 from Alexandre Julliard <julliard@winehq.org> --- That's something that Arch is doing, our makefiles do not ship any source at all. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59601 --- Comment #4 from mirh <mirh@protonmail.ch> --- I understand that makepkg does a lot of heavy lifting behind the scenes, but the build script for wine has no mention at all of those files (and of course it's not like they programmed pacman to account specifically for this). https://gitlab.archlinux.org/pacman/pacman/-/blob/master/scripts/libmakepkg/... They just(?) go through the sources with debugedit.. and so I feel like, either whatever triggers it should apply to kernelbase too, or it shouldn't be the case that the debugger needlessly complains about it when RaiseException is thrown. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59601 --- Comment #5 from Alexandre Julliard <julliard@winehq.org> --- From a quick reading of that script, it uses readelf to get build ids and files to copy, so it won't get any results for PE libraries. They need to adapt the script to get debug information out of PE files. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59601 --- Comment #6 from mirh <mirh@protonmail.ch> --- Ok, I see it now. https://gitlab.archlinux.org/pacman/libmakepkg-dropins/-/blob/main/tidy/50-p... This is how they are collecting the symbols, and for PE files they *do* that too. But as mentioned in the comment there, that doesn't apply yet to sources of PE files (indeed this is eventually the difference between v4l.c which is a unix lib, and debug.c which is win32). I just wonder why this seemed to be happening on ubuntu too? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla