liblsl32.so for ARM architecture #74

bstadlbauer · 2015-12-05T20:28:44Z

Hi!
I am currently trying to run a simple server written in python on a raspberry pi (running raspbian linux). When i try to start the script is tells me that that it cannot find "liblsl32.so" and after some research I found out that it may be complied only for Intel architecture?
(As 'ldd liblsl32.so' tells me 'not a dynamic executable' on an ARM system)

Is it possible to get a library file compiled for ARM architecture or to compile one myself somehow?

dmedine · 2015-12-06T19:03:58Z

Actually, there is now an LSL version for Raspberry-Pi. I believe the code.blocks project will compile just fine, and you can download the binaries on our ftp:
ftp://sccn.ucsd.edu/pub/software/LSL/SDK/
You want 'liblsl-C-C++-1.11'. The binary is called liblsl-bcm2708.so (you can truncate the name, I just added the chip name to istinguish it from other linux builds). Also, I compiled this on a first generation Pi. I don't know if it will run on Version II.

bstadlbauer · 2015-12-06T21:48:24Z

First off, thank you for the quick reply, even though it's not directly an 'issue'!
I tried using 'liblsl-bcm2708.so' ob both, my first generation (B-plus) as well as my second generation (2-B) Pi and it seems not to work. Even though 'readelf -h' tells me that the file was compiled for 'Advanced Micro Devices X86-64' (ARM), 'ldd' still says 'not a dynamic executable' and if I try to add it to my shared object cache (using 'ldconfig') it says 'liblsl-bcm2708.so is for unknown machine 62'.
Do I miss something here? (I am relatively new to using shared objects)

PS: I have managed to import the code::blocks project but as I have never worked with this particular IDE and never compiled a shared object file I am not able to do complie it myself.

dmedine · 2015-12-07T23:33:36Z

Yes, it does indeed appear to be invalid. I did cross-compile it on a virtual linux machine, so I suppose I shouldn't be that surprised that it doesn't work, but I seem to remember testing it before pushing it to the ftp. I am recompiling the binaries on an actual pi (which takes hours) and will replace the broken binaries when it's done.

dmedine · 2015-12-08T01:59:20Z

So the pi is still doing its thing. I will finish this up tomorrow.

One final note is that there were indeed incorrect project settings on the code.blocks project -- causing the library build to fail at link time. I made the correct changes some time ago, and thought that I had saved them, but apparently not. It should all be correct on git etc. now.

dmedine · 2015-12-09T19:40:19Z

This is becoming increasingly difficult (and frustrating). I can compile LSL on the pi (it takes about 3 hours), but I get the symbol not found error on all the LSL functions when I try to link one of the C/C++ examples to it.

I can cross compile it on my virtual linux box and send it to the pi. This time, the example programs compile without errors, but when I try to run them, they report a 'libls-bcm2708.so' file not found error. The file is most certainly there and the permissions are correct.

I also get 'not a dynamic executable' from ldd. I have no idea what is going on here. I definitely had this working several months ago.

dmedine · 2015-12-09T19:41:02Z

Sorry, hit close by accident

chkothe · 2015-12-09T19:47:38Z

The file not found error on the .so file might be related to the file being
built for a different architecture (or perhaps with some other crucial
option set differently, but not sure if there's another option with that
effect besides target arch and bitness).

On Wed, Dec 9, 2015 at 11:41 AM, David Medine notifications@github.com
wrote:

Sorry, hit close by accident

—
Reply to this email directly or view it on GitHub
sccn/labstreaminglayer#74 (comment)
.

dmedine · 2015-12-09T20:11:03Z

Indeed so. But, presumably the cross compiler knows to build for the correct architecture and bitness.

dmedine · 2015-12-09T20:37:48Z

Yes. I verified that the cross compiler should be ok. I compiled a very simple test program and sent it over to the pi. Worked fine.

chkothe · 2015-12-09T20:45:06Z

