Master build failure for ARM when building cross

Any ideas? I haven’t looked at it hard yet.

Philip

eglibc/sysroots/ettus-e200/usr/include -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized -o
CMakeFiles/test-gr-blocks.dir/qa_gr_block.cc.o -c
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/gr-blocks/lib/qa_gr_block.cc
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7083:22:
error: redefinition of ‘struct swig::traits’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6345:22:
error: previous definition of ‘struct swig::traits’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7087:23:
error: redefinition of ‘struct swig::traits_asval’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6349:23:
error: previous definition of ‘struct swig::traits_asval’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7093:23:
error: redefinition of ‘struct swig::traits_from’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6355:23:
error: previous definition of ‘struct swig::traits_from’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueab:

I meant I see this on next :slight_smile: Google suggests x86 builds had this
problem mid February and it was fixed then, but i can’t find a commit
claiming to fix this.

Tom, any hints where to look?

Philip

-------- Original Message --------
Subject: [Discuss-gnuradio] Master build failure for ARM when building
cross
Date: Thu, 18 Apr 2013 21:38:53 -0400
From: Philip B. [email protected]
To: GNURadio D.ion List [email protected]

Any ideas? I haven’t looked at it hard yet.

Philip

eglibc/sysroots/ettus-e200/usr/include -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized -o
CMakeFiles/test-gr-blocks.dir/qa_gr_block.cc.o -c
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/gr-blocks/lib/qa_gr_block.cc
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7083:22:
error: redefinition of ‘struct swig::traits’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6345:22:
error: previous definition of ‘struct swig::traits’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7087:23:
error: redefinition of ‘struct swig::traits_asval’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6349:23:
error: previous definition of ‘struct swig::traits_asval’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7093:23:
error: redefinition of ‘struct swig::traits_from’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6355:23:
error: previous definition of ‘struct swig::traits_from’
/home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueab:


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Philip, this is problem of no help but I ran into this issue when I was
still using ubuntu 10.04, I found a reference where Marcus was having
the
same problem but on ubuntu 12.04

http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00178.html

where I applied the recommended changes and added some other mods
recommended by Josh but I couldn’t fix it I ended up upgrading from
10.04
to 12.04 and everything worked.

My suspicion, and again I’m probably the wrong person to comment on
this,
is that it was a swig/python version issue 10.04 was running Python 2.6
I
don’t remember what swig version and 12.04 is running Python 2.7 and
swig
2.0.4. I would recommend experimenting with alternative swig versions
and
see if the problem goes away.

al fayez

I had problems similar to this using swig < 2.0. Swig 2.0.4 helped.

On Mon, Apr 22, 2013 at 7:08 PM, Almohanad F.

On Mon, Apr 22, 2013 at 7:13 PM, Tim N. [email protected]
wrote:

I had problems similar to this using swig < 2.0. Swig 2.0.4 helped.

May well be fixed by an update to SWIG. This is a problem with all the
areas we’re using SWIG and defining types. Swig doesn’t understand (or
keep track of) when we’re defining typedefs, so its getting conflicts
in various places for various reasons. It was a huge pain to diagnose
and figure out because a fix on 32-bit machines broke the 64-bit, and
vice versa. Frankly, I was just hoping that by keeping silent and
ignoring it, the problem would go away…

The solution is in commit 8088f125a9a (on Mar. 29). I’m not sure why
it really started, honestly, but it seems related to the removal of
gruel and some delicate balance we had working beforehand. Why it’s
happening again, I’m not sure. With luck, though, upgrading SWIG to >
2.0 wll fix it.

Tom

Hi,

The solution is in commit 8088f125a9a (on Mar. 29). I’m not sure why
it really started, honestly, but it seems related to the removal of
gruel and some delicate balance we had working beforehand. Why it’s
happening again, I’m not sure. With luck, though, upgrading SWIG to >
2.0 wll fix it.

I have here Kubuntu 12.04, 32 bit, with swig 2.04 installed, and still
“next” does not build, with an error like mentioned in this thread,
somewhere around 72%.
Sorry, but your hope got not fulfilled, the error did not vanish :slight_smile:

Tom

Ralph.

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

Stupid, but obligatory Q: Did you clear the build dir?

Yes, deleted manually the build folder, did a git clean -dxf, the whole
procedure :slight_smile:

MB

Ralph.

On Tue, Apr 23, 2013 at 09:46:37AM +0200, Ralph A. Schmid, dk5ras wrote:

I have here Kubuntu 12.04, 32 bit, with swig 2.04 installed, and still
“next” does not build, with an error like mentioned in this thread,
somewhere around 72%.
Sorry, but your hope got not fulfilled, the error did not vanish :slight_smile:

Stupid, but obligatory Q: Did you clear the build dir?

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

On 04/23/2013 03:49 AM, Martin B. (CEL) wrote:

On Tue, Apr 23, 2013 at 09:46:37AM +0200, Ralph A. Schmid, dk5ras wrote:

I have here Kubuntu 12.04, 32 bit, with swig 2.04 installed, and still
“next” does not build, with an error like mentioned in this thread,
somewhere around 72%.
Sorry, but your hope got not fulfilled, the error did not vanish :slight_smile:

Stupid, but obligatory Q: Did you clear the build dir?

Yes.

On 04/22/2013 09:59 PM, Tom R. wrote:

The solution is in commit 8088f125a9a (on Mar. 29). I’m not sure why
it really started, honestly, but it seems related to the removal of
gruel and some delicate balance we had working beforehand. Why it’s
happening again, I’m not sure. With luck, though, upgrading SWIG to >
2.0 wll fix it.

Already using swig 2.0.9 and Python 2.7.3.

Philip

On 04/22/2013 09:59 PM, Tom R. wrote:

The solution is in commit 8088f125a9a (on Mar. 29). I’m not sure why
it really started, honestly, but it seems related to the removal of
gruel and some delicate balance we had working beforehand. Why it’s
happening again, I’m not sure. With luck, though, upgrading SWIG to >
2.0 wll fix it.

I tracked the source of my issue to this commit:

71803b9ae55e688476f24637713a89ab6bd2cf17

The prior commit:

ce52bd370c0b13ed4de11df08168768dec327497

builds fine.

I believe these commits are on the maint branch. I’m going to confirm
that head of maint will fail for me.

I’ll poke at this more later. Apparently, we are having spring today in
Blacksburg, so I am going to ride :slight_smile:

Philip

On 04/23/2013 04:10 PM, Philip B. wrote:

ignoring it, the problem would go away…

The prior commit:

ce52bd370c0b13ed4de11df08168768dec327497

builds fine.

I believe these commits are on the maint branch. I’m going to confirm
that head of maint will fail for me.

Head of maint builds. Now looking for what fixed it and how all this
relates to next.

Philip

On Tue, Apr 23, 2013 at 1:32 PM, Philip B.
[email protected]wrote:

Head of maint builds. Now looking for what fixed it and how all this
relates to next.

The fix further along the maint branch might not have gotten merged up
to
next for some reason. Let me know what you find out.

On 04/23/2013 04:10 PM, Philip B. wrote:

ignoring it, the problem would go away…

The prior commit:

ce52bd370c0b13ed4de11df08168768dec327497

builds fine.

The merge 06949d7800f37b7a520e37105972b14f2b71025c

introduces the build failure to next.

The commit 78cd4026c0a9b902162e94905b60a9dd44a07bb7 on maint fixes it.

So it looks like none of the merges from maint->master->next solved the
problem on next.

Looking at the fix isn’t helping me fix the problem on next :frowning:

Philip

On Wed, Apr 24, 2013 at 10:56 AM, Philip B. [email protected]
wrote:

I’ve been trying to find something in next that did not propagate
through from the fix and am not having any luck finding it.

Thanks for all the version testing. I’ll be working on this today.


Johnathan C.
Corgan Labs - SDR Training and Development Services
http://corganlabs.com

On 04/24/2013 02:18 PM, Johnathan C. wrote:

On Wed, Apr 24, 2013 at 10:56 AM, Philip B. [email protected] wrote:

I’ve been trying to find something in next that did not propagate
through from the fix and am not having any luck finding it.

Thanks for all the version testing. I’ll be working on this today.

I did one last test using OE. I did builds for the qemux86 and
qemux86-64 machines. Only the x86-64 gnuradio-next build succeeded.

Looks like next has an issue on 32 bit builds.

Philip

On 04/24/2013 11:31 AM, Philip B. wrote:

vice versa. Frankly, I was just hoping that by keeping silent and
71803b9ae55e688476f24637713a89ab6bd2cf17

The commit 78cd4026c0a9b902162e94905b60a9dd44a07bb7 on maint fixes it.

So it looks like none of the merges from maint->master->next solved the
problem on next.

Looking at the fix isn’t helping me fix the problem on next :frowning:

One final data set. Following master:

4baee9bde3c49662162a7b58aec564e2925f8fda

fails to build

4a95aa2fbbe28f046d4925a44d7a0021050ced34

is where the fix is merged in and builds again

I looked at the next master-next merge at

2a525ac04bcb0a70d193bddf9ba1018a99484904

and next fails to build here.

I’ve been trying to find something in next that did not propagate
through from the fix and am not having any luck finding it.

Philip