root @5.34.05_0: reported as broken by rev-upgrade

[andre.david@…]

port upgrade just picked up an upgrade to root, which ended up not working out so well:

--->  Activating root @5.34.05_0+fftw3+graphviz+gsl+minuit2+opengl+pythia+python27+roofit+soversion+ssl+tmva+xml
--->  Cleaning root
--->  Updating database of binaries: 100.0%
--->  Scanning binaries for linking errors: 100.0%
--->  Found 9 broken file(s), matching files to ports
Error: Port root is still broken after rebuilding it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a bug.

So, I obliged and this is what it looks like

$ sudo port -d -y rev-upgrade
dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
DEBUG: Copying /Users/adavid/Library/Preferences/com.apple.dt.Xcode.plist to /opt/local/var/macports/home/Library/Preferences
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/bugpoint
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llc
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/lli
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-ar
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-as
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-bcanalyzer
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-cov
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-diff
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-dis
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-dwarfdump
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-extract
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-ld
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-link
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-mc
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-nm
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-objdump
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-prof
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-ranlib
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-rtdyld
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/llvm-size
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/macho-dump
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-3.0/bin/opt
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/ld64/ld
DEBUG: skipping ppc in /opt/local/share/cmake-2.8/Modules/CPack.OSXScriptLauncher.in since this system can't run it anyway
DEBUG: skipping ppc in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/py2app/apptemplate/prebuilt/main-fat since this system can't run it anyway
DEBUG: skipping ppc in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/py2app/apptemplate/prebuilt/main-fat3 since this system can't run it anyway
DEBUG: skipping ppc64 in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/py2app/apptemplate/prebuilt/main-universal since this system can't run it anyway
DEBUG: skipping ppc in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/py2app/apptemplate/prebuilt/main-universal since this system can't run it anyway
DEBUG: skipping ppc in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/py2app/bundletemplate/prebuilt/main-fat since this system can't run it anyway
DEBUG: skipping ppc in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/py2app/bundletemplate/prebuilt/main-fat3 since this system can't run it anyway
DEBUG: skipping ppc64 in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/py2app/bundletemplate/prebuilt/main-universal since this system can't run it anyway
DEBUG: skipping ppc in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/py2app/bundletemplate/prebuilt/main-universal since this system can't run it anyway
--->  Scanning binaries for linking errors
Could not open libXrdUtils.1.dylib: Error opening or reading file (referenced from /opt/local/bin/xproofd)
DEBUG: Marking /opt/local/bin/xproofd as broken

Could not open libXrdClient.1.dylib: Error opening or reading file (referenced from /opt/local/bin/xproofd)
DEBUG: Marking /opt/local/bin/xproofd as broken

Could not open libXrdMain.1.dylib: Error opening or reading file (referenced from /opt/local/bin/xproofd)
DEBUG: Marking /opt/local/bin/xproofd as broken
DEBUG: Marking /opt/local/lib/root/libNetx.5.34.so as broken
DEBUG: Marking /opt/local/lib/root/libNetx.5.34.so as broken
DEBUG: Marking /opt/local/lib/root/libProofx.5.34.so as broken
DEBUG: Marking /opt/local/lib/root/libProofx.5.34.so as broken
DEBUG: Marking /opt/local/lib/root/libXrdProofd.5.34.so as broken
DEBUG: Marking /opt/local/lib/root/libXrdProofd.5.34.so as broken

