gnutls won't build on Snow Leopard

Richard L. Hamilton rlhamil at smart.net
Fri Jan 13 02:40:56 UTC 2017


Forgot I had +universal as the default - tried again with port install clang-3.8 -universal, to get the pre-built versions, much quicker (and less surprises from the road less traveled).  I don't mind for libraries, but for a compiler and long toolchain, that's nuts, esp. if there's no advantage.

After that (minutes rather than hours!), gnutls built successfully, and rev-upgrade found no linking errors.  I've added that to my notes of what might require some manual intervention, which currently require (given the compilers I have installed) the following:
kerberos5 	gcc-4.2
dpkg		clang
rrdtool		clang
libgcrypt		llvm-gcc-4.2
gnutls		macports-clang-3.8

I have a script that does a port upgrade minus certain blacklisted ports (those and one or two others), which I deal with by hand, so that they don't cause upgrading the rest to fail.  Of course, on a newer OS, this just isn't a problem. :-)  But that old 2007 Mac Mini can't go past Lion anyway, and Snow Leopard has the advantage of being the last version that can still do Rosetta, so there's no incentive for me to upgrade it to Lion and lose that capability.

Perhaps some of those will now no longer be needed, if the corresponding ports find and use the macports-clang-3.8 by default, if available.  I'll try to remember to try them in the future without specifying a compiler, to see what happens.  

Thanks for the assist!

