Re: [Discuss-gnuradio] Monthly call

[Martin Braun]

On Tue, Mar 13, 2012 at 01:48:04PM -0400, Tom Rondeau wrote:
> Hey everyone,
> 
> 
> I'll put up an agenda later today for this month's developers' call occurring
> this Thursday. But first, I wanted to see everyone's reaction to moving the
> call up a few hours. We did it last month at 3 PM EST and we had a few more
> people attending than usual. If we'll get a similarly larger turnout, I'd like
> schedule this one (and future calls) to the same time: 1500 EDT or 1900 UTC.
> Sound good?

Hi Tom,

despite not having joined this call, I hope they continue to be
early--previous calls were at midnight (CET) and I'm not *that* much of
an enthusiast to stay up that long. Most Europeans will probably agree
to this.

Cheerio
Martin

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

Dipl.-Ing. Martin Braun
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


pgpvZmCJhrUpq.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Monthly call

[Martin Braun]

On Thu, Mar 15, 2012 at 10:35:14AM +0100, Martin Braun wrote:
> despite not having joined this call, I hope they continue to be
> early--previous calls were at midnight (CET) and I'm not *that* much of
> an enthusiast to stay up that long. Most Europeans will probably agree
> to this.

Oh wait, I didn't miss it :) Hope this didn't confuse anyone.
What I said is still valid, though.

MB

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

Dipl.-Ing. Martin Braun
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


pgpiWNVO7wja9.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Monthly call

[Tom Rondeau]

On Thu, Mar 15, 2012 at 5:47 AM, Martin Braun  wrote:

> On Thu, Mar 15, 2012 at 10:35:14AM +0100, Martin Braun wrote:
> > despite not having joined this call, I hope they continue to be
> > early--previous calls were at midnight (CET) and I'm not *that* much of
> > an enthusiast to stay up that long. Most Europeans will probably agree
> > to this.
>
> Oh wait, I didn't miss it :) Hope this didn't confuse anyone.
> What I said is still valid, though.
>
> MB



Thanks, Martin. I heard no objections, so we'll keep doing it early.

I said 3 PM EDT before, but I meant 4 PM like we did last time. This
doesn't cut into lunch hour on the west coast of the US.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Developers' Call for March 15, 2012

[Tom Rondeau]

The agenda is posted:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20120315

New call is at:
4 PM (1600) EST or 2000 UTC

Thanks,
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] build gnuradio without volk module

[Arturo Rinaldi]

Nella citazione in data Thu Mar 15 03:07:49 2012, Tom Rondeau ha 
scritto:

On Wed, Mar 14, 2012 at 8:49 PM, Johnathan Corgan
mailto:jcor...@corganenterprises.com>>
wrote:

On Wed, Mar 14, 2012 at 17:41, Josh Blum mailto:j...@joshknows.com>> wrote:

> Is this the official github for gnuradio?
> https://github.com/gnuradio/gnuradio/tags
>
> Any chance we could get tags pushed there as well (maybe
automated)? It
> would be super easy to link to source tarballs that way.

Tom is setting up this github repo to automatically mirror the
contents of gnuradio.org 's repo, but the
work isn't complete, and the
repo itself doesn't have everything in it (like the tags, as you
noticed.)

He and I are working out some security issues with the automation, but
maybe we can do a manual push of the tags there.

Johnathan



Yes, we should definitely push the tags. Have done that manually for now.

Arturo,

My suggestion would be to use either the github gnuradio account or
gnuradio.org 's git repo. Clone the repo and then
checkout tag v3.5.2. This tag is equivalent to the tarball release
except that it will contain the cmake files to build that way. Here's
the link to the tarball for the v3.5.2 tag on github:

https://github.com/gnuradio/gnuradio/zipball/v3.5.2

One thing to note, though, is that with this, you a) get everything in
the repo and b) don't have some generated stuff that normally goes
into the release tarballs. Issue a shouldn't affect you. For issue b,
you will just have to remember to run ./bootstrap before running
./configure.

As of 3.5.2, we've started using Volk inside of gnuradio-core blocks,
so it has become a requirement, not just an option, so disabling volk
should disable gnuradio-core, too. If that's not happening, I'll fix it.

We will be releasing a 3.5.3 (possibly soon) to fix some other issues
that have recently come up. Due to the autotools issue with volk, we
will try to include the cmake build files in this release, though.

Tom



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


