Opened 9 years ago

Closed 9 years ago

#32477 closed defect (fixed)

Root upgrade from 5.30.03_0 to 5.32.0_0 fails

Reported by: watsodw Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: Cc: mattiafrancescomoro@…, cjones051073 (Chris Jones), mf2k (Frank Schima), mojca (Mojca Miklavec), ryandesign (Ryan Schmidt)
Port: root

Description (last modified by mf2k (Frank Schima))

Root upgrade from 5.30.03_0 to 5.32.0_0 fails with:

:info:build ld: symbol(s) not found
:info:build collect2: ld returned 1 exit status
:info:build make: *** [lib/libRGL.so] Error 1

Attachments (5)

main.log (14.3 KB) - added by watsodw 9 years ago.
root.log (2.4 MB) - added by mojca (Mojca Miklavec) 9 years ago.
Log from failing root installation
main2.log (2.7 MB) - added by watsodw 9 years ago.
2nd root upgrade build log - david.w.watson@…
main3.log (2.6 MB) - added by watsodw 9 years ago.
main4.log (2.4 MB) - added by watsodw 9 years ago.

Change History (30)

Changed 9 years ago by watsodw

Attachment: main.log added

comment:1 Changed 9 years ago by mf2k (Frank Schima)

Description: modified (diff)

In the future, please use WikiFormatting.

comment:2 Changed 9 years ago by mf2k (Frank Schima)

Cc: macsforever2000@… added

Cc Me!

comment:3 Changed 9 years ago by mf2k (Frank Schima)

Your log is not clean. Please clean root, build again and then attach the log if it fails again.

Changed 9 years ago by mojca (Mojca Miklavec)

Attachment: root.log added

Log from failing root installation

comment:4 Changed 9 years ago by mojca (Mojca Miklavec)

Is my log ok? Or what exactly should be done?

Changed 9 years ago by watsodw

Attachment: main2.log added

2nd root upgrade build log - david.w.watson@…

comment:5 Changed 9 years ago by cjones051073 (Chris Jones)

This problem is the reason I disabled the opengl variant by default in the latest version. You need to make sure the mesa port is install with the x11 variant enabled, which is not th default.

Either remove the opengl variant (i.e. uninstall then reinstall), or force a reinstallation of mesa with +x11

Chris

comment:6 Changed 9 years ago by cjones051073 (Chris Jones)

Just a thought, but is it possible for the root Portfile to be updated, so if someone installs or upgrades root with the opengl variant enabled but doesn't have mesa installed with the x11 variant, to issue a warning ?

Changed 9 years ago by watsodw

Attachment: main3.log added

comment:7 in reply to:  6 Changed 9 years ago by watsodw

Retried to build Root without opengl but it failed again, this time in the "staging root to destroot" stage. See main3.log

comment:8 Changed 9 years ago by cjones051073 (Chris Jones)

Did you do a full clean before the last build, i.e.

sudo port clean --all root 

?

comment:9 Changed 9 years ago by cjones051073 (Chris Jones)

Also, scanning through your log I found

:debug:build Privilege de-escalation not attempted as not running as root.
:debug:destroot destroot phase started at Fri Dec  9 14:12:21 CST 2011
:notice:destroot --->  Staging root into destroot
:debug:destroot Can't run destroot under sudo without elevated privileges (due to mtree).
:debug:destroot Run destroot without sudo to avoid root privileges.
:debug:destroot Going to escalate privileges back to root.
:debug:destroot euid changed to: 0. egid changed to: 0.

Did you by chance forget to run the build as root, using sudo ?

Chris

comment:10 Changed 9 years ago by watsodw

Did "sudo port clean --all root", reran install and failed exactly as before. Did run as root. Installing root 5.30.2 and doing upgrade to 5.30.3 did fine, it's just upgrading to 5.32.0 that fails.

comment:11 Changed 9 years ago by cjones051073 (Chris Jones)

Can you uninstall all root versions, do a full clean, then try and install the minimal root version (i.e. no variants). Post the log if it still fails.

Chris

comment:12 Changed 9 years ago by cjones051073 (Chris Jones)

One other thought. At the end of main3.log the build fails due to gfortran

:info:destroot gfortran -O2 -m64 -std=legacy -o misc/minicern/src/hbook.o -c /opt/macports/var/macports/build/_opt_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/work/root/misc/minicern/src/hbook.f
:info:destroot gfortran -O2 -m64 -std=legacy -o misc/minicern/src/kernlib.o -c /opt/macports/var/macports/build/_opt_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/work/root/misc/minicern/src/kernlib.f
:info:destroot gfortran -O2 -m64 -std=legacy -o misc/minicern/src/zebra.o -c /opt/macports/var/macports/build/_opt_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/work/root/misc/minicern/src/zebra.f
:info:destroot /usr/bin/g++-4.2 -dynamiclib -single_module -Wl,-dead_strip_dylibs -install_name /opt/macports/lib/root/libminicern.so -O2 -m64 -mmacosx-version-min=10.6 -o lib/libminicern.so misc/minicern/src/cernlib.o -ldl misc/minicern/src/hbook.o misc/minicern/src/kernlib.o misc/minicern/src/zebra.o /usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64/libgfortranbegin.a
:info:destroot Undefined symbols:
:info:destroot   "__gfortran_internal_free", referenced from:
:info:destroot       _hpaff_ in hbook.o
:info:destroot       _hpaff_ in hbook.o
:info:destroot       _hpaff_ in hbook.o
:info:destroot       _hrfile_ in hbook.o
:info:destroot       _hrfile_ in hbook.o

