1. Home
  2. Omega Talk
  3. Using Protobuf - Error
We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

Using Protobuf - Error

  • C

    @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.

    0
  • T

    @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..

    0
  • C

    @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.

    0
  • T

    @crispyoz :

    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.so

    Is 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..

    0
  • C

    @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.

    0
  • T

    @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.

    0
  • C

    @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 šŸ™‚

    0
  • T

    @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..

    0
  • C

    @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 šŸ˜ž

    0
  • T

    @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..:)

    0
  • T

    @crispyoz :

    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 ..

    0
compilation 7 protobuf 1 cross 1
Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.