[PATCH] libxcrypt: fix hard-coded ".so" extension

[PATCH] libxcrypt: fix hard-coded ".so" extension

[Etienne Cordonnier]

From: Etienne Cordonnier <ecordonnier@snap.com>

2 issues:
- the .so extension is hard-coded, and therefore the libxcryt package compiled with
  meta-darwin is empty, because the dylib files are not contained in FILES_${PN}
- nothing actually produces a file libcrypt-*.so (the symlink file is libcrypt.so, without dash), thus
  defining FILES:${PN} manually to contain libcrypt-*.so has no effect.

Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
---
 meta/recipes-core/libxcrypt/libxcrypt.inc | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/meta/recipes-core/libxcrypt/libxcrypt.inc b/meta/recipes-core/libxcrypt/libxcrypt.inc
index 61b0381076..454a55d73d 100644
--- a/meta/recipes-core/libxcrypt/libxcrypt.inc
+++ b/meta/recipes-core/libxcrypt/libxcrypt.inc
@@ -17,12 +17,6 @@ SRC_URI += "file://fix_cflags_handling.patch"
 
 PROVIDES = "virtual/crypt"
 
-FILES:${PN} = "${libdir}/libcrypt*.so.* \
-               ${libdir}/libcrypt-*.so \
-               ${libdir}/libowcrypt*.so.* \
-               ${libdir}/libowcrypt-*.so \
-"
-
 S = "${WORKDIR}/git"
 
 BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE}"
-- 
2.36.1.vfs.0.0

Re: [PATCH] libxcrypt: fix hard-coded ".so" extension

[Etienne Cordonnier]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

Hello,
is everything OK with the patch? Is there anything blocking a merge?

On Fri, May 26, 2023 at 1:52 PM <ecordonnier@snap.com> wrote:

> From: Etienne Cordonnier <ecordonnier@snap.com>
>
> 2 issues:
> - the .so extension is hard-coded, and therefore the libxcryt package
> compiled with
>   meta-darwin is empty, because the dylib files are not contained in
> FILES_${PN}
> - nothing actually produces a file libcrypt-*.so (the symlink file is
> libcrypt.so, without dash), thus
>   defining FILES:${PN} manually to contain libcrypt-*.so has no effect.
>
> Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
> ---
>  meta/recipes-core/libxcrypt/libxcrypt.inc | 6 ------
>  1 file changed, 6 deletions(-)
>
> diff --git a/meta/recipes-core/libxcrypt/libxcrypt.inc
> b/meta/recipes-core/libxcrypt/libxcrypt.inc
> index 61b0381076..454a55d73d 100644
> --- a/meta/recipes-core/libxcrypt/libxcrypt.inc
> +++ b/meta/recipes-core/libxcrypt/libxcrypt.inc
> @@ -17,12 +17,6 @@ SRC_URI += "file://fix_cflags_handling.patch"
>
>  PROVIDES = "virtual/crypt"
>
> -FILES:${PN} = "${libdir}/libcrypt*.so.* \
> -               ${libdir}/libcrypt-*.so \
> -               ${libdir}/libowcrypt*.so.* \
> -               ${libdir}/libowcrypt-*.so \
> -"
> -
>  S = "${WORKDIR}/git"
>
>  BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE}"
> --
> 2.36.1.vfs.0.0
>
>

