#33558 closed defect (wontfix)
Root 5.32.01: +pythia variant fails to build on Snow Leopard
Reported by: | watsodw | Owned by: | mattiafrancescomoro@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.0.4 |
Keywords: | Cc: | cjones051073 (Chris Jones), cooljeanius (Eric Gallager) | |
Port: | root |
Description (last modified by mf2k (Frank Schima))
Upgrade from Root 5.32.00 to 5.32.01 fails, apparently with problem with pythia.
Attachments (2)
Change History (20)
Changed 13 years ago by watsodw
comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | mattiafrancescomoro@… removed |
---|---|
Owner: | changed from macports-tickets@… to mattiafrancescomoro@… |
Summary: | Root 5.32.01 upgrade fails → Root 5.32.01 upgrade fails: error: 'Event' does not name a type |
Changed 13 years ago by watsodw
comment:3 Changed 13 years ago by cjones051073 (Chris Jones)
Probably just another instance of
https://trac.macports.org/ticket/32525
Please try without the opengl variant.
comment:4 Changed 13 years ago by watsodw
Ran "sudo port install root +clarens +fftw3 +fitsio +gcc46 +graphviz +gsl +minuit2 +mysql +python27 +qt_mac +roofit +soversion +ssl +tmva +xml" for Root 5.32.01, which does not include "+pythia +opengl" that is included in my previous install of Root 5.32.00. It built and installed correctly even though the install added back "+opengl". Evidently 5.32.01 and pythia don't like each other yet.
comment:5 Changed 13 years ago by cjones051073 (Chris Jones)
I think the problem is only with opengl, pythia is OK. Could you try adding pythia back, but still without opengl ?
For the record, pythia and opengl variants build just fine here, with OSX 10.7 and Xcode 4.2. The issue is more with 10.6 and Xcode 3 (which I cannot test against).
Chris
comment:6 Changed 13 years ago by cjones051073 (Chris Jones)
b.t.w. qt_mac my have built but it almost certainly won't work. I don't particularly recommend using this variant...
comment:7 Changed 13 years ago by cjones051073 (Chris Jones)
note you have to add -opengl to disable that variant, as it is enabled by default. Just not adding +opengl is not enough.
comment:8 Changed 13 years ago by watsodw
Did that and the build still fails because of pythia. Builds fine with opengl. By th e way, I'm using 10.6.8 and Xcode 3.2.6.
comment:10 Changed 12 years ago by mf2k (Frank Schima)
Description: | modified (diff) |
---|---|
Summary: | Root 5.32.01 upgrade fails: error: 'Event' does not name a type → Root 5.32.01: +pythia variant fails to build on Snow Leopard |
comment:11 Changed 12 years ago by cjones051073 (Chris Jones)
i suggest unless we here back from the submitter, we just close this. I have no way to test anything on OSX 10.6 anymore, and ROOT 5.32.01 is an obsolete version now.
Chris
comment:12 Changed 12 years ago by mf2k (Frank Schima)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Sounds good. It works for me on Mountain Lion anyway.
comment:13 Changed 12 years ago by cooljeanius (Eric Gallager)
I just tried compiling the latest ROOT with variants +avahi+fftw3+fitsio+ldap+mysql+odbc+pythia+qt_mac+ruby+universal on OSX 10.6, and I got the following error:
/usr/bin/g++-4.2 -dynamiclib -single_module -Wl,-dead_strip_dylibs -install_name /opt/local/lib/root/libminicern.5.so -O2 -m64 -mmacosx-version-min=10.6 -o lib/libminicern.5.34.so misc/minicern/src/cernlib.o -ldl misc/minicern/src/hbook.o misc/minicern/src/kernlib.o misc/minicern/src/zebra.o -compatibility_version 5 -current_version 5.34.02 i686-apple-darwin10-g++-4.2.1: misc/minicern/src/hbook.o: No such file or directory i686-apple-darwin10-g++-4.2.1: misc/minicern/src/kernlib.o: No such file or directory i686-apple-darwin10-g++-4.2.1: misc/minicern/src/zebra.o: No such file or directory make: *** [lib/libminicern.so] Error 1 make: *** Waiting for unfinished jobs.... make: Leaving directory `/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/work/root' Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/work/root" && /usr/bin/make -j2 -w all Exit code: 2 Error: org.macports.build for port root returned: command execution failed DEBUG: Error code: CHILDSTATUS 42221 2 DEBUG: Backtrace: command execution failed while executing "system -nice 0 $fullcmdstring" ("eval" body line 1) invoked from within "eval system $notty $nice \$fullcmdstring" invoked from within "command_exec build" (procedure "portbuild::build_main" line 8) invoked from within "$procedure $targetname" Warning: targets not executed for root: org.macports.activate org.macports.build org.macports.destroot org.macports.install Please see the log file for port root for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port root failed
It doesn't look like the same error message, but it is the same port with the same variant on the same OS, so I figured it belonged here.
comment:15 Changed 12 years ago by cjones051073 (Chris Jones)
You are using a lot of variants there. Please first try without any, and confirm if that works or not. Then start trying the variants one at a time until you find what causes the error.
Also, please post a *full* log file for a clean build attempt (so run 'sudo port clean root' first) and not just a small snippet.
comment:16 Changed 12 years ago by cjones051073 (Chris Jones)
Just noticed you had the universal variant enable '+universal'. Why did you add this ? Really, I cannot think of any reason why you would need universal binaries for this port ? I certainly have never tested it and would be quite surprised if it worked.
comment:17 Changed 12 years ago by mf2k (Frank Schima)
FYI, I just built root +universal with the default variants. I have not tested it in use though.
comment:18 Changed 12 years ago by cjones051073 (Chris Jones)
Good to know the universal variant works, or at least compiles.... Not sure it makes any sense to compile root universal though ...
Please try and isolate the minimum set of variants that causes the issue, and post a full clean log. As I said, I no longer have access to the older OSX 10.6 release, so cannot do any testing myself....
The errors seem to start here:
First, you should see whether this problem is related to the fact that you are upgrading rather than installing from scratch. Deactivate the existing root port, clean the new root build, then try again.