Build error with "next" branch

Hi,

Kubuntu 12.04 32bit LTS, latest gnuradio “master”, everything works. Now
I
thought, give “next” a try, but this fails. Before I go into details and
search for the exact error, I followed this procedure mentioned below.
Is
this the correct way, or is this already part of the problem? :slight_smile:

“git checkout next” and “git pull” in the gnuradio folder, “cd build”,
“make
clean”, “cmake …/”, “make”. Then I run into an error, relative early. I
will extract it when it is confirmed that my procedure was OK, as this
is
another PC and I will have to transfer it first. I know that exact error
messages are important, don’t worry.

The way back with “git checkout master”, otherwise identical to the
above
mentioned procedure, works just fine.

Thank you, and with best regards

Ralph.

Ralph A. Schmid
Mondstr. 10
90762 Frth
+49-171-3631223
[email protected]
http://www.bclog.de/

On Wed, Feb 20, 2013 at 7:54 AM, Ralph A. Schmid, dk5ras
[email protected]wrote:

will extract it when it is confirmed that my procedure was OK, as this is
another PC and I will have to transfer it first. I know that exact error
messages are important, don’t worry.

The way back with “git checkout master”, otherwise identical to the above
mentioned procedure, works just fine.

Thank you, and with best regards

Ralph.

Yes, that’s the way to do it.

Tom

OK, below the output.

“Master” runs just fine through the whole process and runs, so I assume
the
system should be OK so far. The only non standard stuff on the system is
a
minimum gnuradio 3.4.2 installation for OpenBTS, some command line tools
that
somehow depend on UHD and RTLSDR and maybe gnuradio…

Ralph.

