EmotiBit / ofxEmotiBit

OpenFrameworks library and examples for the EmotiBit
MIT License
34 stars 8 forks source link

error: ‘ofxLSL’ does not name a type #145

Closed sigmike closed 4 months ago

sigmike commented 2 years ago

Describe the bug When I run make in EmotiBitOscilloscope I get this error:

In file included from /path/to/of_v0.11.2_linux64gcc6_release/addons/ofxLSL/src/ofxLSLReceiver.h:3,
                 from /path/to/of_v0.11.2_linux64gcc6_release/addons/ofxLSL/src/ofxLSL.h:3,
                 from /path/to/of_v0.11.2_linux64gcc6_release/addons/ofxEmotiBit/EmotiBitOscilloscope/src/ofApp.h:10,
                 from /path/to/of_v0.11.2_linux64gcc6_release/addons/ofxEmotiBit/EmotiBitOscilloscope/src/ofApp.cpp:1:
/path/to/of_v0.11.2_linux64gcc6_release/addons/ofxLSL/libs/labstreaminglayer/include/lsl_cpp.h: In member function ‘void lsl::stream_outlet::check_numchan(std::size_t) const’:
/path/to/of_v0.11.2_linux64gcc6_release/addons/ofxLSL/libs/labstreaminglayer/include/lsl_cpp.h:911:23: warning: comparison of integer expressions of different signedness: ‘std::size_t’ {aka ‘long unsigned int’} and ‘const int32_t’ {aka ‘const int’} [-Wsign-compare]
  911 |                 if (N != channel_count)
      |                     ~~^~~~~~~~~~~~~~~~
/path/to/of_v0.11.2_linux64gcc6_release/addons/ofxEmotiBit/EmotiBitOscilloscope/src/ofApp.h: At global scope:
/path/to/of_v0.11.2_linux64gcc6_release/addons/ofxEmotiBit/EmotiBitOscilloscope/src/ofApp.h:28:9: error: ‘ofxLSL’ does not name a type
   28 |         ofxLSL lsl;
      |         ^~~~~~

Followed by more errors related to lsl and warnings.

Indeed ofxLSL seems to be a namespace and not a type: https://github.com/EmotiBit/ofxLSL/blob/master/src/ofxLSLReceiver.h#L10

To Reproduce Steps to reproduce the behavior:

  1. Follow the instructions in https://github.com/EmotiBit/ofxEmotiBit#developing-on-linux, the error is at the last step

Expected behavior No error.

Desktop:

sigmike commented 2 years ago

I tried with the master branch of the repository instead of the 1.4.11 release and the error disappeared.

But now I get another error:

In file included from /usr/include/c++/12.1.0/vector:63,
                 from /path/to/of_v0.11.2_linux64gcc6_release/libs/openFrameworks/utils/ofConstants.h:282,
                 from /path/to/of_v0.11.2_linux64gcc6_release/libs/openFrameworks/ofMain.h:6,
                 from /path/to/of_v0.11.2_linux64gcc6_release/addons/ofxEmotiBit/EmotiBitOscilloscope/src/ofApp.h:3,
                 from /path/to/of_v0.11.2_linux64gcc6_release/addons/ofxEmotiBit/EmotiBitOscilloscope/src/ofApp.cpp:1:
