Re: latest update to BigSur 11.1 broke gcc

[Ken Cunningham]

we might just delete this line from the portfile, perhaps:


 configure.args-append --with-sysroot="${configure.sdkroot}"

Re: latest update to BigSur 11.1 broke gcc

[Ken Cunningham]

> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk

gcc is supposed to respond to the SDKROOT env var now, and base sets this (most 
of the time … sigh).

perhaps we should find a way to stop baking in —with-sysroot altogether now…

Ken

Re: latest update to BigSur 11.1 broke gcc

[Andreas Skarlatoudis via macports-users]

Hi Chris, 

thanks for the reply. I got a feeling that the problem you describe is behind 
this error but I didn’t know how to fix it. 
I’ve added the export you suggest in my profile and it worked. 

Thanks again for the help, much appreciated! 

Andreas  


Dr. Seismologist

> On Dec 15, 2020, at 2:12 PM, Christopher Jones  
> wrote:
> 
> Hi,
> 
> This is another consequence of a change Apple has introduced with macOS11 
> which is the SDK version now changes on every incremental OS update. So 
> updating from 11.0 to 11.1 (and I presume Xcode 12.3) you now have SDK 11.1, 
> not 11.0, and thus the current build of gcc, which has the sys root to the 
> 11.0 baked into it, now fails.
> 
> A quick workaround is to set in your shell SDKROOT to point to the new path 
> to the 11.1 SDK. I use
> 
> export SDKROOT=`xcrun --show-sdk-path`
> 
> in my ~/.profile which does this for each shell.
> 
> This is almost certainly not the only issue this change in SDK versioning is 
> going to cause, and its likely going to take a while to figure out what to do 
> in MacPorts. One option, for ports which have this problem is to configure 
> them to use the versionless SDK path at configuration time, at least on macOS 
> 11 and newer… This has other issues, but for now it seems the lesser evil to 
> me…
> 
> Chris
> 
>> On 15 Dec 2020, at 9:23 pm, Andreas Skarlatoudis via macports-users 
>> > > wrote:
>> 
>> Hello all, 
>> 
>> I’m working on a MBP, 2018 model and yesterday I updated to the latest 
>> version of BigSur. Since then I cannot compile any fortran code and the 
>> error I get is 
>> 
>> ld: library not found for -lSystem
>> collect2: error: ld returned 1 exit status
>> 
>> 
>> I have tried both gcc9 and gcc10
>> 
>> gfortran -v gives this output :
>> 
>> Using built-in specs.
>> COLLECT_GCC=gfortran
>> COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin20/10.2.0/lto-wrapper
>> Target: x86_64-apple-darwin20
>> Configured with: 
>> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc10/gcc10/work/gcc-10.2.0/configure
>>  --prefix=/opt/local --build=x86_64-apple-darwin20 
>> --enable-languages=c,c++,objc,obj-c++,lto,fortran,jit 
>> --libdir=/opt/local/lib/gcc10 --includedir=/opt/local/include/gcc10 
>> --infodir=/opt/local/share/info --mandir=/opt/local/share/man 
>> --datarootdir=/opt/local/share/gcc-10 --with-local-prefix=/opt/local 
>> --with-system-zlib --disable-nls --program-suffix=-mp-10 
>> --with-gxx-include-dir=/opt/local/include/gcc10/c++/ --with-gmp=/opt/local 
>> --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local 
>> --enable-stage1-checking --disable-multilib --enable-lto 
>> --enable-libstdcxx-time --with-build-config=bootstrap-debug 
>> --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld 
>> --with-ar=/opt/local/bin/ar 
>> --with-bugurl=https://trac.macports.org/newticket 
>>  --enable-host-shared --disable-tls 
>> --with-pkgversion='MacPorts gcc10 10.2.0_4' 
>> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk
>> Thread model: posix
>> Supported LTO compression algorithms: zlib
>> gcc version 10.2.0 (MacPorts gcc10 10.2.0_4) 
>> 
>> I’ve removed and reinstalled MacPorts and all packages but it didn’t help.
>> 
>> Any ideas what may be the problem here? 
>> 
>> Thanks in advance for your help
>> 
>> Andreas 
>> 
>> Dr. Seismologist
>> 
> 

Re: latest update to BigSur 11.1 broke gcc