--->  Found 9 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
DEBUG: Broken: root
DEBUG: Processing port root @0:5.34.05_0 +fftw3+graphviz+gsl+minuit2+opengl+pythia+python27+roofit+soversion+ssl+tmva+xml 
--->  Rebuilding in order
     root @5.34.05 +fftw3+graphviz+gsl+minuit2+opengl+pythia+python27+roofit+soversion+ssl+tmva+xml
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: root 5.34.05_0 exists in the ports tree
DEBUG: root 5.34.05_0 +fftw3+graphviz+gsl+minuit2+opengl+pythia+python27+roofit+soversion+ssl+tmva+xml is the latest installed
DEBUG: root 5.34.05_0 +fftw3+graphviz+gsl+minuit2+opengl+pythia+python27+roofit+soversion+ssl+tmva+xml is active
DEBUG: Merging existing variants '+fftw3+graphviz+gsl+minuit2+opengl+pythia+python27+roofit+soversion+ssl+tmva+xml' into variants
DEBUG: new fully merged portvariants: fftw3 + graphviz + python27 + roofit + bash_completion + pythia + minuit2 + soversion + tmva + xml + ssl + opengl + gsl +
DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/root
DEBUG: OS darwin/12.2.1 (Mac OS X 10.8) arch i386
DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: universal_variant is false, so not adding the default universal variant
DEBUG: Requested variant +bash_completion is not provided by port root.
DEBUG: Executing variant soversion provides soversion
DEBUG: Executing variant graphviz provides graphviz
DEBUG: Executing variant fftw3 provides fftw3
DEBUG: Executing variant gsl provides gsl
DEBUG: Executing variant roofit provides roofit
DEBUG: Executing variant tmva provides tmva
DEBUG: Executing variant minuit2 provides minuit2
DEBUG: Executing variant opengl provides opengl
DEBUG: Executing variant python27 provides python27
DEBUG: Executing variant ssl provides ssl
DEBUG: Executing variant xml provides xml
DEBUG: Executing variant pythia provides pythia
DEBUG: rev-upgrade override ... upgrading!
DEBUG: Not following dependencies
Skipping deactivate root @5.34.05_0+fftw3+graphviz+gsl+minuit2+opengl+pythia+python27+roofit+soversion+ssl+tmva+xml (dry run)
Skipping activate root @5.34.05_0+fftw3+graphviz+gsl+minuit2+opengl+pythia+python27+roofit+soversion+ssl+tmva+xml (dry run)
DEBUG: Rebuilding port root finished with status 0
Warning: If this was no dry run, rev-upgrade would now run the checks again to find unresolved and newly created problems

It does not look like it has to do with my flags (which are many), but something more fundamental, as if some of the libXrd*.dylib are simply not being built. They surely aren't in the disk:

$ sudo find /opt/local/ -iname "*libXrd*"
dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
/opt/local/lib/root/libXrdProofd.5.34.so
/opt/local/lib/root/libXrdProofd.5.so
/opt/local/lib/root/libXrdProofd.so

[cjones051073 (Chris Jones)]

please try a uninstall and clean rebuild, so

sudo port uninstall root
sudo port clean root
sudo port install root

if it still fails, post the *full* log file the message directs you to (not just the terminal output).

cheers Chris

[andre.david@…]

Replying to jonesc@…:

please try a uninstall and clean rebuild, so

sudo port uninstall root
sudo port clean root
sudo port install root

This seems to have cured it, though no real recompilation took place:

$  sudo port uninstall root
--->  Deactivating root @5.34.05_0+fftw3+graphviz+gsl+minuit2+opengl+pythia+python27+roofit+soversion+ssl+tmva+xml
--->  Cleaning root
--->  Uninstalling root @5.34.05_0+fftw3+graphviz+gsl+minuit2+opengl+pythia+python27+roofit+soversion+ssl+tmva+xml
--->  Cleaning root

$  sudo port clean root
--->  Cleaning root

$  sudo port install root
--->  Computing dependencies for root
--->  Fetching archive for root
--->  Attempting to fetch root-5.34.05_0+graphviz+gsl+minuit2+opengl+roofit+soversion+ssl+tmva+xml.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/root
--->  Attempting to fetch root-5.34.05_0+graphviz+gsl+minuit2+opengl+roofit+soversion+ssl+tmva+xml.darwin_12.x86_64.tbz2.rmd160 from http://lil.fr.packages.macports.org/root
--->  Installing root @5.34.05_0+graphviz+gsl+minuit2+opengl+roofit+soversion+ssl+tmva+xml
--->  Activating root @5.34.05_0+graphviz+gsl+minuit2+opengl+roofit+soversion+ssl+tmva+xml
--->  Cleaning root
--->  Updating database of binaries: 100.0%
--->  Scanning binaries for linking errors: 100.0%
--->  No broken files found.

Weird...

[cjones051073 (Chris Jones)]

Hmm... Glad it works.

