[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    Re: [OE-core] [PATCH v2] python3: RDEPEND on libgcc
From:       Khem Raj <raj.khem () gmail ! com>
Date:       2019-12-31 20:31:30
Message-ID: CAMKF1sqdNu_tg-MX3MNkSHQGqVP7U0v=J8_ufx_vK-eNqhp_Og () mail ! gmail ! com
[Download RAW message or body]

On Tue, Dec 31, 2019 at 11:25 AM Joshua Watt <jpewhacker@gmail.com> wrote:
> 
> On Tue, Dec 31, 2019 at 1:11 PM Khem Raj <raj.khem@gmail.com> wrote:
> > 
> > On Tue, Dec 31, 2019 at 11:07 AM Joshua Watt <jpewhacker@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@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@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[prev in list] [next in list] [prev in thread] [next in thread]