Opened 12 years ago
Closed 11 years ago
#38236 closed defect (worksforme)
root @5.34.05_0: reported as broken by rev-upgrade
Reported by: | andre.david@… | Owned by: | mattiafrancescomoro@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.1.3 |
Keywords: | Cc: | cjones051073 (Chris Jones), neverpanic (Clemens Lang), cooljeanius (Eric Gallager) | |
Port: | root |
Description
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
Attachments (1)
Change History (30)
comment:1 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | jonesc@… added |
---|---|
Owner: | changed from macports-tickets@… to mattiafrancescomoro@… |
comment:2 follow-up: 3 Changed 12 years ago by cjones051073 (Chris Jones)
comment:3 Changed 12 years ago by 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...
comment:4 follow-up: 5 Changed 12 years ago by 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
comment:5 Changed 12 years ago by 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?
comment:6 Changed 12 years ago by cjones051073 (Chris Jones)
uninstall and clean root, then just run
sudo port -s install root
comment:7 follow-up: 8 Changed 12 years ago by 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...
comment:8 Changed 12 years ago by 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?
comment:9 follow-up: 10 Changed 12 years ago by 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...
Changed 12 years ago by andre.david@…
Attachment: | root.log.bz2 added |
---|
comment:10 Changed 12 years ago by 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
?
comment:11 follow-up: 12 Changed 12 years ago by 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
comment:12 Changed 12 years ago by 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?
comment:13 Changed 12 years ago by larryv (Lawrence Velázquez)
Cc: | cal@… added |
---|---|
Summary: | root 5.34.05_0 still broken after rebuilding 3 times → root @5.34.05_0: reported as broken by rev-upgrade |
comment:14 Changed 12 years ago by 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.
comment:15 Changed 12 years ago by 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..
comment:16 follow-up: 17 Changed 12 years ago by 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 ?)
comment:17 Changed 12 years ago by 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.
comment:18 Changed 12 years ago by cjones051073 (Chris Jones)
Maybe ... Some interested party is welcome to submit a patch ;)
comment:19 Changed 12 years ago by 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:
- Get the ROOT source.
- Build
xrootd
. configure
ROOT accordingly.- 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 onxrootd
.)
comment:20 follow-up: 21 Changed 12 years ago by 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.
comment:21 follow-up: 22 Changed 12 years ago by 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
).
comment:22 follow-up: 23 Changed 12 years ago by andre.david@…
Replying to larryv@…:
This would be a good place for a subport (i.e., adding
xrootd
as a subport ofROOT
).
Can you point me to an example of a subport?
comment:23 Changed 12 years ago by 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.
comment:24 Changed 12 years ago by 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
comment:25 Changed 12 years ago by andre.david@…
comment:26 Changed 12 years ago by cjones051073 (Chris Jones)
Until the quantum numbers are confirmed, it's the X(126) ... ;)
comment:27 Changed 12 years ago by 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
comment:29 Changed 11 years ago by mf2k (Frank Schima)
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Closing this since it seems that nothing else needs to happen here.
please try a uninstall and clean rebuild, so
if it still fails, post the *full* log file the message directs you to (not just the terminal output).
cheers Chris