[Bug 203021] lang/python27: Should install GDB integration tool(s)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203021

--- Comment #12 from Conrad Meyer <cem at freebsd.org> ---
(In reply to Kubilay Kocak from comment #10)
> @Conrad, during QA (with DEVELOPER=yes in /etc/make.conf), I observe the following:
> 
> ====> Running Q/A tests (stage-qa)
> readelf: Not an ELF file.
> Warning: /wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/libpython2.7.so.1-gdb.py
> doesn't have a SONAME.
> Warning: pkg(8) will not register it as being provided by the port.
> Warning: If another port depend on it, pkg will not be able to know where it comes from.
> Warning: It is directly in /usr/local/lib, it is probably used by other ports.

This is a spurious warning -- it isn't a shared object and obviously nothing
can use it like one.

> I'm not sure what this might mean for desired functionality out of the box for the port
> or binary package. This may not be an issue if no other ports depend (LIB_DEPENDS) on it.

I don't think it's an issue -- it's not a shared object, nothing can
LIB_DEPENDS on it.

> Have you tested whether GDB works as expected with libpython2.7.so.1-gdb.py in that
> location and confirmed it works without additional intervention once installed?

Yep, see comment #6.  We use it pretty frequently at work.

# ls /usr/local/lib/libpython2.7.so.1*
/usr/local/lib/libpython2.7.so.1             
/usr/local/lib/libpython2.7.so.1-gdb.py
# echo -e "import os\nos.abort()" > a.py
# gdb771 --args python a.py
...
(gdb) r
...
Program received signal SIGABRT, Aborted.
[Switching to Thread 8006c1400 (LWP 100708)]
0x000000080129d84a in thr_kill () from /lib/libc.so.7
(gdb) py-bt
Traceback (most recent call first):
  File "a.py", line 2, in <module>
    os.abort()
(gdb) py-list
   1    import os
  >2    os.abort()


(In reply to Kubilay Kocak from comment #11)
> It just occurred to me that this may just be a *.so file name matching thing. 

Yep.

> If so, is it possible (from a 'it works out of the box') point of view to either rename
> the file and/or put it in a still-suitable location not inside LOCALBASE/lib?

The name can't be changed, I think.  There are a few suitable locations. 
Fedora uses a location associated with the separated shared object debuginfo,
which ports doesn't support:

/usr/lib/debug/usr/lib64/libpython2.7.so.1.0.debug-gdb.py

Note that this portion   ^^^^^^^^^^^^^^^^^^^^^^^^^  has to match some file GDB
is loading already.  I'm not sure what search paths GDB has by default.  In the
differential review, someone mentioned:

/usr/local/share/gdb/auto-load/usr/local/lib/libglib-2.0.so.0.5000.2-gdb.py

This is discussed a little bit more in the first few comments of the review.

-- 
You are receiving this mail because:
You are on the CC list for the bug.