root 5.30.01 configure failure when file port is installed and xorg-libX11 is universal

[mf2k (Frank Schima)]

I see the following error trying to build ROOT 5.30.01

:notice:configure --->  Configuring root
:debug:configure Using compiler 'MacPorts gcc 4.5'
:debug:configure Executing proc-pre-org.macports.configure-configure-0
:debug:configure Executing org.macports.configure (root)
:debug:configure Environment: CPATH='/opt/local/include' CXXFLAGS='-pipe -O2 -m64' CPPFLAGS='-I/opt/local/include' CFLAGS='-pipe -O2 -m64' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.6' PKG_CONFIG_PATH='/opt/local/lib/pkgconfig' CXX='/opt/local/bin/g++-mp-4.5' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_mports_trunk_dports_science_root/root/work/.CC_PRINT_OPTIONS' F90FLAGS='-pipe -O2 -m64' LDFLAGS='-L/opt/local/lib' FCFLAGS='-pipe -O2 -m64' OBJC='/opt/local/bin/gcc-mp-4.5' INSTALL='/usr/bin/install -c' MOC='/opt/local/bin/moc' F90='/opt/local/bin/gfortran-mp-4.5' FC='/opt/local/bin/gfortran-mp-4.5' QMAKESPEC='macx-g++' FFLAGS='-pipe -O2 -m64' OBJCFLAGS='-pipe -O2 -m64' QTDIR='/opt/local' F77='/opt/local/bin/gfortran-mp-4.5' CC_PRINT_OPTIONS='YES' CC='/opt/local/bin/gcc-mp-4.5' QMAKE='/opt/local/bin/qmake'
:debug:configure Assembled command: 'cd "/opt/local/var/macports/build/_opt_mports_trunk_dports_science_root/root/work/root" && ./configure macosx64 --prefix=/opt/local --docdir=/opt/local/share/doc/root --libdir=/opt/local/lib/root --testdir=/opt/local/share/root/test --tutdir=/opt/local/share/root/tutorials --etcdir=/opt/local/etc/root --disable-builtin-afterimage --disable-builtin-freetype --disable-builtin-glew --disable-builtin-pcre --disable-builtin-zlib --disable-krb5 --disable-ldap --disable-mysql --disable-odbc --disable-pythia8 --disable-qtgsi --with-x11-libdir=/opt/local/lib --with-xpm-libdir=/opt/local/lib --enable-fftw3 --with-fftw3-incdir="/opt/local/include/" --with-fftw3-libdir="/opt/local/lib" --enable-roofit --enable-opengl --with-opengl-incdir="/opt/local/include" --with-opengl-libdir="/opt/local/lib" --with-glew-incdir="/opt/local/include/" --with-glew-libdir="/opt/local/lib" --enable-python --with-python-incdir="/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6" --with-python-libdir="/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config" --enable-ssl --with-ssl-shared=yes --with-ssl-incdir="/opt/local/include" --with-ssl-libdir="/opt/local/lib" --enable-builtin-ftgl --enable-xml --with-xml-incdir="/opt/local/include/libxml2" --with-xml-libdir="/opt/local/lib" --enable-qt --with-cc=/opt/local/bin/gcc-mp-4.5 --with-cxx=/opt/local/bin/g++-mp-4.5 --with-ld=/opt/local/bin/g++-mp-4.5 --with-f77=/opt/local/bin/gfortran-mp-4.5'
:debug:configure Executing command line:  cd "/opt/local/var/macports/build/_opt_mports_trunk_dports_science_root/root/work/root" && ./configure macosx64 --prefix=/opt/local --docdir=/opt/local/share/doc/root --libdir=/opt/local/lib/root --testdir=/opt/local/share/root/test --tutdir=/opt/local/share/root/tutorials --etcdir=/opt/local/etc/root --disable-builtin-afterimage --disable-builtin-freetype --disable-builtin-glew --disable-builtin-pcre --disable-builtin-zlib --disable-krb5 --disable-ldap --disable-mysql --disable-odbc --disable-pythia8 --disable-qtgsi --with-x11-libdir=/opt/local/lib --with-xpm-libdir=/opt/local/lib --enable-fftw3 --with-fftw3-incdir="/opt/local/include/" --with-fftw3-libdir="/opt/local/lib" --enable-roofit --enable-opengl --with-opengl-incdir="/opt/local/include" --with-opengl-libdir="/opt/local/lib" --with-glew-incdir="/opt/local/include/" --with-glew-libdir="/opt/local/lib" --enable-python --with-python-incdir="/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6" --with-python-libdir="/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config" --enable-ssl --with-ssl-shared=yes --with-ssl-incdir="/opt/local/include" --with-ssl-libdir="/opt/local/lib" --enable-builtin-ftgl --enable-xml --with-xml-incdir="/opt/local/include/libxml2" --with-xml-libdir="/opt/local/lib" --enable-qt --with-cc=/opt/local/bin/gcc-mp-4.5 --with-cxx=/opt/local/bin/g++-mp-4.5 --with-ld=/opt/local/bin/g++-mp-4.5 --with-f77=/opt/local/bin/gfortran-mp-4.5 
:info:configure Checking for source directory ... /opt/local/var/macports/build/_opt_mports_trunk_dports_science_root/root/work/root
:info:configure Configuring for macosx64
:info:configure INFO: --enable-fftw3: already enabled by default.
:info:configure INFO: --enable-opengl: already enabled by default.
:info:configure INFO: --enable-python: already enabled by default.
:info:configure INFO: --enable-ssl: already enabled by default.
:info:configure INFO: --enable-xml: already enabled by default.
:info:configure Checking for GNU Make version >= 3.80 ... ok
:info:configure Checking for C compiler ... /opt/local/bin/gcc-mp-4.5
:info:configure Checking for C++ compiler ... /opt/local/bin/g++-mp-4.5
:info:configure Checking for linker (LD) ... /opt/local/bin/g++-mp-4.5
:info:configure Checking for F77 compiler ... /opt/local/bin/gfortran-mp-4.5
:info:configure Checking for libX11 ... no
:info:configure configure: libX11 MUST be installed
:info:configure See http://root.cern.ch/drupal/content/build-prerequisites
:info:configure shell command " cd "/opt/local/var/macports/build/_opt_mports_trunk_dports_science_root/root/work/root" && ./configure macosx64 --prefix=/opt/local --docdir=/opt/local/share/doc/root --libdir=/opt/local/lib/root --testdir=/opt/local/share/root/test --tutdir=/opt/local/share/root/tutorials --etcdir=/opt/local/etc/root --disable-builtin-afterimage --disable-builtin-freetype --disable-builtin-glew --disable-builtin-pcre --disable-builtin-zlib --disable-krb5 --disable-ldap --disable-mysql --disable-odbc --disable-pythia8 --disable-qtgsi --with-x11-libdir=/opt/local/lib --with-xpm-libdir=/opt/local/lib --enable-fftw3 --with-fftw3-incdir="/opt/local/include/" --with-fftw3-libdir="/opt/local/lib" --enable-roofit --enable-opengl --with-opengl-incdir="/opt/local/include" --with-opengl-libdir="/opt/local/lib" --with-glew-incdir="/opt/local/include/" --with-glew-libdir="/opt/local/lib" --enable-python --with-python-incdir="/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6" --with-python-libdir="/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config" --enable-ssl --with-ssl-shared=yes --with-ssl-incdir="/opt/local/include" --with-ssl-libdir="/opt/local/lib" --enable-builtin-ftgl --enable-xml --with-xml-incdir="/opt/local/include/libxml2" --with-xml-libdir="/opt/local/lib" --enable-qt --with-cc=/opt/local/bin/gcc-mp-4.5 --with-cxx=/opt/local/bin/g++-mp-4.5 --with-ld=/opt/local/bin/g++-mp-4.5 --with-f77=/opt/local/bin/gfortran-mp-4.5 " returned error 1
:error:configure Target org.macports.configure returned: configure failure: shell command failed (see log for details)
:debug:configure Backtrace: configure failure: shell command failed (see log for details)
    while executing
