Path: csiph.com!feeder.erje.net!2.eu.feeder.erje.net!news2.arglkargh.de!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From: Scott Talbert <swt@techie.net>
Newsgroups: linux.debian.maint.python
Subject: Re: Broken dbgsym packages for Python 3
Date: Tue, 05 Jun 2018 06:20:02 +0200
Message-ID: <vXbBU-FF-3@gated-at.bofh.it>
References: <vWMtQ-2jf-3@gated-at.bofh.it> <vWPrH-49x-1@gated-at.bofh.it> <vX3bk-3MZ-7@gated-at.bofh.it>
Old-Return-Path: <swt@techie.net>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Approved: robomod@news.nic.it
Lines: 36
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.python:10607

On Mon, 4 Jun 2018, Matthias Klose wrote:

>>> I've got a package (wxpython4.0) that builds modules for both Python 2.7
>>> and Python 3.  When I rebuilt the package in early May, I started getting
>>> the lintian warning debug-file-with-no-debug-symbols for the Python 3
>>> dbgsym packages only.  Sure enough, looking at those files, there is not
>>> much there.  The Python 2.7 dbgsym files are fine.  Given that I haven't
>>> changed anything in how the Python 3 modules are compiled, it seems that
>>> some outside change in the distribution has caused this.  Has anyone else
>>> noticed this, or have any idea what might have caused these dbgsym
>>> packages to stop working?
>> 
>> The -dbgsym packages don't work for Python anyway because you need to call 
>> the
>> debug interpreter, so I don't think it matters much either way.
>
> Usually the python*-*-dbg packages contain two things:
>
> - the unstripped extensions for the dbg interpreter
> - the debug symbols for the python*-* packages.
>
> If you don't have both of these, you should investigate why.

Yes, I'm talking about the automatically generated -dbgsym packages that 
contain the /usr/lib/debug/.build-id/... files.  I have looked into it 
further and the problem seems to be happening during the link phase.  I 
checked the individual .o files (for the Python 3 version) and they all 
contain .debug_str and I can see the symbol names with readelf 
--debug-dump=str.  But then after linking, they are gone.  I ran the exact 
same link command on the Python 2 .o files and the resulting .so has the 
debug info.

Rather bizarre.  I don't know what to think.  g++ (or whatever actually 
does the linking?) doesn't like the Python 3 debug info and discards it?

Scott