This issue is discussed on the mailing list in the thread "eigen3 migration" started 13 April, see http://thread.gmane.org/gmane.comp.lib.eigen/1941 . A summary of the discussion follows. The problem is that the X11 header file X.h include the following macro: #define Success 0 If this header file is included before Eigen/Core, then the following definition fails to compile: enum ComputationInfo { Success = 0, NumericalIssue = 1, NoConvergence = 2 }; Furthermore, the resulting error message is apparently rather puzzling. Possible solutions: 1. Rename Success in Eigen to something else, say SuccessfulComputation. This does however break all Eigen3 user code which uses this constant. 2. Do nothing, and have the user resolve the problem. For instance, the user could #undef Success before the #include <Eigen/Core> if they are not using X.h's Success. We could make the error message a bit easier to understand with things like #ifdef Success #error "Success macro defined by some header file, possibly X.h" #endif 3. Rhys suggested the following: Would something goofy like enum ComputationInfo { #ifndef Success Success = 0, #elif Success == 0 # undef Success Success = 0, # define Success 0 #else # error "Success #defined with non-zero value" #endif NumericalIssue = 1, NoConvergence = 2 }; work? This works around any preceding '#define Success 0' macro by 'pushing/popping' its definition. In the end, the token 'Success' will still be macro expanded but ComputationInfo's enum will contain an entry for the literal as well. Finally, it loudly breaks if someone uses the wholly incompatible '#define Success 1'.
solution 3 does not work with: Eigen::Success. So it remains options 1 or 2 and I'd go for 2 with an explicit error message. It is not our business to deal with crappy #define ... The pb is on X11 side.
(In reply to comment #1) > solution 3 does not work with: Eigen::Success. > > So it remains options 1 or 2 and I'd go for 2 with an explicit error message. > It is not our business to deal with crappy #define ... The pb is on X11 side. I agree, you can't implement spurious workarounds for every macro that some other library defines -- especially if they don't stick to conventions such as UPPERCASE_ONLY and starting with a (hopefully) unique prefix. Maybe the #error message should contain a workaround (or a link to one), though. With any solution there is still a problem when including X11 after Eigen and using Eigen::Success (which can't be detected by Eigen).
I added an #error in case Success is already defined (changesets d84c8f4660e6 and 336bc7749caa). I hope users are smart enough to look at the first error message, as it is followed at least on GCC with a lot of other error messages.
*** Bug 274 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/253.