Official bladeRF forum

Posted: **Tue Jan 23, 2018 6:25 am**

Hello, recently i have been trying to get yatebts to work on my machine, but for now no luck. Yate gets compiled and works ok, but yatebts crash on error during the make process. Here is the output i get:
Makefile:122: recipe for target 'MSInfo.o' failed
make[2]: *** [MSInfo.o] Error 1
make[2]: Leaving directory '/root/yate-bts/mbts/GPRS'
Makefile:140: recipe for target '../GPRS/libGPRS.a' failed
make[1]: *** [../GPRS/libGPRS.a] Error 2
make[1]: Leaving directory '/root/yate-bts/mbts/apps'
Makefile:53: recipe for target 'all' failed
make: *** [all] Error 2

I tried on several installations of linux but always get the same error. Anyone has faced this problem and managed to solve it?.
Thanks in advance!!!!

Posted: **Tue Jan 23, 2018 10:34 am**

The first error there is talking about MSInfo.o, and that error is likely killing the rest of the make script. I could be wrong, but MSInfo sounds like some Microsoft thing, which sounds suspicious to me if you're building on Linux. Can you post more details leading up to that error? Also try running make with a single job at a time and more verbose output:

Code: Select all

make -j1 VERBOSE=1

Posted: **Wed Jan 24, 2018 6:34 am**

I'm investigating, but have no clue what could be that MSinfo.o object file. The files were cloned with git from the yate-bts repository and tried on a linux box. No windows here. I have been searching for that file but nothing comes out of a search in my box.
Will keep investigating.

Posted: **Wed Jan 24, 2018 3:26 pm**

Yate is trying to generate that object file from the following source files:

Code: Select all

mbts/GPRS/MSInfo.h
mbts/GPRS/MSInfo.cpp

