<div>I'm running the 2.6.1 validation at the moment. Is there going to be a fix for this Mac issue before the release? I don't have one, one of you Maccists will need to leap in and fix it... assuming that you want the next Rivet release to work for you ;-)</div><br><div>Andy</div><br><div><signature id="initial"><div><table cellpadding="0" cellspacing="0"><tbody><tr><td colspan="2"><div style="padding-bottom:15px"><div><strong>Dr Andy Buckley, Senior Lecturer / Royal Society University Research Fellow</strong></div><div>Particle Physics Experiment Group, University of Glasgow</div></div></td></tr><tr><td style="vertical-align:top"></td><td><div style="font-size:0.9em;white-space:nowrap;border-left:2px solid gray;margin-left:20px;padding-left:20px"><div><div></div><div></div></div></div></td></tr></tbody></table></div></signature></div><div class="gmail_quote_attribution">On Jul 30 2018, at 9:33 pm, Andy Buckley <andy.buckley@cern.ch> wrote:</div><blockquote><br><div><div>Is it relevant that the doc builds are explicitly called as $(PYTHON) $(srcdir)/mk-analyses-html etc., rather than just $(srcdir)/mk-analyses-html ? Maybe the implicit "shebang" execution is not such a problem... but I don't have a Mac to test on. It works fine on my Linux system without the $(PYTHON), though, so I've changed it to that and pushed the release-2-6-x head.</div><br><div><em>Really</em> looking forward to getting past all these technical compatibility issues that crop up every time we approach this release!</div><br><div>Andy</div><br><div><div><div><table cellpadding="0" cellspacing="0"><tbody><tr><td colspan="2"><div style="padding-bottom:15px;"><div><strong>Dr Andy Buckley, Lecturer / Royal Society University Research Fellow</strong></div><div>Particle Physics Experiment Group, University of Glasgow</div></div></td></tr><tr><td style="vertical-align:top;"></td><td><div style="font-size:0.9em;white-space:nowrap;border-left:2px solid gray;margin-left:20px;padding-left:20px;"><div><div></div><div></div></div></div></td></tr></tbody></table></div></div></div><div>On Jul 30 2018, at 8:18 pm, James William Monk <james.william.monk@cern.ch> wrote:</div><blockquote><br><div><div>Thanks David,</div><br><div>How then does the rivet main executable work then? That is itself a python script that loads the Rivet libs. How does it manage to inherit the DYLD_LIBRARY_PATH</div><br><div>cheers,</div><br><div>James</div><br><br><blockquote><div>On 30 Jul 2018, at 17:28, David Grellscheid <david.grellscheid@durham.ac.uk> wrote:</div><br><div>You've diagnosed it right. All programs in /usr/bin are considered protected, and will not be passed any DYLD environment. A python in /usr/local or /opt will work fine</div><br><div>Also, making the script executable does not help. The first line with the #! still calls either /usr/bin/env or /usr/bin/python with exactly the same issue</div><br><div>David (on house move teabreak)</div><br><br><br><br><div>On 30 July 2018 16:17:18 BST, James William Monk <james.william.monk@cern.ch> wrote:</div><blockquote><div>Hi everyone,</div><br><div>Did we ever come across the problem that the mac System Integrity</div><div>Protection (SIP) does not pass on the DYLD_LIBRARY_PATH to a subprocess</div><div>if it thinks that subprocess is a “protected” process? I believe that</div><div>is the problem here, and is preventing the library path being set</div><div>correctly during the Rivet build because it spawns a python subprocess</div><div>that does not inherit the correct environment</div><br><div>It seems that if I do a python script to simply print the environment,</div><div>i.e.</div><br><div>import os</div><div>for key in os.environ.keys():</div><div>print key</div><br><div>then execute</div><br><div>foo=“bar” python test</div><div>(where test contains the script above)</div><br><div>Then I see that foo is detected in the environment. However, if I do</div><br><div>DYLD_LIBRARY_PATH=“bar” python test</div><br><div>Then DYLD_LIBRARY_PATH does not show up! Presumably SIP has decided</div><div>that the python subprocess must be protected from malicious setting of</div><div>the environment. I can see why they might think that is important,</div><div>since changing the path would potentially cause it to load a bad</div><div>version of some library. I can disable SIP to confirm this, but that</div><div>requires a reboot of my mac and is not something we should ask users to</div><div>do.</div><br><div>I think that the fix for this is that the mk-analysis-html script has</div><div>to be executable. That way it will inherit from the build environment,</div><div>not from the python subprocess whose environment has been wiped clean.</div><br><br><div>cheers,</div><br><div>James</div><br><br><br><br><br><br><blockquote><div>On 30 Jul 2018, at 16:36, James William Monk</div></blockquote><div><james.william.monk@cern.ch> wrote:</div><blockquote><br><div>Hi Sabah,</div><br><div>There is a bug in the build system for the docs in Rivet 2.6 on mac.</div></blockquote><div>This issue has occurred before, but I only just remembered it. It</div><div>looks like David Grellscheid has tried to fix it in the past, but when</div><div>I use the updated Makefile.am from the doc dir, I still get the same</div><div>problem. I knew there was a reason I was still on Rivet 2.5.4 :)</div><blockquote><br><div>It looks to me like there is a mistake in the setup for the</div></blockquote><div>environment needed for the python script mk-analysis-html. At least</div><div>one error is that it seems to have the PYTHONPATH pointing to the</div><div>installation prefix, but there is nothing there of course because Rivet</div><div>hasn’t been installed yet. Another error is that DYLD_LIBRARY_PATH is</div><div>not set. I tested this by modifying doc/mk-analysis-html by adding</div><blockquote><br><div>print "Hello from mk-analysis-html. I think $PYTHONPATH = " +</div></blockquote><div>os.environ['PYTHONPATH']</div><blockquote><div>print "environ keys are"</div><div>for key in os.environ.keys():</div><div>print key</div><br><div>This problem is only related to the building of the documentation,</div></blockquote><div>but disabling doxygen doesn’t seem to help. I *think* if you plough on</div><div>regardless and do make install, you will get Rivet installed in your</div><div>prefix, just without the docs and the rivetenv.sh script.</div><blockquote><br><div>cheers,</div><br><div>James</div><br><blockquote><div>On 28 Jul 2018, at 13:11, Sabah Salih <sabah.salih@manchester.ac.uk></div></blockquote></blockquote><div>wrote:</div><blockquote><blockquote><br><div>Dear James,</div><div>I am very grateful for your kind help</div><div>I tried to apply rivet-bootstrap content line by line via command</div></blockquote></blockquote><div>line</div><blockquote><blockquote><br><div>YODA, HEPMC,... are fine</div><div>When I reached Rivet I get the following:</div><div>I attached the file which have the complete steps for RIVET</div><br><div>Many Thanks, Sabah.</div><br><br><br><div>File</div></blockquote></blockquote><div>"/private/tmp/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/__init__.py",</div><div>line 12, in <module></div><blockquote><blockquote><div>from rivet.core import *</div><div>ImportError:</div></blockquote></blockquote><div>dlopen(/private/tmp/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/core.so,</div><div>10): Library not loaded: /tmp/rivet/local/lib/libRivet.dylib</div><blockquote><blockquote><div>Referenced from:</div></blockquote></blockquote><div>/private/tmp/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/core.so</div><blockquote><blockquote><div>Reason: image not found</div><div>make[1]: *** [analyses.json] Error 1</div><div>make[1]: *** Waiting for unfinished jobs....</div><div>Using output file name 'analyses.html' and directory 'analyses'</div><div>Traceback (most recent call last):</div><div>File "mk-analysis-html", line 25, in <module></div><div>import rivet</div><div>File</div></blockquote></blockquote><div>"/private/tmp/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/__init__.py",</div><div>line 12, in <module></div><blockquote><blockquote><div>from rivet.core import *</div><div>ImportError:</div></blockquote></blockquote><div>dlopen(/private/tmp/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/core.so,</div><div>10): Library not loaded: /tmp/rivet/local/lib/libRivet.dylib</div><blockquote><blockquote><div>Referenced from:</div></blockquote></blockquote><div>/private/tmp/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/core.so</div><blockquote><blockquote><div>Reason: image not found</div><div>make[1]: *** [analyses.html] Error 1</div><div>make: *** [all-recursive] Error 1</div><br><div>ls -lh</div></blockquote></blockquote><div>/private/tmp/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/</div><blockquote><blockquote><div>total 312</div><div>-rw-r--r-- 1 admin wheel 351B 3 Oct 2017 __init__.py</div><div>-rw-r--r-- 1 admin wheel 598B 28 Jul 11:26 __init__.pyc</div><div>-rw-r--r-- 1 admin wheel 3.0K 6 Nov 2017 aopaths.py</div><div>-rwxr-xr-x 1 admin wheel 121K 28 Jul 11:15 core.so</div><div>-rw-r--r-- 1 admin wheel 7.8K 3 Oct 2017 plotinfo.py</div><div>-rw-r--r-- 1 admin wheel 2.5K 3 Oct 2017 spiresbib.py</div><div>-rw-r--r-- 1 admin wheel 6.9K 20 Nov 2017 util.py</div><br><br><div>Many Thanks, Sabah.</div><br><div>From Sabah Salih</div><div>Particle Physics Group,</div><div>The School of Physics and Astronomy,</div><div>The University of Manchester,</div><div>Schuster Laboratory,</div><div>Brunswick Street,</div><div>Manchester M13 9PL.</div><div>Tel: +44 1612754171 or x4171</div><div>E-mail: sabah.salih@manchester.ac.uk</div><br><div>________________________________________</div><div>From: James William Monk [james.william.monk@cern.ch]</div><div>Sent: 25 July 2018 22:46</div><div>To: Sabah Salih</div><div>Cc: James William Monk; Andy Buckley; rivet@projects.hepforge.org</div><div>Subject: Re: [Rivet] ruvet and osx</div><br><div>Hi Sabah,</div><br><div>That error is just confirming that the Rivet lib is not present, I</div></blockquote></blockquote><div>presume because the build and/or installation failed. Do you see any</div><div>other error that looks like a build error? I’m not very familiar with</div><div>the bootstrap, so I can’t say whether it produces any build logs, or</div><div>where they would be, but we need to see the build failure message to</div><div>know why the libraries weren't built properly.</div><blockquote><blockquote><br><div>cheers,</div><br><div>James</div><br><br><br><blockquote><div>On 25 Jul 2018, at 19:09, Sabah Salih</div></blockquote></blockquote></blockquote><div><sabah.salih@manchester.ac.uk> wrote:</div><blockquote><blockquote><blockquote><br><div>Dear James,</div><div>Thank you so much.</div><div>Following your advice I did the following:</div><br><div>edit rivet-bootstrap</div><br><div>and changed</div><br><div>function conf { ./configure --prefix=$INSTALL_PREFIX "$@"; }</div><div>to</div><div>function conf { ./configure CC=/usr/bin/clang CXX=/usr/bin/clang++</div></blockquote></blockquote></blockquote><div>--prefix=$INSTALL_PREFIX "$@"; }</div><blockquote><blockquote><blockquote><br><div>and</div><div>./configure --prefix=$INSTALL_PREFIX</div><div>to</div><div>./configure CC=/usr/bin/clang CXX=/usr/bin/clang++</div></blockquote></blockquote></blockquote><div>--prefix=$INSTALL_PREFIX</div><blockquote><blockquote><blockquote><br><div>When I type</div><div>./rivet-bootstrap</div><br><div>I get this</div><div>File</div></blockquote></blockquote></blockquote><div>"/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/__init__.py",</div><div>line 12, in <module></div><blockquote><blockquote><blockquote><div>from rivet.core import *</div><div>ImportError:</div></blockquote></blockquote></blockquote><div>dlopen(/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/core.so,</div><div>10): Library not loaded:</div><div>/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/local/lib/libRivet.dylib</div><blockquote><blockquote><blockquote><div>Referenced from:</div></blockquote></blockquote></blockquote><div>/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/core.so</div><blockquote><blockquote><blockquote><div>Reason: image not found</div><div>make[1]: *** [analyses.json] Error 1</div><div>make[1]: *** Waiting for unfinished jobs....</div><div>Using output file name 'analyses.html' and directory 'analyses'</div><div>Traceback (most recent call last):</div><div>File "mk-analysis-html", line 25, in <module></div><div>import rivet</div><div>File</div></blockquote></blockquote></blockquote><div>"/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/__init__.py",</div><div>line 12, in <module></div><blockquote><blockquote><blockquote><div>from rivet.core import *</div><div>ImportError:</div></blockquote></blockquote></blockquote><div>dlopen(/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/core.so,</div><div>10): Library not loaded:</div><div>/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/local/lib/libRivet.dylib</div><blockquote><blockquote><blockquote><div>Referenced from:</div></blockquote></blockquote></blockquote><div>/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/Rivet-2.6.0/pyext/build/lib.macosx-10.13-intel-2.7/rivet/core.so</div><blockquote><blockquote><blockquote><div>Reason: image not found</div><div>make[1]: *** [analyses.html] Error 1</div><div>make: *** [all-recursive] Error 1</div><br><div>ls local/lib/libRivet.dylib</div><div>ls: local/lib/libRivet.dylib: No such file or directory</div><br><div>Many Thanks, Sabah.</div><br><br><div>From Sabah Salih</div><div>Particle Physics Group,</div><div>The School of Physics and Astronomy,</div><div>The University of Manchester,</div><div>Schuster Laboratory,</div><div>Brunswick Street,</div><div>Manchester M13 9PL.</div><div>Tel: +44 1612754171 or x4171</div><div>E-mail: sabah.salih@manchester.ac.uk</div><br><div>________________________________________</div><div>From: James William Monk [james.william.monk@cern.ch]</div><div>Sent: 25 July 2018 13:57</div><div>To: Sabah Salih</div><div>Cc: James William Monk; Andy Buckley; rivet@projects.hepforge.org</div><div>Subject: Re: [Rivet] ruvet and osx</div><br><div>Hi Sabah,</div><br><div>No, there’s no need to cross compile here, we just need to make</div></blockquote></blockquote></blockquote><div>sure it uses compilers and libs all from the same toolchain and doesn’t</div><div>mix and match system tools with homebrew tools. For example, to try to</div><div>use the system compiler you could try something like configuring Rivet</div><div>and its dependencies with the extra config option</div><blockquote><blockquote><blockquote><br><div>./configure <usual config options> CC=/usr/bin/clang</div></blockquote></blockquote></blockquote><div>CXX=/usr/bin/clang++</div><blockquote><blockquote><blockquote><br><div>It looks like you prefer to use homebrew’s tools though. I don’t</div></blockquote></blockquote></blockquote><div>know where they are located on your system, but the equivalent</div><div>configure command would be</div><blockquote><blockquote><blockquote><br><div>./configure <usual config opts> CC=/path/to/brew/gcc</div></blockquote></blockquote></blockquote><div>CXX=/path/to/brew/g++</div><blockquote><blockquote><blockquote><br><div>where you fill in the paths to the brew installation versions of</div></blockquote></blockquote></blockquote><div>gcc and g++. Of course, any Rivet dependencies (FastJet, GSL,</div><div>HepMC...) will also need to be configured in the same way first.</div><blockquote><blockquote><blockquote><br><div>If you just want to run Rivet, as opposed to develop for it, I’d</div></blockquote></blockquote></blockquote><div>also suggest taking a look at the Docker distribution for mac:</div><blockquote><blockquote><blockquote><br><div>https://rivet.hepforge.org/trac/wiki/Docker</div><br><div>cheers,</div><br><div>James</div><br><br><blockquote><div>On 25 Jul 2018, at 08:37, Sabah Salih</div></blockquote></blockquote></blockquote></blockquote><div><sabah.salih@manchester.ac.uk> wrote:</div><blockquote><blockquote><blockquote><blockquote><br><div>Dear James,</div><div>It is so nice to hear from you.</div><div>Thank you so much for your kind reply.</div><br><div>I just done</div><br><div>brew tap osx-cross/arm</div><div>brew tap osx-cross/avr</div><br><div>brew install arm-gcc-bin</div><br><div>brew install avr-gcc</div><div>This look like installing gcc8</div><br><div>Is this what you meant?</div><br><div>Many Tanks, Sabah.</div><br><div>From Sabah Salih</div><div>Particle Physics Group,</div><div>The School of Physics and Astronomy,</div><div>The University of Manchester,</div><div>Schuster Laboratory,</div><div>Brunswick Street,</div><div>Manchester M13 9PL.</div><div>Tel: +44 1612754171 or x4171</div><div>E-mail: sabah.salih@manchester.ac.uk</div><br><div>________________________________________</div><div>From: James William Monk [james.william.monk@cern.ch]</div><div>Sent: 25 July 2018 01:10</div><div>To: Andy Buckley; Sabah Salih</div><div>Cc: rivet@projects.hepforge.org</div><div>Subject: Re: [Rivet] ruvet and osx</div><br><div>Hi,</div><br><div>From a bit of nurdling about on various fora, that error appears</div></blockquote></blockquote></blockquote></blockquote><div>to refer to an option that is present for clang, but not gcc. Clang is</div><div>the supplied default on mac. You have installed a separate gcc</div><div>toolchain via homebrew. What I can imagine may be happening is that</div><div>autotools is detecting the system clang and adding options</div><div>appropriately, but then the g++ command is now calling the gcc from</div><div>homebrew. For example, on my own mac I see</div><blockquote><blockquote><blockquote><blockquote><br><div>g++ --version</div><div>Configured with:</div></blockquote></blockquote></blockquote></blockquote><div>--prefix=/Applications/Xcode.app/Contents/Developer/usr</div><div>--with-gxx-include-dir=/usr/include/c++/4.2.1</div><blockquote><blockquote><blockquote><blockquote><div>Apple LLVM version 9.1.0 (clang-902.0.39.2)</div><div>Target: x86_64-apple-darwin17.7.0</div><br><div>It’s possible you may be able to cure this with some appropriate</div></blockquote></blockquote></blockquote></blockquote><div>environment settings like</div><blockquote><blockquote><blockquote><blockquote><br><div>export CC=/usr/bin/clang</div><div>export CXX=/usr/bin/clang++</div><br><div>Which would try to force it to use the system clang compiler</div></blockquote></blockquote></blockquote></blockquote><div>consistently. Alternatively, try to point it to your homebrew compiler</div><div>location. You may also like to consider removing homebrew as another</div><div>solution - I don’t know what else it adds for you, but personally I</div><div>have never found those kinds of packaging systems helpful on a mac</div><div>precisely because they bring a second toolchain into play that is not</div><div>always entirely consistent with the system toolchain.</div><blockquote><blockquote><blockquote><blockquote><br><div>cheers,</div><br><div>James</div><br><br><br><blockquote><div>On 25 Jul 2018, at 00:48, Andy Buckley <andy.buckley@cern.ch></div></blockquote></blockquote></blockquote></blockquote></blockquote><div>wrote:</div><blockquote><blockquote><blockquote><blockquote><blockquote><br><div>I'm afraid I don't use Macs, so am not sure what is best. Using</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>an earlier compiler might work; I'm a little surprised that autoreconf</div><div>did not help. Hopefully someone else on the Rivet team has a bit more</div><div>Mac experience and can help out.</div><blockquote><blockquote><blockquote><blockquote><blockquote><br><div>Andy</div><br><div>Dr Andy Buckley, Lecturer / Royal Society University Research</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>Fellow</div><blockquote><blockquote><blockquote><blockquote><blockquote><div>Particle Physics Experiment Group, University of Glasgow</div><div>On Jul 24 2018, at 4:52 pm, Sabah Salih</div></blockquote></blockquote></blockquote></blockquote></blockquote><div><sabah.salih@manchester.ac.uk> wrote:</div><blockquote><blockquote><blockquote><blockquote><blockquote><br><br><div>Dear Andy,</div><div>Thank you ever so much. The problem look like it is in</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>YODA.</div><blockquote><blockquote><blockquote><blockquote><blockquote><div>I did</div><br><div>cd YODA-1.7.0</div><br><div>autoreconf -i</div><div>make</div><br><div>that did not fix it</div><br><div>cd ..</div><div>this is where rivet-bootstrap</div><br><div>and rerun</div><br><div>./rivet-bootstrap</div><br><div>This did not fix it neither.</div><br><div>What is the best way to get rivet to work in a mac please.?</div><div>It does not have to be gcc8</div><br><div>Many thanks, Sabah</div><br><br><div>From Sabah Salih</div><div>Particle Physics Group,</div><div>The School of Physics and Astronomy,</div><div>The University of Manchester,</div><div>Schuster Laboratory,</div><div>Brunswick Street,</div><div>Manchester M13 9PL.</div><div>Tel: +44 1612754171 or x4171</div><div>E-mail: sabah.salih@manchester.ac.uk</div><div>From: Andy Buckley [andy.buckley@cern.ch]</div><div>Sent: 19 July 2018 14:41</div><div>To: Sabah Salih</div><div>Cc: rivet@projects.hepforge.org</div><div>Subject: Re: [Rivet] ruvet and osx</div><br><div>Hi Sabah,</div><div>I have no idea about compilation with GCC 8 -- it looks like our</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>"autotools" build system assumes that a compiler flag will work, but</div><div>GCC 8 has removed it. I suspect that new versions of autotools would</div><div>fix it, but of course our existing tarball is built with an older</div><div>version.</div><blockquote><blockquote><blockquote><blockquote><blockquote><br><div>You could try building the (final) Rivet step by hand, first</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>rebuilding the autotools bits with a call to "autoreconf -i". It may</div><div>even be possible to re-run the bootstrap script after doing that, and</div><div>let it finish the build with the updated Makefiles.</div><blockquote><blockquote><blockquote><blockquote><blockquote><br><div>Andy</div><br><div>Dr Andy Buckley, Lecturer / Royal Society University Research</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>Fellow</div><blockquote><blockquote><blockquote><blockquote><blockquote><div>Particle Physics Experiment Group, University of Glasgow</div><div>On Jul 19 2018, at 9:15 am, Sabah Salih</div></blockquote></blockquote></blockquote></blockquote></blockquote><div><sabah.salih@manchester.ac.uk> wrote:</div><blockquote><blockquote><blockquote><blockquote><blockquote><br><br><div>Dear All,</div><div>I am trying to install rivet in a max osx 10.13.6</div><div>I have</div><br><div>gcc --version</div><div>gcc (Homebrew GCC 8.1.0) 8.1.0</div><div>Copyright (C) 2018 Free Software Foundation, Inc.</div><div>This is free software; see the source for copying conditions.</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>There is NO</div><blockquote><blockquote><blockquote><blockquote><blockquote><div>warranty; not even for MERCHANTABILITY or FITNESS FOR A</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>PARTICULAR PURPOSE.</div><blockquote><blockquote><blockquote><blockquote><blockquote><br><div>gfortran --version</div><div>GNU Fortran (Homebrew GCC 8.1.0) 8.1.0</div><div>Copyright (C) 2018 Free Software Foundation, Inc.</div><div>This is free software; see the source for copying conditions.</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>There is NO</div><blockquote><blockquote><blockquote><blockquote><blockquote><div>warranty; not even for MERCHANTABILITY or FITNESS FOR A</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>PARTICULAR PURPOSE.</div><blockquote><blockquote><blockquote><blockquote><blockquote><br><div>g++ --version</div><div>g++ (Homebrew GCC 8.1.0) 8.1.0</div><div>Copyright (C) 2018 Free Software Foundation, Inc.</div><div>This is free software; see the source for copying conditions.</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>There is NO</div><blockquote><blockquote><blockquote><blockquote><blockquote><div>warranty; not even for MERCHANTABILITY or FITNESS FOR A</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>PARTICULAR PURPOSE.</div><blockquote><blockquote><blockquote><blockquote><blockquote><br><br><div>I got rivet from the following url</div><br><div>wget</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>http://rivet.hepforge.org/hg/bootstrap/raw-file/2.6.0/rivet-bootstrap</div><blockquote><blockquote><blockquote><blockquote><blockquote><div>chmod +x rivet-bootstrap</div><br><div>After I run the following</div><div>./rivet-bootstrap</div><br><div>I get the following in the end</div><br><br><div>g++ -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe</div></blockquote></blockquote></blockquote></blockquote></blockquote><div>-fno-common -fno-strict-aliasing -fwrapv -DENABLE_DTRACE -DMACOSX</div><div>-DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g</div><div>-fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -DNDEBUG</div><div>-I/usr/include -I/usr/include -pipe</div><div>-I/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/YODA-1.7.0/include</div><div>-I/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/YODA-1.7.0/include</div><div>-I/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/YODA-1.7.0/pyext/yoda</div><div>-I/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/YODA-1.7.0/pyext/yoda</div><div>-I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7</div><div>-c</div><div>/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/YODA-1.7.0/pyext/yoda/util.cpp</div><div>-o</div><div>/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/YODA-1.7.0/pyext/build/temp.macosx-10.13-intel-2.7/Users/admin/madgraph/MG5_aMC_v2_6_3/rivet/YODA-1.7.0/pyext/yoda/util.o</div><div>-O3 -Wno-unused-but-set-variable -Wno-sign-compare</div><blockquote><blockquote><blockquote><blockquote><blockquote><div>g++: error: unrecognized command line option '-Wshorten-64-to-32'</div><div>error: command 'g++' failed with exit status 1</div><div>make[2]: *** [all-local] Error 1</div><div>make[1]: *** [all-recursive] Error 1</div><div>make: *** [all-recursive] Error 1</div><br><br><div>What do I have to do to fix it please?</div><br><br><div>Maany Thanks, Sabah.</div><br><div>From Sabah Salih</div><div>Particle Physics Group,</div><div>The School of Physics and Astronomy,</div><div>The University of Manchester,</div><div>Schuster Laboratory,</div><div>Brunswick Street,</div><div>Manchester M13 9PL.</div><div>Tel: +44 1612754171 or x4171</div><div>E-mail: sabah.salih@manchester.ac.uk</div><div>_______________________________________________</div><div>Rivet mailing list</div><div>Rivet@projects.hepforge.org</div><div>https://www.hepforge.org/lists/listinfo/rivet</div><div>_______________________________________________</div><div>Rivet mailing list</div><div>Rivet@projects.hepforge.org</div><div>https://www.hepforge.org/lists/listinfo/rivet</div></blockquote><br><div>_______________________________________________</div><div>Rivet mailing list</div><div>Rivet@projects.hepforge.org</div><div>https://www.hepforge.org/lists/listinfo/rivet</div></blockquote><br><div>_______________________________________________</div><div>Rivet mailing list</div><div>Rivet@projects.hepforge.org</div><div>https://www.hepforge.org/lists/listinfo/rivet</div></blockquote><br><div><rivet-install.txt>_______________________________________________</div><div>Rivet mailing list</div><div>Rivet@projects.hepforge.org</div><div>https://www.hepforge.org/lists/listinfo/rivet</div></blockquote><br></blockquote></blockquote><div>_______________________________________________</div><div>Rivet mailing list</div><div>Rivet@projects.hepforge.org</div><div>https://www.hepforge.org/lists/listinfo/rivet</div></blockquote></div></blockquote></div></blockquote>