[OE-core] [PATCH v2] python3: RDEPEND on libgcc

[Khem Raj]

On Tue, Dec 31, 2019 at 11:25 AM Joshua Watt <jpewhacker at gmail.com> wrote:
>
> On Tue, Dec 31, 2019 at 1:11 PM Khem Raj <raj.khem at gmail.com> wrote:
> >
> > On Tue, Dec 31, 2019 at 11:07 AM Joshua Watt <jpewhacker at gmail.com> wrote:
> > >
> > > Python uses features of glibc that require it to dynamically load (i.e.
> > > dlopen()) libgcc_s at runtime. However, since this isn't a link time
> > > dependency, it doesn't get picked up automatically by bitbake so
> > > manually add it to RDEPENDS.
> > >
> > > There is an outstanding bug in Python to make it explicitly link against
> > > libgcc at link time which would remove the need for this. See:
> > > https://bugs.python.org/issue37395
> > >
> > > Signed-off-by: Joshua Watt <JPEWhacker at gmail.com>
> > > ---
> > >  meta/recipes-devtools/python/python3_3.7.5.bb | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/meta/recipes-devtools/python/python3_3.7.5.bb b/meta/recipes-devtools/python/python3_3.7.5.bb
> > > index 137b540dba..78312b05f3 100644
> > > --- a/meta/recipes-devtools/python/python3_3.7.5.bb
> > > +++ b/meta/recipes-devtools/python/python3_3.7.5.bb
> > > @@ -306,6 +306,8 @@ RPROVIDES_${PN}-venv += "python3-pyvenv"
> > >  PACKAGES =+ "libpython3 libpython3-staticdev"
> > >  FILES_libpython3 = "${libdir}/libpython*.so.*"
> > >  FILES_libpython3-staticdev += "${prefix}/lib/python${PYTHON_MAJMIN}/config-${PYTHON_BINABI}-*/libpython${PYTHON_BINABI}.a"
> > > +# See https://bugs.python.org/issue18748 and https://bugs.python.org/issue37395
> > > +RDEPENDS_libpython3 += "libgcc"
> >
> > while this is glibc specific change depending on gcc runtime, it seems
> > we should only apply is when we use gcc runtime and glibc
> >
> > glibc part is easy just use libc-glibc override for gcc runtime piece
> > perhaps, its good to introduce, virtual/compiler-runtime and let
> > libgcc
> > provide it by default, but let apps depend on virtual/compiler-runtime
>
> I'll use the libc-glibc override so that it's specific to glibc, but I
> think the virtual/compiler-runtime might be a bit premature, unless
> you know of a usecase where it would currently be necessary?
>

eg. one might use compiler-rt to provide built-ins and use
llvm-libunwind for unwinding info not rely on libgcc, one can say it
can then provide libgcc and substitute it. However, it will be better
if it was in design to be able to do that from top.

> >
> >
> > >  INSANE_SKIP_${PN}-dev += "dev-elf"
> > >
> > >  # catch all the rest (unsorted)
> > > --
> > > 2.23.0
> > >
> > > --
> > > _______________________________________________
> > > Openembedded-core mailing list
> > > Openembedded-core at lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core