4 Replies Latest reply: Jan 8, 2012 5:41 PM by tedk RSS

Cross-compiling Google protobufs

ms705 Community Member
Currently Being Moderated

Hello,

 

An application we are porting to the SCC needs Google's protocol buffers library [1]. Since it can be built from source fairly straightforwardly, it shouldn't be a problem to cross-compile it for the SCC. Unfortunately, however, it appears to be -- when compiling, I receive the following error message which I can make very little of:

 

make[2]: Entering directory `/shared/ms705/test/ext/protobuf-2.3.0/src'

oldpwd=`pwd` && ( cd . && $oldpwd/protoc -I. --cpp_out=$oldpwd google/protobuf/unittest.proto google/protobuf/unittest_empty.proto google/protobuf/unittest_import.proto google/protobuf/unittest_mset.proto google/protobuf/unittest_optimize_for.proto google/protobuf/unittest_embed_optimize_for.proto google/protobuf/unittest_custom_options.proto google/protobuf/unittest_lite.proto google/protobuf/unittest_import_lite.proto google/protobuf/unittest_lite_imports_nonlite.proto google/protobuf/unittest_no_generic_services.proto google/protobuf/compiler/cpp/cpp_test_bad_identifiers.proto )
/home/ms705/shared/test/ext/protobuf-2.3.0/src/.libs/lt-protoc: relocation error: /opt/i386-unknown-linux-gnu/bin/../lib/gcc/i386-unknown-linux-gnu/3.4.5/../../../../i386-unknown-linux-gnu/lib/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference

 

My only guess is that there's some issue with a symbol inconsistency between ld-linux.so.2 and the SCC compiler environment's libc.so.6?

 

We are running sccKit 1.3 on an Intel-supplied MCPC, and I have sourced /opt/compilerSetupFiles/crosscompile.sh prior to building protobufs.

 

Any ideas are much appreciated!

 

[edit: formatting]

  • 1. Re: Cross-compiling Google protobufs
    tedk Community Member
    Currently Being Moderated

    What system are you running on? Your own or a data center system? If a data center system, which one?

     

    I can buld the protocol buffer library on the MCPC for use on the MCPC. As you mentioned, it gets built pretty straightforwardly ... configure, make, make check, make install.

     

    How are you bulding it for the SCC? I don't think the configure script is pertinent in this case.

     

    Has anyone had experience with configure/make/make install opensource sw for the SCC? What did you do?

     

    I noticed you are scc 1.3.0. Is this for a reason? 1.4.1.3 is our release of record. 1.4.2 in beta. Are you using protobuf 2.3.0 for a reason? I noticed that 2.4.1 is the latest release.

  • 2. Re: Cross-compiling Google protobufs
    ms705 Community Member
    Currently Being Moderated

    Thanks for your response!

    What system are you running on? Your own or a data center system? If a data center system, which one?

     

    Our own, but an Intel-supplied MCPC.

     

    I can buld the protocol buffer library on the MCPC for use on the MCPC. As you mentioned, it gets built pretty straightforwardly ... configure, make, make check, make install.

     

    Interesting, I don't think I tried that since the MCPC is a 64-bit system in our case, so I assumed the library as built for the MCPC won't work on the SCC.

    How are you bulding it for the SCC? I don't think the configure script is pertinent in this case.

     

    I sourced the crosscompile.sh script, and then followed the configure, make, make check sequence as per protobuf documentation. (Again, based on the assumption that I need to source crosscompile.sh before building in order to link in the correct 32-bit libraries for the SCC).

     

    Has anyone had experience with configure/make/make install opensource sw for the SCC? What did you do?

     

    We have previously successfully built various pieces of OSS for the SCC from source -- most notably, python and various libraries its minimal version depends on. In all cases, the normal build sequence worked after using crosscompile.sh, but dependencies on dynamically linked libraries made it necessary to perform this step first.

    I noticed you are scc 1.3.0. Is this for a reason? 1.4.1.3 is our release of record. 1.4.2 in beta. Are you using protobuf 2.3.0 for a reason? I noticed that 2.4.1 is the latest release.

     

    No particular reason, other than that the box has not been upgraded yet. I'll do so and report back; as for protobufs, I think we went for 2.3.0 since that is the version packaged in Ubuntu, but I'll try the newer one, thanks for pointing it out. Will report back with the results.

  • 3. Re: Cross-compiling Google protobufs
    ms705 Community Member
    Currently Being Moderated

    Good news -- protobufs version 2.4.1 compiles just fine (both with and without the crosscompile script). Yay!

     

    I'll upgrade sccKit nonetheless. Thanks for your help!

  • 4. Re: Cross-compiling Google protobufs
    tedk Community Member
    Currently Being Moderated

    Yes, the MCPC is a 64-bit system and a library built on the MCPC for the MCPC is not going to work on the SCC. But I did that just because I wasn't sure how to proceed with the cross compiler. I just wanted to see protobufs work.

     

    I took a peek inside the configure script for protobufs and was concerned that it wasn't doing the right stuff for a cross compilation. But I guess you say that it is if you source the cross compiler first. Did you modify the configure script? Do you login to a core to run protoc?

     

    How are you using protobufs on the SCC? On the MCPC, (just to run that addressbook example that comes with the download) I did

    protoc -I=/home/tekubasx/PROTO --cpp_out=/home/tekubasx/PROTO  /home/tekubasx/PROTO/protobuf-2.4.1/examples/addressbook.proto

     

    and then

    ./add_person_cpp myaddrbk

     

    answered the questions and then

    ./list_people_cpp myaddrbk

    to see the results.

     

    That's about the level of my experience with protobufs! I'm curious about how you are using it with the SCC. Have you published something that I missed?

     

    I think you'll see much better performance with 1.4.1.3. Installing it doesn't mean you can't go back. With 1.4.1.3, you do need to add a Gbit switch with a couple of additional ethernet cables and modify some config files. But we keep the 1.3.0 files under the 1.3.0 directory in /opt/sccKit and point the current link to the version we want. If you switch sccKit versions it is important ensure that you also load the corresponding bitstream into the FPGA and edit the config files .. there are a bunch, like the zone files under bind. But we keep versions of these config files for the sccKit versions so it's just a copy and not an edit for us.

More Like This

  • Retrieving data ...

Legend

  • Correct Answers - 4 points
  • Helpful Answers - 2 points