Re: wxWidgets-3.0 warnings with Big Sur

[Ken Cunningham]

> On Dec 29, 2020, at 8:47 PM, Kevin Horton  wrote:
> 
> I moved libwx_osx_cocoau_core-3.0.0.dylib and libwx_osx_cocoau_core-3.0.dylib 
> aside and symlinked those names to /libwx_osx_cocoau_core-3.0.0.4.0.dylib
> 
> ls -al *core*
> -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
> libwx_osx_cocoau_core-3.0.0.4.0.dylib
> lrwxr-xr-x  1 root  wheel   37 Dec 29 20:44 
> libwx_osx_cocoau_core-3.0.0.dylib -> libwx_osx_cocoau_core-3.0.0.4.0.dylib
> lrwxr-xr-x  1 root  wheel   37 Dec 29 20:44 
> libwx_osx_cocoau_core-3.0.dylib -> libwx_osx_cocoau_core-3.0.0.4.0.dylib
> 
> I rebuilt gnuplot, but still get the same errors:
> 
> objc[90874]: Class wxNSAppController is implemented in both 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
>  (0x10c39fc40) and 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>  (0x10b1fbc40). One of the two will be used. Which one is undefined.
> objc[90874]: Class ModalDialogDelegate is implemented in both 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
>  (0x10c39fc68) and 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>  (0x10b1fbc68). One of the two will be used. Which one is undefined.
> objc[90874]: Class wxNSApplication is implemented in both 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
>  (0x10c39fcb8) and 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>  (0x10b1fbcb8). One of the two will be used. Which one is undefined.
> 
> Anything else to try to learn something useful?

Nah — turns out it’s a known bug, so add another vote to Ryan’s radar if you 
can.

Make the symlinks yourself, and then you’re good. 

Nothing wrong with wxWidgets-3.0. Not worth rewriting the scripts in wxWidgets 
for this Apple bug, IMHO.

K

Re: wxWidgets-3.0 warnings with Big Sur

[Kevin Horton]

> On Dec 29, 2020, at 20:13, Ryan Schmidt  wrote:
> 
> On Dec 29, 2020, at 20:12, Kevin Horton wrote:
> 
>> On Dec 29, 2020, at 17:20, Ken Cunningham wrote:
>>> 
>>> Interesting.
>>> 
>>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
>>> and
>>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>>> are actually the same library; one is just a symlink to the other:
>>> 
>>> % ls -la 
>>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0*
>>>
>>> -rwxr-xr-x  1 macports  wheel  4563192 31 Oct  2019 
>>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
>>> lrwxr-xr-x  1 root  wheel   37 31 Oct  2019 
>>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib
>>>  -> libwx_osx_cocoau_core-3.0.0.4.0.dylib
>>> lrwxr-xr-x  1 root  wheel   33 31 Oct  2019 
>>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>>>  -> libwx_osx_cocoau_core-3.0.0.dylib
>>> 
>>> I have only one referenced:
>>> 
>>> % otool -L /opt/local/bin/gnuplot | grep core  
>>> 
>>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>>>  (compatibility version 5.0.0, current version 5.0.0)
>>> 
>>> and I see no such warnings on Catalina, but perhaps this is related to the 
>>> new way that dylibs are found on BigSur, and it’s getting confused by the 
>>> symlink…
>>> 
>>> It’s very hard to imagine nobody would have ever noticed that before, 
>>> though.
>>> 
>>> Ken
>> 
>> Things seem different on Big Sur.  I don't see any symlinks here:
>> 
>> %  ls -la 
>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0*
>> -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
>> -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib
>> -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
> 
> I suspect this is because of this Apple bug that I have mentioned before:
> 
> https://lists.macports.org/pipermail/macports-dev/2020-November/042641.html
> 
> Please check if Xcode 12.3 still has the problem. If it does, please file 
> additional bug reports with Apple about this and mention that it is a 
> duplicate of FB8915358 so that they realize how many people it affects so 
> that they fix it.
> 
This is with XCode 12.3.

I moved libwx_osx_cocoau_core-3.0.0.dylib and libwx_osx_cocoau_core-3.0.dylib 
aside and symlinked those names to /libwx_osx_cocoau_core-3.0.0.4.0.dylib

 ls -al *core*
-rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
libwx_osx_cocoau_core-3.0.0.4.0.dylib
lrwxr-xr-x  1 root  wheel   37 Dec 29 20:44 
libwx_osx_cocoau_core-3.0.0.dylib -> libwx_osx_cocoau_core-3.0.0.4.0.dylib
lrwxr-xr-x  1 root  wheel   37 Dec 29 20:44 libwx_osx_cocoau_core-3.0.dylib 
-> libwx_osx_cocoau_core-3.0.0.4.0.dylib

I rebuilt gnuplot, but still get the same errors:

objc[90874]: Class wxNSAppController is implemented in both 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
 (0x10c39fc40) and 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
 (0x10b1fbc40). One of the two will be used. Which one is undefined.
objc[90874]: Class ModalDialogDelegate is implemented in both 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
 (0x10c39fc68) and 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
 (0x10b1fbc68). One of the two will be used. Which one is undefined.
objc[90874]: Class wxNSApplication is implemented in both 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
 (0x10c39fcb8) and 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
 (0x10b1fbcb8). One of the two will be used. Which one is undefined.

Anything else to try to learn something useful?

Thanks,

Kevin

Re: odd problem trying to use Macports ...

[Ryan Schmidt]

On Dec 29, 2020, at 20:28, Richard Bonomo TDS personal wrote:

> My system runs MacOS 10.12 (Sierra).  I've used Macports for some time every 
> now and again.
> 
> However, when I tried to use it recently, this happened:
> 
> **
> $ port version
> dlopen(/opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib, 10): no 
> suitable image found.  Did find:
>/opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib: no matching 
> architecture in universal wrapper
>while executing
> "load /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib"
>("package ifneeded macports 1.0" script)
>invoked from within
> "package require macports"
>(file "/opt/local/bin/port" line 38)
> ***

What is the architecture of that file? It sounds like it is not the right 
architecture for your computer.

lipo -info /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib

What is its modification date? I'll bet it's old.

ls -l /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib

The whole /opt/local/share/macports/Tcl directory went away in 2014, and that 
change was released in MacPorts 2.3.0:

https://github.com/macports/macports-base/commits/06b6c3951c62d62d12ff9dc0cf0454cf02d7a690

The installer deletes this directory when upgrading. Maybe somehow you have 
restored this old directory from an old backup or you have run a third-party 
installer that replaced your MacPorts with a much older version that still had 
this directory.

Downloading the current MacPorts installer for Sierra from our web site and 
running it should hopefully set things right again. This will not affect your 
installed ports.

Re: wxWidgets-3.0 warnings with Big Sur

[Ken Cunningham]

> On Dec 29, 2020, at 8:13 PM, Ryan Schmidt  wrote:

> I suspect this is because of this Apple bug that I have mentioned before:
> 
> https://lists.macports.org/pipermail/macports-dev/2020-November/042641.html
> 
> Please check if Xcode 12.3 still has the problem. If it does, please file 
> additional bug reports with Apple about this and mention that it is a 
> duplicate of FB8915358 so that they realize how many people it affects so 
> that they fix it.
> 

Indeed, that must be it.

The Portfile itself has no calls to install_name_tool, but there are several 
references to it in the build scripts from upstream.

Ken

Re: wxWidgets-3.0 warnings with Big Sur

[Ryan Schmidt]

On Dec 29, 2020, at 20:12, Kevin Horton wrote:

> On Dec 29, 2020, at 17:20, Ken Cunningham wrote:
>> 
>> Interesting.
>> 
>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
>> and
>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>> are actually the same library; one is just a symlink to the other:
>> 
>> % ls -la 
>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0*
>>
>> -rwxr-xr-x  1 macports  wheel  4563192 31 Oct  2019 
>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
>> lrwxr-xr-x  1 root  wheel   37 31 Oct  2019 
>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib
>>  -> libwx_osx_cocoau_core-3.0.0.4.0.dylib
>> lrwxr-xr-x  1 root  wheel   33 31 Oct  2019 
>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>>  -> libwx_osx_cocoau_core-3.0.0.dylib
>> 
>> I have only one referenced:
>> 
>> % otool -L /opt/local/bin/gnuplot | grep core  
>>  
>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>>  (compatibility version 5.0.0, current version 5.0.0)
>> 
>> and I see no such warnings on Catalina, but perhaps this is related to the 
>> new way that dylibs are found on BigSur, and it’s getting confused by the 
>> symlink…
>> 
>> It’s very hard to imagine nobody would have ever noticed that before, though.
>> 
>> Ken
> 
> Things seem different on Big Sur.  I don't see any symlinks here:
> 
> %  ls -la 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0*
> -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
> -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib
> -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib

I suspect this is because of this Apple bug that I have mentioned before:

https://lists.macports.org/pipermail/macports-dev/2020-November/042641.html

Please check if Xcode 12.3 still has the problem. If it does, please file 
additional bug reports with Apple about this and mention that it is a duplicate 
of FB8915358 so that they realize how many people it affects so that they fix 
it.

Re: wxWidgets-3.0 warnings with Big Sur

[Ken Cunningham]

> On Dec 29, 2020, at 6:12 PM, Kevin Horton  wrote:
> 
> Things seem different on Big Sur.  I don't see any symlinks here:
> 
> %  ls -la 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0*
> -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
> -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib
> -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
> 