[-- Attachment #2: Type: text/html, Size: 1942 bytes --]

Re: [OE-core] [PATCH] libxcrypt: fix hard-coded ".so" extension

[Ross Burton]

Probably just fell through a crack, I’ve queued it locally for testing.

Sorry about that!

Ross

> On 9 Jun 2023, at 10:37, Etienne Cordonnier via lists.openembedded.org <ecordonnier=snap.com@lists.openembedded.org> wrote:
> 
> Hello,
> is everything OK with the patch? Is there anything blocking a merge?
> 
> On Fri, May 26, 2023 at 1:52 PM <ecordonnier@snap.com> wrote:
> From: Etienne Cordonnier <ecordonnier@snap.com>
> 
> 2 issues:
> - the .so extension is hard-coded, and therefore the libxcryt package compiled with
>   meta-darwin is empty, because the dylib files are not contained in FILES_${PN}
> - nothing actually produces a file libcrypt-*.so (the symlink file is libcrypt.so, without dash), thus
>   defining FILES:${PN} manually to contain libcrypt-*.so has no effect.
> 
> Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
> ---
>  meta/recipes-core/libxcrypt/libxcrypt.inc | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/meta/recipes-core/libxcrypt/libxcrypt.inc b/meta/recipes-core/libxcrypt/libxcrypt.inc
> index 61b0381076..454a55d73d 100644
> --- a/meta/recipes-core/libxcrypt/libxcrypt.inc
> +++ b/meta/recipes-core/libxcrypt/libxcrypt.inc
> @@ -17,12 +17,6 @@ SRC_URI += "file://fix_cflags_handling.patch"
> 
>  PROVIDES = "virtual/crypt"
> 
> -FILES:${PN} = "${libdir}/libcrypt*.so.* \
> -               ${libdir}/libcrypt-*.so \
> -               ${libdir}/libowcrypt*.so.* \
> -               ${libdir}/libowcrypt-*.so \
> -"
> -
>  S = "${WORKDIR}/git"
> 
>  BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE}"
> -- 
> 2.36.1.vfs.0.0
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#182558): https://lists.openembedded.org/g/openembedded-core/message/182558
> Mute This Topic: https://lists.openembedded.org/mt/99149665/6875888
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ross.burton@arm.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [OE-core] [PATCH] libxcrypt: fix hard-coded ".so" extension

[Alexandre Belloni]

On 09/06/2023 15:19:12+0000, Ross Burton wrote:
> Probably just fell through a crack, I’ve queued it locally for testing.
> 

It didn't apply cleanly on my master-next and I was waiting for things
to calm down to get back to it.

> Sorry about that!
> 
> Ross
> 
> > On 9 Jun 2023, at 10:37, Etienne Cordonnier via lists.openembedded.org <ecordonnier=snap.com@lists.openembedded.org> wrote:
> > 
> > Hello,
> > is everything OK with the patch? Is there anything blocking a merge?
> > 
> > On Fri, May 26, 2023 at 1:52 PM <ecordonnier@snap.com> wrote:
> > From: Etienne Cordonnier <ecordonnier@snap.com>
> > 
> > 2 issues:
> > - the .so extension is hard-coded, and therefore the libxcryt package compiled with
> >   meta-darwin is empty, because the dylib files are not contained in FILES_${PN}
> > - nothing actually produces a file libcrypt-*.so (the symlink file is libcrypt.so, without dash), thus
> >   defining FILES:${PN} manually to contain libcrypt-*.so has no effect.
> > 
> > Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
> > ---
> >  meta/recipes-core/libxcrypt/libxcrypt.inc | 6 ------
> >  1 file changed, 6 deletions(-)
> > 
> > diff --git a/meta/recipes-core/libxcrypt/libxcrypt.inc b/meta/recipes-core/libxcrypt/libxcrypt.inc
> > index 61b0381076..454a55d73d 100644
> > --- a/meta/recipes-core/libxcrypt/libxcrypt.inc
> > +++ b/meta/recipes-core/libxcrypt/libxcrypt.inc
> > @@ -17,12 +17,6 @@ SRC_URI += "file://fix_cflags_handling.patch"
> > 
> >  PROVIDES = "virtual/crypt"
> > 
> > -FILES:${PN} = "${libdir}/libcrypt*.so.* \
> > -               ${libdir}/libcrypt-*.so \
> > -               ${libdir}/libowcrypt*.so.* \
> > -               ${libdir}/libowcrypt-*.so \
> > -"
> > -
> >  S = "${WORKDIR}/git"
> > 
> >  BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE}"
> > -- 
> > 2.36.1.vfs.0.0
> > 
> > 
> > 
> > 
> 

> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#182559): https://lists.openembedded.org/g/openembedded-core/message/182559
> Mute This Topic: https://lists.openembedded.org/mt/99149665/3617179
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alexandre.belloni@bootlin.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH] libxcrypt: fix hard-coded ".so" extension