> On Jan 12, 2017, at 20:01, Richard L. Hamilton <rlhamil at smart.net> wrote:
> 
> It'll likely be a few hours before (if!) the dependency chain for clang-3.8 finishes building, assuming I have sufficient disk space. :-)  But what the heck, the machine is doing most of the work, so I'll try.
> 
>> On Jan 12, 2017, at 19:54, Marius Schamschula <lists at schamschula.com <mailto:lists at schamschula.com>> wrote:
>> 
>> Richard,
>> 
>> Please look at the discussion on trac:
>> 
>> https://trac.macports.org/ticket/53295 <https://trac.macports.org/ticket/53295>
>> 
>>> On Jan 12, 2017, at 6:49 PM, Richard L. Hamilton <rlhamil at smart.net <mailto:rlhamil at smart.net>> wrote:
>>> 
>>> From what I can find  https://en.wikipedia.org/wiki/Advanced_Vector_Extensions <https://en.wikipedia.org/wiki/Advanced_Vector_Extensions>
>>> the Core 2 Duo does _not_ support AVX (it's way too old - this machine was 2007).  CPU info (from sysctl):
>>> hw.optional.floatingpoint: 1
>>> hw.optional.mmx: 1
>>> hw.optional.sse: 1
>>> hw.optional.sse2: 1
>>> hw.optional.sse3: 1
>>> hw.optional.supplementalsse3: 1
>>> hw.optional.sse4_1: 0
>>> hw.optional.sse4_2: 0
>>> hw.optional.x86_64: 1
>>> hw.optional.aes: 0
>>> machdep.cpu.max_basic: 10
>>> machdep.cpu.max_ext: 2147483656
>>> machdep.cpu.vendor: GenuineIntel
>>> machdep.cpu.brand_string: Intel(R) Core(TM)2 CPU         T7200  @ 2.00GHz
>>> machdep.cpu.family: 6
>>> machdep.cpu.model: 15
>>> machdep.cpu.extmodel: 0
>>> machdep.cpu.extfamily: 0
>>> machdep.cpu.stepping: 6
>>> machdep.cpu.feature_bits: 3219913727 58301
>>> machdep.cpu.extfeature_bits: 537921536 1
>>> machdep.cpu.signature: 1782
>>> machdep.cpu.brand: 0
>>> machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM
>>> machdep.cpu.extfeatures: SYSCALL XD EM64T LAHF
>>> machdep.cpu.logical_per_package: 2
>>> machdep.cpu.cores_per_package: 2
>>> machdep.cpu.microcode_version: 199
>>> machdep.cpu.mwait.linesize_min: 64
>>> machdep.cpu.mwait.linesize_max: 64
>>> machdep.cpu.mwait.extensions: 3
>>> machdep.cpu.mwait.sub_Cstates: 139808
>>> machdep.cpu.thermal.sensor: 1
>>> machdep.cpu.thermal.dynamic_acceleration: 0
>>> machdep.cpu.thermal.invariant_APIC_timer: 0
>>> machdep.cpu.thermal.thresholds: 2
>>> machdep.cpu.thermal.ACNT_MCNT: 1
>>> machdep.cpu.thermal.core_power_limits: 0
>>> machdep.cpu.thermal.fine_grain_clock_mod: 0
>>> machdep.cpu.thermal.package_thermal_intr: 0
>>> machdep.cpu.thermal.hardware_feedback: 0
>>> machdep.cpu.thermal.energy_policy: 0
>>> machdep.cpu.arch_perf.version: 2
>>> machdep.cpu.arch_perf.number: 2
>>> machdep.cpu.arch_perf.width: 40
>>> machdep.cpu.arch_perf.events_number: 7
>>> machdep.cpu.arch_perf.events: 0
>>> machdep.cpu.arch_perf.fixed_number: 0
>>> machdep.cpu.arch_perf.fixed_width: 0
>>> machdep.cpu.cache.linesize: 64
>>> machdep.cpu.cache.L2_associativity: 8
>>> machdep.cpu.cache.size: 4096
>>> machdep.cpu.tlb.inst.small: 128
>>> machdep.cpu.tlb.inst.large: 8
>>> machdep.cpu.tlb.data.small: 16
>>> machdep.cpu.tlb.data.small_level1: 256
>>> machdep.cpu.tlb.data.large: 16
>>> machdep.cpu.tlb.data.large_level1: 32
>>> machdep.cpu.address_bits.physical: 36
>>> machdep.cpu.address_bits.virtual: 48
>>> machdep.cpu.core_count: 2
>>> machdep.cpu.thread_count: 2
>>> 
>>> It doesn't even have SSE4, so it wouldn't make sense that it had AVX.
>>> 
>>> So...how do I get it to run configure with the --disable-hardware-acceleration switch; do I have to edit the portfile, or is there something I can do from the command line?  The following does NOT work (looking at the log file shows that the added arg was NOT passed):
>>> port upgrade gnutls configure.args-append=--disable-hardware-acceleration
>>> 
>>> Now maybe I could dig the full list of normal args out of the portfile, and pass configure.args="[whole list of args]" on the command line, but that's just as bad as editing the portfile, because I'd have to look at it each time.
>>> 
>>> I'm guessing that the AVX support in gnutls came in with the big version jump from the previous 3.4.17 to 3.5.8.  I think that for those with older hardware, it would be much friendlier if the portfile supported a variant to disable hardware acceleration.
>>> 
>>> 
>>>> On Jan 12, 2017, at 06:56, Marius Schamschula <lists at schamschula.com <mailto:lists at schamschula.com>> wrote:
>>>> 
>>>> Richard,
>>>> 
>>>> I checked on my Leopard box, and found that gnutls 3.5.8 properly built there. So, it seems that we have an issue unique to Snow Leopard.
>>>> 
>>>> There are two options:
>>>> 
>>>> 1) try to find a compiler other than Apple’s gcc that will properly deal with the AVX extensions
>>>> 
>>>> or
>>>> 
>>>> 2) use the —disable-hardware-acceleration switch
>>>> 
>>>>> On Jan 10, 2017, at 8:35 PM, Richard L. Hamilton <rlhamil at smart.net <mailto:rlhamil at smart.net>> wrote:
>>>>> 
>>>>> sh-3.2# uname -a
>>>>> Darwin myeye.pri 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
>>>>> sh-3.2# /usr/bin/gcc --version
>>>>> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
>>>>> Copyright (C) 2007 Free Software Foundation, Inc.
>>>>> This is free software; see the source for copying conditions.  There is NO
>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>>> 
>>>>> 
>>>>>> On Jan 10, 2017, at 19:53, Marius Schamschula <lists at schamschula.com <mailto:lists at schamschula.com>> wrote:
>>>>>> 
>>>>>> Richard,
>>>>>> 
>>>>>> Unfortunately, I have no way of testing under Snow Leopard, even though I test some builds under Leopard on a G5.
>>>>>> 
>>>>>> It is clear the build is not finding the AVX extensions on you mini. Given you have a Core2 Duo, the hardware is there.
>>>>>> 
>>>>>> Can you give me the result of
>>>>>> 
>>>>>> /usr/bin/gcc —version
>>>>>> 
>>>>>> 
>>>>>>> On Jan 10, 2017, at 6:17 PM, Richard L. Hamilton <rlhamil at smart.net <mailto:rlhamil at smart.net>> wrote:
>>>>>>> 
>>>>>>> Hardware Version: Mac mini (Mid 2007)
>>>>>>> Model Identifier: Macmini2,1
>>>>>>> Mac OS X 10.6.8 10K549 (Snow Leopard)
>>>>>>> Xcode 3.2.6 DevToolsSupport-1806.0
>>>>>>> MacPorts Version: 2.3.5
>>>>>>> 
>>>>>>> <main.log-gnutls.txt.gz>
>>>>>> 
>>>>>> Marius
>>>>>> --
>>>>>> Marius Schamschula
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> Marius
>>>> --
>>>> Marius Schamschula
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> Marius
>> --
>> Marius Schamschula
>> 
>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20170112/54161e83/attachment.html>


More information about the macports-users mailing list