thx very much to all of you. I look forward to work with the 3.5.3 
official tarball.


Regards, Arturo

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault

[Stefan Ott]

On Wed, Mar 14, 2012 at 19:11, Stefan Ott  wrote:
> On Wed, Mar 14, 2012 at 18:58, Nick Foster  wrote:
>>
>> What version of UHD are you using?
>
> At the moment I am using a git checkout from late February - good
> point, I'll update and report back.

I now tried with UHD 3.3.2 as well as the with the latest version from
git, I still get the same segfaults.

-- 
Stefan Ott
Communication and Distributed Systems
Institute of Computer Science and Applied Mathematics
University of Bern

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault

[Stefan Ott]

On Wed, Mar 14, 2012 at 20:51, Philip Balister  wrote:
>>
>> Does anyone have a clue about what I might be doing wrong?
>
> Besides completely voiding the warranty :) :) :)  <- Note smileys, I
> actually enjoy people doing crazy stuff.

:)

> When you say Linux 3.1.0, is that mainline?

Yep (3.1.10, not 3.1.0, in case that matters)

> If you do want to update your kernel to something more recent, try
> starting from here:
>
> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=shortlog;h=refs/heads/omap-3.2

The kernel that I'm using seems to work just fine on some other
gumstix nodes but sure, I'll give it a try and see whether anything
changes.

> Finally, there are docs on the web for working out where in the code the
> oops really occurs. Can you try working through that procedure and see
> if it happens in the driver, or elsewhere.

Ok, I'll see whether I can find it and report back once I have more information.

cheers
-- 
Stefan Ott
Communication and Distributed Systems
Institute of Computer Science and Applied Mathematics
University of Bern

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault

[Stefan Ott]

On Thu, Mar 15, 2012 at 18:02, Stefan Ott  wrote:
>
>> Finally, there are docs on the web for working out where in the code the
>> oops really occurs. Can you try working through that procedure and see
>> if it happens in the driver, or elsewhere.
>
> Ok, I'll see whether I can find it and report back once I have more 
> information.

So far, what I've found through the magic of strace and printf is that
the offending call seems to be the USRP_E_WRITE_CTL32 ioctl that
happens as a consequence of poke32 (in e100_ctrl.cpp) when called from
e100_ctrl_impl.

That's still with (vanilla) kernel 3.1.10 though.

cheers
-- 
Stefan Ott
Communication and Distributed Systems
Institute of Computer Science and Applied Mathematics
University of Bern

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault

[Philip Balister]

On 03/15/2012 02:26 PM, Stefan Ott wrote:
> On Thu, Mar 15, 2012 at 18:02, Stefan Ott  wrote:
>>
>>> Finally, there are docs on the web for working out where in the code the
>>> oops really occurs. Can you try working through that procedure and see
>>> if it happens in the driver, or elsewhere.
>>
>> Ok, I'll see whether I can find it and report back once I have more 
>> information.
> 
> So far, what I've found through the magic of strace and printf is that
> the offending call seems to be the USRP_E_WRITE_CTL32 ioctl that
> happens as a consequence of poke32 (in e100_ctrl.cpp) when called from
> e100_ctrl_impl.
> 
> That's still with (vanilla) kernel 3.1.10 though.

Can you look carefully at what data is being passed to the driver? We
may need to range check the data before we use it in the driver.

Philip

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Best way to share/install hierarchical grc blocks?

[Porges, Donald]

Hi,

I'm trying to figure out a good way to distribute some custom heir blocks that 
go with my low-level custom blocks I've written.  The issue is that the xml and 
py files are both generated into my ~/.grc_gnuradio directory, and the xml 
files contain lines like

execfile("/Users/myname/.grc_gnuradio/file.py")

which obviously is not distributable.  (Those lines get generated into any grc 
output files that use the block, so editing it at the point of use is not much 
of a solution.)  

The obvious answer is to edit that line by hand, but the next problem is that I 
don't even know where the gnuradio directory is for other people (could be a 
different host platform, for instance).  There also seems to be no "execfile 
search path" concept, which would allow me to perform some light editing of the 
xml file to remove the absolute path.  So how do people share their created 
hierarchical blocks?