Ok, time to call Mulder & Scully! ;)

On Wed, Dec 9, 2015 at 12:37 PM, David Medine notifications@github.com
wrote:

Yes. I verified that the cross compiler should be ok. I compiled a very
simple test program and sent it over to the pi. Worked fine.

—
Reply to this email directly or view it on GitHub
sccn/labstreaminglayer#74 (comment)
.

dmedine · 2015-12-09T20:45:35Z

If only I could.

dmedine · 2015-12-10T01:37:24Z

OK, so I guess a fresh build of liblsl on the pi itself did the trick. Everything seems to be working correctly now. I am still compiling the debug library, but I will add the Pi release binaries to the ftp now.

dmedine · 2015-12-10T01:42:55Z

ftp://sccn.ucsd.edu/pub/software/LSL/SDK/liblsl-All-Languages-1.11.zip
and
ftp://sccn.ucsd.edu/pub/software/LSL/SDK/liblsl-C-C++-1.11.zip
have a liblsl-bcm2708.so that should work correctly now.

bstadlbauer · 2015-12-10T08:04:01Z

Thanks a lot for all the effort! I got the file from the 'All-Languages' zip and it works fine now. Just a note: it seems that the new library is not in the 'C-C++-1.11' zip up to now.

dmedine · 2015-12-10T18:25:39Z

Should be there now. Debug version as well.

On 12/10/2015 12:04 AM, beaniwonder wrote:

Thanks a lot for all the effort! I got the file from the
'All-Languages' zip and it works fine now. Just a note: it seems that
the new library is not in the 'C-C++-1.11' zip up to now.

—
Reply to this email directly or view it on GitHub
sccn/labstreaminglayer#74 (comment).

kblomqvist · 2016-10-30T20:23:34Z

@dmedine Could you provide instructions how you managed to build on Pi? I'm struggling with similar linking issues as you did. Seems like the Boost needs some special treatment?

Cross-compiling:

git clone https://github.com/sccn/labstreaminglayer.git
cd labstreaminglayer/LSL/liblsl
mkdir build
cd build
cmake .. -DCMAKE_CXX_COMPILER=arm-linux-gnueabihf-g++
make

...

Linking CXX shared library liblsl.so
CMakeFiles/lsl.dir/legacy/legacy_abi.cpp.o:(.data.rel.ro+0x0): multiple definition of `typeinfo for lslboost::archive::basic_binary_oarchive<eos::portable_oarchive>'
CMakeFiles/lsl.dir/tcp_server.cpp.o:(.data.rel.ro+0x0): first defined here
CMakeFiles/lsl.dir/legacy/legacy_abi.cpp.o:(.rodata+0xc3c): multiple definition of `typeinfo name for lslboost::archive::basic_binary_oarchive<eos::portable_oarchive>'
CMakeFiles/lsl.dir/tcp_server.cpp.o:(.rodata+0x1d7c): first defined here
CMakeFiles/lsl.dir/legacy/legacy_abi.cpp.o:(.data.rel.ro+0xc): multiple definition of `typeinfo for lslboost::archive::basic_binary_oprimitive<eos::portable_oarchive, char, std::char_traits<char> >'
CMakeFiles/lsl.dir/tcp_server.cpp.o:(.data.rel.ro+0xc): first defined here
CMakeFiles/lsl.dir/legacy/legacy_abi.cpp.o:(.rodata+0x12fc): multiple definition of `typeinfo name for lslboost::archive::basic_binary_oprimitive<eos::portable_oarchive, char, std::char_traits<char> >'
CMakeFiles/lsl.dir/tcp_server.cpp.o:(.rodata+0x1fd8): first defined here
collect2: error: ld returned 1 exit status
src/CMakeFiles/lsl.dir/build.make:711: recipe for target 'src/liblsl.so' failed
make[2]: *** [src/liblsl.so] Error 1
CMakeFiles/Makefile2:125: recipe for target 'src/CMakeFiles/lsl.dir/all' failed
make[1]: *** [src/CMakeFiles/lsl.dir/all] Error 2
Makefile:76: recipe for target 'all' failed
make: *** [all] Error 2

