RE: GDB in a .deb package...Python?

> -----Original Message-----
> From: Simon Marchi <[email protected]>
> Sent: Monday, October 28, 2024 09:33
> To: Robert Dubner <[email protected]>; [email protected]
> Cc: 'James K. Lowden' <[email protected]>
> Subject: Re: GDB in a .deb package...Python?
>
>
>
> 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

Simon, thank you.  I had reluctantly come to a similar conclusion.

So, for the moment, I have switched to building and packaging GDB in a 
Debian "bookworm" schroot/chroot (bookworm is apparently the basis for 
Ubuntu 22), and specifying Python3.11 as a prerequisite, and that seems to 
be working for an Ubuntu 22.04 target.

It's still not quite the right way, as you rightly describe, but right now I 
need to be developing the debugger, not debugging the packaging.

(Is it just me, or does anybody else feel slightly disconnected from reality 
when using one version of GDB to debug another version of GDB?)


Thanks again.

Bob Dubner