"$procedure $targetname"
:info:configure Warning: the following items did not execute (for root): org.macports.install org.macports.configure org.macports.build org.macports.destroot
:notice:configure Log for root is at: /opt/local/var/macports/logs/_opt_mports_trunk_dports_science_root/root/main.log

Strange, I never had this problem before.

[mf2k (Frank Schima)]

FYI:

$ port installed xorg-server
The following ports are currently installed:
  xorg-server @1.10.4_0 (active)

[ryandesign (Ryan Carsten Schmidt)]

Sorry, I just filed duplicate #31261 about this. See there for the reason and the solution.

[cjones051073 (Chris Jones)]

it appears you are using a gcc variant. I will check these but please try again without it (so use llvm gcc 4.2).

[ryandesign (Ryan Carsten Schmidt)]

Frank was using a gcc variant but I was not.

[cjones051073 (Chris Jones)]

OK.... My mistake. There are a lot of variants and errors fly around at the moment such that I am starting to lose track...

I also only have a single 3 year old mac book pro to test on, so there is a limit to the number of variants and binaries I can realistically test. I also only have 10.7 available now...

It seems then there is a problem with universal binaries.....

I'll see if I can figure out a bug report to send to the root team, but my expectations on getting this fixed through them is not high.

If someone can explain what needs to change in the Portfile to patch this locally, I'll also happily try that as well ...

Chris

[cjones051073 (Chris Jones)]

Based on what I can figure out, the problem is specifically with the MacPorts version of 'file'. Using the Apple supplied one works fine.

Because of this I think there is no point to follow this up with the root team, as the problem is not really theirs...

[ryandesign (Ryan Carsten Schmidt)]

I commented in #31261 on how we could fix this.

The problem is not specifically the MacPorts version of file; any other non-Apple version of the file command would have the same problem. The problem is the root developers assume the file command is the Apple version, and in some environments it won't necessarily be. It is unwise of them to rely on Apple's extensions to the file command in their script.