One obvious difference is the variants you used on the second install where just the defaults, whereas previously you had given a few extra ones. This has the difference (other than the obvious, enabling new features) for forcing a build from source install, instead of from the binary tarballs.

If you are interested in paying you could try again adding back those variants. This would actually take you pretty much to what I use, also on OSX 10.8, so it would be surprising if it didn't work but ....

Chris

[andre.david@…]

Replying to jonesc@…:

If you are interested in p[l]aying you could try again adding back those variants.

I did not notice that the default variants were being picked up. Thanks for the heads up.

So the difference of my set of variants to the default on is: +fftw3+pythia+python27. I checked, and adding any of the three variants triggers the full compilation and the error.

How can I force the compilation for the default variants?

[cjones051073 (Chris Jones)]

uninstall and clean root, then just run

sudo port -s install root

[cjones051073 (Chris Jones)]

p.s what Xcode are you using ? Have you checked its up to date, and have to started it recently and checked the command line tools are up to date ?

have you done anything 'odd' to the macports.conf file or similar...

[andre.david@…]

Replying to jonesc@…:

p.s what Xcode are you using ? Have you checked its up to date, and have to started it recently and checked the command line tools are up to date ?

Xcode Version 4.6 (4H127), all tools up to date.

have you done anything 'odd' to the macports.conf file or similar...

No.

And yes, sudo port -s install root fails with the same prolbem, so it is not the variants.

Again, the libXrd*.dylib are simply not being built. Something changes in the configuration process when setting up the build area?

[cjones051073 (Chris Jones)]

Please attach the full build log file from a clean build (i.e. run sudo port clean root first)

Something is odd in your system, as exactly the same works for me here...

[andre.david@…]

Replying to jonesc@…:

Please attach the full build log file from a clean build (i.e. run sudo port clean root first)

Something is odd in your system, as exactly the same works for me here...

Attached. I noticed:

Checking for XrdVersion.hh ... /opt/xrootd/include/xrootd
Checking for xrootd version ... "v3.2.7"
Checking for libXrdMain ... /opt/xrootd/lib
Checking for libXrdUtils ... /opt/xrootd/lib
Checking for libXrdClient ... /opt/xrootd/lib

How can xrootd be outside /opt/local?

[cjones051073 (Chris Jones)]

It looks like you have an another installation of ROOT/xrootd under /opt/xrootd. MacPorts would not have put that there, so you must have installed it some other way as MacPorts *only* puts things in /opt/local (at least by default, you could have changed something in the configuration).

You need to remove /opt/xrootd and try again.

Chris

[andre.david@…]

Replying to jonesc@…:

It looks like you have an another installation of ROOT/xrootd under /opt/xrootd. MacPorts would not have put that there, so you must have installed it some other way as MacPorts *only* puts things in /opt/local (at least by default, you could have changed something in the configuration).

So, consulting my logs, I did install xrootd in /opt/xrootd. And sudo port install --no-rev-upgrade root +fftw3+graphviz+gsl+minuit2+opengl+pythia+python27+roofit+soversion+ssl+tmva+xml works as a temporary patch.

But this is overall nasty. From what I understand, rev-upgrade does not know about /opt/xrootd/lib presumably because it is not run as myself (sudo dixit). As myself, I have

export ROOTSYS=/opt/local
if [ -f ${ROOTSYS}/bin/thisroot.sh ]; then
  . ${ROOTSYS}/bin/thisroot.sh
  source ${ROOTSYS}/bin/setxrd.sh /opt/xrootd

which leads to

$ echo $LD_LIBRARY_PATH 
/opt/xrootd/lib

So, this is still an issue that may be solved with some help from the Macports gurus:

Is there a generic way to pass an extra path that rev-upgrade checks?

[neverpanic (Clemens Lang)]

Why would you want to pass in an extra path to rev-upgrade?

The root port should take care of installing all required files and making sure binaries reference the required libraries by full path, e.g. using install_name_tool(1) or by passing a full path to the -id flag when linking the library.

Also, setting $LD_LIBRARY_PATH has no effect on OS X systems and its equivalent $DYLD_LIBRARY_PATH should not be used, if avoidable. As I said, instead the root port should ensure all binaries reference the required libraries using their full path.

[cjones051073 (Chris Jones)]