(I suppose the answer could be "give them my .grc_gnuradio files and tell them 
to edit all of the references", but that doesn't make for a nice delivery.)

Don Porges
Lyric Labs/Analog Devices

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Best way to share/install hierarchical grc blocks?

[Tom Rondeau]

On Thu, Mar 15, 2012 at 3:28 PM, Porges, Donald wrote:

> Hi,
>
> I'm trying to figure out a good way to distribute some custom heir blocks
> that go with my low-level custom blocks I've written.  The issue is that
> the xml and py files are both generated into my ~/.grc_gnuradio directory,
> and the xml files contain lines like
>
> execfile("/Users/myname/.grc_gnuradio/file.py")
>
> which obviously is not distributable.  (Those lines get generated into any
> grc output files that use the block, so editing it at the point of use is
> not much of a solution.)
>
> The obvious answer is to edit that line by hand, but the next problem is
> that I don't even know where the gnuradio directory is for other people
> (could be a different host platform, for instance).  There also seems to be
> no "execfile search path" concept, which would allow me to perform some
> light editing of the xml file to remove the absolute path.  So how do
> people share their created hierarchical blocks?
>
> (I suppose the answer could be "give them my .grc_gnuradio files and tell
> them to edit all of the references", but that doesn't make for a nice
> delivery.)
>
> Don Porges
> Lyric Labs/Analog Devices
>


Does this help?

http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Installing-the-XML-Block-Definition

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Best way to share/install hierarchical grc blocks?

[Josh Blum]

On 03/15/2012 02:14 PM, Porges, Donald wrote:
> I've read that, and it only applies to telling grc where the xml is
> for a non-hierarchical block; that is, it solves a build-time
> problem, not a runtime problem.
> 
> 
> On Mar 15, 2012, at 5:07 PM, Tom Rondeau wrote:
> 
> On Thu, Mar 15, 2012 at 3:28 PM, Porges, Donald
> mailto:donald.por...@analog.com>> wrote: 
> Hi,
> 
> I'm trying to figure out a good way to distribute some custom heir
> blocks that go with my low-level custom blocks I've written.  The
> issue is that the xml and py files are both generated into my
> ~/.grc_gnuradio directory, and the xml files contain lines like
> 
> execfile("/Users/myname/.grc_gnuradio/file.py")
> 

Well, this is my doing, and I can't say I love it. The idea was that
user didnt need to set their PYTHONPATH.

This would be a code change, but it could be better replaced by "from
file import class". Here is the relevant line:
http://gnuradio.org/cgit/gnuradio.git/tree/grc/python/convert_hier.py#n39

I guess the additional thing is that the generated client code also
append os.path.join(os.expanduser('~'), '.grc_gnuradio') to the
sys.path, so the imports would still work when the PYTHONPATH env var
isnt set.

-josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Best way to share/install hierarchical grc blocks?

[Tom Rondeau]

On Thu, Mar 15, 2012 at 5:14 PM, Porges, Donald wrote:

> I've read that, and it only applies to telling grc where the xml is for a
> non-hierarchical block; that is, it solves a build-time problem, not a
> runtime problem.
>


Oh, I see. I wasn't reading closely enough. So generally, I've just used
the original XML file that you create and save yourself in whatever
directory you're working in. You can pass this along and then others would
open up gnuradio-companion, open this file, and build it locally themselves.

But that still feels kludgy, doesn't it? I've always ignored the .xml file
you're talking about, though. You could just pass around your original grc
file and the py file that's created. There's someone who has also created a
grcc (I think that's the name they gave it) that allows you to take a grc
file and compile it into a Python file by running this on the command line.
We have talked about getting it into GNU Radio, but I need to track it down
again. This might help, so now you just pass around your .grc file and the
other people can more easily just run grcc against it to create the hier
block. I assume that when grcc would "compile" a hierarchical block that it
would end up in the user's ~/.grc_gnuradio directory just like if you
created it in gnuradio-companion.

Anyone have more info on this tool?

Tom




> On Mar 15, 2012, at 5:07 PM, Tom Rondeau wrote:
>
> On Thu, Mar 15, 2012 at 3:28 PM, Porges, Donald  > wrote:
> Hi,
>
> I'm trying to figure out a good way to distribute some custom heir blocks
> that go with my low-level custom blocks I've written.  The issue is that
> the xml and py files are both generated into my ~/.grc_gnuradio directory,
> and the xml files contain lines like
>
> execfile("/Users/myname/.grc_gnuradio/file.py")
>
> which obviously is not distributable.  (Those lines get generated into any
> grc output files that use the block, so editing it at the point of use is
> not much of a solution.)
>
> The obvious answer is to edit that line by hand, but the next problem is
> that I don't even know where the gnuradio directory is for other people
> (could be a different host platform, for instance).  There also seems to be
> no "execfile search path" concept, which would allow me to perform some
> light editing of the xml file to remove the absolute path.  So how do
> people share their created hierarchical blocks?
>
> (I suppose the answer could be "give them my .grc_gnuradio files and tell
> them to edit all of the references", but that doesn't make for a nice
> delivery.)
>
> Don Porges
> Lyric Labs/Analog Devices
>
>
> Does this help?
>
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Installing-the-XML-Block-Definition
>
> Tom
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Best way to share/install hierarchical grc blocks?

[Porges, Donald]

I need to think about some of these ideas, but wanted to thank both of you for 
the replies.  My inclination right now is to install the .py.xml into the grc 
installation-wide "blocks" directory, and the .py into the correct gr 
subdirectory for my additions,
and then have an install-time step that edits the .py.xml so that the execfile 
line points directly to that .py file.  (I'm presuming that a hier-block  
.py.xml file, once installed in the "normal" place, won't try to mess with 
~/.grc_gnuradio, but I haven't tried it yet.)  I'm using the 
how-to-write-a-block framework, so the python install directory would be 
available to the Makefile in the build/grc directory (which right now has no 
build actions since it just is there for "make install")

Incidentally, I tried changing the execfile into "from dir import class", but 
it seemed to not quite produce the same state, in that I was not able to 
instantiate the module after that.  But I may have just done something wrong 
and given up too early.


On Mar 15, 2012, at 5:07 PM, Tom Rondeau wrote:

On Thu, Mar 15, 2012 at 3:28 PM, Porges, Donald 
mailto:donald.por...@analog.com>> wrote:
Hi,

I'm trying to figure out a good way to distribute some custom heir blocks that 
go with my low-level custom blocks I've written.  The issue is that the xml and 
py files are both generated into my ~/.grc_gnuradio directory, and the xml 
files contain lines like

execfile("/Users/myname/.grc_gnuradio/file.py")

which obviously is not distributable.  (Those lines get generated into any grc 
output files that use the block, so editing it at the point of use is not much 
of a solution.)

The obvious answer is to edit that line by hand, but the next problem is that I 
don't even know where the gnuradio directory is for other people (could be a 
different host platform, for instance).  There also seems to be no "execfile 
search path" concept, which would allow me to perform some light editing of the 
xml file to remove the absolute path.  So how do people share their created 
hierarchical blocks?

(I suppose the answer could be "give them my .grc_gnuradio files and tell them 
to edit all of the references", but that doesn't make for a nice delivery.)

Don Porges
Lyric Labs/Analog Devices


Does this help?

http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Installing-the-XML-Block-Definition

Tom




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] volk/cmake include preference issue

[Josh Blum]

It seems the volk library build was adding include paths for external
dependencies before adding local ones. In this case of external
dependencies like orc being installed into /usr/local, volk would be
compiling against headers that were potentially old gnuradio installs in
/usr/local

I know this caused an issue for some on freebsd (since many dependencies
go into /usr/local). And supposedly OSX in some cases as well.

Here is a potential fix, the output of make VERBOSE=1 -C volk seems to
indicate that the build includes are now listed first:
http://gnuradio.org/cgit/jblum.git/commit/?h=volk_include_order

I dont believe this is an issue for the rest of the components. It seems
that listing the build includes first was always the case and copied
into all the components.

-josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Best way to share/install hierarchical grc blocks?

[Porges, Donald]

I've read that, and it only applies to telling grc where the xml is for a 
non-hierarchical block; that is, it solves a build-time problem, not a runtime 
problem.


On Mar 15, 2012, at 5:07 PM, Tom Rondeau wrote:

On Thu, Mar 15, 2012 at 3:28 PM, Porges, Donald 
mailto:donald.por...@analog.com>> wrote:
Hi,

I'm trying to figure out a good way to distribute some custom heir blocks that 
go with my low-level custom blocks I've written.  The issue is that the xml and 
py files are both generated into my ~/.grc_gnuradio directory, and the xml 
files contain lines like

execfile("/Users/myname/.grc_gnuradio/file.py")

which obviously is not distributable.  (Those lines get generated into any grc 
output files that use the block, so editing it at the point of use is not much 
of a solution.)

The obvious answer is to edit that line by hand, but the next problem is that I 
don't even know where the gnuradio directory is for other people (could be a 
different host platform, for instance).  There also seems to be no "execfile 
search path" concept, which would allow me to perform some light editing of the 
xml file to remove the absolute path.  So how do people share their created 
hierarchical blocks?

(I suppose the answer could be "give them my .grc_gnuradio files and tell them 
to edit all of the references", but that doesn't make for a nice delivery.)

Don Porges
Lyric Labs/Analog Devices


Does this help?

http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Installing-the-XML-Block-Definition

Tom




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Volk on 32-bit archs

[Tom Rondeau]

I just merged my fixes for 32-bit architectures for Volk use on 32-bit
machines. If anyone was having problems before with this, they should be
cleaned up.

Josh's fix for the include directory was also just merged, so things should
be better now all around.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Release 3.5.2.1

[Johnathan Corgan]

This is a bug fix release to address certain issues with libvolk on
32-bit machines.

The new release tarball is at:

http://gnuradio.org/redmine/attachments/download/319/gnuradio-3.5.2.1.tar.gz

- Log -
v3.5.2.1

Johnathan Corgan (2):
 build: updated ignores
 update revision to v3.5.2.1

Josh Blum (2):
 cmake: add slackware detection
 volk: set local includes first for precedence

Nicholas Corgan (1):
 cmake: Windows uses size of void* to determine x86 vs. x64 and
names installer .exe accordingly

Tom Rondeau (4):
 core: makes sure that the Fourier taps for the FFT filter are aligned.
 volk: makes the float-to-int conversion consistent and fixes an
overflow bug on 32-bit machines.
 volk: turning off sse implementation of complex dot product for
32-bit machines until it's fixed.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] change gnuradio to pure c++ code?

[baobaonanpo D]

Hi,
Is there anyone has changed gnuradio framework files to pure c++ code
,removed the python code, or has interested in doing this, I do work
recently but encounter difficulties, can I so lucky to reference someone's
information or get a hand from you?
Thanks very much !
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] change gnuradio to pure c++ code?

[Johnathan Corgan]

On Thu, Mar 15, 2012 at 18:43, baobaonanpo D  wrote:

> Is there anyone has changed gnuradio framework files to pure c++ code
> ,removed the python code, or has interested in doing this, I do work
> recently but encounter difficulties, can I so lucky to reference someone's
> information or get a hand from you?

GNU Radio has supported C++ only applications, without Python
involved, for several years.  For a simple example, see:

http://gnuradio.org/cgit/gnuradio.git/tree/gr-audio/examples/c++/dial_tone.cc

For a fully developed, "real" application:

https://github.com/csete/gqrx

Johnathan

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Trouble building (32-bit Linux, volk-related?)

[Ian Cullinan]

Hi all,

I'm having trouble building gnuradio from git on my 32-bit Ubuntu 10.10
machine. The error I'm getting is:

$ make
[  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, volk_machine_avx_32.c, 
volk_machine_avx_only.c
[  0%] Generating volk_32f_x2_min_32f_a_orc_impl.c
[  0%] Generating volk_32fc_x2_multiply_32fc_a_orc_impl.c
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: splitql
ERROR: unknown token[0]: swaplq
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: splitql
ERROR: unknown token[0]: mergelq
Failed to compile volk_32fc_x2_multiply_32fc_a_orc_impl
Failed to compile volk_32fc_x2_multiply_32fc_a_orc_impl
make[2]: *** [volk/lib/volk_32fc_x2_multiply_32fc_a_orc_impl.c] Error 1
make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2
make: *** [all] Error 2


I successfully built and installed from git late last year without any
problems, so my first thought was that I had old code lying around
screwing things up so I deleted my whole gnuradio source tree and `git
clone`d a new one to no avail. I also get the same error if I `git
checkout` any of the v3.5 tags so I don't think it's a recent code
change that's broken things.

I assume this means there's something wrong with my system - does anyone
have suggestions as where to look? 

Thanks,
Ian Cullinan


__
This communication contains information which may be confidential or 
privileged. The information is intended solely for the use of the individual or 
entity named above.  If you are not the intended recipient, be aware that any 
disclosure, copying, distribution or use of the contents of this information is 
prohibited.  If you have received this communication in error, please notify me 
by telephone immediately.
__

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio