* [PATCH] libmodulemd: fix erroneous linking against v2 library when v1 was requested
@ 2019-05-21 16:11 Alexander Kanavin
2019-05-22 2:04 ` Khem Raj
0 siblings, 1 reply; 6+ messages in thread
From: Alexander Kanavin @ 2019-05-21 16:11 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
...xplicitly-specify-the-v1-library-in-.patch | 28 +++++++++++++++++++
.../libmodulemd/libmodulemd_git.bb | 1 +
2 files changed, 29 insertions(+)
create mode 100644 meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
diff --git a/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch b/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
new file mode 100644
index 00000000000..1568d25f9d8
--- /dev/null
+++ b/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
@@ -0,0 +1,28 @@
+From b651551134cf170038b3e01812e3767969506491 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin <alex.kanavin@gmail.com>
+Date: Tue, 21 May 2019 17:59:26 +0200
+Subject: [PATCH] v1/meson.build: explicitly specify the v1 library in
+ pkgconfig
+
+Otherwise there would be '-lmodulemd' which resolves
+to v2 version if both v2 and v1 are present in the sysroot.
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
+---
+ modulemd/v1/meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/modulemd/v1/meson.build b/modulemd/v1/meson.build
+index 4d54e69..9144ca2 100644
+--- a/modulemd/v1/meson.build
++++ b/modulemd/v1/meson.build
+@@ -325,7 +325,7 @@ configure_file(
+ )
+
+ pkg.generate(
+- libraries : modulemd_v1_lib,
++ libraries : '-l:libmodulemd.so.1',
+ subdirs : v1_header_path,
+ version : libmodulemd_v1_version,
+ name : 'modulemd',
diff --git a/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb b/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
index d7f486868b8..d4ffd281b5f 100644
--- a/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
+++ b/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
@@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=25a3927bff3ee4f5b21bcb0ed3fcd6bb"
SRC_URI = "git://github.com/fedora-modularity/libmodulemd;protocol=https \
file://0001-spec_tmpl.sh-use-bin-sh-not-usr-bin-sh.patch \
file://0002-modulemd-v1-meson.build-do-not-generate-gir-or-gtkdo.patch \
+ file://0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch \
"
PV = "2.4.0"
--
2.17.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] libmodulemd: fix erroneous linking against v2 library when v1 was requested
2019-05-21 16:11 [PATCH] libmodulemd: fix erroneous linking against v2 library when v1 was requested Alexander Kanavin
@ 2019-05-22 2:04 ` Khem Raj
2019-05-22 10:28 ` Alexander Kanavin
0 siblings, 1 reply; 6+ messages in thread
From: Khem Raj @ 2019-05-22 2:04 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: Patches and discussions about the oe-core layer
On Tue, May 21, 2019 at 9:12 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> ---
> ...xplicitly-specify-the-v1-library-in-.patch | 28 +++++++++++++++++++
> .../libmodulemd/libmodulemd_git.bb | 1 +
> 2 files changed, 29 insertions(+)
> create mode 100644 meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
>
> diff --git a/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch b/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
> new file mode 100644
> index 00000000000..1568d25f9d8
> --- /dev/null
> +++ b/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
> @@ -0,0 +1,28 @@
> +From b651551134cf170038b3e01812e3767969506491 Mon Sep 17 00:00:00 2001
> +From: Alexander Kanavin <alex.kanavin@gmail.com>
> +Date: Tue, 21 May 2019 17:59:26 +0200
> +Subject: [PATCH] v1/meson.build: explicitly specify the v1 library in
> + pkgconfig
> +
> +Otherwise there would be '-lmodulemd' which resolves
> +to v2 version if both v2 and v1 are present in the sysroot.
> +
> +Upstream-Status: Pending
> +Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> +---
> + modulemd/v1/meson.build | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/modulemd/v1/meson.build b/modulemd/v1/meson.build
> +index 4d54e69..9144ca2 100644
> +--- a/modulemd/v1/meson.build
> ++++ b/modulemd/v1/meson.build
> +@@ -325,7 +325,7 @@ configure_file(
> + )
> +
> + pkg.generate(
> +- libraries : modulemd_v1_lib,
> ++ libraries : '-l:libmodulemd.so.1',
shouldn't it be generating a separate package for v1 ?
hardcoding linker paths seems a bit hackish here, is it going
to generate a .pc file with .so.1 version ?
> + subdirs : v1_header_path,
> + version : libmodulemd_v1_version,
> + name : 'modulemd',
> diff --git a/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb b/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
> index d7f486868b8..d4ffd281b5f 100644
> --- a/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
> +++ b/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
> @@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=25a3927bff3ee4f5b21bcb0ed3fcd6bb"
> SRC_URI = "git://github.com/fedora-modularity/libmodulemd;protocol=https \
> file://0001-spec_tmpl.sh-use-bin-sh-not-usr-bin-sh.patch \
> file://0002-modulemd-v1-meson.build-do-not-generate-gir-or-gtkdo.patch \
> + file://0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch \
> "
>
> PV = "2.4.0"
> --
> 2.17.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libmodulemd: fix erroneous linking against v2 library when v1 was requested
2019-05-22 2:04 ` Khem Raj
@ 2019-05-22 10:28 ` Alexander Kanavin
2019-05-22 11:08 ` Richard Purdie
0 siblings, 1 reply; 6+ messages in thread
From: Alexander Kanavin @ 2019-05-22 10:28 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
On Wed, 22 May 2019 at 04:04, Khem Raj <raj.khem@gmail.com> wrote:
> > +
> > + pkg.generate(
> > +- libraries : modulemd_v1_lib,
> > ++ libraries : '-l:libmodulemd.so.1',
>
> shouldn't it be generating a separate package for v1 ?
> hardcoding linker paths seems a bit hackish here, is it going
> to generate a .pc file with .so.1 version ?
The problem is that both v2 and v1 are installed into the sysroot; we
don't have a mechanism to choose one or the other via DEPENDS (unlike
desktop distros where you can install -v1-dev or -v2-dev package for
your build).
Then both v2 and v1 .pc files (without this patch) refer to
'-lmodulemd' which in our case always resolves to v2 library.
Wth the patch the generated v1 .pc will look like this, while v2
continues to use the original '-lmodlulemd' in Libs:
prefix=${pcfiledir}/../../../usr
libdir=${prefix}/lib
includedir=${prefix}/include
Name: modulemd
Description: Module metadata manipulation library
Version: 1.8.10
Requires: glib-2.0, gobject-2.0
Libs: -l:libmodulemd.so.1
Cflags: -I${includedir}/modulemd
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libmodulemd: fix erroneous linking against v2 library when v1 was requested
2019-05-22 10:28 ` Alexander Kanavin
@ 2019-05-22 11:08 ` Richard Purdie
2019-05-22 11:20 ` Alexander Kanavin
0 siblings, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2019-05-22 11:08 UTC (permalink / raw)
To: Alexander Kanavin, Khem Raj
Cc: Patches and discussions about the oe-core layer
On Wed, 2019-05-22 at 12:28 +0200, Alexander Kanavin wrote:
> On Wed, 22 May 2019 at 04:04, Khem Raj <raj.khem@gmail.com> wrote:
> > > +
> > > + pkg.generate(
> > > +- libraries : modulemd_v1_lib,
> > > ++ libraries : '-l:libmodulemd.so.1',
> >
> > shouldn't it be generating a separate package for v1 ?
> > hardcoding linker paths seems a bit hackish here, is it going
> > to generate a .pc file with .so.1 version ?
>
> The problem is that both v2 and v1 are installed into the sysroot; we
> don't have a mechanism to choose one or the other via DEPENDS (unlike
> desktop distros where you can install -v1-dev or -v2-dev package for
> your build).
> Then both v2 and v1 .pc files (without this patch) refer to
> '-lmodulemd' which in our case always resolves to v2 library.
>
> Wth the patch the generated v1 .pc will look like this, while v2
> continues to use the original '-lmodlulemd' in Libs:
>
> prefix=${pcfiledir}/../../../usr
> libdir=${prefix}/lib
> includedir=${prefix}/include
>
> Name: modulemd
> Description: Module metadata manipulation library
> Version: 1.8.10
> Requires: glib-2.0, gobject-2.0
> Libs: -l:libmodulemd.so.1
> Cflags: -I${includedir}/modulemd
FWIW I think if there were two different recipes we could select which
was in the sysroot through DEPENDS?
Cheers,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libmodulemd: fix erroneous linking against v2 library when v1 was requested
2019-05-22 11:08 ` Richard Purdie
@ 2019-05-22 11:20 ` Alexander Kanavin
2019-05-22 13:48 ` Khem Raj
0 siblings, 1 reply; 6+ messages in thread
From: Alexander Kanavin @ 2019-05-22 11:20 UTC (permalink / raw)
To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer
I'm not sure that would work, as at do_rootfs time both createrepo_c
(v2 user) and libdnf (v1 user) need to be present in the
sysroot-native, and so v1 and v2 files would clash at that point
(libmodulemd.so would be provided by both).
I am kind of hoping that libdnf would migrate off v1 to v2, and we
could then simply disable v1 altogether. So far it hasn't happened,
and libdnf update is now also blocked by the c++ code that older
compilers don't like, so I'd leave thing as they are for now.
Alex
On Wed, 22 May 2019 at 13:08, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Wed, 2019-05-22 at 12:28 +0200, Alexander Kanavin wrote:
> > On Wed, 22 May 2019 at 04:04, Khem Raj <raj.khem@gmail.com> wrote:
> > > > +
> > > > + pkg.generate(
> > > > +- libraries : modulemd_v1_lib,
> > > > ++ libraries : '-l:libmodulemd.so.1',
> > >
> > > shouldn't it be generating a separate package for v1 ?
> > > hardcoding linker paths seems a bit hackish here, is it going
> > > to generate a .pc file with .so.1 version ?
> >
> > The problem is that both v2 and v1 are installed into the sysroot; we
> > don't have a mechanism to choose one or the other via DEPENDS (unlike
> > desktop distros where you can install -v1-dev or -v2-dev package for
> > your build).
> > Then both v2 and v1 .pc files (without this patch) refer to
> > '-lmodulemd' which in our case always resolves to v2 library.
> >
> > Wth the patch the generated v1 .pc will look like this, while v2
> > continues to use the original '-lmodlulemd' in Libs:
> >
> > prefix=${pcfiledir}/../../../usr
> > libdir=${prefix}/lib
> > includedir=${prefix}/include
> >
> > Name: modulemd
> > Description: Module metadata manipulation library
> > Version: 1.8.10
> > Requires: glib-2.0, gobject-2.0
> > Libs: -l:libmodulemd.so.1
> > Cflags: -I${includedir}/modulemd
>
> FWIW I think if there were two different recipes we could select which
> was in the sysroot through DEPENDS?
>
> Cheers,
>
> Richard
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libmodulemd: fix erroneous linking against v2 library when v1 was requested
2019-05-22 11:20 ` Alexander Kanavin
@ 2019-05-22 13:48 ` Khem Raj
0 siblings, 0 replies; 6+ messages in thread
From: Khem Raj @ 2019-05-22 13:48 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]
On Wed, May 22, 2019 at 4:21 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:
> I'm not sure that would work, as at do_rootfs time both createrepo_c
> (v2 user) and libdnf (v1 user) need to be present in the
> sysroot-native, and so v1 and v2 files would clash at that point
> (libmodulemd.so would be provided by both).
>
> I am kind of hoping that libdnf would migrate off v1 to v2, and we
> could then simply disable v1 altogether. So far it hasn't happened,
> and libdnf update is now also blocked by the c++ code that older
> compilers don't like, so I'd leave thing as they are for now.
>
>
conflicts will happen only when dev packages
are bundled into image.
we probably need something like libusb for this case and then remove the
compat package when its
no longer needed.
> Alex
>
> On Wed, 22 May 2019 at 13:08, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > On Wed, 2019-05-22 at 12:28 +0200, Alexander Kanavin wrote:
> > > On Wed, 22 May 2019 at 04:04, Khem Raj <raj.khem@gmail.com> wrote:
> > > > > +
> > > > > + pkg.generate(
> > > > > +- libraries : modulemd_v1_lib,
> > > > > ++ libraries : '-l:libmodulemd.so.1',
> > > >
> > > > shouldn't it be generating a separate package for v1 ?
> > > > hardcoding linker paths seems a bit hackish here, is it going
> > > > to generate a .pc file with .so.1 version ?
> > >
> > > The problem is that both v2 and v1 are installed into the sysroot; we
> > > don't have a mechanism to choose one or the other via DEPENDS (unlike
> > > desktop distros where you can install -v1-dev or -v2-dev package for
> > > your build).
> > > Then both v2 and v1 .pc files (without this patch) refer to
> > > '-lmodulemd' which in our case always resolves to v2 library.
> > >
> > > Wth the patch the generated v1 .pc will look like this, while v2
> > > continues to use the original '-lmodlulemd' in Libs:
> > >
> > > prefix=${pcfiledir}/../../../usr
> > > libdir=${prefix}/lib
> > > includedir=${prefix}/include
> > >
> > > Name: modulemd
> > > Description: Module metadata manipulation library
> > > Version: 1.8.10
> > > Requires: glib-2.0, gobject-2.0
> > > Libs: -l:libmodulemd.so.1
> > > Cflags: -I${includedir}/modulemd
> >
> > FWIW I think if there were two different recipes we could select which
> > was in the sysroot through DEPENDS?
> >
> > Cheers,
> >
> > Richard
> >
>
[-- Attachment #2: Type: text/html, Size: 3795 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-05-22 13:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-21 16:11 [PATCH] libmodulemd: fix erroneous linking against v2 library when v1 was requested Alexander Kanavin
2019-05-22 2:04 ` Khem Raj
2019-05-22 10:28 ` Alexander Kanavin
2019-05-22 11:08 ` Richard Purdie
2019-05-22 11:20 ` Alexander Kanavin
2019-05-22 13:48 ` Khem Raj
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.