[Christopher Jones]

Hi,

This is another consequence of a change Apple has introduced with macOS11 which 
is the SDK version now changes on every incremental OS update. So updating from 
11.0 to 11.1 (and I presume Xcode 12.3) you now have SDK 11.1, not 11.0, and 
thus the current build of gcc, which has the sys root to the 11.0 baked into 
it, now fails.

A quick workaround is to set in your shell SDKROOT to point to the new path to 
the 11.1 SDK. I use

export SDKROOT=`xcrun --show-sdk-path`

in my ~/.profile which does this for each shell.

This is almost certainly not the only issue this change in SDK versioning is 
going to cause, and its likely going to take a while to figure out what to do 
in MacPorts. One option, for ports which have this problem is to configure them 
to use the versionless SDK path at configuration time, at least on macOS 11 and 
newer… This has other issues, but for now it seems the lesser evil to me…

Chris

> On 15 Dec 2020, at 9:23 pm, Andreas Skarlatoudis via macports-users 
>  wrote:
> 
> Hello all, 
> 
> I’m working on a MBP, 2018 model and yesterday I updated to the latest 
> version of BigSur. Since then I cannot compile any fortran code and the error 
> I get is 
> 
> ld: library not found for -lSystem
> collect2: error: ld returned 1 exit status
> 
> 
> I have tried both gcc9 and gcc10
> 
> gfortran -v gives this output :
> 
> Using built-in specs.
> COLLECT_GCC=gfortran
> COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin20/10.2.0/lto-wrapper
> Target: x86_64-apple-darwin20
> Configured with: 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc10/gcc10/work/gcc-10.2.0/configure
>  --prefix=/opt/local --build=x86_64-apple-darwin20 
> --enable-languages=c,c++,objc,obj-c++,lto,fortran,jit 
> --libdir=/opt/local/lib/gcc10 --includedir=/opt/local/include/gcc10 
> --infodir=/opt/local/share/info --mandir=/opt/local/share/man 
> --datarootdir=/opt/local/share/gcc-10 --with-local-prefix=/opt/local 
> --with-system-zlib --disable-nls --program-suffix=-mp-10 
> --with-gxx-include-dir=/opt/local/include/gcc10/c++/ --with-gmp=/opt/local 
> --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local 
> --enable-stage1-checking --disable-multilib --enable-lto 
> --enable-libstdcxx-time --with-build-config=bootstrap-debug 
> --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld 
> --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket 
>  --enable-host-shared --disable-tls 
> --with-pkgversion='MacPorts gcc10 10.2.0_4' 
> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 10.2.0 (MacPorts gcc10 10.2.0_4) 
> 
> I’ve removed and reinstalled MacPorts and all packages but it didn’t help.
> 
> Any ideas what may be the problem here? 
> 
> Thanks in advance for your help
> 
> Andreas 
> 
> Dr. Seismologist
> 



smime.p7s
Description: S/MIME cryptographic signature

latest update to BigSur 11.1 broke gcc

[Andreas Skarlatoudis via macports-users]

Hello all, 

I’m working on a MBP, 2018 model and yesterday I updated to the latest version 
of BigSur. Since then I cannot compile any fortran code and the error I get is 

ld: library not found for -lSystem
collect2: error: ld returned 1 exit status


I have tried both gcc9 and gcc10

gfortran -v gives this output :

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin20/10.2.0/lto-wrapper
Target: x86_64-apple-darwin20
Configured with: 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc10/gcc10/work/gcc-10.2.0/configure
 --prefix=/opt/local --build=x86_64-apple-darwin20 
--enable-languages=c,c++,objc,obj-c++,lto,fortran,jit 
--libdir=/opt/local/lib/gcc10 --includedir=/opt/local/include/gcc10 
--infodir=/opt/local/share/info --mandir=/opt/local/share/man 
--datarootdir=/opt/local/share/gcc-10 --with-local-prefix=/opt/local 
--with-system-zlib --disable-nls --program-suffix=-mp-10 
--with-gxx-include-dir=/opt/local/include/gcc10/c++/ --with-gmp=/opt/local 
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local 
--enable-stage1-checking --disable-multilib --enable-lto 
--enable-libstdcxx-time --with-build-config=bootstrap-debug 
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld 
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket 
 --enable-host-shared --disable-tls 
