New build structure! (Warning #2)

GNU Radio
1

Another big change is happening today! Josh B. has make GNU Radio
build
using cmake, and we are hoping to switch over to it completely. The
‘next’
branch has just pulled in his changes, and we now have parallel build
systems, cmake and autofoo. We are trying to make cmake the default
build
system, so we need people to start using it and testing as much as
possible.
For people who have issues using cmake, the autofoo stuff will still be
there. The parallel build system will be in place official from 3.5. As
of
3.6, we will have made a decision to move to cmake or stay with
autotools;
the other will be removed. It is expected that we will move to cmake, so
this is a Warning to everyone that autotools is being deprecated as our
build method.

Details about using cmake can be found here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork

To summarizes:

$ cd gnuradio
$ git checkout next
$ git pull
$ mkdir build
$ cd build
$ cmake …/
$ make
$ make test
$ sudo make install

Again, if that fails but you really need to use the current next branch,
the
same autotools build process will work. Please let us know if you find
any
issues.

Thanks!
Tom

2

On 10/19/2011 09:43 PM, Tom R. wrote:

… we need people to start using it and testing as much as possible.
Build went smoothly with cmake on Ubuntu 11.10 x64 Unfortunately, it
built as 32 bit, but it works. I usually build with Marcus L.'s
script which handles the architecture automatically. I assume I could
have given it a proper flag to build as 64 bit? Basically it installed
to /usr/local/lib/… instead of /usr/local/lib64/…

Pretty cool. I like the progress indicators as things run.

3

On 10/19/2011 08:42 PM, Dan CaJacob wrote:

On 10/19/2011 09:43 PM, Tom R. wrote:

… we need people to start using it and testing as much as possible.
Build went smoothly with cmake on Ubuntu 11.10 x64 Unfortunately, it
built as 32 bit, but it works. I usually build with Marcus L.'s
script which handles the architecture automatically. I assume I could
have given it a proper flag to build as 64 bit? Basically it installed
to /usr/local/lib/… instead of /usr/local/lib64/…

lib64 is a redhat thing, so that should be correct for ubuntu

Pretty cool. I like the progress indicators as things run.

:slight_smile:

4

Hi happy to hear it, autotools were complaining about old syntax on my
machine

Using gentoo (not too heavily updated I’m afraid) and not succeding

Configuring using cmake went well, but compiling didn’t, already at
first
stop volk (that I’m not entirely sure i need) a lot of errors occured.
To be more specific, more than my shell history could take.

2011/10/20 Tom R. [email protected]

[snip]
$ cd gnuradio
$ git checkout next
$ git pull
$ mkdir build
$ cd build
$ cmake …/

Up to here it went well

$ make

This fails already at volk

$ make test
$ sudo make install

Is there any way to disable parts such as volk? (akin to --disable-volk
that doesn’t seem to work)

The errors seems to be syntax errors in volk. Errors include:

"In file included from
/home/expert/skole/speciale/GnuRadio/git/build/volk/lib/volk.c:6:
/home/expert/skole/speciale/GnuRadio/git/build/volk/lib/volk_machines.h:20:
fejl: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘attribute’ before
‘volk_16i_branch_4_state_8_a_archs’
" (the first one, fejl means error in danish)

Any other outputs I can provide to help, just ask.

Again, if that fails but you really need to use the current next branch,
the same autotools build process will work. Please let us know if you find
any issues.

Thanks, I’ll just checkout master again :wink:

Best
Paul M. Bendixen

      • / -/* * -/* - * */- * * //- */- * / /- * * -//- / - - *-
        */-
  • /- -/ -/* / - * / - * - * -/- * - */- - -/- -//
5

Details about using cmake can be found here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork

I’m loving it! And less build stuff thanks to the lack of usrp*…
great!

One thing that doesn’t work perfect here: I always have to run
‘ldconfig’ after installation. Couldn’t that be part of ‘make install’
(or am I the only one who has this problem?).

MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

6

2011/10/20 Josh B. [email protected]

To be more specific, more than my shell history could take.

Hmm. thats not expected; volk should compile perfectly. Try to

completely clean the source tree before building w/ cmake. git clean

-dfx If you still see the errors can you dump to a file and post them

Volk usually also fails on the old install, the problem is , I think it
should detect that it was no good and take it out of the build entirely?

Also, cmake -DENABLE_VOLK=OFF will disable it.

Yeah, found that when i posted the output of cmake to a file and read it,
could there be some more intuitive way of finding this out than
trial-and-error?
I think the configurescript should bypass the volk entirely when it
cannot
build it?

Cmake wrote out the following
– Configuring volk support…
– Enabling volk support.
– Override with -DENABLE_VOLK=ON/OFF
– Available arches:
generic;3dnow;popcount;mmx;sse;sse2;orc;sse3;ssse3;sse4_a;sse4_1;sse4_2
– Available machines:
generic;sse2_only;sse2_32;sse3_32;ssse3_32;sse4_a_32;sse4_1_32;sse4_2_32
– checking for module ‘orc-0.4 > 0.4.11’
– package ‘orc-0.4 > 0.4.11’ not found
– Did not find liborc and orcc, disabling orc support…
– Using install prefix: /usr/local

Also, because i use gentoo, I earlier had to give the QWT dir in order
for
gnuradio to build gr-qtgui, the cmake now writes:
– Could NOT find Qwt (missing: QWT_INCLUDE_DIRS)
…
– Configuring gr-qtgui support…
– Dependency Boost_FOUND = TRUE
– Dependency QT4_FOUND = YES
– Dependency QWT_FOUND = FALSE
– Dependency ENABLE_GR_CORE = ON
– Dependency PYTHONLIBS_FOUND = TRUE
– Dependency PYQT4_FOUND = TRUE
– Disabling gr-qtgui support.
– Override with -DENABLE_GR_QTGUI=ON/OFF

Seeing as i have qwt in version 5.2.0 I find this weird.
(I do not however have pyqwt (it is masked in gentoo), could this be the
actual error?)

Anyways, the make test works now, I’m not going to test make install in
order to maintain compatibility with the environment we are doing our
thesis
on, but everything looks fine.

Best

Paul

7

On 10/20/2011 04:19 AM, Paul M. Bendixen wrote:

Hi happy to hear it, autotools were complaining about old syntax on my
machine

Using gentoo (not too heavily updated I’m afraid) and not succeding

Configuring using cmake went well, but compiling didn’t, already at first
stop volk (that I’m not entirely sure i need) a lot of errors occured.
To be more specific, more than my shell history could take.

Hmm. thats not expected; volk should compile perfectly. Try to
completely clean the source tree before building w/ cmake. git clean
-dfx If you still see the errors can you dump to a file and post them?

Also, cmake -DENABLE_VOLK=OFF will disable it.

-josh

8

Volk usually also fails on the old install, the problem is , I think it
should detect that it was no good and take it out of the build entirely?

No, this is a bug that needs to be fixed. Please help. Provide compiler
version gcc --version and all error verbose. Thanks.

Also, cmake -DENABLE_VOLK=OFF will disable it.

Yeah, found that when i posted the output of cmake to a file and read it,
could there be some more intuitive way of finding this out than
trial-and-error?

cmake-gui, ccmake (ncurses) would make it more obvious. Also future
documentation. :slight_smile:

I think the configurescript should bypass the volk entirely when it cannot
build it?

How can the configure know that volk cannot be built?

-Josh

9

On Thu, Oct 20, 2011 at 8:29 AM, Josh B. [email protected] wrote:

Also, cmake -DENABLE_VOLK=OFF will disable it.
cannot
build it?

How can the configure know that volk cannot be built?

-Josh

Just reiterating what Josh said. We would love for the configuration
process
to know that your machine can’t build Volk, but it has no way of knowing
that. If your machine meets the dependencies, it will try to build it.
Help
us figure out why with a full error log.

Volk will have to be built, so turning it off isn’t really going to be
an
option. We will be using volk inside gnuradio-core blocks as soon as we
can.
Once we’ve done that, you will need Volk to build or you won’t be able
to
compile gnuradio-core. Again, help us figure out what’s going wrong on
your
machine so we can get it to work.

Thanks!
Tom

10

On 10/20/2011 09:00 AM, Martin B. wrote:

One thing that doesn’t work perfect here: I always have to run
‘ldconfig’ after installation. Couldn’t that be part of ‘make install’
(or am I the only one who has this problem?).
I had the same problem. But after runnin it and setting the PYTHONPATH,
everything was fine.

11

On 20/10/2011 11:59 AM, Dan CaJacob wrote:

On 10/20/2011 09:00 AM, Martin B. wrote:

One thing that doesn’t work perfect here: I always have to run
‘ldconfig’ after installation. Couldn’t that be part of ‘make install’
(or am I the only one who has this problem?).
I had the same problem. But after runnin it and setting the
PYTHONPATH, everything was fine.

The build-gnuradio script takes care of running ldconfig

12

– Dependency PYTHONLIBS_FOUND = TRUE
– Dependency PYQT4_FOUND = TRUE
– Disabling gr-qtgui support.
– Override with -DENABLE_GR_QTGUI=ON/OFF

Seeing as i have qwt in version 5.2.0 I find this weird.
(I do not however have pyqwt (it is masked in gentoo), could this be the
actual error?)

Paul -

I run Arch Linux, and have similar troubles with QWT. One of the main
issues is that QWT is not bundled in a way that makes it easy to work
with
(it lacks a package-config file, etc.,) - which makes it hard for build
toolchains to find it consistently on all Linux OSes. As a result, I
almost
always have to manually pass in the location of QWT.

Anyway, you mentioned that you used to pass it in manually. Did you try
doing that here, by adding your QWT install directory to CMake’s search
path?

Cheers,
Ben

13

On 10/20/2011 12:02 PM, Marcus D. Leech wrote:

On 20/10/2011 11:59 AM, Dan CaJacob wrote:

On 10/20/2011 09:00 AM, Martin B. wrote:

One thing that doesn’t work perfect here: I always have to run
‘ldconfig’ after installation. Couldn’t that be part of ‘make install’
(or am I the only one who has this problem?).
I had the same problem. But after runnin it and setting the
PYTHONPATH, everything was fine.

The build-gnuradio script takes care of running ldconfig
Right. I actually used individual functions of your script to cleanup
my install. I was testing the cmake build, though and I don’t think
that is integrated into build-gnuradio yet. I love your script though!

In the future, I imagine that cmake will make it possible to easily
create deb and other binary packages that will install everything and do
all of the extra steps necessary to get things going (like running
ldconfig).

14

2011/10/20 Josh B. [email protected]

Volk usually also fails on the old install, the problem is , I think it
should detect that it was no good and take it out of the build entirely?

No, this is a bug that needs to be fixed. Please help. Provide compiler
version gcc --version and all error verbose. Thanks.

gcc --version: gcc (Gentoo 4.3.4 p1.2, pie-10.1.5) 4.3.4

error from make is in make.log
Furthermore stdout wrote:

[ 0%] Generating …/include/volk/volk.h, volk.c, volk_init.h,
…/include/volk/volk_typedefs.h, …/include/volk/volk_cpu.h, volk_cpu.c,
…/include/volk/volk_config_fixed.h, volk_environment_init.c,
volk_environment_init.h, volk_machines.h, volk_machines.c,
volk_machine_generic.c, volk_machine_sse2_only.c,
volk_machine_sse2_32.c,
volk_machine_sse3_32.c, volk_machine_ssse3_32.c,
volk_machine_sse4_a_32.c,
volk_machine_sse4_1_32.c, volk_machine_sse4_2_32.c
Scanning dependencies of target volk
[ 0%] Building C object volk/lib/CMakeFiles/volk.dir/volk_prefs.c.o
[ 0%] Building C object volk/lib/CMakeFiles/volk.dir/volk_rank_archs.c.o
[ 0%] Building C object volk/lib/CMakeFiles/volk.dir/volk.c.o

before dying

Also, cmake -DENABLE_VOLK=OFF will disable it.

Yeah, found that when i posted the output of cmake to a file and read
it,
could there be some more intuitive way of finding this out than
trial-and-error?

cmake-gui, ccmake (ncurses) would make it more obvious. Also future

documentation. :slight_smile:

Ok, sooo much easier and understandable :slight_smile: You should suggest this as the
default method of configuring :smiley:

I think the configurescript should bypass the volk entirely when it
cannot
build it?

How can the configure know that volk cannot be built?

Take a look in configure.log, it says a lot about things I do not have,
might this not be an indicator?

-Josh

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Best Paul M. Bendixen

15

On Thu, Oct 20, 2011 at 6:51 AM, Josh B. [email protected] wrote:

lib64 is a redhat thing, so that should be correct for ubuntu

Actually, it’s also used in Ubuntu 11.10 now. I just built UHD and GNU
Radio yesterday. UHD installed in lib/ while GNU Radio (using
autotools) went to lib64/

Alex

16

Il 20/10/2011 03:43, Tom R. ha scritto:

everyone that autotools is being deprecated as our build method.
$ cd build
Tom

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
does this mean that i could perform the steps

/ mkdir build
cd build
cmake -DCPACK_GENERATOR=DEB …/
make package/

and make deb(s) of the current git release ? which is the switch to
disable one of the components ?

Regards, Arturo

17

On 10/20/2011 09:00 AM, Paul M. Bendixen wrote:

gcc --version: gcc (Gentoo 4.3.4 p1.2, pie-10.1.5) 4.3.4

error from make is in make.log
Furthermore stdout wrote:

You need to clean your source directory. This file should not exist:
/home/expert/skole/speciale/GnuRadio/git/volk/include/volk/volk.h:7:29:
error: volk/volk_config.h: Ingen sdan fil eller filkatalog

Can you git clean -dfx and try again?

-Josh

18

On 10/20/2011 02:01 PM, Josh B. wrote:

have given it a proper flag to build as 64 bit? Basically it installed
bit. So something must be confused.

-josh
I think he might be using ML’s build-gnuradio script, which installs to
lib64 if the directory exists, regardless of whether the operating
system in RH. That’s why I was confused when it didn’t install to lib64
when I was testing cmake.

19

does this mean that i could perform the steps

/ mkdir build
cd build
cmake -DCPACK_GENERATOR=DEB …/
make package/

and make deb(s) of the current git release ? which is the switch to

Basically, yes that will generate a big deb file for the whole project.
There are a few considerations to do it right.

  1. A list of all the dependencies for the package manager. This needs to
    be defined per supported OS because the names are different across os
    versions and os. I am thinking recent fedoras, ubuntus, and some
    debians.

  2. Some prerm/postinst rules to run ldconfig to install grc icons, etc…
    This is called pre/post install/uninstall for rpms

  3. And if you want component based deps/rpms, you need to do something
    different. I started this work and there have been a few posts about it.
    The important thing is that the install rules in cmake all specify a
    component so its easy to get a list of files per component (then do some
    magic with it). Branch here:
    http://gnuradio.org/cgit/jblum.git/log/?h=multi_deb

Basically there is still work to be done

disable one of the components ?

See the configure verbose or checkout cmake-gui or ccmake (ncurses). You
will see all the ENABLE_* variables for each component

-josh

20

On 20/10/2011 2:35 PM, Dan CaJacob wrote:

I think he might be using ML’s build-gnuradio script, which installs
to lib64 if the directory exists, regardless of whether the operating
system in RH. That’s why I was confused when it didn’t install to
lib64 when I was testing cmake.

Actually the only thing that the build-gnuradio script does that could
possibly affect where things get installed is that it sets
PKG_CONFIG_PATH to /usr/local/lib/pkgconfig, and if
/usr/local/lib64/pkgconfig exists, it sets it to that instead, before
calling the bulk of the gnuradio builder chain.