Closed barjac closed 6 years ago
Considering the amount of error: ‘class Glib::RefPtr<Glib::Object>’ has no member named ‘get’
my guess is that something is missing in your gtkmm or glibmm package. Or maybe they do not have missing files but need a newer compiler to enable some features. Our meson output shows the same libraries versions so outdated packages should not be the problem:
The Meson build system
Version: 0.46.1
Source dir: /home/wallace/myfiles/code/pulseeffects
Build dir: /home/wallace/myfiles/code/pulseeffects/_build
Build type: native build
Project name: pulseeffects
Native C compiler: cc (gcc 8.1.1 "cc (GCC) 8.1.1 20180531")
Native C++ compiler: c++ (gcc 8.1.1 "c++ (GCC) 8.1.1 20180531")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.4.2)
Native dependency glib-2.0 found: YES 2.56.1
Configuring pulseeffects.cpp using configuration
Native dependency libpulse found: YES 11.1
Native dependency glib-2.0 found: YES 2.56.1
Native dependency glibmm-2.4 found: YES 2.56.0
Native dependency gtk+-3.0 found: YES 3.22.30
Native dependency gtkmm-3.0 found: YES 3.22.2
Native dependency gstreamer-1.0 found: YES 1.14.1
Native dependency gstreamer-plugins-bad-1.0 found: YES 1.14.1
Native dependency gstreamer-webrtc-1.0 found: YES 1.14.1
Native dependency lilv-0 found: YES 0.24.2
Native dependency libbs2b found: YES 3.1.0
Dependency Boost (system, filesystem) found: YES 1.66
Program meson_post_install.py found: YES (/usr/bin/env python3 /home/wallace/myfiles/code/pulseeffects/meson_post_install.py)
Build targets in project: 8
Found ninja-1.8.2 at /usr/bin/ninja
In any case this error message points directly to missing member functions in the gtkmm or glibmm(probably this one) libraries. So that is were the investigation has to focus
I did not pay attention to your glibmm version. It is 2.52.1
while I have 2.56.1
. If this is the problem I will have to increase the required version of this library
I took a look at glibmm documentation and the get method was implemented in version 2.56
.
Thanks for investigationg. I will look at updating our glibmm package.
We do already have lib64glibmm2.56-devel, but after changing the BuildRequire some other BR is still pulling in lib64glibmm2.4-devel with it, which is being used by the PE build. After patching src/meson.build to require 2.56 the 'get' errors are gone, but we now have another issue: http://mtf.duckdns.org/pub/linux/barjac/distrib/cauldron/x86_64/log/pulseeffects-4.0.1-1.mga7.src.rpm/build.0.20180608115633.log
Now the problem is with libsigc++
. By the way I totally forgot to add it to the dependency list. One more change I will have to make when I release 4.0.2
. On Arch Linux repositories we have version 2.10.0
. But based on your log it seems your system has version 3.0
. There are lots of lines with /usr/include/sigc++-3.0
. It seems that there isn't a stable 3.0
release yet https://download.gnome.org/sources/libsigc++/. And maybe it can only be used with gtkmm when gtk4 is released. Take a look at this post from 2016 https://www.murrayc.com/permalink/2016/03/07/libsigc-3-0-very-variadic/. I don't know if the status has changed since then.
Could you try to add this line dependency('sigc++-2.0', version: '>=2.10')
to the meson.build
file at the src
folder? Maybe it will be necessary to restrain the maximum version too dependency('sigc++-2.0', version: ['>=2.10', '<3.0'])
With this patch things don't seem to change much
> diff -ur pulseeffects-4.0.1/src/meson.build pulseeffects-4.0.1n/src/meson.build
> --- pulseeffects-4.0.1/src/meson.build 2018-06-05 02:37:58.000000000 +0100
> +++ pulseeffects-4.0.1n/src/meson.build 2018-06-08 17:15:30.753314193 +0100
> @@ -82,9 +82,10 @@
> pulseeffects_deps = [
> dependency('libpulse'),
> dependency('glib-2.0'),
> - dependency('glibmm-2.4'),
> + dependency('glibmm-2.56'),
> dependency('gtk+-3.0', version: '>= 3.20'),
> dependency('gtkmm-3.0',version: '>= 3.20'),
> + dependency('sigc++-2.0', version: ['>=2.10', '<3.0']),
> dependency('gstreamer-1.0', version: '>= 1.12.5'),
> dependency('gstreamer-plugins-bad-1.0', version: '>= 1.12.5'),
> dependency('gstreamer-webrtc-1.0', required: false),
=============================
Our current build requires are as follows: BuildRequires: boost-devel BuildRequires: desktop-file-utils BuildRequires: libxml2-utils BuildRequires: meson BuildRequires: pkgconfig(fftw3) BuildRequires: pkgconfig(gtk+-3.0) BuildRequires: pkgconfig(gtkmm-3.0) BuildRequires: pkgconfig(glibmm-2.56) BuildRequires: pkgconfig(gstreamer-1.0) >= 1.12 BuildRequires: pkgconfig(gstreamer-plugins-bad-1.0) >= 1.12 BuildRequires: pkgconfig(libbs2b) BuildRequires: pkgconfig(libpulse) >= 11.0 BuildRequires: pkgconfig(lilv-0) BuildRequires: pkgconfig(py3cairo) BuildRequires: pkgconfig(python3) BuildRequires: pkgconfig(pygobject-3.0) BuildRequires: pkgconfig(sigc++-2.0) BuildRequires: python3-numpy-devel >= 1.13 BuildRequires: python3-scipy >= 1.0
Maybe something in there may be causing a problem.
The last log is here: http://mtf.duckdns.org/pub/linux/barjac/distrib/cauldron/x86_64/log/pulseeffects-4.0.1-1.mga7.src.rpm/build.0.20180608172134.log
I read the link you commented on but I'm afraid it went over my head.
All the installed package versions in the build chroot are listed here if they may help. http://mtf.duckdns.org/pub/linux/barjac/distrib/cauldron/x86_64/log/pulseeffects-4.0.1-1.mga7.src.rpm/rpm_qa.0.20180608172134.log
Current log still shows the compiler using /usr/include/sigc++-3.0
as the path for sigc++ instead of /usr/include/sigc++-2.0
as it happens to me here in Arch. Your packages list shows you have:
lib64sigc++3.0-devel-2.99.11-1.mga7
lib64sigc++3.0_0-2.99.11-1.mga7
installed. The question now is how to tell meson to not use the headers of these packages. It has to use the sigc++ from the packages:
lib64sigc++2.0-devel-2.10.0-1.mga6
lib64sigc++2.0_0-2.10.0-1.mga6
What is the output of the command pkg-config --list-all | grep -i sigc
in your machine?
What is odd is that meson is making use of the version restriction in the patch:
Native dependency sigc++-2.0 found: YES 2.10.0
I don't understand why at the compilation time it is using the headers from 3.0
. It does not make sense
In your log there is also -I/usr/include/sigc++-3.0
as argument of gcc as well as -I/usr/include/sigc++-2.0
. This is definitely not right. It should not mix both.
What is on my machine is not relevant as each build is done in a clean chroot with a minimal base system and BuildRequires. I can access the chroot and check later. I agree it should not mix both and would think that both should not be there. I can't as yet figure out what is pulling in the 'other' versions.
Are you able to run the command pkg-config --list-all | grep -i sigc
in this chroot? I am suspecting that the 2.99
version may be identifying itself as being 2.0
and confusing meson in the process.
It could also help to see the contents of the files /usr/lib/pkgconfig/sigc++-2.0.pc
and /usr/lib/pkgconfig/sigc++-3.0.pc
Content of sigc++-2.0.pc: prefix=/usr exec_prefix=/usr libdir=/usr/lib64 datarootdir=${prefix}/share datadir=/usr/share includedir=/usr/include
docdir=${datarootdir}/doc/libsigc++-2.0 doxytagfile=${docdir}/reference/libsigc++-2.0.tag htmlrefdir=${docdir}/reference/html htmlrefpub=http://library.gnome.org/devel/libsigc++/unstable/
Name: libsigc++ Description: Typesafe signal and callback system for C++ Version: 2.10.0 URL: http://libsigc.sourceforge.net/ Libs: -L${libdir} -lsigc-2.0 Cflags: -I${includedir}/sigc++-2.0 -I${libdir}/sigc++-2.0/include
Content of sigc++-3.0.pc: prefix=/usr exec_prefix=/usr libdir=/usr/lib64 datarootdir=${prefix}/share datadir=/usr/share includedir=/usr/include
docdir=${datarootdir}/doc/libsigc++-3.0 doxytagfile=${docdir}/reference/libsigc++-3.0.tag htmlrefdir=${docdir}/reference/html htmlrefpub=http://library.gnome.org/devel/libsigc++/unstable/
Name: libsigc++ Description: Typesafe signal and callback system for C++ Version: 2.99.11 URL: http://libsigc.sourceforge.net/ Libs: -L${libdir} -lsigc-3.0 Cflags: -I${includedir}/sigc++-3.0 -I${libdir}/sigc++-3.0/include
As requsted from chroot:
[iurt cauldron] bazlocalhost~$ pkg-config --list-all | grep -i sigc
sigc++-2.0 libsigc++ - Typesafe signal and callback system for C++
sigc++-3.0 libsigc++ - Typesafe signal and callback system for C++
[iurt cauldron] bazlocalhost~$
your sigc++3 is seen as 2.99.11
. It is reasonable considering that version 3.0
was not officially released by the sigc++ developers yet. Try to patch the meson.build with dependency('sigc++-2.0', version: ['>=2.10', '<2.9'])
. Let's see if with this restriction meson removes the path to sigc++3 headers from gcc options
If this does not work I think that the only option will be to remove sigc++3
OK it's all sorted now. Our glibmm maintainer has pushed a new glibmm2.4-2.56 and this has untangled the mix-up. PE now builds without any meson.build patching. There appears to be an equalizer gui issue (frequency starts low on left and increases to 16.3kHz, then drops to 714Hz and starts increasing again with values which should be interspersed between the earlier ones) however I will open a new issue for this with screen shot. Many thanks for your help as always.
Try to reset PE settings or at least the equalizer settings using the same menu where you can change the number of bands
Ah OK - never used that before - thanks :)
I am attempting to update our (Mageia) package and hitting build errors. Would appreciate some help ;) Full build log is here: http://mtf.duckdns.org/pub/linux/barjac/distrib/cauldron/x86_64/log/pulseeffects-4.0.1-1.mga7.src.rpm/build.0.20180607221936.log Thanks, Barry