--with-pkgversion='MacPorts gcc10 10.2.0_4' 
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (MacPorts gcc10 10.2.0_4) 

I’ve removed and reinstalled MacPorts and all packages but it didn’t help.

Any ideas what may be the problem here? 

Thanks in advance for your help

Andreas 

Dr. Seismologist

Re: clamav-server notes question

[Lenore Horner]

Thank you.
> The binary daemondo is part of MacPorts:
So the notes indicated - or at any rate that “a” daemondo is part of MacPorts.
> 
> $ which daemondo
> /opt/local/bin/daemondo
I found that but didn’t know how to tell if it was the right one.  It isn’t in 
a MacPorts directory so I didn’t see a way to know this is the MacPorts 
daemondo and not some other daemondo since the name looks fairly generic.  
Thanks for confirming that I did grant access to the correct file.
> 
> To allow this process full disk access hit ‘+’ under System Preferences> 
> Security & Privacy> Privacy> Full Disk Access,
Did that.
> 
> Then in the Finder window hit Command-Shift-. to show the hidden directories, 
> then navigate to /opt/local/bin/daemondo.
Did that.
> 
> All clamav-server logs are in /opt/local/var/log/clamav, or 
> ~/Library/Logs/ClamavScanIt for user-invoked ClamavScanIt.sh calls. Look for 
> ClamavScanOnAccess.log and ClamavScanSchedule.log.
Wasn’t seeing anything there when I wrote, but now there are things there, so I 
guess it is working.  Thanks for confiming that is all I should be seeing.
> 
> Except for the logs, clamav-server scans happen silently in the background. 
> Quarantined files are placed in /opt/Quarantine or 
> ${CLAMAV_SERVER_QUARANTINE} according to rules in the scripts:
> /opt/local/etc/LaunchDaemons/org.macports.ClamavScanOnAccess/ClamavScanOnAccess.wrapper
> /opt/local/etc/LaunchDaemons/org.macports.ClamavScanSchedule/ClamavScanSchedule.wrapper
> /opt/local/bin/ClamavScanIt.sh
> 
> There’s several other shell variable in these scripts that provide user 
> control of control scanning behavior.
> 
> If you follow the instructions for the Finder.app Contextual Menu for 
> ClamavScanIt.sh, then right-click on a file and run ClamavScanIt, you’ll see 
> the little Automator gear running in the Menu Bar, then a notification of the 
> result.
That I was seeing.
> 
> An undocumented feature to set environment variables at boot time is to 
> create and load a plist like the following:
> 
> /Library/LaunchDaemons/private.myserver.launchctl-setenv.plist
>> 
>> > "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
>> ">
>> 
>> 
>>  Label
>>  private.myserver.launchctl-setenv
>>  ProgramArguments
>>  
>>  /bin/bash
>>  -c
>>  /bin/launchctl setenv CLAMAV_SERVER_QUARANTINE 
>> /path/to/my/quarantine ; /bin/launchctl setenv 
>> CLAMAV_SERVER_SCAN_SCHEDULE_TARGETS ("/" 
>> "/Volumes/MyDisk”)
>>  
>>  RunAtLoad
>>  
>> 
>> 
> 
> 
> 
> 
>> On Dec 14, 2020, at 11:35 AM, Lenore Horner > > wrote:
>> 
>> I’m not understanding one part of the notes for clamav-server.  They say
>> “On macOS 10.14+ On-Schedule and On-Access scans require enabling
>>   Full Disk Access for the MacPorts process "daemondo" in:
>>   
>>   System Preferences> Security & Privacy> Full Disk Access”.
>> I’ve looked through the results of port contents clamav and port contents 
>> clamav-server and don’t see any file deamondo listed.  There is a deamondo 
>> in /opt/local/bin but how do I know that’s the right one?  It’s not labeled 
>> in any clear way as having come from MacPorts.  How would I verify that 
>> automake scanning of ~/downloads and ~/desktop is happening?  I only see the 
>> log for the manual scanning.  Does that mean I still don’t have the 
>> automatic scanning configured correctly (so there is some other deamondo I 
>> need to follow the instructions above for because I think the rest I’ve 
>> followed successfully) or is the logging of that going somewhere else?
>> 
>> Thanks,
>> Lenore
>