It would seem that this failure under Xcode 11.2 beta 2 is due to the
current patch dropping -fno-stack-check for Xcode 11.2 in anticipation of a
fix.
# Workaround for test failure :-
# > ./sblat2 < ./sblat2.dat
# Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.
# Current information is that this should be fixed in Xcode 11.2
if { ([vercmp ${os.major} 19] >= 0) && ([vercmp $xcodeversion 11.2] < 0) } {
if {[string match clang ${configure.compiler}]} {
configure.cc-append -fno-stack-check
}
}
So this would seem to rule out OpenBLAS as the source of the pymol crashes
under python2.7 with the QT interface as, under Xcode 11.1, OpenBLAS
already built with -fno-stack-check. Perhaps the problem is in python2.7
when -fstack-check is used?
Jack
On Sun, Oct 13, 2019 at 11:08 AM Chris Jones <jon...@hep.phy.cam.ac.uk>
wrote:
>
>
> On 13 Oct 2019, at 4:02 pm, Jack Howarth <howarth.at.macpo...@gmail.com>
> wrote:
>
>
> Well this is interesting. After installing Xcode 11 Beta 2, Command Line
> tools and setting the Xcode-select path to the Xcode-beta.app, I find that
> 'sudo port build OpenBLAS' now fails with...
>
> :info:build OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat2 <
> ./sblat2.dat
>
> :info:build Program received signal SIGSEGV: Segmentation fault - invalid
> memory reference.
>
> :info:build Backtrace for this error:
>
> :info:build #0 0x1029863e4
>
> :info:build #1 0x102985b06
>
> :info:build #2 0x7fff688fab1c
>
> :info:build /bin/sh: line 1: 22671 Segmentation fault: 11
> OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat2 < ./sblat2.dat
>
> :info:build make[1]: *** [level2] Error 139
>
> :info:build make[1]: *** Waiting for unfinished jobs....
>
> :info:build make[1]: Leaving directory
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/xianyi-OpenBLAS-5f36f18/test'
>
>
> That just means the stack check issue is in fact not addressed in 11.2, or
> there is in fact a real issue with the openblas source.
>
>
>
> On Sun, Oct 13, 2019 at 10:49 AM Jack Howarth <
> howarth.at.macpo...@gmail.com> wrote:
>
>> Okay, I have Xcode 11.2 beta 2 and the associated Command Line Tools
>> installed. Is there some permutation of options to pass to 'port' that will
>> rebuild and reinstall a currently installed MacPorts package without
>> uninstalling it first?
>> Jack
>>
>> On Sun, Oct 13, 2019 at 10:13 AM Chris Jones <jon...@hep.phy.cam.ac.uk>
>> wrote:
>>
>>>
>>>
>>> > On 13 Oct 2019, at 3:11 pm, Joshua Root <j...@macports.org> wrote:
>>> >
>>> > On 2019-10-14 00:59 , Jack Howarth wrote:
>>> >>
>>> >>
>>> >>> On Sun, Oct 13, 2019 at 9:49 AM Chris Jones <
>>> jon...@hep.phy.cam.ac.uk
>>> >>> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 13 Oct 2019, at 2:46 pm, Joshua Root <j...@macports.org
>>> >>> <mailto:j...@macports.org>> wrote:
>>> >>>
>>> >>> On 2019-10-14 00:35 , Chris Jones wrote:
>>> >>>>
>>> >>>> After that, my next guess would perhaps another issue related to
>>> the
>>> >>>> stack-check issue with Xcode 11. See e.g. the fix I added for
>>> >>>> OpenBLAS
>>> >>>>
>>> >>>>
>>> https://github.com/macports/macports-ports/commit/6e78e5c9495b4dc4e7e050fae2b41dd5b9accfdd#diff-a755de84ca7f97ab071328807d829e0b
>>> >>>
>>> >>> I'd be wary of removing a hardening measure and leaving it at
>>> that. It
>>> >>> could be revealing a genuine stack-smashing bug.
>>> >>
>>> >> Agreed. Accordingly to Jeremy though its a Xcode bug expected to be
>>> >> fixed in 11.2. Thats why I subsequently added a version check, see
>>> e.g.
>>> >
>>> > Ah, good to know. Do you have a link to Jeremy's statement out of
>>> curiosity?
>>>
>>> No I don’t, I only know this second hand from a comment by Ken...
>>>
>>> >
>>> >>
>>> https://github.com/macports/macports-ports/blob/master/math/OpenBLAS/Portfile
>>> >>
>>> >> Line 109.
>>> >>
>>> >>>
>>> >>> - Josh
>>> >>
>>> >>
>>> >> Josh,
>>> >> Does anyone know if this is already fixed in the posted Xcode
>>> 11.2
>>> >> beta 2? If so, would rebuilding the OpenBLAS package with it be
>>> >> sufficient or aren't we sure where the offending code lies?
>>> >> Jack
>>> >
>>> > I don't know sorry.
>>> >
>>> > - Josh
>>>
>>>