Sorry, but I do not see this as an issue for MacPorts to solve. MacPorts knows nothing of anything outside its primary root, which is by default /opt/local. For the same reason we don't support having anything under /usr/local, I think we just cannot support what you are trying to do..

​http://trac.macports.org/wiki/FAQ#usrlocal

[cjones051073 (Chris Jones)]

... hit submit to soon...

The real solution is to get a version of xrootd into MacPorts, which can then be kept consistent (or get the ROOT port to build it, if thats possible ?)

[andre.david@…]

Replying to jonesc@…:

... hit submit to soon...

The real solution is to get a version of xrootd into MacPorts, which can then be kept consistent (or get the ROOT port to build it, if thats possible ?)

According to ​http://root.cern.ch/drupal/content/installing-xrootd the xrootd installation is included with ROOT sources. Perhaps it could be another variant. That would make it completely clean and transparent.

[cjones051073 (Chris Jones)]

Maybe ... Some interested party is welcome to submit a patch ;)

[andre.david@…]

I am interested in helping; It's been two years since I last touched a Portfile and I never worked on the build process internals.

From reading the instructions above, it seems that this would have to be a two-stage build:

1. Get the ROOT source.
2. Build xrootd.
3. configure ROOT accordingly.
4. Build ROOT.

Since two builds are implied, which works best:

• Have a sub-build nested in the ROOT one? (Is this even possible/clean/recommended?)
• A separate port for xrootd which uses the same source? (And then ROOT depends on xrootd.)

[cjones051073 (Chris Jones)]

Personally, I would say the second of the two options. Have a new port for xrootd. The fact it uses the same tarball as root is not an issue (gcc and libstdcxx do this for instance). The root port should then be updated with a new variant that depends on this new xrootd port, and sets the relevant configure options to use it. This has the advantage that xrootd can evolve at its own pace (although some degree of coordinate between the two ports might be useful), and both ports can be installed with or without the other, if required.

[larryv (Lawrence Velázquez)]

Replying to jonesc@…:

Personally, I would say the second of the two options. Have a new port for xrootd. The fact it uses the same tarball as root is not an issue (gcc and libstdcxx do this for instance). The root port should then be updated with a new variant that depends on this new xrootd port, and sets the relevant configure options to use it. This has the advantage that xrootd can evolve at its own pace (although some degree of coordinate between the two ports might be useful), and both ports can be installed with or without the other, if required.

This would be a good place for a subport (i.e., adding xrootd as a subport of ROOT).

[andre.david@…]

Replying to larryv@…:

This would be a good place for a subport (i.e., adding xrootd as a subport of ROOT).

Can you point me to an example of a subport?

[larryv (Lawrence Velázquez)]

Replying to andre.david@…:

Can you point me to an example of a subport?

The curl/curl-ca-bundle​ portfile is the canonical example, as far as I’m concerned. One I recently worked on myself is KlustaKwik/maskedKlustaKwik​.

[cjones051073 (Chris Jones)]

Looking at the code base for xrootd, it actually is a stand alone application, and can be installed independently of root. It also uses cmake to build and thus it was pretty easy for me to put together a new port for it. See ticket #38344 for an update to root and links to the new port (and an update to pythia to fix a conflict with libevent).

Please give it a try, and provide feedback to the above tickets ;)

cheers Chris

[andre.david@…]

The patches from #38344 and #38341 correctly pick up and build the new xrootd port (#38343) sort out the whole issue for me. Back to finding them Higgs bosons.

Thanks!

[cjones051073 (Chris Jones)]

Until the quantum numbers are confirmed, it's the X(126) ... ;)

[andre.david@…]

Going very off-topic and in a nutshell 0- is very much disfavoured and 2+ has of yet to find a place in a properly renormalizable field theory.

Latest results were shown just last week at the Rencontres de Moriond:

• presentation slides at ​https://indico.in2p3.fr/conferenceOtherViews.py?view=standard&confId=7411#2013-03-06
• video recordings at ​http://webcast.in2p3.fr/events-rencontres_de_moriond_2013

[cooljeanius (Eric Gallager)]

Cc Me!

[mf2k (Frank Schima)]

Closing this since it seems that nothing else needs to happen here.