GDB in a .deb package...Python?

[Simon Marchi]

On 2024-10-26 22:55, Robert Dubner wrote:
> I am part of a team creating a COBOL front end for GCC, and we've reached
> the point where I am modifying GDB so that when debugging a COBOL inferior
> that has a data definition
> 
> "01 hyph-var picture S99V99 value -1.23."
> 
> the GDB command "print hyph-var" properly displays "-01.23"
> 
> (Programmers familiar with COBOL won't be surprised by that.  The rest of
> you will scratch your heads and say, "I sorta see what's going on there,
> but..." which happens a lot with COBOL.)
> 
> I should mention that the GCC steering committee has accepted our front
> end. We are currently starting to send the patches to GCC to incorporate
> that front end.  And before too long I am going to be asking here about
> how to go about getting my work on GDB incorporated into the source code.
> 
> But that's not important now.
> 
> What is important is that I have reached a point where I want to release
> my modified gdb-cobol into the wild for alpha testing. I have created a
> CI/CD process on our gitlab instance
> (https://gitlab.cobolworx.com/COBOLworx/gdb-cobol) that builds a .deb
> package for my gdb-cobol in a schroot environment that happens to be
> running on an Ubuntu 20.04 LTS instance, and it has Python3.8 installed.
> 
> After I install that package on an Ubuntu 22.04 instance that has Python
> 3.10.12 installed, when I invoke the gdb-cobol executable I instantly get
> the message:
> 
> "gdb-cobol: error while loading shared libraries: libpython3.8.so.1.0:
> cannot open shared object file: No such file or directory"
> 
> Running ldd on the gdb-cobol executable unsurprisingly reports
> 
> "libpython3.8.so.1.0 => not found"
> 
> I am about to start exploring solutions to this problem, because I need to
> be able to create a .deb package for machines that are not under my
> control, and I won't know what version of Python they have installed.
> 
> But I figured I'd ask:  Can somebody let me know what I have to do to
> eliminate that problem?  
> 
> (The first thing I am going to try is incorporating the relevant library
> into the .deb package.  But if there's a better way, I'd like to know
> about it.)
> 
> Thank you very much.

The right way to do this is to re-build the package on all the distro
versions you want to distribute it for.  This means, build it on an
Ubuntu 20.04 machine to produce the package for Ubuntu 20.04, build it
on an Ubuntu 22.04 machine to produce the packge for Ubuntu 22.04, etc.
However, that can be done using Docker (or other technology) containers
or virtual machines, you don't need to have different physical machines
with the different OSes installed.

Simon