Root upgrade from 5.30.03_0 to 5.32.0_0 fails

[watsodw]

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

[mf2k (Frank Schima)]

In the future, please use WikiFormatting.

[mf2k (Frank Schima)]

Cc Me!

[mf2k (Frank Schima)]

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

[mojca (Mojca Miklavec)]

Log from failing root installation

[mojca (Mojca Miklavec)]

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

[watsodw]

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

[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

[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 ?

[watsodw]

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

[cjones051073 (Chris Jones)]

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

sudo port clean --all root 

?

[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

[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.

[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

[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

[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

[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

[cjones051073 (Chris Jones)]

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

[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).

[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.

[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 ?

[watsodw]

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

[cjones051073 (Chris Jones)]

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

[mojca (Mojca Miklavec)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

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.

[cjones051073 (Chris Jones)]

Hopefully the GLEW issue is addressed in ticket #32491

[mf2k (Frank Schima)]

Is this still an issue?