Hello,
On 2014-12-31 09:06, Joel Holdsworth wrote: > Is your problem related to the std::isnan issue? If so, this has now > been fixed > No, I'm stuck with a linking issue with pulseview HEAD on FreeBSD - see below: Question: have anyone tried to build sigrok and pulseview on FreeBSD recently ? sigrok libs and cli compiles and links - with no problems - but pulseview does not link Linking CXX executable pulseview CMakeFiles/pulseview.dir/main.cpp.o: In function `std::__1::__tree<std::__1::__value_type<sr_loglevel const, sigrok::LogLevel const* const>, std::__1::__map_value_compare<sr_loglevel const, std::__1::__value_type<sr_loglevel const, sigrok::LogLevel const* const>, std::__1::less<sr_loglevel const>, true>, std::__1::allocator<std::__1::__value_type<sr_loglevel const, sigrok::LogLevel const* const> > >::__root() const': /usr/include/c++/v1/__tree:878: undefined reference to `sigrok::EnumValue<sigrok::LogLevel, sr_loglevel>::_values' CMakeFiles/pulseview.dir/main.cpp.o: In function `sigrok::EnumValue<sigrok::LogLevel, sr_loglevel>::get(int)': /home/wuffe/local/prj/sigrok_trunk_build/libsigrok.git/bindings/cxx/include/libsigrok/libsigrok.hpp:1001: undefined reference to `sigrok::EnumValue<sigrok::LogLevel, sr_loglevel>::_values' CMakeFiles/pulseview.dir/pv/view/logicsignal.cpp.o: In function `std::__1::__tree<std::__1::__value_type<sr_trigger_matches const, sigrok::TriggerMatchType const* const>, std::__1::__map_value_compare<sr_trigger_matches const, std::__1::__value_type<sr_trigger_matches const, sigrok::TriggerMatchType const* const>, std::__1::less<sr_trigger_matches const>, true>, std::__1::allocator<std::__1::__value_type<sr_trigger_matches const, sigrok::TriggerMatchType const* const> > >::__root() const': /usr/include/c++/v1/__tree:878: undefined reference to `sigrok::EnumValue<sigrok::TriggerMatchType, sr_trigger_matches>::_values' CMakeFiles/pulseview.dir/pv/view/logicsignal.cpp.o: In function `sigrok::EnumValue<sigrok::TriggerMatchType, sr_trigger_matches>::get(int)': /home/wuffe/local/prj/sigrok_trunk_build/libsigrok.git/bindings/cxx/include/libsigrok/libsigrok.hpp:1001: undefined reference to `sigrok::EnumValue<sigrok::TriggerMatchType, sr_trigger_matches>::_values' clang: error: linker command failed with exit code 1 (use -v to see invocation) CMakeFiles/pulseview.dir/build.make:3022: recipe for target 'pulseview' failed gmake[4]: *** [pulseview] Error 1 /Uffe > On 30 December 2014 23:46:57 GMT+00:00, Uffe Jakobsen <[email protected]> wrote: > > > > On 2014-12-29 13:12, Rodrigo Amestica wrote: > > At Wed, 24 Dec 2014 01:28:51 +0100, > Uffe Jakobsen wrote: > > > > > On 2014-12-19 01:19, Rodrigo Amestica wrote: > > At Tue, 09 Dec 2014 10:56:51 +0100, > Uffe Jakobsen wrote: > > > Follow-up: > > The above problem seems to be due to the fact that > cxx-bindings for > libsigrok have failed even though --enable-cxx was > specified > > Just saw another post to this list reporting related > problem: > "AX_CXX_COMPILE_STDCXX_11 macro is too old" > > I'm digging further down... > > /Uffe > > > > in relation with the 'related problem', today I have cloned > ax_cxx_compile_stdcxx_11.m4 from git into a local > directory and in > libsigrok/autogen.sh <http://autogen.sh> I have used > ACLOCAL_DIR to point to that directory. Now I > can see bindings being generated and libsigrok, > libsigrokdecode and pulseview > from git all build successfully for me (ubuntu 14.04, 64 > bits). > > > > I've solved the problem in a similar but different way - without > modifying autogen.sh <http://autogen.sh> :-) > > I downloaded the single missing file > "ax_cxx_compile_stdcxx_11.m4" into > a separate directory named "aclocal". Then I used the env var > ACLOCAL_PATH to point to that dir (using an absolute path). > > This way all the existing m4 macros installed by os and/or > packages are > still inspected - but after my local "aclocal" directory has > been searches. > > See: > > https://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html > > This got me further - only to stumble over new challenges :-) > > > many thanks for the feedback Uffe. > > What sort of new challenges did you stumble upon? Anything that > could explain > why pulseview is not able to open anything but sr files. > > > > Not that is not on my list of problems. > > My primary platform is FreeBSD and pulseview (head) is currently unable > to compile using *ANY* of the compilers available for FreeBSD. The > problem seems to be a C++11 issue - but I need to dig some more into that. > > /Uffe > > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
