|
|
[Rivet] Rivet boost::BOOST_FOREACH
David Bjergaard
david.b at duke.edu
Tue Aug 11 10:27:54 BST 2015
And the obligatory build info:
> $ g++ --version
> g++ (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)
> $ cat boost_version.cxx
> #include <boost/version.hpp>
> #include <iostream>
> #include <iomanip>
> int main()
> {
> std::cout << "Using Boost "
> << BOOST_VERSION / 100000 << "." // major version
> << BOOST_VERSION / 100 % 1000 << "." // minor version
> << BOOST_VERSION % 100 // patch level
> << std::endl;
> return 0;
> }
> $ g++ boost_version.cxx
> $ ./a.out
> Using Boost 1.53.0
> $ uname -a
> Linux hostname 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
AFAIK this is a CentOS machine.
Cheers,
David
David Bjergaard <david.bjergaard at gmail.com> writes:
> Hi Andy, Andrii,
>
> I just ran into this very same problem with 1.53. Installing 1.56 as per the
> bootstrap prescription fixed it. I've always used 1.55 previously so maybe its
> worth bumping the configure script to expect 1.55 or higher? This doesn't change
> the bootstrap prescription and it avoids a seemingly broken build. Once
> configure finishes, the rest of the build should "just work".
>
> Cheers,
>
> Dave
>
> Andy Buckley <andy.buckley at cern.ch> writes:
>
>> Hi again Andrii,
>>
>> This myriad of compilers and Boost versions that are incompatible with
>> Boost's own "pretty foreach" recipe is very surprising to me. We've
>> tested with a variety of common systems for every release since at
>> least 2010, and always made sure that it was usable... modulo the
>> requirement to install a more recent Boost than the ancient SL5/6
>> system copies.
>>
>> But we didn't check *all* versions of Boost for compatibility, because
>> Boost's own documentation didn't suggest that there would be any
>> issue. They are doing complicated tricks internally, and "unbuggy"
>> Boost releases have frequently become buggy as new, stricter compilers
>> have come into use. I'm very surprised that you report Boost 1.53 as
>> incompatible, since that version's documentation specifically
>> recommends the recipe that we use, but to the best of my knowledge I
>> have not personally tried that version.
>>
>> It's good to know that there is this problem, but I think our response
>> just has to be to increase the required Boost version. We have never
>> been able to use the SL system version, so this is no change... and if
>> you use our bootstrap script it will make a sufficient Boost
>> installation automatically (without needing to compile it, since we
>> use only headers).
>>
>> Sorry for the inconvenience, but glad you found a workaround for your
>> system.
>>
>> Andy
>>
>>
>>
>> On 05/08/15 12:13, Andrii Verbytskyi wrote:
>>> Dear Andy,
>>> 1)
>>>>>>
>>>>>> http://www.boost.org/doc/libs/1_58_0/doc/html/foreach.html#foreach.introduction.making__literal_boost_foreach__literal__prettier
>>>>>
>>>>> But that is not 1.55 you are using and might not (and it doesn't!) fit
>>>>> Rivet >1.48 requirement. Quite confusing.
>>>>
>>>> I just picked the first result that came up in Google. That instruction
>>>> has been in place since version 1.52 in 2012, because of problems
>>>> introduced by clashes with the internal use of a "foreach" identifier.
>>>> Sounds like we should update the Rivet Boost version requirement, if
>>>> 1.48 is causing trouble -- we're not testing on a platform with that
>>>> version so it's good to know there's a problem.
>>>
>>> The >1.47 requirement is in the Rivet *now*. I don't know why it is
>>> there and if it causes problems.
>>> Maybe the workaround is present there since 1.52, but it clearly fails
>>> with 1.53.
>>> Also, it looks SL7 will stay with 1.53 and making 1.55 a minimal
>>> requirement will make Rivet incompatible with the default and most used
>>> HEP OS of the next 5 years.
>>>
>>>
>>> 2)
>>>>>> I have a feeling that this bug relates to the version of Boost you're
>>>>>> using, in conjunction with more recent compilers.
>>>>>
>>>>> Well, I try to stick to the default systems, I do not want to introduce
>>>>> my custom versions for boost, gcc, glibc and so on. Now my system is
>>>>> vanilla CentOS7.
>>>>
>>>> Maybe someone else on this list can confirm, but it sounds like the
>>>> default GCC + Boost versions on CentOS 7 might be a problematic combination.
>>>
>>> It also fails with clang. I don't have other compilers and time to try.
>>> I cannot try other boost as recompilation of boost requires too much
>>> external libraries and there is no binaries(rpms).
>>>
>>>
>>>
>>>
>>>
>>> 3)
>>>>
>>>>>> I recall that an
>>>>>> updated boost.m4 script that we introduced in the recent version 2.3.0
>>>>>> addresses the problem...
>>>>>
>>>>> No, I've tried 2.2 and 2.1 as well.
>>>>
>>>> I mean that versions before 2.3 might have the problem while 2.3 is ok.
>>>> Or does 2.3.0 also get through your configure step and then fail at
>>>> compile time?
>>>
>>> Sure.
>>>
>>>
>>> 4)
>>>>>> or rather it detects that there will be a
>>>>>> problem and requires a consistent GCC+Boost installation.
>>>>> It requires boost>1.48 or so and nothing more to solve r/lvalue problem.
>>>>>
>>>>>
>>>>>> The *real* solution will be to require and use the C++11 range-for
>>>>>> construct instead of Boost's macro. This will also work a lot better for
>>>>>> e.g. iterating over std::maps, which don't work well with the macro
>>>>>> approach. And of course we can replace a lot (but not all, I think)
>>>>>> Boost functionality in Rivet with C++11 standard features
>>>>> As I see, foreach appears in quite simple constructions for which even
>>>>> C++0x will work fine. I mean "for (std::<blabla>::iterator it=...)"
>>>>> one will need one or zero more lines. In total, that would require
>>>>> ~200-300 lines.
>>>>
>>>> Yes, but Rivet's whole design philosophy is aligned with the "make
>>>> simple things simple quoted on the Boost foreach web page". We've been
>>>> using this functionality for more than 5 years! We're not going to take
>>>> a backward step to use iterators unnecessarily when a) the current use
>>>> of BOOST_FOREACH works on all the systems we've tested, including LCG
>>>> platforms, and b) the properly language-integrated version of that macro
>>>> is so close to being usable.
>>>
>>> Sure, BOOST_FOREACH looks nice and in the Rivet it also works on some
>>> "specially prepared" systems. But "so close" implies "is not", which
>>> means it will fail on other, "ordinary" systems.
>>>
>>>
>>>
>>> 5)
>>>>>
>>>>>> , so it's very
>>>>>> appealing to many of us. But we don't feel that non-experiment HEP
>>>>>> computing resources are yet in a state where we can make that C++11
>>>>>> requirement without causing pain to many theory users.
>>>>>
>>>>> Actually the experementalists are even less flexible with the software.
>>>>> In many cases it is _very_ hard and inconvenient to install somewhere a
>>>>> custom version of compiler, boost and so on in the userspace. Some
>>>>> programs will not work with custom versions at all. And custom versions
>>>>> for every single library is a direct way to dependency hell. For many
>>>>> physics software packages I would prefer to have less features but
>>>>> easier installation and compatibility.
>>>>
>>>> What I meant is that the SL *system* versions of these packages are
>>>> often 5+ years out of date and not sufficient, but that experiment
>>>> software environments usually use much newer versions of all our
>>>> dependencies. We could move to requiring C++11 and the experiment/LCG
>>>> environments would have no problem, but the system compilers would not
>>>> be sufficiently capable.
>>>
>>> I would not blame compilers or old software:
>>>
>>>
>>> https://gcc.gnu.org/gcc-4.8/
>>> GCC 4.8.3 May 22, 2014
>>> http://www.boost.org/users/history/
>>> Version 1.53.0 February 4th, 2013 18:29 GMT
>>> http://llvm.org/
>>> 3.4.2: June 2014
>>>
>>> 2013-10-25 Andy Buckley <andy.buckley at cern.ch>
>>> * 2.0.0 release!!!!!!
>>> 2014-02-06 Andy Buckley <andy.buckley at cern.ch>
>>> * 2.1.0 release!
>>> 2014-09-30 Andy Buckley <andy.buckley at cern.ch>
>>> * 2.2.0 release!
>>> 2015-06-30 Andy Buckley <andy.buckley at cern.ch>
>>> * Bump version to 2.3.0 and require YODA > 1.4.0 (current head at
>>>
>>>
>>>
>>>
>>> 6)
>>>>>> For what it's worth, I'm currently using GCC 4.9.2 and Boost 1.55 and it
>>>>>> works fine. In the pre-release testing that we do on CERN lxplus we use
>>>>>> the system compiler but install our own 1.55 version of Boost.
>>>>>
>>>>> As far as I understand other versions don't work.
>>>>> GCC 4.9.2 and Boost 1.55 are not default on the lxplus.cern.ch,
>>>>> bastion.desy.de, gate.rzg.mpg.de, (fnal?) and many others. If it doesn't
>>>>> work there, one should use custom version.
>>>>
>>>> As I said, the defaults on HEP systems are very often not sufficient.
>>>> That's why the experiments override them with full up-to-date
>>>> environments.
>>>
>>> For obvious reasons that will not work for any of past (i.e. non-LHC)
>>> experiments (significant fraction of Rivet analyses). The machines and
>>> software are either "frozen" or don't exist anymore (implies using
>>> public computing resources, mostly with default versions of compilers
>>> and libraries). In some cases the old software will not work with
>>> up-to-date software.
>>>
>>>
>>>
>>> 7)
>>>>> Anyway,
>>>>> it looks it works (compiles!) for me with a trivial patch (see
>>>>> attached).
>>>>
>>>> Which is exactly what we used to have, and reversed because of the
>>>> problems that it can have and the updated Boost solution. I'm glad it
>>>> works for your package/compiler combination, but we won't apply it upstream.
>>>
>>> Sure. The proper solution would be to replace BOOST_FOREACH or to have
>>> different versions of that part of code for different boost versions.
>>> (Sorry, no time to prepare that patch.)
>>>
>>>
>>>
>>> Best regards,
>>> Andrii
>>>
>>>
>>>> Andy
>>>>
>>>>
>>>>>> On 04/08/15 13:05, Andrii Verbytskyi wrote:
>>>>>>> Dear Andy,
>>>>>>> I just tried to compile 2.* versions of Rivet on CentOS
>>>>>>> 7/gcc4.8.3/boost1.53.
>>>>>>> All those attempts failed, the compiler doesn't accept
>>>>>>> the Rivet code:
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> CXX libRivetCore_la-Run.lo
>>>>>>> In file included from ../../include/Rivet/Run.hh:5:0,
>>>>>>> from Run.cc:2:
>>>>>>> ../../include/Rivet/Tools/RivetBoost.hh:16:36: error: declaration of
>>>>>>> namespace 'boost::BOOST_FOREACH' conflicts with
>>>>>>> namespace BOOST_FOREACH = foreach;
>>>>>>> ^
>>>>>>> In file included from /usr/include/boost/foreach.hpp:89:0,
>>>>>>> from ../../include/Rivet/Tools/RivetBoost.hh:12,
>>>>>>> from ../../include/Rivet/Run.hh:5,
>>>>>>> from Run.cc:2:
>>>>>>> /usr/include/boost/foreach_fwd.hpp:56:1: error: previous declaration of
>>>>>>> namespace 'boost::BOOST_FOREACH' here
>>>>>>> {
>>>>>>> ^
>>>>>>> In file included from ../../include/Rivet/Math/MathUtils.hh:5:0,
>>>>>>> from ../../include/Rivet/Math/Math.hh:5,
>>>>>>> from ../../include/Rivet/Tools/Utils.hh:5,
>>>>>>> from ../../include/Rivet/Config/RivetCommon.hh:26,
>>>>>>> from ../../include/Rivet/AnalysisHandler.hh:5,
>>>>>>> from Run.cc:3:
>>>>>>> ../../include/Rivet/Math/MathHeader.hh:45:16: warning: 'Rivet::MAXINT'
>>>>>>> defined but not used [-Wunused-variable]
>>>>>>> const double MAXINT = std::numeric_limits<int>::max();
>>>>>>> ----------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> It looks the reason is a well known (since 4 years!) BOOST bug.
>>>>>>> 1) Which compilers do you use for tests, i.e. with which compiler Rivet
>>>>>>> will work?
>>>>>>> 2) Has anyone tried to compile Rivet with (new)gcc?
>>>>>>> 3) Is it possible to drop that construction from Rivet? It looks it
>>>>>>> doesn't appear too often in the code and when it does the replacement is
>>>>>>> obvious.
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Andrii
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, 2014-12-05 at 14:10 +0100, Andrii Verbytskyi wrote:
>>>>>>>> Hi,
>>>>>>>> yes, environment variables are working, however passing arguments via
>>>>>>>> environment variables is implicit way and implicit way is worse that
>>>>>>>> explicit. Also, in many cases environment variables will make things
>>>>>>>> less convenient or even defunct. A good example is using rivet
>>>>>>>> from a Makefile. One can say the same about using rivet in system() and
>>>>>>>> so on. Also, the way of setting environment variables depends on shell
>>>>>>>> --> less convenient usage of rivet even from shell.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Andrii
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, 2014-12-05 at 13:00 +0000, Andy Buckley wrote:
>>>>>>>>> Hi Andrii,
>>>>>>>>>
>>>>>>>>> Don't the environment variables work for these? --analysis-path is just
>>>>>>>>> syntactic sugar for those, and to be honest I was considering removing
>>>>>>>>> it to clean up the command-line interface!
>>>>>>>>>
>>>>>>>>> Andy
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 05/12/14 12:44, Andrii Verbytskyi wrote:
>>>>>>>>>> Dear Andy,
>>>>>>>>>> here are some (hopefully useful) improvements for Rivet.
>>>>>>>>>>
>>>>>>>>>> In addition to --analysis-path I think it would be useful to have
>>>>>>>>>>
>>>>>>>>>> --ref-path, --info-path, --plot-path.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So here are the files with the changes. Please note that rivet should be
>>>>>>>>>> generated from rivet.in with a substitution of install paths.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Andrii
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
More information about the Rivet
mailing list
|