Bug 547 - C++ Bindings fail to build: duplicate enum members
Summary: C++ Bindings fail to build: duplicate enum members
Alias: None
Product: libsigrok
Classification: Unclassified
Component: Bindings: C++ (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: Nobody
: 937 1228 (view as bug list)
Depends on:
Reported: 2015-01-26 23:19 CET by Mathew Hall
Modified: 2019-05-01 18:22 CEST (History)
7 users (show)

patch to enums.py (3.05 KB, application/octet-stream)
2015-01-26 23:19 CET, Mathew Hall

Note You need to log in before you can comment on or make changes to this bug.
Description Mathew Hall 2015-01-26 23:19:24 CET
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
Comment 1 Uwe Hermann 2015-03-04 00:15:27 CET
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 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.


(note: you may have to adapt some paths in the script, depending on your setup and depending on whether you use Homebrew or not)

Comment 2 Uwe Hermann 2015-03-10 14:55:31 CET
Hm, apparently someone else was hit by the same issue on Ubuntu, so this is not Mac-specific.


I'll see if I can reproduce on Ubuntu.
Comment 3 Uwe Hermann 2015-03-13 18:26:06 CET
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.
Comment 4 Mathew Hall 2015-03-13 22:48:02 CET
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
    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.
Comment 5 Aveek B. 2015-03-28 14:26:59 CET
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
Comment 6 Anatol 2016-08-22 07:05:56 CEST
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?
Comment 7 Daniel Elstner 2016-08-22 12:54:24 CEST
(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.
Comment 8 Uwe Hermann 2019-05-01 18:20:59 CEST
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!
Comment 9 Uwe Hermann 2019-05-01 18:21:13 CEST
*** Bug 937 has been marked as a duplicate of this bug. ***
Comment 10 Uwe Hermann 2019-05-01 18:22:27 CEST
*** Bug 1228 has been marked as a duplicate of this bug. ***