Created attachment 113 [details] patch to enums.py When building sigrok on Mac OS X 10.10, make fails after the Doxygen target is built. The file bindings/cxx/include/libsigrokcxx/enums.hpp contains duplicate entries for each enum member (see below). The problem is due to duplicates in the Doxygen file that get propagated to the headers (and swig files) via the enums.py script . The attached patch fixes the issue. CXX bindings/cxx/classes.lo In file included from bindings/cxx/classes.cpp:20: In file included from ./bindings/cxx/include/libsigrokcxx/libsigrokcxx.hpp:1024: bindings/cxx/include/libsigrokcxx/enums.hpp:21:32: error: duplicate member 'NONE' static const LogLevel * const NONE; ^ bindings/cxx/include/libsigrokcxx/enums.hpp:9:32: note: previous declaration is here static const LogLevel * const NONE; ^ bindings/cxx/include/libsigrokcxx/enums.hpp:23:32: error: duplicate member 'ERR' static const LogLevel * const ERR; ... % g++ --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix % python --version Python 2.7.6 Configure command: ./configure --prefix=/opt/local --enable-java=no
Hi Matthew, that's strange, I can't reproduce this here (Mac OS X 10.6.8), building with gcc/g++ 4.9.2, Python 2.7.9, Doxygen 1.8.9.1 from Homebrew (all other build requirements also from Homebrew). Can you try the sigrok-native-macosx script from the sigrok-util repo please? That one builds all components without problems on my system. If that also doesn't work we should find out the exact reason for that. http://sigrok.org/gitweb/?p=sigrok-util.git;a=tree;f=cross-compile/macosx (note: you may have to adapt some paths in the script, depending on your setup and depending on whether you use Homebrew or not) Thanks!
Hm, apparently someone else was hit by the same issue on Ubuntu, so this is not Mac-specific. http://news.gmane.org/gmane.comp.debugging.sigrok.devel I'll see if I can reproduce on Ubuntu.
Hm, no luck so far. I ran the sigrok-cross-linux script (twice in a row) on an Ubuntu 14.04.2 LTS with the following lib/tool versions (same as the user on the mailing list mentioned): gcc/g++ 4.8.2-19ubuntu1 doxygen 1.8.6 Python 2.7.6 No build failures, everything worked fine. The script uses -j2 by default so it would probably have caught any issues related to parallel builds as well, I assume.
Hi Uwe, Apologies for the delay in getting back to you. I've taken a look at the sigrok-native-macosx script and after getting it running it seems the error doesn't appear. I've been building according to the instructions on the Wiki: http://sigrok.org/wiki/Mac_OS_X and it seems the only difference is the directories. The native-macosx script builds in a separate directory, but I've been building in the libsigrok directory. Looks like it's down to the bindings directory being non-empty. You can reproduce the issue by removing the `cd build` and changing its matching `cd ../..` to `cd ..` and changing `../configure` to `./configure` each of the relevant building blocks, i.e: mkdir -p $PYPATH $GIT_CLONE git://sigrok.org/libsigrok cd libsigrok ./autogen.sh PKG_CONFIG_PATH=$P ./configure $C --disable-java $SB make $PARALLEL $V PYTHONPATH=$PYPATH $SB make install $V $SB make check $V cd .. Hope this helps. If you need any more information please let me know.
Confirmed the issue on Ubuntu 14.10. The issue is caused if the build directory path has a symlink. Changing to the real path, libsigrok builds correctly. Software versions: GCC: 4.9.1-16ubuntu6 Doxygen: 1.8.8 Python: 2.7.8
I confirm that this issue still exists when compiling the project at Arch Linux. Moving project outside of symlink "fixes" the issue. It is not very convenient that project put such restrictions to the source location. Any chance to see the problem fixed?
(In reply to comment #6) > Moving project outside of symlink "fixes" the issue. Hm, that hints at a problem with the filename manipulation in the Python scripts. IIRC there was some magic in there to identify common prefixes of build and source directories or somesuch. There might be a realpath or something in there for canonization which could lead to symlinks being treated differently.
This should be fixed in 3535a6eeee267ebb0092a0f6600b0b3edc055bf8, via explicitly referencing absolute SRCDIR/BUILDDIR in all Doxyfiles, thanks! According to my testing this seems to work with in-tree and out-of-tree builds, as well as with builds where the libsigrok directory is inside a directory that is a symlink (as well as when it's not a symlink). Further testing is highly welcome, though!
*** Bug 937 has been marked as a duplicate of this bug. ***
*** Bug 1228 has been marked as a duplicate of this bug. ***