I'm not really sure why this is happening, but gfortran is not available be default. You need I think to use one of the gcc variants to get this. Are you using one of these ? Are you specifically wanting to enable fortran support ?

Chris

comment:13 Changed 9 years ago by cjones051073 (Chris Jones)

Your configure step is finding a gfortran compiler

:info:configure Checking for F77 compiler ... gfortran

My OS X 10.7 machine does have a fortran compiler, so this step fails...

Unfortunately, I don't have a 10.6 machine. Could you report what 'which gfortran' gives you ?

Chris

comment:14 Changed 9 years ago by watsodw

Okay, uninstalled all root versions, did a "sudo port clean --all root", then "sudo port install root". Failed exactly as before. I'm not doing anything I know of to enable fortran support. "which gfortran" gives "/usr/bin/gfortran". gfortran -v gives:

Configured with: /Builds/apple/gcc-5664/build/obj/src/configure --disable-checking --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++,fortran --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5664)

Great. Now I have no version of root available. See main4.log

Changed 9 years ago by watsodw

Attachment: main4.log added

comment:15 Changed 9 years ago by cjones051073 (Chris Jones)

please try installing with one of the gcc variants gcc44, gcc45 or gcc46, take your pick).

comment:16 Changed 9 years ago by watsodw

I was ahead of you on this one. Did a port install with gcc46 variant and it worked. I don't know if you have seen this, but from the Root website release notes for version 5.32.0:

On MacOS X move to a more secure way of building. We will now always use the --enable-explicitlink ./configure option which will cause a shared lib or executable to be linked with all its dependent libraries. The OSX linker is quite good and processing this extended set of libraries for each link does cost only 3s extra time for all 100+ shared libs (13s instead of 10s). Not much for the extra security. In addition we went back to the default linker option "-undefined error", so you will get an error if symbols are unresolved. Shared libs are also linked with the option "-Wl,-dead_strip_dylibs" which tells the linker to remove any shared lib which is not used to resolve any symbols (this should solve the long standing issue of ACliC linking all previously created shared libs even when not needed).

comment:17 in reply to:  16 Changed 9 years ago by watsodw

Replying to david.w.watson@…:

I was ahead of you on this one. Did a port install with gcc46 variant and it worked. I don't know if you have seen this, but from the Root website release notes for version 5.32.0:

On MacOS X move to a more secure way of building. We will now always use the --enable-explicitlink ./configure option which will cause a shared lib or executable to be linked with all its dependent libraries. The OSX linker is quite good and processing this extended set of libraries for each link does cost only 3s extra time for all 100+ shared libs (13s instead of 10s). Not much for the extra security. In addition we went back to the default linker option "-undefined error", so you will get an error if symbols are unresolved. Shared libs are also linked with the option "-Wl,-dead_strip_dylibs" which tells the linker to remove any shared lib which is not used to resolve any symbols (this should solve the long standing issue of ACliC linking all previously created shared libs even when not needed).

Forgot to add, must be an issue with my gcc/gfortan 4.2.1.

comment:18 Changed 9 years ago by cjones051073 (Chris Jones)

Glad it worked for you.

Yes, I had seen that comment on the ROOT web site. Possibly related.

As I don't have a 10.6 machine to investigate on, its going to be difficult for me to do much. It does though look like the gfortran you have in /usr/bin is the problem.

If you have the time and inclination, and can reproduce the problem outside macports, building root from the tarball from CERN directly, then maybe we could take this to the root devs. If it does work, then its some MacPorts issue, so we also learn something....

b.t.w., just to confirm, is the gcc/gfortran you using th system supplied one, or did you install them yourself ?

comment:19 Changed 9 years ago by watsodw

gcc is from Apple, gfortran I installed from http://R.research.att.com/gfortran-4.2.1.dmg.

comment:20 Changed 9 years ago by cjones051073 (Chris Jones)

Ahhh. So the problem is with the external gfortran version I would say....

comment:21 Changed 9 years ago by mojca (Mojca Miklavec)

Cc: mojca.miklavec.lists@… added

Cc Me!

comment:22 Changed 9 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added

jonesc, there is nothing unusual about the output you pointed out in comment:9. It's just a normal part of MacPorts' privilege-(de-)escalation code.

As for fortran, it's really not a good idea to install 3rd-party software like gfortran into system directories like /bin, /usr/bin or /usr/local/bin. This previously caused us almost endless grief with libtool; after years we finally figured out how to fix that for libtool, but now other ports like root will probably be affected as well. If you want a less troublesome MacPorts experience, remove fortran compilers from system directories; they do not belong there. Please report this problem also to the creators of your fortran distributions and request that they no longer provide distributions that put fortran compilers in system directories. Recommend that they use a unique prefix under /opt instead.

comment:23 Changed 9 years ago by cjones051073 (Chris Jones)

Hopefully the GLEW issue is addressed in ticket #32491

comment:24 Changed 9 years ago by mf2k (Frank Schima)

Is this still an issue?

comment:25 Changed 9 years ago by mf2k (Frank Schima)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.