Are these dylibs individually manipulatable? Can you move the bottom two 
somewhere safe, and create the correct symlinks as Catalina has? 

One would think that would fix the issue, and then if that indeed works, we can 
sort out where that is getting messed up in the construction of wxWidgets on 
BigSur perhaps.

Ken

odd problem trying to use Macports ...

[Richard Bonomo TDS personal]

Hello!

My system runs MacOS 10.12 (Sierra).  I've used Macports for some time every 
now and again.

However, when I tried to use it recently, this happened:

**
$ port version
dlopen(/opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib, 10): no 
suitable image found.  Did find:
/opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib: no matching 
architecture in universal wrapper
while executing
"load /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib"
("package ifneeded macports 1.0" script)
invoked from within
"package require macports"
(file "/opt/local/bin/port" line 38)
***

So far, I've not been able to find an explanation or real fix for this.
(The same thing happens if I try to execute any other "ports" command.)

Anybody know what happened?

Thank you.

Rich
(Richard Bonomo)

Re: wxWidgets-3.0 warnings with Big Sur

[Kevin Horton]

On Dec 29, 2020, at 17:20, Ken Cunningham  
wrote:
> 
> Interesting.
> 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
> and
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
> are actually the same library; one is just a symlink to the other:
> 
> % ls -la 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0*
>
> -rwxr-xr-x  1 macports  wheel  4563192 31 Oct  2019 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
> lrwxr-xr-x  1 root  wheel   37 31 Oct  2019 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib
>  -> libwx_osx_cocoau_core-3.0.0.4.0.dylib
> lrwxr-xr-x  1 root  wheel   33 31 Oct  2019 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>  -> libwx_osx_cocoau_core-3.0.0.dylib
> 
> I have only one referenced:
> 
> % otool -L /opt/local/bin/gnuplot | grep core  
>   
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>  (compatibility version 5.0.0, current version 5.0.0)
> 
> and I see no such warnings on Catalina, but perhaps this is related to the 
> new way that dylibs are found on BigSur, and it’s getting confused by the 
> symlink…
> 
> It’s very hard to imagine nobody would have ever noticed that before, though.
> 
> Ken

Things seem different on Big Sur.  I don't see any symlinks here:

%  ls -la 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0*
-rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
-rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib
-rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib

And the files have different inodes, so not hard links either:

% ls -il *core*
68952234 -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
libwx_osx_cocoau_core-3.0.0.4.0.dylib
68952250 -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
libwx_osx_cocoau_core-3.0.0.dylib
68952220 -rwxr-xr-x  1 root  wheel  4743504 Nov 23 00:52 
libwx_osx_cocoau_core-3.0.dylib

But only one is found by otool

% otool -L /opt/local/bin/gnuplot | grep core

/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
 (compatibility version 5.0.0, current version 5.0.0)

Everything seems to work correctly, if you ignore the spewage, so this likely 
sits low on the priority list.

Kevin

Re: MacVim @8.2.snapshot166_1+huge builtin updater appears

[Ryan Schmidt]

On Dec 29, 2020, at 12:21, Richard L. Hamilton wrote:

> Saw the MacVim updater window recently.  I would think that (if not too 
> difficult) builtin updaters should be disabled (I think this came up with 
> iTerm or iTerm2 or something before) in MaPorts ports, which should only be 
> updated with port upgrade.

Yes, built-in updaters should be disabled. Please file a bug report or a pull 
request.

Re: wxWidgets-3.0 warnings with Big Sur

[Ken Cunningham]

Interesting.

/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
and
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
are actually the same library; one is just a symlink to the other:

% ls -la 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0*
   
-rwxr-xr-x  1 macports  wheel  4563192 31 Oct  2019 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
lrwxr-xr-x  1 root  wheel   37 31 Oct  2019 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib
 -> libwx_osx_cocoau_core-3.0.0.4.0.dylib
lrwxr-xr-x  1 root  wheel   33 31 Oct  2019 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
 -> libwx_osx_cocoau_core-3.0.0.dylib

I have only one referenced:

% otool -L /opt/local/bin/gnuplot | grep core  

/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
 (compatibility version 5.0.0, current version 5.0.0)

and I see no such warnings on Catalina, but perhaps this is related to the new 
way that dylibs are found on BigSur, and it’s getting confused by the symlink…

It’s very hard to imagine nobody would have ever noticed that before, though.

Ken

wxWidgets-3.0 warnings with Big Sur

[Kevin Horton]

I'm running macOS 11.1 and followed the migration instructions.  Today I ran 
gnuplot for the first time, and the CLI spewed out over 400 lines of warnings 
related to wxWidgets.  The first few lines were:

objc[53143]: Class wxNSAppController is implemented in both 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
 (0x10bf24c40) and 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
 (0x10ad85c40). One of the two will be used. Which one is undefined.