[ 2%] Generating documentation with doxygen
/home/ras/gnuradio/gr-audio/lib/osx/osx_impl.h:57: Warning: include file
boost/detail/endian.hpp not found, perhaps you forgot to add its
directory to
INCLUDE_PATH?
/home/ras/gnuradio/gruel/src/lib/pmt/pmt_int.h:243: Warning: include
file
pmt_unv_int.h not found, perhaps you forgot to add its directory to
INCLUDE_PATH?
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)
entering extended mode
(./_formulas.tex
LaTeX2e <2009/09/24>
Babel <v3.8l> and hyphenation patterns for english, usenglishmax,
dumylang,
noh
yphenation, loaded.
(/usr/share/texmf-texlive/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texmf-texlive/tex/latex/base/size10.clo))
(/usr/share/texmf-texlive/tex/latex/graphics/epsfig.sty
(/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty)
(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
(/etc/texmf/tex/latex/config/graphics.cfg)
(/usr/share/texmf-texlive/tex/latex/graphics/dvips.def))))
No file _formulas.aux.
[1] [2] [3] [4] [5] (./_formulas.aux) )
Output written on _formulas.dvi (5 pages, 1272 bytes).
Transcript written on _formulas.log.
[ 2%] Built target doxygen_target
[ 2%] Generating …/include/gruel/pmt_serial_tags.h
[ 2%] Generating pmt/pmt_unv_int.h, pmt/qa_pmt_unv.h, pmt/pmt_unv.cc,
pmt/qa_pmt_unv.cc
Scanning dependencies of target gruel
[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter.cc.o
[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter_msgq.cc.o
[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_producer.cc.o
[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o
[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_unv.cc.o
[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt.cc.o
[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_io.cc.o
[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o
[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_serialize.cc.o
[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/realtime.cc.o
[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/sys_pri.cc.o
[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread.cc.o
[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_body_wrapper.cc.o
[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_group.cc.o
Linking CXX shared library libgruel-3.7git.so
make[2]: *** [gruel/src/lib/libgruel-3.7git.so.0.0.0] Error 1
make[1]: *** [gruel/src/lib/CMakeFiles/gruel.dir/all] Error 2
make: *** [all] Error 2

On Wed, Feb 20, 2013 at 9:19 AM, Ralph A. Schmid [email protected]
wrote:

to INCLUDE_PATH?

(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)

gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o
[ 3%] Building CXX object

make: *** [all] Error 2

Ralph,

Are you sure this is the entire output? There’s nothing indicating what
the
error was.

Still, I’m wondering if there’s a problem with it pulling in installed
versions of the headers as opposed to local versions (we worked to
correct
this from happening fairly recently, but doesn’t mean it’s not still
happening here).

Tom

Hi,

I did not copy everything from beginning on, as it looked all normal,
but if
it helps I can copy all the stuff, including output of cmake - as the
thing
happens in an earliy stage it is not so much stuff to look through…
Although I do not know very much about linux, I do not fear any special
instructions you may give me, to get more information about it.

I assume completely deleting the “build” folder contents before
switching
the branch should not make a difference?!

Ralph.

From: [email protected] [mailto:[email protected]] On Behalf Of
Tom
Rondeau
Sent: Wednesday, February 20, 2013 3:25 PM
To: Ralph A. Schmid
Cc: GNURadio D.ion List
Subject: Re: [Discuss-gnuradio] build error with “next” branch

On Wed, Feb 20, 2013 at 9:19 AM, Ralph A. Schmid [email protected]
wrote:

OK, below the output.

“Master” runs just fine through the whole process and runs, so I assume
the
system should be OK so far. The only non standard stuff on the system is
a
minimum gnuradio 3.4.2 installation for OpenBTS, some command line tools
that somehow depend on UHD and RTLSDR and maybe gnuradio…

Ralph.

[ 2%] Generating documentation with doxygen

/home/ras/gnuradio/gr-audio/lib/osx/osx_impl.h:57: Warning: include file
boost/detail/endian.hpp not found, perhaps you forgot to add its
directory
to INCLUDE_PATH?

/home/ras/gnuradio/gruel/src/lib/pmt/pmt_int.h:243: Warning: include
file
pmt_unv_int.h not found, perhaps you forgot to add its directory to
INCLUDE_PATH?

This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)

entering extended mode

(./_formulas.tex

LaTeX2e <2009/09/24>

Babel <v3.8l> and hyphenation patterns for english, usenglishmax,
dumylang,
noh

yphenation, loaded.

(/usr/share/texmf-texlive/tex/latex/base/article.cls

Document Class: article 2007/10/19 v1.4h Standard LaTeX document class

(/usr/share/texmf-texlive/tex/latex/base/size10.clo))

(/usr/share/texmf-texlive/tex/latex/graphics/epsfig.sty

(/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty

(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty)

(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty

(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)

(/etc/texmf/tex/latex/config/graphics.cfg)

(/usr/share/texmf-texlive/tex/latex/graphics/dvips.def))))

No file _formulas.aux.

[1] [2] [3] [4] [5] (./_formulas.aux) )

Output written on _formulas.dvi (5 pages, 1272 bytes).

Transcript written on _formulas.log.

[ 2%] Built target doxygen_target

[ 2%] Generating …/include/gruel/pmt_serial_tags.h

[ 2%] Generating pmt/pmt_unv_int.h, pmt/qa_pmt_unv.h, pmt/pmt_unv.cc,
pmt/qa_pmt_unv.cc

Scanning dependencies of target gruel

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter.cc.o

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter_msgq.cc.o

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_producer.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_unv.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_io.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_serialize.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/realtime.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/sys_pri.cc.o

[ 3%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/thread.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_body_wrapper.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_group.cc.o

Linking CXX shared library libgruel-3.7git.so

make[2]: *** [gruel/src/lib/libgruel-3.7git.so.0.0.0] Error 1

make[1]: *** [gruel/src/lib/CMakeFiles/gruel.dir/all] Error 2

make: *** [all] Error 2

Ralph,

Are you sure this is the entire output? There’s nothing indicating what
the
error was.

Still, I’m wondering if there’s a problem with it pulling in installed
versions of the headers as opposed to local versions (we worked to
correct
this from happening fairly recently, but doesn’t mean it’s not still
happening here).

Tom

On Wed, Feb 20, 2013 at 7:30 AM, Tom R. [email protected] wrote:

On Wed, Feb 20, 2013 at 9:49 AM, Ralph A. Schmid, dk5ras <[email protected]

wrote:

Actually, yes, delete the build directory. There’s possibly some stuff
that’s built there that’s confusing things. Cmake should automatically tell
that things are old and need to be regenerated, but just to be safe. (I
actually have entirely separate build folders for each branch to make sure
thing stay sane.)

It’s too late now, as the OP already did a git checkout and pull, but
best
practice is to go into the build directory and do a ‘sudo make
uninstall’
to remove any traces of the first build that had gotten installed. Then
delete the build directory, go back to the source directory, do the git
checkout and update to switch branches, and start over with a new build
directory.

Johnathan

On Wed, Feb 20, 2013 at 9:49 AM, Ralph A. Schmid, dk5ras
[email protected]wrote:


I assume completely deleting the build folder contents before switching
the branch should not make a difference?!****


Ralph.

Actually, yes, delete the build directory. There’s possibly some stuff
that’s built there that’s confusing things. Cmake should automatically
tell
that things are old and need to be regenerated, but just to be safe. (I
actually have entirely separate build folders for each branch to make
sure
thing stay sane.)

Also, probably no need for the entire output. I’m just trying to figure
out
what the real error message is. Just look through the output and see
where
it gives you any errors. Don’t worry about Doxygen errors. And I know
you
said you were new to Linux, so treat this as a learning exercise.
Understanding how to grok your compiler output is a really useful skill
:slight_smile:

Tom

The build and build install worked just fine, but now the crazy thing
complains
that the pythonpath is not set. Huh?! Why does a new build influence a
environment variable? And I have no idea how to handle these things
under
Linux :frowning: So much to learn that I never wanted to know :slight_smile:

Ralph.

Yep, the output was complete, just copy and paste, and before it
everything
looked normal. Now I emptied the build folder before starting over once
again - and, tadaaaa! I came over the magic 3%, at the moment it is at
14%
without error. We will see if it completes, on my Core 2 Duo ThinkPad at
1.6
GHz compiling takes a while…

Ralph.

From: [email protected] [mailto:[email protected]] On Behalf Of
Tom
Rondeau
Sent: Wednesday, February 20, 2013 4:31 PM
To: Ralph A. Schmid, dk5ras
Cc: GNURadio D.ion List
Subject: Re: [Discuss-gnuradio] build error with “next” branch

On Wed, Feb 20, 2013 at 9:49 AM, Ralph A. Schmid, dk5ras
[email protected]
wrote:

Hi,

I did not copy everything from beginning on, as it looked all normal,
but if
it helps I can copy all the stuff, including output of cmake - as the
thing
happens in an earliy stage it is not so much stuff to look through…
Although I do not know very much about linux, I do not fear any special
instructions you may give me, to get more information about it.

I assume completely deleting the “build” folder contents before
switching
the branch should not make a difference?!

Ralph.

Actually, yes, delete the build directory. There’s possibly some stuff
that’s built there that’s confusing things. Cmake should automatically
tell
that things are old and need to be regenerated, but just to be safe. (I
actually have entirely separate build folders for each branch to make
sure
thing stay sane.)

Also, probably no need for the entire output. I’m just trying to figure
out
what the real error message is. Just look through the output and see
where
it gives you any errors. Don’t worry about Doxygen errors. And I know
you
said you were new to Linux, so treat this as a learning exercise.
Understanding how to grok your compiler output is a really useful skill
:slight_smile:

Tom

From: [email protected] [mailto:[email protected]] On Behalf Of
Tom
Rondeau
Sent: Wednesday, February 20, 2013 3:25 PM
To: Ralph A. Schmid
Cc: GNURadio D.ion List
Subject: Re: [Discuss-gnuradio] build error with “next” branch

On Wed, Feb 20, 2013 at 9:19 AM, Ralph A. Schmid [email protected]
wrote:

OK, below the output.

“Master” runs just fine through the whole process and runs, so I assume
the
system should be OK so far. The only non standard stuff on the system is
a
minimum gnuradio 3.4.2 installation for OpenBTS, some command line tools
that somehow depend on UHD and RTLSDR and maybe gnuradio…

Ralph.

[ 2%] Generating documentation with doxygen

/home/ras/gnuradio/gr-audio/lib/osx/osx_impl.h:57: Warning: include file
boost/detail/endian.hpp not found, perhaps you forgot to add its
directory
to INCLUDE_PATH?

/home/ras/gnuradio/gruel/src/lib/pmt/pmt_int.h:243: Warning: include
file
pmt_unv_int.h not found, perhaps you forgot to add its directory to
INCLUDE_PATH?

This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)

entering extended mode

(./_formulas.tex

LaTeX2e <2009/09/24>

Babel <v3.8l> and hyphenation patterns for english, usenglishmax,
dumylang,
noh

yphenation, loaded.

(/usr/share/texmf-texlive/tex/latex/base/article.cls

Document Class: article 2007/10/19 v1.4h Standard LaTeX document class

(/usr/share/texmf-texlive/tex/latex/base/size10.clo))

(/usr/share/texmf-texlive/tex/latex/graphics/epsfig.sty

(/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty

(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty)

(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty

(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)

(/etc/texmf/tex/latex/config/graphics.cfg)

(/usr/share/texmf-texlive/tex/latex/graphics/dvips.def))))

No file _formulas.aux.

[1] [2] [3] [4] [5] (./_formulas.aux) )

Output written on _formulas.dvi (5 pages, 1272 bytes).

Transcript written on _formulas.log.

[ 2%] Built target doxygen_target

[ 2%] Generating …/include/gruel/pmt_serial_tags.h

[ 2%] Generating pmt/pmt_unv_int.h, pmt/qa_pmt_unv.h, pmt/pmt_unv.cc,
pmt/qa_pmt_unv.cc

Scanning dependencies of target gruel

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter.cc.o

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter_msgq.cc.o

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_producer.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_unv.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_io.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_serialize.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/realtime.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/sys_pri.cc.o

[ 3%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/thread.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_body_wrapper.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_group.cc.o

Linking CXX shared library libgruel-3.7git.so

make[2]: *** [gruel/src/lib/libgruel-3.7git.so.0.0.0] Error 1

make[1]: *** [gruel/src/lib/CMakeFiles/gruel.dir/all] Error 2

make: *** [all] Error 2

Ralph,

Are you sure this is the entire output? There’s nothing indicating what
the
error was.

Still, I’m wondering if there’s a problem with it pulling in installed
versions of the headers as opposed to local versions (we worked to
correct
this from happening fairly recently, but doesn’t mean it’s not still
happening here).

Tom

The build and build install worked just fine, but now the crazy thing
complains that the pythonpath is not set. Huh?! Why does a new build
influence a environment variable? And I have no idea how to handle
these things under Linux :frowning: So much to learn that I never wanted to
know :slight_smile:

Ralph.

You should set your PYTHONPATH in your .bashrc

I have mine set thusly:

PYTHONPATH=/usr/local/lib64/python2.7/site-packages:$HOME/bin
PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/site-packages:$HOME/bin:.
export PYTHONPATH

You may need to adjust based on your own install environment.

/usr/local/lib/python2.7/dist-packages.

Tom

Indeed, and build-gnuradio actually tells you what your PYTHONPATH
should be set to for Gnu Radio support. The build-gnuradio script
could
edit your .bashrc and set that variable for you, but doing so is
dangerous because .bashrc is, essentially, a program, which would
involve
build-gnuradio somehow interpreting the semantics of said program,
and figuring out where to put the PYTHONPATH setting. Some hand-holding
is best left not done…

On Wed, Feb 20, 2013 at 12:09 PM, Ralph A. Schmid [email protected]
wrote:

**

The build and build install worked just fine, but now the crazy thing
complains that the pythonpath is not set. Huh?! Why does a new build
influence a environment variable? And I have no idea how to handle these
things under Linux :frowning: So much to learn that I never wanted to know :slight_smile:

Ralph.

I assure you that the install did not change your environmental
variables.

To set it, use ‘export PYTHONPATH=[path]:$PYTHONPATH’. Some shells want
you
to use ‘set’ instead of ‘export.’ The [path] is the path to the
installed
Python packages; something like /usr/local/lib/python2.7/dist-packages.

Tom

On Wed, Feb 20, 2013 at 9:09 AM, Ralph A. Schmid [email protected]
wrote:

So much to learn that I never wanted to know :slight_smile:

It is for this reason that I will be happy when the majority of users
install GNU Radio via operating system vendor supplied packages. Right
now
this can be done using Ubuntu 12.10, Debian “testing”, and a couple
versions of RedHat Linux (I don’t recall the details.)

Johnathan

Johnathan
How up-to-date are the Ubuntu packages?

On Wed, Feb 20, 2013 at 9:23 AM, Marcus D. Leech [email protected]
wrote:

How up-to-date are the Ubuntu packages?

Release 3.6.1. If the timing works out, it looks like we can still get
3.6.3 or 3.6.4 (not yet released) into 13.04.

Johnathan

On Wed, Feb 20, 2013 at 12:23 PM, Marcus D. Leech [email protected]
wrote:

this can be done using Ubuntu 12.10, Debian “testing”, and a couple
versions of RedHat Linux (I don’t recall the details.)

Johnathan

How up-to-date are the Ubuntu packages?

3.6.1.

Tom

On Wed, Feb 20, 2013 at 6:59 PM, Johnathan C.
[email protected] wrote:

On Wed, Feb 20, 2013 at 9:23 AM, Marcus D. Leech [email protected] wrote:

How up-to-date are the Ubuntu packages?

Release 3.6.1. If the timing works out, it looks like we can still get
3.6.3 or 3.6.4 (not yet released) into 13.04.

I’m wondering what makes you think that given that the current version
in 13.04 alpha is still 3.6.1?

I don’t know if I mentioned it before, but Ubuntu has infrastructure
that can fetch code from a repository and automatically build packages
whenever the code changes, and make the packages available via PPA,
see for example https://launchpad.net/~gpredict-team/+archive/daily
This could be an interesting option as there seems to be an increasing
number of people who are interested in using the latest GNU Radio.

Alex

On Wed, Feb 20, 2013 at 12:41 PM, Alexandru C. [email protected]
wrote:

I’m wondering what makes you think that given that the current version
in 13.04 alpha is still 3.6.1?

Release 3.6.3 has already been packaged for Debian; it’s only a matter
of
coordination to see if it can get into Ubuntu.

I don’t know if I mentioned it before, but Ubuntu has infrastructure
that can fetch code from a repository and automatically build packages
whenever the code changes, and make the packages available via PPA,
see for example https://launchpad.net/~gpredict-team/+archive/daily
This could be an interesting option as there seems to be an increasing
number of people who are interested in using the latest GNU Radio.

I agree; we’ve considered this for making versions available that are
not
yet in the distribution repositories.

If 13.04 stays with 3.6.1, then we’d look at doing a PPA for 3.6.3 or
3.6.4
as needed.

Johnathan

Well, this is exactly what everyone recommends not to do, they tell,
go
with the latest sources.

Ralph.

From: Johnathan C. [mailto:[email protected]]
Sent: Wednesday, 20 February, 2013 18:19
To: Ralph A. Schmid
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] build error with “next” branch

On Wed, Feb 20, 2013 at 9:09 AM, Ralph A. Schmid [email protected]
wrote:

So much to learn that I never wanted to know :slight_smile:

It is for this reason that I will be happy when the majority of users
install GNU Radio via operating system vendor supplied packages. Right
now
this can be done using Ubuntu 12.10, Debian “testing”, and a couple
versions
of RedHat Linux (I don’t recall the details.)

Johnathan

I can reproduce this behavior; when going back to “master” everything is
fine, switching to “next” brings up a window complaining about the
pythonpath when trying to start grc. I never had set this path manually,
the
initial installation was done with Marcus’ script and worked without
manual
changes.

Ralph.

From: [email protected] [mailto:[email protected]] On Behalf Of
Tom
Rondeau
Sent: Wednesday, 20 February, 2013 18:13
To: Ralph A. Schmid
Cc: GNURadio D.ion List
Subject: Re: [Discuss-gnuradio] build error with “next” branch

On Wed, Feb 20, 2013 at 12:09 PM, Ralph A. Schmid [email protected]
wrote:

The build and build install worked just fine, but now the crazy thing
complains that the pythonpath is not set. Huh?! Why does a new build
influence a environment variable? And I have no idea how to handle these
things under Linux :frowning: So much to learn that I never wanted to know :slight_smile:

Ralph.

I assure you that the install did not change your environmental
variables.

To set it, use ‘export PYTHONPATH=[path]:$PYTHONPATH’. Some shells want
you
to use ‘set’ instead of ‘export.’ The [path] is the path to the
installed
Python packages; something like /usr/local/lib/python2.7/dist-packages.

Tom