Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7
From:
Marcus Müller
Subject:
Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7
Date:
Fri, 3 Jun 2016 16:19:20 +0200
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
Everyone should get a kick out of this: I
had fixed this once before [1] but it was actually YOU, Marcus,
that broke it again! [2]
I wish that was true! First of all, we need to find a better way to
fix that then to build libtool on practically all platforms from
source.
You really don't need libtool > 2.4.6 to build thrift. Works
perfectly on my Fedora 22 with libtool 2.4.2 .
The problem is not the libtool version, by the way. autoconf/aclocal
just can't, for some reasons I really can't figure out, find the
"default" system-wide M4 files containing the PKG_CHECK_MODULES
macro under specific circumstances. It seems that installing libtool
into the same prefix one is going to use later on fixes the problem
(as the M4s end up in a location that aclocal ends up looking in).
Have a test: if you edit the bootstrap.sh of thrift, and modify the
the M4 syntax error disappears, at least for me. Of course, thrift
wouldn't successfully build with those modifications, either, but
that's really a long rabbit hole to go into :) Hence my curiosity!
I spent several hours on trying to make thrift build, again, when
running pybombs on a Centos7 minimal install that had nothing but
python2.7, pip and git manually installed. That's why I asked you! I
really never intended to mess with your progress; however, when I
found out the libtool version is not really to blame, I made a PR to
scale down that 2.6.4 requirement (since it didn't fix building in
the end).
Best regards,
Marcus
On 03.06.2016 15:46, Eric Statzer
wrote:
Hmm, nope thrift is not building successfully. I
guess the failure was masked since thrift is an "optional"
package. I get the error:
./configure: line 17775: syntax error near
unexpected token `QT,'
which is actually an issue with the version of
pkg-config on CentOS 7:
$ pkg-config --version
0.27.1
Everyone should get a kick out of this: I had fixed
this once before [1] but it was actually YOU, Marcus, that
broke it again! [2]
I'll revisit the pkg-config version issue again. I
think it was just the libtool version of commit 489762b
that was causing heartburn (with Ubuntu 14.04, if I
recall). I agree that the version requirement of libtool
was probably over-specced, but it looks like we still need
pkg-config >= 2.8.
A change like this will probably require regression
testing on the major distros, do we want to wade in to the
dangerous waters of identifying what those distros are? I
guess I'm willing to set up docker images (like [3], which
I need to update to install as a non-root user) to test
Ubuntu 16.04/14.04 and CentOS 7. If there are other
distros we want to hit we might need another volunteer.
On Fri, Jun 3, 2016 at 9:09 AM Marcus Müller <address@hidden>
wrote:
Hi Eric,
out of curiosity, since I can't do that on my clean CentOS 7
machines: have you managed to get thrift to build on a clean
installation?
Best regards,
Marcus
On 03.06.2016 14:40, Eric Statzer wrote:
In
continuation of Martin's thread from last month
[1], this is an update on testing of the "pybombs
prefix init ~/path/to/prefix -R gnuradio-default" on a CentOS 7 host.
I submitted a pull
request [2] to address an issue with building
pyqwt5 on CentOS 7. I haven't tested the change
in my Docker farm yet, but I wanted to get the
change out there to prompt discussion. At this
point, I'm not sure if any other common distros
(Ubuntu 14.04?) build pyqwt5 from source, but I'm
willing to add some more Docker containers to my
Docker farm to do some regression testing on this
if someone can confirm that this change is not
limited to CentOS 7***.
I ran in to one
other issue a couple weeks ago with building
libosmo-dsp on CentOS 7. The issue was related to
trying to use a non-system version of automake to
run autoreconf with the "-i" flag, but I'm unable
to reproduce the issue now (go figure), so I need
to do some more poking around.
Thanks,
Eric
*** On a side note,
CentOS 7 is now available to me as a viable
option, so I'm done fighting with CentOS 6.