[cctbxbb] Boost broken on mac?

richard.gildea at diamond.ac.uk richard.gildea at diamond.ac.uk
Tue Apr 12 02:54:30 PDT 2016


Hi Luc,

Markus and I were looking into the cctbx Makefile, and wondered if it would make sense to add the line

./bin/libtbx.configure . --clear-scons-memory

to the "make clean" command. I guess this would solve the issue of SCons thinking it was using a much older version of the compiler than it actually was?

$ cat Makefile
# DO NOT EDIT THIS FILE!
# This file will be overwritten by the next libtbx/configure.py,
# libtbx.configure, or libtbx.refresh.

default:
	./bin/libtbx.scons -j "`./bin/libtbx.show_number_of_processors`"

nostop:
	./bin/libtbx.scons -j "`./bin/libtbx.show_number_of_processors`" -k

bp:
	./bin/libtbx.scons -j "`./bin/libtbx.show_number_of_processors`" -k boost_python_tests=1

reconf:
	./bin/libtbx.configure .
	./bin/libtbx.scons -j "`./bin/libtbx.show_number_of_processors`"

redo:
	./bin/libtbx.configure . --clear-scons-memory
	./bin/libtbx.scons -j "`./bin/libtbx.show_number_of_processors`"

clean:
	./bin/libtbx.scons -j "`./bin/libtbx.show_number_of_processors`" -c

# example
selfx:
	rm -rf selfx_tmp
	mkdir selfx_tmp
	cd selfx_tmp ; \
		libtbx.start_binary_bundle example boost ; \
		libtbx.bundle_as_selfx example build_id ; \
		mv example_build_id.selfx .. ; \
		cd .. ; \
		ls -l example_build_id.selfx

Cheers,

Richard


Dr Richard Gildea
Data Analysis Scientist
Tel: +441235 77 8078

Diamond Light Source Ltd.
Diamond House
Harwell Science & Innovation Campus
Didcot
Oxfordshire
OX11 0DE

________________________________________
From: cctbxbb-bounces at phenix-online.org [cctbxbb-bounces at phenix-online.org] on behalf of Luc Bourhis [luc_j_bourhis at mac.com]
Sent: 07 April 2016 11:05
To: cctbx mailing list
Subject: Re: [cctbxbb] Boost broken on mac?

SCons caches the result of TryRun in .sconf_temp and it gets stale sometimes. In your case, SCons did not track the fact that clang had changed I guess.

I did commit my fix to libtbx/SConscript. Note that it does not fix the error in xray/conversions.h, weirdly enough. So I left my hack in there.

So now, I’ve got some work cut for myself for the next rainy day: come with a reduce test case that I can submit to the clang bugzilla. The problem in xray/conversions.h is clearly the most promising to start with. But still, a lot of work.

> On 7 Apr 2016, at 11:43, richard.gildea at diamond.ac.uk wrote:
>
> Strangely for my development build, the build system appears convinced that it is using clang 6.1.0...
>
> Editing around line 784 of libtbx/SConscript, where clang_version is determined, to read:
>
>    from subprocess import call
>    print call(["which", "clang"])
>    print call(["clang", "--version"])
>    flag, output = conf.TryRun("\n".join(test_code), extension='.cpp')
>    conf.Finish()
>    assert flag
>    output = output.replace(":,", ":None,")
>    print output
>
> I get the following output:
>
>
> /usr/bin/clang
>
> 0
>
> Apple LLVM version 7.3.0 (clang-703.0.29)
>
> Target: x86_64-apple-darwin15.3.0
>
> Thread model: posix
>
> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> 0
>
> {"llvm":1, "clang":1, "clang_major":6, "clang_minor":1, "clang_patchlevel":0, "GNUC":4, "GNUC_MINOR":2, "GNUC_PATCHLEVEL":1, "clang_version": "6.1.0 (clang-602.0.53)", "VERSION": "4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)", }
>
> On MacOS, using  clang 6.1.0
>
>
> If I wipe the build directory (or rather, renamed so not wiped completely) then it is now happy that it is using clang 7.3.0:
>
>
> /usr/bin/clang
>
> 0
>
> Apple LLVM version 7.3.0 (clang-703.0.29)
>
> Target: x86_64-apple-darwin15.3.0
>
> Thread model: posix
>
> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> 0
>
> {"llvm":1, "clang":1, "clang_major":7, "clang_minor":3, "clang_patchlevel":0, "GNUC":4, "GNUC_MINOR":2, "GNUC_PATCHLEVEL":1, "clang_version": "7.3.0 (clang-703.0.29)", "VERSION": "4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.29)", }
>
> On MacOS, using  clang 7.3.0
>
>
> Any idea what is going on here? Why does it think it is somehow using an older version of the clang to what is actually installed?!
>
>
> Cheers,
>
>
> Richard
>
>
> Dr Richard Gildea
> Data Analysis Scientist
> Tel: +441235 77 8078
>
> Diamond Light Source Ltd.
> Diamond House
> Harwell Science & Innovation Campus
> Didcot
> Oxfordshire
> OX11 0DE
> ________________________________
> From: cctbxbb-bounces at phenix-online.org [cctbxbb-bounces at phenix-online.org] on behalf of Luc Bourhis [luc_j_bourhis at mac.com]
> Sent: 07 April 2016 10:23
> To: cctbx mailing list
> Subject: Re: [cctbxbb] Boost broken on mac?
>
> Could you confirm whether the following two tests fail for you after your latest change?
>
> libtbx.python "/Users/rjgildea/tmp/tst_bootstrap/tmp/modules/cctbx_project/cctbx/maptbx/boost_python/tst_maptbx.py" [FAIL]
> […]
>
> libtbx.python "/Users/rjgildea/tmp/tst_bootstrap/tmp/modules/cctbx_project/scitbx/lbfgs/tst_lbfgs_fem.py" [FAIL]
> […]
>
> I see those too. Tracking them is too much effort indeed. I followed the route already suggested by Marcin: break -ffast-math in finer options and find the one breaking our code. After a round-trip through Clang source code (I wish they had a proper documentation of *all* their command-line options as it exists for gcc), I came with a fix which keeps all useful optimisations enabled while the 3 failing tests do now pass.
>
> Gonna commit shortly.
>
> Best wishes,
>
> Luc
>
>
>
>
> --
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>
>
> _______________________________________________
> cctbxbb mailing list
> cctbxbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/cctbxbb


_______________________________________________
cctbxbb mailing list
cctbxbb at phenix-online.org
http://phenix-online.org/mailman/listinfo/cctbxbb



More information about the cctbxbb mailing list