Same thing on RPi with USE_SYSTEM_BOOST:

sudo apt-get install libboost-all-dev
git clone https://github.com/sccn/labstreaminglayer.git
cd labstreaminglayer/LSL/liblsl
mkdir build
cd build
cmake .. -DUSE_SYSTEM_BOOST=ON
make

...

Linking CXX shared library liblsl.so
CMakeFiles/lsl.dir/legacy/legacy_abi.cpp.o:(.data.rel.ro+0x0): multiple definition of `typeinfo for boost::archive::basic_binary_oarchive<eos::portable_oarchive>'
CMakeFiles/lsl.dir/tcp_server.cpp.o:(.data.rel.ro+0x0): first defined here
CMakeFiles/lsl.dir/legacy/legacy_abi.cpp.o:(.rodata+0x9fc): multiple definition of `typeinfo name for boost::archive::basic_binary_oarchive<eos::portable_oarchive>'
CMakeFiles/lsl.dir/tcp_server.cpp.o:(.rodata+0x17d8): first defined here
CMakeFiles/lsl.dir/legacy/legacy_abi.cpp.o:(.data.rel.ro+0xc): multiple definition of `typeinfo for boost::archive::basic_binary_oprimitive<eos::portable_oarchive, char, std::char_traits<char> >'
CMakeFiles/lsl.dir/tcp_server.cpp.o:(.data.rel.ro+0xc): first defined here
CMakeFiles/lsl.dir/legacy/legacy_abi.cpp.o:(.rodata+0x10bc): multiple definition of `typeinfo name for boost::archive::basic_binary_oprimitive<eos::portable_oarchive, char, std::char_traits<char> >'
CMakeFiles/lsl.dir/tcp_server.cpp.o:(.rodata+0x19c4): first defined here
collect2: error: ld returned 1 exit status
src/CMakeFiles/lsl.dir/build.make:716: recipe for target 'src/liblsl.so' failed
make[2]: *** [src/liblsl.so] Error 1
CMakeFiles/Makefile2:75: recipe for target 'src/CMakeFiles/lsl.dir/all' failed
make[1]: *** [src/CMakeFiles/lsl.dir/all] Error 2
Makefile:76: recipe for target 'all' failed
make: *** [all] Error 2

Edit:
Got an idea that maybe #pragma once is not supported by arm-linux-gnueabihf-gcc and thus there wouldn't be a proper header guards in place. However, only #pragma warnings was marked as unknown while compiling with -DCMAKE_CXX_FLAGS="-Wunknown-pragmas":

cmake .. -DUSE_SYSTEM_BOOST=ON -DCMAKE_CXX_FLAGS="-Wunknown-pragmas"
make

kblomqvist · 2016-10-31T17:37:06Z

Workaround: add -Wl,--allow-multiple-definition

cmake .. -DCMAKE_CXX_COMPILER=arm-linux-gnueabihf-g++ -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--allow-multiple-definition"

At least the sources compile and link. Don't know whether the library works. I will test that tomorrow.

dmedine · 2016-10-31T17:54:13Z

Glad to know you got the build to work!

I actually used code::blocks to do my compilation. I made it on a
virtual machine with the arm toolchain for the Pi processor. I don't
recall having to add any extra compiler flags. I may have removed the
legacy_abi.cpp file from the build. That is only for making sure (as far
as I know) that LSL is compatible with all the different flavors of
Windows C++ compilers. It isn't necessary on OSX, Linux, etc. and can
generate some build and linking errors on those systems.

On 10/31/2016 10:37 AM, Kim Blomqvist wrote:

Workaround: add |-Wl,--allow-multiple-definition|

