Using Protobuf - Error
-
@joh my guess is that it is not picking up the correct library, add -d option to your command line so script will spit out the details.
-
I just tried compiling "protobuf" in an Omega2+, after installing gcc (with an sd card overlay).
protobuf-3.13.0 (latest):
root@Omega-745F:~# wget -c https://github.com/protocolbuffers/protobuf/releases/download/v3.13.0/protobuf-cpp-3.13.0.tar.gz
root@Omega-745F:~# tar xf protobuf-cpp-3.13.0.tar.gz
root@Omega-745F:~# cd protobuf-3.13.0
root@Omega-745F:~/protobuf-3.13.0#./confiure
..
..
checking zlib version... headers missing or too old (requires 1.2.0.4)
checking whether g++ supports C++11 features by default... yes
checking whether -latomic is needed... yes
checking whether gcc is Clang... no
checking whether pthreads work with -pthread... no
checking whether pthreads work with -pthreads... no
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -pthread... no
checking whether pthreads work with -pthreads... no
checking whether pthreads work with -mthreads... no
checking for the pthreads library -lpthread... no
checking whether pthreads work with --thread-safe... no
checking whether pthreads work with -mt... no
checking for pthread-config... no
checking the location of hash_map... <unordered_map>
..
configure: creating ./config.status
config.status: creating Makefile
config.status: creating scripts/gmock-config
config.status: creating build-aux/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
root@Omega-745F:~/protobuf-3.13.0# make
..
make[2]: Entering directory '/root/protobuf-3.13.0/src'
CXX google/protobuf/compiler/main.o
CXX google/protobuf/stubs/bytestream.lo
CXX google/protobuf/stubs/common.lo
google/protobuf/stubs/common.cc:50:2: error: #error "No suitable threading library available."
#error "No suitable threading library available."protobuf-2.6.1:
root@Omega-745F:~# wget -c https://github.com/protocolbuffers/protobuf/releases/download/v2.6.1/protobuf-2.6.1.tar.bz2
root@Omega-745F:~# tar xf protobuf-2.6.1.tar.bz2
root@Omega-745F:~# cd protobuf-2.6.1
root@Omega-745F:~/protobuf-2.6.1# ./configure
..
checking zlib version... ok (1.2.0.4 or later)
checking for library containing zlibVersion... no
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking whether to check for GCC pthread/shared inconsistencies... yes
checking whether -pthread is sufficient with -shared... yes
checking whether what we have so far is sufficient with -nostdlib... yes
..
configure: creating ./config.status
config.status: creating Makefile
config.status: creating scripts/gtest-config
config.status: creating build-aux/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
root@Omega-745F:~/protobuf-2.6.1# make
..
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -DNDEBUG -MT google/proo
/tmp/ccoONjbE.s: Assembler messages:
/tmp/ccoONjbE.s:1926: Error: opcode not supported on this processor: mips1 (mips1)sync' /tmp/ccoONjbE.s:4614: Error: opcode not supported on this processor: mips1 (mips1)sync'
/tmp/ccoONjbE.s:5532: Error: opcode not supported on this processor: mips1 (mips1) `sync'
make[2]: *** [Makefile:2055: google/protobuf/stubs/common.lo] Error 1
make[2]: Leaving directory '/root/protobuf-2.6.1/src'
make[1]: *** [Makefile:700: all-recursive] Error 1
make[1]: Leaving directory '/root/protobuf-2.6.1'
make: *** [Makefile:606: all] Error 2protobuf-2.4.1: (the very first version available for download)
root@Omega-745F:~# wget -c https://github.com/protocolbuffers/protobuf/releases/download/v2.4.1/protobuf-2.4.1.tar.bz2
root@Omega-745F:~# tar xf protobuf-2.4.1.tar.bz2
root@Omega-745F:~# cd protobuf-2.4.1/
root@Omega-745F:~/protobuf-2.4.1# ./configure
..
checking zlib version... ok (1.2.0.4 or later)
checking for library containing zlibVersion... no
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking whether to check for GCC pthread/shared inconsistencies... yes
checking whether -pthread is sufficient with -shared... yes
checking whether what we have so far is sufficient with -nostdlib... yes
..
configure: creating ./config.status
config.status: creating Makefile
config.status: creating scripts/gtest-config
config.status: creating build-aux/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
root@Omega-745F:~/protobuf-2.4.1# time make
..
make[3]: Leaving directory '/root/protobuf-2.4.1/src'
make[2]: Leaving directory '/root/protobuf-2.4.1/src'
make[1]: Leaving directory '/root/protobuf-2.4.1'
real 1h 16m 46s
user 1h 6m 01s
sys 2m 10.58s
root@Omega-745F:~/protobuf-2.4.1#Note:
Omega2+ (128MB) requires 50MB+ swap for compilationroot@Omega-745F:~/protobuf-3.13.0# free
total used free shared buffers cached
Mem: 124808 101348 23460 8 14884 31080
-/+ buffers/cache: 55384 69424
Swap: 131068 2048 129020Without swap compilation fails for v.2.4.1, which is the only version that still stays in after a few seconds since "make" is run):
virtual memory exhausted: Out of memory
make[2]: *** [Makefile:1179: descriptor.lo] Error 1
make[2]: Leaving directory '/root/protobuf-2.4.1/src'
make[1]: *** [Makefile:530: all-recursive] Error 1
make[1]: Leaving directory '/root/protobuf-2.4.1'
make: *** [Makefile:435: all] Error 2Note:
There are a few warnings while compiling v 2.4.1, all of them says :
..
"locally defined but not used [-Wunused-lo]"Here is the pthread and gcc info:
root@Omega-745F:~# opkg files libpthread
Package libpthread (1.1.19-1) is installed on root and has the following files: (does not list any files)
root@Omega-745F:~#root@Omega-745F:~# opkg files gcc
Package gcc (5.4.0-3) is installed on root and has the following files:
/usr/include/linux/mmtimer.h
..Thanks.
-
@tjoseph1 To me it just makes no sense to compile anything on the device, it's just a dead end waiting to occur. The better long term solution is to resolve the issue with the cross compilation of the code. But we need a little more info to be able to troubleshoot it. It looks like xCompile has been modified so we need to see what it is actually doing and where it is looking.
-
@crispyoz :
protobuf v2.4.1 compiles.. v2.6.1 & v3.13.0 do not compile at all.. Both terminates giving out pthread related error.. may be the newer code was written for later versions of libs.The "native" gcc version in the device appears to be 5.4.0.
I read somewhere that the run-time and the compiler have to match. The executable code generated by newer compiler can not expected to be fully supported by older run-time; where as newer run-time shall fully support executable from older compilers..if I remember it correctly.
If that is the case, shouldn't that be a concern ?
If we compile the app with cross-compiler(toolchain-mipsel_24kc_gcc-7.3.0_musl) and take it to the device that has an older run-time, will that work flawlessly?
When I use the cross compiler, and check with the file command:
$ file <executable> the output shows:
ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-mipsel-sf.so.1, not stripped/lib/ld-musl-mipsel-sf.so.1 is present in the device as a link to /lib/libc.so
The executables generated in the device (using 5.4.0) are also pointing to the same libc.
I guess that is the "correct" run-time for "toolchain-mipsel_24kc_gcc-7.3.0_musl" ?readelf shows that the header data are different for the exes generated by "native" and "cross" compilers.
Thanks..
-
@tjoseph1 If you compile on a later version of the compiler, that compiler can be expected to include updated versions of the various libraries you'll need. When you then move your app to a system with an older version set of libraries then some of the code you are calling may not even exist in those older libraries and certainly their entry points could be expected to change. Any of your dependencies will ultimately have a dependency on the GLIBC, so if you are compiling against a newer version of GLIBC then attempting to run against an older version of GLIBC you may run into trouble. Possibly you can update GLIBC but there may be kernel version dependencies. A bit of a slippery slope.
Cross compilation does complicate things, but if you're building anything of any complexity and you try to do it on the Omega2(+) you'll eventually run out of resources and you'll certainly end up getting frustrated with the performance. This is not an Omega thing, IoT devices are designed to be minimalist.
IMHO learning to work with the cross compilation model is the best solution.
-
xCompling is the preferred for me. I did the above experiment with "protobuf" to see how it goes with native build tools. At least we know that Omega2's native env does not support protobuf.
The /lib/libc.so is from package libc (1.1.19-1).
root@Omega-745F:~/protobuf-2.4.1# opkg files libc
Package libc (1.1.19-1) is installed on root and has the following files:
/lib/ld-musl-mipsel-sf.so.1
/lib/libc.soIs libc-1.1.19-1 fully support with the
gcc-7.3.0_musl?
Otherwise simple things may work, others may not, I guess.Omega2+ is limited .. as per 21C standards. It is much much better than a 200MHz PentiumPro with its 66MHz FSB "loaded with" 64 MB EDO (less an FPU)
Sometimes it is very inspirational reading about the great men at Bell labs and their PDP-11 where both C and Unix were born.
Coming back to the "compatibility" .. Don't I have to compile the entire stuff as static then (in the cross compiler) and move to Omega2?
And isn't that applicable to the OP @joh wrt his efforts with protobuf if that stuff ever going to work properly in an Omega2 ?
Thanks..
-
@tjoseph1 take a look at musl.libc.org for compatibility details, they typically document the binutils and gcc minimum requirements therein .
The problem with static compilation is that if you are developing commercial stuff you will likely run afoul of GPL.
-
@crispyoz :
Thanks a lot for pointing to the license issue..
You helped me clarifying all the doubts I had wrt onion in this forum.
In this specific scenario, protobuf is BSD & musl is MIT. I couldn't find a GPL related binding for any (including commercial) usage that require only those two.
I would think that you were giving me an advise to Read The Fine License of all the libs that I may use in my endeavor..
Please let me know..if I missed it, it is important me to know that I am not in violation.
-
@tjoseph1 I was making the more general point that if you are considering static linking of anything you need to understand the licensing implication, as you do whenever you are using any third party library. I don't have any concerns about Omega and OpenWrt OOB, but developers often require other third party libraries and it really sucks when you spend weeks or months developing something then suddenly realise you've used GPL'd libraries and need to release the source to your commercial product.
I'm all in favour of open source licensing and I don't have any issue personally with any of the licenses, but when we are developing products we need to be cognizant of the impacts of the choices we are making. Law suits really hurt your profit margin
-
@crispyoz :
Thanks.. I share your thoughts; RTF License.GPL might have been the right thing for RMS to counter the 'boxed s/w' (with a price tag) that appeared in the 80s. If I remember it correctly, the owner of Brunei was the wealthiest & MJackson was the top most earning, those days.
Things changed..boxed phenomenon extended to boxed implementors..to the extent..that..
power does not last..card does not read..help..!!I respect RMS & the developers who think GPL is the right model to release their s/w. There must be a reason for glibc docs carry his name on page#1.
I read somewhere that, IBM did have a policy, to evaluate if a prosepectve customer was worthy to buy/operate the "room full" computer, before IBM accepted the purchase order.
I guess, Bugatti, RR and many others do that even today..
-
@tjoseph1 RMS earned his spot.
Blackberry used to require certain capabilities before they would agree to deploy their BES system in an enterprise.
I bought a Bentley, they didn't care about anything other than I could pay the bill.
I was going to call Bugatti and see if I could order a Veyron but you can't drive them on the road in Sydney as they are left hand drive. And there was a small problem of the $2.8m price tag
-
@crispyoz :
As a proud owner of a Bentley, you may not want to go for Bugatti.
"If I go this route, what is it going to bring in, that I do not already have?" Mask of Zorro..Get a Cessna..:)
-
https://codescape.mips.com/sdk/v2.0.0k/docs/_static/gpl_3.1.txt
is detailing about "GCC RUNTIME LIBRARY EXCEPTION" which I understand if correctly, permits using compiler and run-time, while not requiring the source of the work to be made available as in the case of a pure GPL approach ?As you have correctly pointed-out, using other GPLed libraries from other sources will require that GPL be strictly followed, unless specified otherwise in those libs.
Thanks ..