/usr/include/c++/12.1.0/bits/stl_uninitialized.h: In instantiation of ‘constexpr bool std::__check_constructible() [with _ValueType = unique_ptr<ofxBaseGui>; _Tp = const unique_ptr<ofxBaseGui>&]’:
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:182:4:   required from ‘_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator<const unique_ptr<ofxBaseGui>*, vector<unique_ptr<ofxBaseGui> > >; _ForwardIterator = unique_ptr<ofxBaseGui>*]’
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:372:37:   required from ‘_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, allocator<_Tp>&) [with _InputIterator = __gnu_cxx::__normal_iterator<const unique_ptr<ofxBaseGui>*, vector<unique_ptr<ofxBaseGui> > >; _ForwardIterator = unique_ptr<ofxBaseGui>*; _Tp = unique_ptr<ofxBaseGui>]’
/usr/include/c++/12.1.0/bits/stl_vector.h:601:31:   required from ‘std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp = std::unique_ptr<ofxBaseGui>; _Alloc = std::allocator<std::unique_ptr<ofxBaseGui> >]’
/path/to/of_v0.11.2_linux64gcc6_release/addons/ofxGui/src/ofxGuiGroup.h:10:7:   required from ‘void std::_Construct(_Tp*, _Args&& ...) [with _Tp = ofxPanel; _Args = {const ofxPanel&}]’
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:120:21:   [ skipping 2 instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ]
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:185:15:   required from ‘_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = const ofxPanel*; _ForwardIterator = ofxPanel*]’
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:372:37:   required from ‘_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, allocator<_Tp>&) [with _InputIterator = const ofxPanel*; _ForwardIterator = ofxPanel*; _Tp = ofxPanel]’
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:397:2:   required from ‘_ForwardIterator std::__uninitialized_move_if_noexcept_a(_InputIterator, _InputIterator, _ForwardIterator, _Allocator&) [with _InputIterator = ofxPanel*; _ForwardIterator = ofxPanel*; _Allocator = allocator<ofxPanel>]’
/usr/include/c++/12.1.0/bits/vector.tcc:674:48:   required from ‘void std::vector<_Tp, _Alloc>::_M_default_append(size_type) [with _Tp = ofxPanel; _Alloc = std::allocator<ofxPanel>; size_type = long unsigned int]’
/usr/include/c++/12.1.0/bits/stl_vector.h:1011:4:   required from ‘void std::vector<_Tp, _Alloc>::resize(size_type) [with _Tp = ofxPanel; _Alloc = std::allocator<ofxPanel>; size_type = long unsigned int]’
/path/to/of_v0.11.2_linux64gcc6_release/addons/ofxEmotiBit/EmotiBitOscilloscope/src/ofApp.cpp:1175:18:   required from here
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:90:56: error: static assertion failed: result type must be constructible from input type
   90 |       static_assert(is_constructible<_ValueType, _Tp>::value,
      |                                                        ^~~~~
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:90:56: note: ‘std::integral_constant<bool, false>::value’ evaluates to false
nitin710 commented 2 years ago

@sigmike With reference to you older comment, the master branch is compatible with the master of all other dependencies (as you have later mentioned.) There was a breaking change in the LSL repo, going from 1.4.11 to current master. We are working on improving our process going forward, to create a clear dependency requirement. For now, working on master for every branch should work! (as you have figured out)

As for the second comment, I have not seen that error before (on any OS. tested on Ubuntu 20.04 for linux). I am going to try and replicate it.

Will post if on this thread if I have any suspects.

kurnevsky commented 2 years ago

I'm trying to build it on nix and have exactly same error that's mentioned in https://github.com/EmotiBit/ofxEmotiBit/issues/145#issuecomment-1179498594 @nitin710 so if you need a way to reproduce it I can post my nix file - it should be quite easy to reproduce the same environment on any system using nix packet manager.

kurnevsky commented 2 years ago

Uploaded my attempt here: https://github.com/kurnevsky/EmotiBit-nix

nitin710 commented 2 years ago

@sigmike Well, I am not able to recreate this error in ubuntu 20.04, which, unfortunately, is the only linux distro we test our builds on.

Can you share some more info about this error (ex, what function (and line)) in the codebase is causing this error? Can this be an error when compiling an openframeworks dependency?

nitin710 commented 2 years ago

Also, can you confirm you are working on openframeworks 0.11.0? we have not yet ported ofxEmotibit to the latest 0.11.2

kurnevsky commented 2 years ago

I indeed used openframeworks 0.11.2. But with 0.11.0 I have a different error:

openframeworks> Compiling EmotiBitOscilloscope for Release
openframeworks> make[1]: Entering directory '/build/source/addons/ofxEmotiBit/EmotiBitOscilloscope'
openframeworks> /build/source/libs/openFrameworksCompiled/project/makefileCommon/config.addons.mk:210: *** missing separator.  Stop.
openframeworks> make[1]: Leaving directory '/build/source/addons/ofxEmotiBit/EmotiBitOscilloscope'
openframeworks> make: *** [/build/source/libs/openFrameworksCompiled/project/makefileCommon/compile.project.mk:129: Release] Error 2
kurnevsky commented 2 years ago

Alright, after backporting several commits I made it (almost) compiling. So this error indeed is caused by openframeworks 0.11.1. Hopefully I'll make it working for nix, which will provide a reproducible builds. Because now the situation is really sad - any version update of anything can break everything, also compiled libraries are placed directly to the repo...

sigmike commented 2 years ago

can you confirm you are working on openframeworks 0.11.0? we have not yet ported ofxEmotibit to the latest 0.11.2

I was using 0.11.2. I see you've updated the link in the instructions to make it send to the compatible version, thank you.

Building OF 0.11.0 on Arch Linux (and soon on other distributions) is not straightforward because it's not compatible with recent version of some dependencies. Here are the patches I had to apply to make it build:

And I had to run ./bin/EmotiBitOscilloscope_debug from the ofxEmotiBit/EmotiBitOscilloscope directory. Running cd bin; ./EmotiBitOscilloscope_debug or make RunDebug as instructed by the end of the compilation process failed with this error:

./EmotiBitOscilloscope_debug: error while loading shared libraries: ./bin/liblsl-1.14.0-manylinux2010_x64.so: cannot open shared object file: No such file or directory

The oscilloscope is finally working.

Next time I will probably use @kurnevsky's nix version if I figure out how. Thanks for sharing it.

kurnevsky commented 2 years ago

@sigmike if you have nix installed you can just run nix develop from the root of my repo. It will run nix shell with installed EmotiBitOscilloscope. It runs fine for me, but I can't test how it works as at the moment I have difficulties uploading EmotiBit firmware to Feather M0.

nitin710 commented 2 years ago

@sigmike regarding the error

error while loading shared libraries

check out the last note in the instructions to build: https://github.com/EmotiBit/ofxEmotiBit#developing-on-linux. can you try updating the LD_LIBRARY_PATH and compiling again?

Also, mentioned in the forum on this thread: https://www.reddit.com/r/EmotiBit/comments/u0pqww/comment/i4b77jj/?utm_source=share&utm_medium=web2x&context=3

sigmike commented 2 years ago

can you try updating the LD_LIBRARY_PATH and compiling again?

I don't think LD_LIBRARY_PATH changes anything at compilation time. I tried anyway but it didn't change the result.

The error is not exactly the one in your links. The problem is the name of the dynamic library does include the ./bin/ part, which is weird:

> ldd EmotiBitOscilloscope_debug
    linux-vdso.so.1 (0x00007fffe8559000)
    ./bin/liblsl-1.14.0-manylinux2010_x64.so => not found
    libPocoFoundation.so.83 => /usr/lib/libPocoFoundation.so.83 (0x00007f0fe4a00000)
[...]

No LD_LIBRARY_PATH I could try did work in that case, even setting it to the parent of the bin directory. But running it from that parent directory does work.

nitin710 commented 2 years ago

Updating LD_LIBRARY_PATH and calling make again seemed to solve the problem on Ubuntu 20.04.

A dirty hack could be moving the liblsl-1.14.0-manylinux2010_x64.so into the /usr/bin folder. I have got it to work that way (before I discovered the LD_LIBRARY_PATH route).

However, it is curious that the linker is not able to find the path to the file.

kurnevsky commented 2 years ago

A dirty hack could be moving the liblsl-1.14.0-manylinux2010_x64.so into the /usr/bin folder. I have got it to work that way (before I discovered the LD_LIBRARY_PATH route).

I'd encourage you not to store compiled libraries in git repository if possible. It's a very dirty way to distribute dependencies - compiled libraries will work only with limited set of linux distributions and any update of dynamically linked library might break it. One of possible solutions is to use nix. But if you still decide to continue using compiled libraries it would be good to provide information what exact version of library was used and how it was compiled.