OpenBTS compilation error


#1

First I got the openBTS code from gnuradio site (svn co
http://gnuradio.org/svn/openbts/trunk/ openbts).

Then I run the ./bootstrap and ./configure commands succesfully.

But the following errors occurred when I run make. (“xxxx” was used to
mask out my username on the machine.) Can anyone shed some light on
this?

I was using a 32-bit Ubuntu 8.10 desktop virtual machine on a 64-bit
Windows XP machine.

Thanks!


make[2]: Entering directory /home/xxxx/openbts/openbts/Transceiver' if /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I. . -I../CommonLibs -I../Control -I../GSM -I../SIP -I../TRXManager -I/usr/local/i nclude -g -O2 -MT radioInterface.lo -MD -MP -MF ".deps/radioInterface.Tpo" -c -o radioInterface.lo radioInterface.cpp; \ then mv -f ".deps/radioInterface.Tpo" ".deps/radioInterface.Plo"; else r m -f ".deps/radioInterface.Tpo"; exit 1; fi libtool: compile: g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../CommonLibs -I../Control -I../GSM -I../SIP -I../TRXManager -I/usr/local/include -g -O2 -MT radioInterfac e.lo -MD -MP -MF .deps/radioInterface.Tpo -c radioInterface.cpp -fPIC -DPIC -o .libs/radioInterface.o In file included from USRPDevice.h:25, from radioInterface.h:25, from radioInterface.cpp:23: /usr/local/include/usrp_bytesex.h:37:2: warning: #warning Using non-portable cod e (likely wrong other than ILP32). In file included from radioInterface.h:24, from radioInterface.cpp:23: sigProcLib.h:35: warning: ‘typedef’ was ignored in this declaration sigProcLib.h:45: warning: ‘typedef’ was ignored in this declaration In file included from radioInterface.h:25, from radioInterface.cpp:23: USRPDevice.h:42: error: ‘usrp_standard_rx_sptr’ does not name a type USRPDevice.h:43: error: ‘usrp_standard_tx_sptr’ does not name a type make[2]: *** [radioInterface.lo] Error 1 make[2]: Leaving directory/home/xxxx/openbts/openbts/Transceiver’


#2

T. W. wrote:

Windows XP machine.
“.deps/radioInterface.Tpo” -c
.libs/radioInterface.o
In file included from USRPDevice.h:25,
from radioInterface.h:25,
from radioInterface.cpp:23:
/usr/local/include/usrp_bytesex.h:37:2: warning: #warning Using
non-portable cod
e (likely wrong other than ILP32).

This is a known bug.
A temporary workaround can be done by using attached patch.

See description below.

Martin DvH wrote:

I haven’t gotten to implementing the configure stuff yet.

This patch should be changed to use configure stuff to check for byteswap.h.
But for people wanting a quick-and-dirty hack it can be used.

Greetings,
Martin


#3

Martin,

Thanks very much for your help!

Your patch #1 seems to be already in the subversion repository.

I manually applied your patch #2 to /Transceiver/USRPDevice.h. Now the
following warning went away.

“.deps/radioInterface.Tpo” -c
.libs/radioInterface.o
In file included from USRPDevice.h:25,
from radioInterface.h:25,
from radioInterface.cpp:23:
/usr/local/include/usrp_bytesex.h:37:2: warning: #warning Using
non-portable cod
e (likely wrong other than ILP32).

But the other two warnings/errors still remain as follows.

libtool: compile: g++ -DHAVE_CONFIG_H -I. -I. -I… -I…/CommonLibs
-I…/Control -I…/GSM -I…/SIP -I…/TRXManager -I/usr/local/include -g
-O2 -MT radioInterface.lo -MD -MP -MF .deps/radioInterface.Tpo
-c radioInterface.cpp -fPIC -DPIC -o .libs/radioInterface.o
In file included from radioInterface.h:24,
from radioInterface.cpp:23:
sigProcLib.h:35: warning: ‘typedef’ was ignored in this declaration
sigProcLib.h:45: warning: ‘typedef’ was ignored in this declaration
In file included from radioInterface.h:25,
from radioInterface.cpp:23:
USRPDevice.h:42: error: ‘usrp_standard_rx_sptr’ does not name a type
USRPDevice.h:43: error: ‘usrp_standard_tx_sptr’ does not name a type
make[2]: *** [radioInterface.lo] Error 1

I did a quick grep but couldn’t find where “usrp_standard_rx_sptr” was
defined… The following two lines were all I found…

./USRPDevice.h~: usrp_standard_rx_sptr m_uRx; ///< the USRP receiver
./USRPDevice.h: usrp_standard_rx_sptr m_uRx; ///< the USRP receiver


#4

I have gnuradio-3.1.3. I grabbed the tarball, then followed the
./configure, make, make install process when I installed it. I can see
the following four files in /usr/local/lib/ :

-rwxr-xr-x 1 root root 938 2009-02-18 15:57 libusrp.la
lrwxrwxrwx 1 root root 16 2009-02-18 15:57 libusrp.so ->
libusrp.so.0.0.0
lrwxrwxrwx 1 root root 16 2009-02-18 15:57 libusrp.so.0 ->
libusrp.so.0.0.0
-rwxr-xr-x 1 root root 412687 2009-02-18 15:57 libusrp.so.0.0.0

Does it like right?

Are you saying usrp_standard_rx_sptr and usrp_standard_tx_sptr were
defined in libusrp?

Thanks!

-TW

Fabian wrote:

Do you have the latest trunk version of GNURadio installed correctly?
Do you have the library libusrp?

  • Fabian

Am 27.02.2009 um 19:55 schrieb T. W.:


#5

Hi,

I also encountered the same errors.
USRPDevice.h:42: error: ‘usrp_standard_rx_sptr’ does not name a type
USRPDevice.h:43: error: ‘usrp_standard_tx_sptr’ does not name a type

Where can I get the “attached patch”???

Thank you,
Jane

Martin D. wrote:

T. W. wrote:

Windows XP machine.
“.deps/radioInterface.Tpo” -c
.libs/radioInterface.o
In file included from USRPDevice.h:25,
from radioInterface.h:25,
from radioInterface.cpp:23:
/usr/local/include/usrp_bytesex.h:37:2: warning: #warning Using
non-portable cod
e (likely wrong other than ILP32).

This is a known bug.
A temporary workaround can be done by using attached patch.

See description below.

Martin DvH wrote:

I haven’t gotten to implementing the configure stuff yet.

This patch should be changed to use configure stuff to check for byteswap.h.
But for people wanting a quick-and-dirty hack it can be used.

Greetings,
Martin


#6

Do you have the latest trunk version of GNURadio installed correctly?
Do you have the library libusrp?

  • Fabian

Am 27.02.2009 um 19:55 schrieb T. W.:


#7

You have to take the latest trunk of GNURadio, not the 3.1.3. release.
Get it with

svn co http://gnuradio.org/svn/gnuradio/trunk gnuradio

and follow the instructions on this page
http://gnuradio.org/trac/wiki/BuildGuide

  • Fabian

Am 27.02.2009 um 22:44 schrieb T. W.:


#8

Jane C. wrote:

Hi,

I also encountered the same errors.
USRPDevice.h:42: error: ‘usrp_standard_rx_sptr’ does not name a type
USRPDevice.h:43: error: ‘usrp_standard_tx_sptr’ does not name a type

Where can I get the “attached patch”???
It was in my original reply:
Here you have the complete patch inline:
<<>>>
Index: Transceiver/USRPDevice.h
===================================================================
— Transceiver/USRPDevice.h (revision 10235)
+++ Transceiver/USRPDevice.h (working copy)
@@ -19,8 +19,8 @@

*/

+#define HAVE_BYTESWAP_H

#include “usrp_standard.h”
#include “usrp_bytesex.h”
#include “usrp_prims.h”

<<>>

Greetings,
Martin


#9

Hi Fabian and Martin,

The problem is solved. Thank you so much for your time and help!!

Regards,
Jane

Martin D. wrote:

Jane C. wrote:

Hi,

I also encountered the same errors.
USRPDevice.h:42: error: ‘usrp_standard_rx_sptr’ does not name a type
USRPDevice.h:43: error: ‘usrp_standard_tx_sptr’ does not name a type

Where can I get the “attached patch”???
It was in my original reply:
Here you have the complete patch inline:
<<>>>
Index: Transceiver/USRPDevice.h
===================================================================
— Transceiver/USRPDevice.h (revision 10235)
+++ Transceiver/USRPDevice.h (working copy)
@@ -19,8 +19,8 @@

*/

+#define HAVE_BYTESWAP_H

#include “usrp_standard.h”
#include “usrp_bytesex.h”
#include “usrp_prims.h”

<<>>

Greetings,
Martin


#10

Index: Transceiver/USRPDevice.h

— Transceiver/USRPDevice.h (revision 10235)
+++ Transceiver/USRPDevice.h (working copy)
@@ -19,8 +19,8 @@

*/

+#define HAVE_BYTESWAP_H

The correct fix was to add the missing autoconf section to the start
of USRPDevice.cpp:

Modified: openbts/trunk/Transceiver/USRPDevice.cpp

— openbts/trunk/Transceiver/USRPDevice.cpp 2009-03-03 19:44:29
UTC (rev 10556)
+++ openbts/trunk/Transceiver/USRPDevice.cpp 2009-03-04 18:12:16
UTC (rev 10557)
@@ -26,6 +26,9 @@
SWLOOPBACK compile for software loopback testing
*/

+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif

This has been done in the openbts trunk.

Johnathan