cmake .. -DCMAKE_CXX_COMPILER=arm-linux-gnueabihf-g++ -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--allow-multiple-definition"

At least the sources compiles and links. Don't know whether the
library works or not (will test tomorrow).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
sccn/labstreaminglayer#74 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADch7lQR4mAkefo5mOfnzEz7K_96Kk4Zks5q5idCgaJpZM4GvgX8.

kblomqvist · 2016-10-31T18:01:31Z

Removing legacy_abi.cpp from the build did the trick too. No need for -Wl,--allow-multiple-definition. Thanks for the hint.

jona-sassenhagen · 2017-05-16T20:58:34Z

I had the same problem, and removing the reference to legacy_abi.cpp fixed it. Would be nice to have this changed on master!

micuat · 2017-06-21T04:52:28Z

I'm trying this too and had to exclude legacy_abi.cpp from src/CMakeLists.txt. @dmedine, is the legacy api still being used (in other words can it be moved to an optional package) ?

micuat · 2017-06-21T04:57:36Z

also I found the binary for distribution (liblsl-bcm2708.so) is 64 bit so it won't run on pi.

dmedine · 2017-06-21T06:51:57Z

That's my bad. A mistake from using the cross-compiler and then not testing. Coincidentally, I have my pi out at home right now so in the coming days I will compile it natively and re-upload the binary. That way it will definitely work. In the meantime, please exclude the legacy_abi.cpp from the project. I thought I had already done this in the commit of the code.blocks project, but maybe not. That code is only relevant for Windows and causes all sorts of issues with gcc.

…

On 6/21/17 6:57 AM, Naoto HIÉDA wrote: also I found the binary for distribution (liblsl-bcm2708.so) is 64 bit so it won't run on pi. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <sccn/labstreaminglayer#74 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADch7j3-f5v0TkzU11t8rdaA4hRIiMMvks5sGKLBgaJpZM4GvgX8>.

micuat · 2017-06-21T13:33:54Z

