Ticket #33558 (closed defect: wontfix)
Root 5.32.01: +pythia variant fails to build on Snow Leopard
| Reported by: | david.w.watson@… | Owned by: | mattiafrancescomoro@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.0.4 |
| Keywords: | Cc: | jonesc@…, egall@… | |
| Port: | root |
Description (last modified by macsforever2000@…) (diff)
Upgrade from Root 5.32.00 to 5.32.01 fails, apparently with problem with pythia.
Attachments
Change History
comment:1 Changed 15 months ago by ryandesign@…
- Owner changed from macports-tickets@… to mattiafrancescomoro@…
- Cc mattiafrancescomoro@… removed
- Summary changed from Root 5.32.01 upgrade fails to Root 5.32.01 upgrade fails: error: 'Event' does not name a type
The errors seem to start here:
:info:build In file included from /opt/macports/include/Pythia.h:12:0, :info:build from include/TPythia8.h:69, :info:build from /opt/macports/var/macports/build/_opt_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/work/root/montecarlo/pythia8/src/TPythia8.cxx:75: :info:build /opt/macports/include/Analysis.h:38:22: error: 'Event' does not name a type
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.
sudo port -f deactivate root sudo port clean root sudo port install root
comment:2 Changed 15 months ago by david.w.watson@…
Did that. Build fails with other errors. See main2.log.
comment:3 Changed 15 months ago by jonesc@…
Probably just another instance of
https://trac.macports.org/ticket/32525
Please try without the opengl variant.
comment:4 Changed 15 months ago by david.w.watson@…
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 15 months ago by jonesc@…
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 15 months ago by jonesc@…
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 15 months ago by jonesc@…
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 15 months ago by david.w.watson@…
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 7 months ago by macsforever2000@…
- Description modified (diff)
- Summary changed from Root 5.32.01 upgrade fails: error: 'Event' does not name a type to Root 5.32.01: +pythia variant fails to build on Snow Leopard
comment:11 Changed 7 months ago by jonesc@…
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 7 months ago by macsforever2000@…
- Status changed from new to closed
- Resolution set to wontfix
Sounds good. It works for me on Mountain Lion anyway.
comment:13 Changed 7 months ago by egall@…
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 7 months ago by jonesc@…
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 7 months ago by jonesc@…
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 7 months ago by macsforever2000@…
FYI, I just built root +universal with the default variants. I have not tested it in use though.
comment:18 Changed 7 months ago by jonesc@…
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....