objc[53143]: Class ModalDialogDelegate is implemented in both 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
 (0x10bf24c68) and 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
 (0x10ad85c68). One of the two will be used. Which one is undefined.
objc[53143]: Class wxNSApplication is implemented in both 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib
 (0x10bf24cb8) and 
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
 (0x10ad85cb8). One of the two will be used. Which one is undefined.

I uninstalled gnuplot, wxWidgets-3.0, wxWidgets-common  and wxWidgets_select 
and then installed them to force a rebuild.  No change.

Gnuplot appears to work normally, so no panic.

Is there anything else I should try before filing a bug?

Thanks,

Kevin

Re: Qt

[Ken Cunningham]

pretty much all the qt5 ports are building on all systems.

a couple of them are still not 100% for arm64.

I last listed the full output of the qt 5.15.2 builds on the systems 10.13 and 
up here:



towards the bottom of that ticket.

Best,

ken


PS: just updated qt5-qtcreator as well, tested on 10.15 and 11.0 Intel, and 
moving to test the last couple of systems soon.

There is a PR in place for that at present.

Re: Qt

[Ruben Di Battista]

Hello Tom,

theoretically the QT5 ports are building correctly. Can you maybe
provide more information?

* What's your Macports version?
* What's your macOs version?
* Can you attach the build log?

On Tue, Dec 29, 2020 at 8:38 PM Tom  wrote:
>
> Hello,
>
> is there a qt port, which ist building?
> All I have tried so far, are not building.
>
> Regards



-- 
  _
-. .´  |
  ',  ;|∞∞
˜˜   |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `'
https://rdb.is

Qt

[Tom]

Hello,

is there a qt port, which ist building?
All I have tried so far, are not building.

Regards

MacVim @8.2.snapshot166_1+huge builtin updater appears

[Richard L. Hamilton]

Saw the MacVim updater window recently.  I would think that (if not too 
difficult) builtin updaters should be disabled (I think this came up with iTerm 
or iTerm2 or something before) in MaPorts ports, which should only be updated 
with port upgrade.



smime.p7s
Description: S/MIME cryptographic signature

Re: macOS 11.1 SDK does not appear to be installed

[Ryan Schmidt]

On Dec 28, 2020, at 19:09, Tom Gederberg wrote:

> I updated my system to Big Sur and followed the MacPorts migration 
> instructions and updated Xcode to version 12.3.
> 
> However, when I try to build ports in MacPorts, I now get the following 
> warnings.
> 
> Warning: The macOS 11.1 SDK does not appear to be installed. Ports may not 
> build correctly.
> Warning: You can install it as part of the Xcode Command Line Tools package 
> by running `xcode-select --install’.
> 
> What am I doing wrong?

There is or was a bug in macOS that deletes the CLT receipt. When this happens, 
MacPorts and Software Update can no longer determine what version of CLT you 
have installed. You should fix the problem by reinstalling the CLT. You may 
need to do so again periodically in the future until Apple fixes their bug. See 
https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt

A small number of ports may cause this warning to appear erroneously, even 
though the CLT and their receipt are properly installed, for example qt5 and 
its subports. See https://trac.macports.org/ticket/61736

Re: mac build of mythtv

[Ryan Schmidt]

On Dec 29, 2020, at 00:55, James Linder wrote:

> I posted this to mythtv-users, but I wondered in anyone had any interest. The 
> obvious first step is wrapping John's work in a port.
> 
> -
> John (Hoyt) did a stellar job getting the macos/ansible build proceess to 
> work and in no way is this critique any reflection on his effort.
> (and all his work is here https://sourceforge.net/projects/mythtvformacosx/)
> 
> Mythfrontend on mac is aweful!
> What we need is someone who understands the gubbins of macos to take an 
> interest and lead us from the wilderness :-)
> 
> The app is slow to start and to stop (talking 20, 30 seconds)(cf 1-2 sec: 
> linux)
> Cutlist editor core dumps *every time* editing a HD (h254) recording
> On linux scan of video fills in meta data. On macos it often does not. 
> I->Change Details->Retrieve often works, often on 2nd or 3rd try. Sometimes 
> at least the text is set but the image is not.
> 
> There are also funnies with regard to season vs episode meta data retrieved.
> I->C->R retrieves season meta data, scan retrives episode meta data. This 
> occurs on linux too. A workaround is to reset metadata and scan until succces.
> --

Sounds like there are some bugs in mythtv.

Normally in MacPorts, we merely package software that its developers have 
provided. We aren't ourselves the developers of that software and aren't 
responsible for fixing bugs or making other improvements in it, though 
individual users who are interested might do so. If there are bugs in the 
software, file bug reports with its developers, and help fix them if you can.

The maintainer of the mythtv ports in MacPorts is Craig; I've Cc'd him; maybe 
he has more input.