@dmedine sorry I didn't use code blocks - I built straight from cmake so maybe that's the reason. In the meantime I built a library so that I can run on a Pi (chkothe/pylsl#2). I had to omit -DUSE_SYSTEM_BOOST=ON so liblsl will work standalone and I renamed it to liblsl32armv7l.so (since python seems to have problems with filenames with hyphen)

dxjones · 2018-08-14T19:36:46Z

I downloaded @micuat's ARM library liblsl32armv7l.so onto my Raspberry Pi 3 B+ and when I try to run an example, it fails with an undefined symbol: lsl_library_info

/usr/local/lib/python2.7/dist-packages/pylsl/examples# python ReceiveData.py
AttributeError: /usr/local/lib/python2.7/dist-packages/pylsl/liblsl32.so: undefined symbol: lsl_library_info

I checked the symbols in the ".so" file using nm -gC liblsl32.so and it shows me all the lsl_ symbols, but the undefined symbol is missing.

Could it be possible this function was excluded somehow when @micuat did the recompile for the ARM architecture??

I am hoping you will be able to figure out how to resolve this problem, because we are stuck and unable to proceed. (We are trying to read raw EEG data from the Muse).

Any help or advice appreciated.

cboulay · 2018-08-14T20:09:05Z

@tstenner , how hard is it to add an ARM build to Travis?

tstenner · 2018-08-15T09:32:10Z

Very hard, as they have no ARM machines. I have a 3B (but no charger) and some changes to reduce the compile time, so it's on my radar but it might take some days

tstenner · 2018-08-15T09:37:59Z

On a second thought: VS2017 has an arm toolchain and the android toolchain compiles for ARM Linux, so that's something appveyor could have preinstalled

swld · 2018-08-17T01:40:10Z

@dxjones i have the same problem.
File "/usr/lib/python3.5/ctypes/init.py", line 365, in getitem
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/local/lib/python3.5/dist-packages/pylsl/liblsl32.so: undefined symbol: lsl_library_info

i'm really new with this and need help, how to compile in raspberry

cboulay · 2018-08-17T14:50:54Z

Please see sccn/liblsl#2 (and test the file attached to my comment there) and discussion in #336

dmedine closed this as completed Dec 9, 2015

dmedine reopened this Dec 9, 2015

bstadlbauer closed this as completed Dec 10, 2015

jona-sassenhagen mentioned this issue May 16, 2017

Step-by-step process to connect with Muse alexandrebarachant/muse-lsl#1

Closed

micuat mentioned this issue Jun 21, 2017

ARM 32 bit support chkothe/pylsl#2

Open

Gilgahex mentioned this issue Jul 2, 2018

Running on Raspberry Pi alexandrebarachant/muse-lsl#55

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

liblsl32.so for ARM architecture #74

liblsl32.so for ARM architecture #74

bstadlbauer commented Dec 5, 2015

dmedine commented Dec 6, 2015

bstadlbauer commented Dec 6, 2015

dmedine commented Dec 7, 2015

dmedine commented Dec 8, 2015

dmedine commented Dec 9, 2015

dmedine commented Dec 9, 2015

chkothe commented Dec 9, 2015

dmedine commented Dec 9, 2015

dmedine commented Dec 9, 2015

chkothe commented Dec 9, 2015

dmedine commented Dec 9, 2015

dmedine commented Dec 10, 2015

dmedine commented Dec 10, 2015

bstadlbauer commented Dec 10, 2015

dmedine commented Dec 10, 2015

kblomqvist commented Oct 30, 2016 •

edited

Loading

kblomqvist commented Oct 31, 2016 •

edited

Loading

dmedine commented Oct 31, 2016

kblomqvist commented Oct 31, 2016 •

edited

Loading

jona-sassenhagen commented May 16, 2017

micuat commented Jun 21, 2017

micuat commented Jun 21, 2017

dmedine commented Jun 21, 2017 via email

micuat commented Jun 21, 2017

dxjones commented Aug 14, 2018

cboulay commented Aug 14, 2018

tstenner commented Aug 15, 2018

tstenner commented Aug 15, 2018

swld commented Aug 17, 2018

cboulay commented Aug 17, 2018

liblsl32.so for ARM architecture #74

liblsl32.so for ARM architecture #74

Comments

bstadlbauer commented Dec 5, 2015

dmedine commented Dec 6, 2015

bstadlbauer commented Dec 6, 2015

dmedine commented Dec 7, 2015

dmedine commented Dec 8, 2015

dmedine commented Dec 9, 2015

dmedine commented Dec 9, 2015

chkothe commented Dec 9, 2015

dmedine commented Dec 9, 2015

dmedine commented Dec 9, 2015

chkothe commented Dec 9, 2015

dmedine commented Dec 9, 2015

dmedine commented Dec 10, 2015

dmedine commented Dec 10, 2015

bstadlbauer commented Dec 10, 2015

dmedine commented Dec 10, 2015

kblomqvist commented Oct 30, 2016 • edited Loading

kblomqvist commented Oct 31, 2016 • edited Loading

dmedine commented Oct 31, 2016

kblomqvist commented Oct 31, 2016 • edited Loading

jona-sassenhagen commented May 16, 2017

micuat commented Jun 21, 2017

micuat commented Jun 21, 2017

dmedine commented Jun 21, 2017 via email

micuat commented Jun 21, 2017

dxjones commented Aug 14, 2018

cboulay commented Aug 14, 2018

tstenner commented Aug 15, 2018

tstenner commented Aug 15, 2018

swld commented Aug 17, 2018

cboulay commented Aug 17, 2018

kblomqvist commented Oct 30, 2016 •

edited

Loading

kblomqvist commented Oct 31, 2016 •

edited

Loading

kblomqvist commented Oct 31, 2016 •

edited

Loading