[cjones051073 (Chris Jones)]

I still don't fully follow.

Why does MacPorts supply the file port at all, when it doesn't understand universal binaries, common on Mac systems.... ?

[cjones051073 (Chris Jones)]

Replying to jonesc@…:

I still don't fully follow.

Why does MacPorts supply the file port at all, when it doesn't understand universal binaries, common on Mac systems.... ?

Hit send too soon...

I mean, why supply a port that is very likely to fail in a lot of situations. What specifically is wrong with just using the Apple file command... Do certain OSX versions not have it ?

[cjones051073 (Chris Jones)]

I'm not against hacking the root Portfile to work around the problems with MacPorts file port.

If you can though point me to a specific concrete example of what I need to do, that would be useful....

Chris

[ryandesign (Ryan Carsten Schmidt)]

The purpose of MacPorts is to give users access to software that isn't already on their Mac, and newer versions of software that already is. In this case, the version of file included in Snow Leopard is version 5.03 while the version in MacPorts is 5.08. Presumably 5.08 includes bug fixes, and the ability to detect new types of files. For some users that may outweigh the inability to deal with universal binaries.

You might also ask: why do we provide ports for newer versions of gcc when they can't create universal binaries, which Apple's version can? The answer is sometimes you just need the capabilities of a newer version of gcc, and don't care about universal.

And as I said it's not a problem exclusive to MacPorts users either. A user could have installed file using Fink, or Homebrew, or compiled it by hand.

If we're trying to assign blame, there's plenty to go around. Why hasn't Apple contributed their universal patches back to the developers of file? Or if they have, why haven't the developers of file incorporated them? I don't know.

We must resign ourselves to the reality that not all versions of the file command understand all binaries, so it might be best not rely on file, or at least to specify the full path to a presumed working version of it (/usr/bin/file). I'll attach a patch that does this, since it's probably the shortest patch for the problem.

My recommendation to the developers of root would be to use lipo -info instead of file; that's what MacPorts uses internally. Then again, we've also had numerous inexplicable instances of users somehow replacing their /usr/bin/lipo commands with much older versions that don't understand 64-bit binaries. It's really hard to anticipate all the ways a user can screw up their computer.

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[cjones051073 (Chris Jones)]

Thanks for the patch !

Its not that I don't agree with the general idea that MacPorts should aim to provide newer versions of software, where reasonable. It is just in this case I think the ROOT devs are not being that outrageous in assuming the file version they get running 'file', so found via $PATH, is one that is able to digest binaries found on mac systems... If MacPorts chooses to provide a version which is broken, for whatever reasons that might be, then that is MacPorts problem and not roots. What exactly does the file version 5.8 provide, that version 5.03 doesn't, that is worth this pain ?

My karma with the root team is at an all time low trying to debate the python problem with them. Given I cannot really justify to myself MacPorts 'file' port, I am not really prepared to approach them to to discuss it, as I seriously doubt I will get anywhere...

Your patch I think is the only realistic way forward.

Chris

[ryandesign (Ryan Carsten Schmidt)]

Replying to jonesc@…:

It is just in this case I think the ROOT devs are not being that outrageous in assuming the file version they get running 'file', so found via $PATH, is one that is able to digest binaries found on mac systems...

And this will unfortunately not be the case if that file was installed by the user using MacPorts, Fink, Homebrew, or compiled from source. Only Apple's specially-modified file understands universal binaries.

If MacPorts chooses to provide a version which is broken, for whatever reasons that might be, then that is MacPorts problem and not roots. What exactly does the file version 5.8 provide, that version 5.03 doesn't, that is worth this pain ?

I haven't checked their ChangeLog.

Your patch I think is the only realistic way forward.

May I commit it?

[cjones051073 (Chris Jones)]

"And this will unfortunately not be the case if that file was installed by the user using MacPorts, Fink, Homebrew, or compiled from source. Only Apple's specially-modified file understands universal binaries."

That doesn't matter. Regardless of how it is installed I don't think it is too outrageous to assume a utility found on a system properly supports that system. If people are choosing to install a broken (as far as macs go) version of find, thats *their* choice.

Please do commit. If you could base your commit on my last patch here

#31247

that would be perfect.

[ryandesign (Ryan Carsten Schmidt)]

I've committed my patch from here in r84074. I'll deal with #31247 next.

[sewebster@…]

Replying to jonesc@…:

That doesn't matter. Regardless of how it is installed I don't think it is too outrageous to assume a utility found on a system properly supports that system. If people are choosing to install a broken (as far as macs go) version of find, thats *their* choice.

One could possibly argue that if you are writing software that depends on a utility, that you will expect it to be the version of that utility that is produced by the developers of said utility. If you wanted to depend on some special modified version of that utility, you might want to check to make sure you found the special one. Of course you could look at it in different ways too.... hence this problem :)

[sewebster@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

Why hasn't Apple contributed their universal patches back to the developers of file? Or if they have, why haven't the developers of file incorporated them? I don't know.

I've filed ​file ticket 211 for this now.

[cooljeanius (Eric Gallager)]

Cc Me!