In this case, MS is "multislot", so please disregard my ignorant post earlier. (In my defense, I hadn't read the code before making the comment!)

I run Arch Linux, so I just grabbed the precompiled Yate dependency from pacman. Then I did an SVN checkout of the latest yatebts, ran the autogen.sh and configure scripts -- no errors. Finally, running "make" I got the same MSInfo error you did. However, if you grep for error messages leading up to that point, I see a bunch of stuff like this:

Code: Select all

MSInfo.cpp: In member function ‘bool GPRS::MSInfo::msAssignChannels()’:                                                                                               
MSInfo.cpp:641:86: error: no match for ‘operator<<’ (operand types are ‘std::ostream {aka std::basic_ostream<char>}’ and ‘std::ostringstream {aka std::__cxx11::basic_ostringstream<char>}’)
             GPRSLOG(INFO,GPRS_MSG|GPRS_CHECK_OK) << "Multislot assignment for "<<this<<os;                                                                                                     
/usr/include/c++/7.2.1/ostream:220:7: note:   no known conversion for argument 1 from ‘std::ostringstream {aka std::__cxx11::basic_ostringstream<char>}’ to ‘double’                                                                                                                                        
g++ -Wall   -I../.. -I../.. -I. -I./../CommonLibs -I./../A53 -I./../Connection -I./../GSM -I./../Globals -I./../sqlite3 -I./../Control -I./../CLI -I./../GPRS -I./../Peering -I./../SGSNGGSN -I./../TRXManager -O2 -DLITTLE_ENDIAN -Wno-overloaded-virtual -fPIC -DHAVE_GCC_FORMAT_CHECK -DHAVE_BLOCK_RETURN
 -I/usr/include/yate -DHAVE_CONFIG_H -c  RLCEngine.cpp                                                                                                                     
/usr/include/c++/7.2.1/ostream:224:7: note: candidate: std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(float) [with _CharT = char; _Traits = std::char_traits<char>; std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream<char>]
       operator<<(float __f)                                                                                                                                                                                                                                                                                
       ^~~~~~~~                                                                                                                                                                                                                                     
MSInfo.cpp:641:86: note: candidate: operator<<(int, int) <built-in>                                                                                                                                                                                                                                         
/usr/include/c++/7.2.1/ostream:224:7: note:   no known conversion for argument 1 from ‘std::ostringstream {aka std::__cxx11::basic_ostringstream<char>}’ to ‘float’        
MSInfo.cpp:641:86: note:   no known conversion for argument 2 from ‘std::ostringstream {aka std::__cxx11::basic_ostringstream<char>}’ to ‘int’                                                                                                                                                              
/usr/include/c++/7.2.1/ostream:232:7: note: candidate: std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(long double) [with _CharT = char; _Traits = std::char_traits<char>; std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream<cha
r>]                                                                                                                                                                            
       operator<<(long double __f)                                                                                                                                               
       ^~~~~~~~

The << operator is overloaded, and I don't think they would have put code this broken into master/trunk. Therefore, I suspect that this may be "yet another" one of those GCC v6 --> GCC v7 portability issues (I have GCC v7.2.1). What version of GCC do you have?

I'll see if I can massage the code into building, but it might take some time as I'm balancing a few other tasks at the moment.

Posted: **Thu Jan 25, 2018 4:08 pm**

Yeah, so there is a similar issue #416 in their issue tracker about gcc6. I decided to go straight to gcc5 from the Arch AUR. If you're running another Linux distro, you'd have to take whatever steps are necessary to build and/or install gcc5 (v5.5.0).

Then run the following in the root of your checked out yatebts repo:

Code: Select all

make clean
# I assume you've already run autogen.sh
./configure --prefix=/your/install/prefix CXX=$(which c++-5) CC=$(which gcc-5) CPP=$(which cpp-5)
make
echo $?

And it seems to have built successfully for me. Please let me know how this goes on your end.

Edit: My binaries are named c++-5, gcc-5, and cpp-5. You'd have to make the necessary changes if your gcc5 binaries are named differently.

Posted: **Sun Jan 28, 2018 9:40 am**

Thanks a lot for the responses. I have checked and i'm already in gcc 7, but trying to install the package on my distro seems to not be possible, as it has been removed. My distro is kali linux rolling but i'm having problems trying to locate the package. At the moment i'm trying to get the gcc5 package from the deprecated repositories but so far haven't got any luck.

Posted: **Tue Jan 30, 2018 6:53 am**

Hello all, i finally managed to build the yatebts package without the install of gcc5 applying a patch provided here: http://yate.null.ro/mantis/view.php?id=416. It modifies the two files that use the wrong code for that version. I tested it and it builds ok.
The problem i have now is that it seems to not detect the bladerf as it shows the following error:

Starting MBTS...
2018-01-29_14:15:13.011142 <gsmtrx:GOON> Failed to create radio interface: Message not handled
ALERT 140619497412416 14:15:13.0 TRXManager.cpp:135:sendCommand: RESET failed with status 2
2018-01-29_14:15:13.011269 <mbts:WARN> TRXManager.cpp:135:sendCommand: RESET failed with status 2
ALERT 140619497412416 14:15:13.0 OpenBTS.cpp:250:main: Failed to reset transceiver
2018-01-29_14:15:13.011440 <mbts:WARN> OpenBTS.cpp:250:main: Failed to reset transceiver

Posted: **Tue Jan 30, 2018 9:37 am**

Problem solved. Seems that libusb needs to be installed at build time. I installed it, and rebuild the two apps(yate and yatebts) and all is working now.
Thanks!!

Posted: **Tue Jan 30, 2018 10:06 am**

Great news!

Posted: **Thu Mar 08, 2018 3:22 am**

hey,

how do you apply patch to the yatebts downloads?

Thanks

Posted: **Fri Mar 09, 2018 10:22 am**

First, download the .patch file attached to issue #416. Review it to make sure there's nothing nefarious in there (it's fine as of this writing).

If you have a checked out copy of yatebts SVN trunk with no local changes, you should be able to have SVN apply the patch for you. Assuming your current directory and the .patch file are in the root of the checked out repository:

Code: Select all

# Dry-run first to make sure there are no issues
[yatebts-svn]$ svn patch --strip 1 --dry-run yatebts-5.0.0-gcc6.patch
U         mbts/GPRS/MSInfo.cpp
U         mbts/SGSNGGSN/Sgsn.cpp
>         applied hunk @@ -252,7 +252,7 @@ with offset 1

# Looks good ... now actually apply the patch
[yatebts-svn]$ svn patch --strip 1 yatebts-5.0.0-gcc6.patch

# Optional: running `svn diff' should look identical to the contents of yatebts-5.0.0-gcc6.patch
[yatebts-svn]$ svn diff

# Proceed with normal build steps

If you downloaded the release tarball, use the `patch' command instead (this also works on the above if you don't want to use `svn patch' for whatever reason).

Code: Select all

# Dry-run first to make sure there are no issues
[yatebts-tarball]$ patch --dry-run -p1 -i yatebts-5.0.0-gcc6.patch
checking file mbts/GPRS/MSInfo.cpp                                      
checking file mbts/SGSNGGSN/Sgsn.cpp                                    
Hunk #2 succeeded at 253 (offset 1 line).                               

# No issues, so actually apply the patch
[yatebts-tarball]$ patch -p1 -i yatebts-5.0.0-gcc6.patch

# Proceed with normal build steps

Posted: **Tue May 29, 2018 9:24 pm**

creator9724 wrote: ↑Tue Jan 30, 2018 9:37 am Problem solved. Seems that libusb needs to be installed at build time. I installed it, and rebuild the two apps(yate and yatebts) and all is working now.
Thanks!!

hi men can you share the procedure or the url whit the steps and the right firmware to get work sucessfull, i have one week trying with many firmwares ando compilling several firmwares but dont get luck, can you give me a referer how do you did it please. thanks

Posted: **Wed May 30, 2018 8:56 am**

hackultimate wrote: ↑Tue May 29, 2018 9:24 pm
creator9724 wrote: ↑Tue Jan 30, 2018 9:37 am Problem solved. Seems that libusb needs to be installed at build time. I installed it, and rebuild the two apps(yate and yatebts) and all is working now.
Thanks!!
hi men can you share the procedure or the url whit the steps and the right firmware to get work sucessfull, i have one week trying with many firmwares ando compilling several firmwares but dont get luck, can you give me a referer how do you did it please. thanks

Please provide the steps you took and where you are getting stuck. Build logs/errors are usually the most helpful.

Official bladeRF forum

Problem building yatebts. Anyone has a clue?

Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?

Re: Problem building yatebts. Anyone has a clue?