Re: latest update to BigSur 11.1 broke gcc

[Christopher Jones]

From a combination of my memory, and reading the tickets referenced in the gcc 
port file, if we don’t use 
—with-sysroot we would need to use --with-build-sysroot in order for the build 
to work, and last time that was tried it didn’t work correctly.

> On 16 Dec 2020, at 3:37 am, Ken Cunningham  
> wrote:
> 
> we might just delete this line from the portfile, perhaps:
> 
> 
>  configure.args-append --with-sysroot="${configure.sdkroot}"



smime.p7s
Description: S/MIME cryptographic signature

Re: latest update to BigSur 11.1 broke gcc

[Ken Cunningham]

I'll try it. Things have changed in gcc -- after all, we don't bake any such 
path into our clang installs, and they don't exhibit this issue.

K

> On Dec 16, 2020, at 02:38, Christopher Jones  wrote:
> 
> From a combination of my memory, and reading the tickets referenced in the 
> gcc port file, if we don’t use 
> —with-sysroot we would need to use --with-build-sysroot in order for the 
> build to work, and last time that was tried it didn’t work correctly.
> 
>> On 16 Dec 2020, at 3:37 am, Ken Cunningham  
>> wrote:
>> 
>> we might just delete this line from the portfile, perhaps:
>> 
>> 
>>  configure.args-append --with-sysroot="${configure.sdkroot}"
> 

AnRe: latest update to BigSur 11.1 broke gcc

[Chris Jones]

I tried it myself, and switching to --with-build-sysroot with gcc10 on big sur 
does seem to build. I haven't had time to run any tests to see exactly what 
this means w.r.t. the default sdk search paths. But in any case I think the 
best advice is anyway to explicitly set it yourself, using one of the numerous 
methods (command line flag, SDKROOT, or use xcrun) in which case whatever the 
default search paths  are does not really make much difference. If we do decide 
to switching to the above then what this means in practise I think is just it 
enforces that users will have to do this, rather than it sometimes working for 
them.

Out of interest what happens with the macports clang ports ? If no default path 
to an sdk is set there, presumably users are also required with these compilers 
to always explicitly give the sdk they wish to use, via similar methods ?

Chris 

> On 16 Dec 2020, at 3:42 pm, Ken Cunningham  
> wrote:
> 
> 
> I'll try it. Things have changed in gcc -- after all, we don't bake any such 
> path into our clang installs, and they don't exhibit this issue.
> 
> K
> 
>> On Dec 16, 2020, at 02:38, Christopher Jones  
>> wrote:
>> 
>> From a combination of my memory, and reading the tickets referenced in the 
>> gcc port file, if we don’t use 
>> —with-sysroot we would need to use --with-build-sysroot in order for the 
>> build to work, and last time that was tried it didn’t work correctly.
>> 
>>> On 16 Dec 2020, at 3:37 am, Ken Cunningham 
>>>  wrote:
>>> 
>>> we might just delete this line from the portfile, perhaps:
>>> 
>>> 
>>>  configure.args-append --with-sysroot="${configure.sdkroot}"
>> 

Re: AnRe: latest update to BigSur 11.1 broke gcc

[Ken Cunningham]

I recall this discussion and commit from last year about how gcc finds it’s SDK 
to use:

https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=24ec3cc957c4181d8da9972cb2aa212a3e0cec1c
 



Notably, at this moment in time, if the SDKROOT is set to “/“ gcc will ignore 
it…. hah hah.

Ken

Re: Binaries over different os10 versions

[Ryan Schmidt]

On Dec 12, 2020, at 15:23, dan d. wrote:

> Does a binary, like lynx the browser, work over several versions of os10.  I 
> have one older machine which version is 6 upgrades removed from
> the most recent one.  Will that lynx continue to work if most of the versions 
> are skipped by installing a more recent version of os10? -- I
> was thinking instead of doing the macports step by step migration for a newer 
> os10 i would just do an install from scratch but keep the older
> binaries I frequently use until the macports for the new version is installed

If you compile something on one version of macOS, then yes, it continues to be 
usable on later versions of macOS, with certain exceptions. This is why 
applications that you download from the App Store or from developer web sites 
often continue to work even if you use a newer version of the OS than the 
developer did. Some exceptions are that a binary compiled for PowerPC cannot 
run on 10.7 or later, and a binary compiled for 32-bit Intel cannot run on 
10.15 or later.

If you upgrade the OS and reinstall MacPorts but do not reinstall or upgrade 
any of your ports, your installed ports will probably continue to work on the 
new OS. But once you start upgrading or installing some of your ports, all bets 
are off with regard to those ports that you have not yet upgraded or 
reinstalled. For example, if you had lynx installed before, then you upgrade 
your OS but do not upgrade any ports, lynx will probably work on the new OS. 
But if you then upgrade some ports, lynx may stop working, for example because 
you upgraded one of the libraries that lynx uses and perhaps your older lynx 
binary is incompatible with the new version of the library. 
Upgrading/reinstalling lynx and all other ports on your new OS version would 
get you back to a consistent matched set of ports.

Re: Strange python-38 error when running pip search

[Ryan Schmidt]

On Dec 14, 2020, at 16:26, Carlo Tambuatco wrote:

> I have python38 installed via macports. It is the default python 
> via python_select.
> 
> I don’t think I should file a ticket in this case because this error isn’t 
> local to the python(s) 
> installed via macports. It even occurs when running a pip search from pythons 
> installed 
> manually.
> 
> The error occurs when I do 
> 
> $ pip search 
> 
> Begin error:
> 
> ERROR: Exception:
> Traceback (most recent call last):
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_internal/cli/base_command.py",
>  line 224, in _main
>status = self.run(options, args)
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_internal/commands/search.py",
>  line 62, in run
>pypi_hits = self.search(query, options)
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_internal/commands/search.py",
>  line 82, in search
>hits = pypi.search({'name': query, 'summary': query}, 'or')
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/xmlrpc/client.py",
>  line 1109, in __call__
>return self.__send(self.__name, args)
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/xmlrpc/client.py",
>  line 1450, in __request
>response = self.__transport.request(
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_internal/network/xmlrpc.py",
>  line 46, in request
>return self.parse_response(response.raw)
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/xmlrpc/client.py",
>  line 1341, in parse_response
>return u.close()
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/xmlrpc/client.py",
>  line 655, in close
>raise Fault(**self._stack[0])
> xmlrpc.client.Fault:  temporarily disabled due to unmanageable load and will be deprecated in the 
> near future. Please use the Simple or JSON API instead.’>
> 
> End error:
> 
> 
> I have no idea what is going on and don’t know where to begin. This started 
> either today or yesterday.

I guess you should file a bug report with the developers of pip?

Re: Need help reverting to older library

[Ryan Schmidt]

> On Dec 9, 2020, at 01:30, list_email--- wrote:
> 
> 
>> On Dec 6, 2020, at 9:35 AM, Ken Cunningham wrote:
>> 
>> of course the simplest method of reverting to an older binary is to just 
>> reactivate it if you still have it installed, but inactive, after an update. 
>> 
>> This will show you what versions are installed:
>> 
>> port -v installed portname
>> 
>> and this: 
>> 
>> port activate portname
>> 
> I like this approach. Unfortunately, I have only the current version:
> 
>   shapelib @1.5.0_0 (active)
> 
> Is there some way that I can set this aside and install the version I need 
> and then make it active?

Instructions are at https://trac.macports.org/wiki/howto/InstallingOlderPort