[Etienne Cordonnier]

[-- Attachment #1: Type: text/plain, Size: 3110 bytes --]

> It didn't apply cleanly on my master-next and I was waiting for things
> to calm down to get back to it.

OK, thanks for the update. Don't hesitate to let me know in case I should
rebase the patch to avoid a git conflict. It seems to work on the latest
master-next. The files in libxcrypt and libxcrypt-dev are the same before
and after the patch:

$ oe-pkgdata-util list-pkg-files libxcrypt
libxcrypt:
/usr/lib/libcrypt.so.2
/usr/lib/libcrypt.so.2.0.0

libxcrypt-dev:
/usr/include/crypt.h
/usr/lib/libcrypt.so
/usr/lib/pkgconfig/libcrypt.pc
/usr/lib/pkgconfig/libxcrypt.pc


On Fri, Jun 9, 2023 at 5:50 PM Alexandre Belloni <
alexandre.belloni@bootlin.com> wrote:

> On 09/06/2023 15:19:12+0000, Ross Burton wrote:
> > Probably just fell through a crack, I’ve queued it locally for testing.
> >
>
> It didn't apply cleanly on my master-next and I was waiting for things
> to calm down to get back to it.
>
> > Sorry about that!
> >
> > Ross
> >
> > > On 9 Jun 2023, at 10:37, Etienne Cordonnier via lists.openembedded.org
> <ecordonnier=snap.com@lists.openembedded.org> wrote:
> > >
> > > Hello,
> > > is everything OK with the patch? Is there anything blocking a merge?
> > >
> > > On Fri, May 26, 2023 at 1:52 PM <ecordonnier@snap.com> wrote:
> > > From: Etienne Cordonnier <ecordonnier@snap.com>
> > >
> > > 2 issues:
> > > - the .so extension is hard-coded, and therefore the libxcryt package
> compiled with
> > >   meta-darwin is empty, because the dylib files are not contained in
> FILES_${PN}
> > > - nothing actually produces a file libcrypt-*.so (the symlink file is
> libcrypt.so, without dash), thus
> > >   defining FILES:${PN} manually to contain libcrypt-*.so has no effect.
> > >
> > > Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
> > > ---
> > >  meta/recipes-core/libxcrypt/libxcrypt.inc | 6 ------
> > >  1 file changed, 6 deletions(-)
> > >
> > > diff --git a/meta/recipes-core/libxcrypt/libxcrypt.inc
> b/meta/recipes-core/libxcrypt/libxcrypt.inc
> > > index 61b0381076..454a55d73d 100644
> > > --- a/meta/recipes-core/libxcrypt/libxcrypt.inc
> > > +++ b/meta/recipes-core/libxcrypt/libxcrypt.inc
> > > @@ -17,12 +17,6 @@ SRC_URI += "file://fix_cflags_handling.patch"
> > >
> > >  PROVIDES = "virtual/crypt"
> > >
> > > -FILES:${PN} = "${libdir}/libcrypt*.so.* \
> > > -               ${libdir}/libcrypt-*.so \
> > > -               ${libdir}/libowcrypt*.so.* \
> > > -               ${libdir}/libowcrypt-*.so \
> > > -"
> > > -
> > >  S = "${WORKDIR}/git"
> > >
> > >  BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE}"
> > > --
> > > 2.36.1.vfs.0.0
> > >
> > >
> > >
> > >
> >
>
> >
> > 
> >
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bootlin.com&d=DwIDaQ&c=ncDTmphkJTvjIDPh0hpF_4vCHvabgGkICC2epckfdiw&r=AhkbNonVuMIGRfPx_Qj9TsRih1DULJTKUkSGa66m67E&m=12f3CsTplzLkTcoMijzp0ABurdB9V1l2zSzRlTZfbJX-s-QgWApUHSds7cLJYJfD&s=qgbUtzi4aOcTJaUzK5IgGCUAlilJwvwSsSgKsBLvADI&e=
>

[-- Attachment #2: Type: text/html, Size: 4667 bytes --]