Re: Using X11 for an older program

[Ryan Schmidt]

On Dec 21, 2020, at 12:55, Michael wrote:

> This should be a simple one. I hope.
> 
> I just installed a program that was compiled against the release version of 
> mac's X11. Crashes on startup with this:
> 
> dyld: launch, loading dependent libraries
> 
> Dyld Error Message:
> Library not loaded: /opt/X11/lib/libpng15.15.dylib
> 
> What symbolic links do I need? /opt has no X11 directory.

You can make symlinks at /opt/X11/lib/libpng15.15.dylib pointing to wherever 
libpng15.15.dylib is on your system, or better yet, use install_name_tool to 
change the library references in that program to refer to wherever 
libpng15.15.dylib is on your system.

Don't try to symlink libpng15.15.dylib to libpng16.16.dylib or use 
install_name_tool to make that change. The library name has changed because 
they are not interchangeable. If they had been meant to be interchangeable, the 
library name would not have changed.


On Dec 21, 2020, at 13:34, Michael wrote:

> Ok, another question. I found this:
> 
> /opt/local/lib/libpng16.16.dylib
> 
> I cannot find the older version. What do I need to do to install both the 
> current and the older version of this library at the same time?

MacPorts provides only one version of libpng: the latest, currently version 
1.6.x, which has a library name libpng16.16.dylib. libpng15.15.dylib was 
probably libpng 1.5.x. You could manually compile the last libpng 1.5.x in some 
other prefix and then use install_name_tool to make the program you downloaded 
refer to it.

Ideally, of course, you'd recompile the other program so that it links with the 
current libpng16.16.dylib, if you have access to its source code.

Re: ARM gdb compilation fails with implicit function declaration error ioctl

[Ryan Schmidt]

On Dec 21, 2020, at 14:52, Christoph Kukulies wrote:

> Excuses if is not actually a macports issue but I’m a bit lost.
> 
> I’m about to build this:
> https://gitlab.com/LinkiTools/binutils-gdb
> 
> 
> /Users/kuku/Downloads/binutils-gdb-users-ARM-embedded-gdb-master-2018q4/
> 
> 
> 
> 
> Running ./configure and make in this directory ends with an error:
> 
> config.status: executing default commands
> rm -f readline.o
> gcc -c -DHAVE_CONFIG_H-I. -I. -DRL_LIBRARY_VERSION='"6.2"' -g -O2 
> readline.c
> rm -f vi_mode.o
> gcc -c -DHAVE_CONFIG_H-I. -I. -DRL_LIBRARY_VERSION='"6.2"' -g -O2 
> vi_mode.c
> rm -f funmap.o
> gcc -c -DHAVE_CONFIG_H-I. -I. -DRL_LIBRARY_VERSION='"6.2"' -g -O2 funmap.c
> rm -f keymaps.o
> gcc -c -DHAVE_CONFIG_H-I. -I. -DRL_LIBRARY_VERSION='"6.2"' -g -O2 
> keymaps.c
> rm -f parens.o
> gcc -c -DHAVE_CONFIG_H-I. -I. -DRL_LIBRARY_VERSION='"6.2"' -g -O2 parens.c
> rm -f search.o
> gcc -c -DHAVE_CONFIG_H-I. -I. -DRL_LIBRARY_VERSION='"6.2"' -g -O2 search.c
> rm -f rltty.o
> gcc -c -DHAVE_CONFIG_H-I. -I. -DRL_LIBRARY_VERSION='"6.2"' -g -O2 rltty.c
> rltty.c:83:7: error: implicit declaration of function 'ioctl' is invalid in 
> C99 [-Werror,-Wimplicit-function-declaration]
>   if (ioctl (tty, TIOCGWINSZ, ) == 0)
>   ^
> rltty.c:720:3: error: implicit declaration of function 'ioctl' is invalid in 
> C99 [-Werror,-Wimplicit-function-declaration]
>   ioctl (fildes, TIOCSTART, 0);
>   ^
> rltty.c:759:3: error: implicit declaration of function 'ioctl' is invalid in 
> C99 [-Werror,-Wimplicit-function-declaration]
>   ioctl (fildes, TIOCSTOP, 0);
>   ^
> 3 errors generated.
> make[2]: *** [rltty.o] Error 1
> make[1]: *** [all-readline] Error 2
> make: *** [all] Error 2
> 
> 
> 
> Is there a way to either pass gcc an appropriate -W switch to overcome this 
> error or „repair“ the readline source accordingly?
> 
> 
> $ gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
> --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/c++/4.2.1
> Apple clang version 12.0.0 (clang-1200.0.32.28)
> Target: x86_64-apple-darwin19.6.0
> Thread model: posix
> InstalledDir: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> 
> OS is macOS Catalina 10.15.7
> 
> Help greatly appreciated.
> 
> (reason why not using a binary package is that I want to apply a patch to 
> arm-none-eabi-gdb.

Implicit declaration of function is an error in the source code. The developers 
should fix the problem, usually by including the right headers that declare the 
functions that are being used. You should report it to them.

Re: Using X11 for an older program

[Ryan Schmidt]

On Dec 21, 2020, at 21:01, Michael wrote:

> OK. Next question: Is there any reason I cannot install libpng version 15 at 
> the sametime?
> 
> I am aware that there is a non-versioned link file, that the latest version 
> of the dynamic library installs. That can stay at 16 where it belongs. I mean 
> specifically having both the libpng15 and the libpng16 files.
> 
> I am very surprised at linking to a specific version of a dynamic library. 
> This is actually commercial software, and it did not link to generic 
> "libpng", nor to generic "libpng15" -- linking to a specific version of a 
> dynamic library? Isn't the whole point of dynamic libraries that you don't 
> get a single specific buggy version, but the latest non-buggy version?

The developer of the library decides the granularity at which the library is 
versioned and decides what constitutes a backward incompatible change.

The developer of libpng has decided that all libpng 1.5.x versions are 
compatible with one another; they all use library name libpng15.15.dylib; and 
that all libpng 1.6.x versions are compatible with one another; they all use 
library name libpng16.16.dylib. You can install a newer version of libpng 1.6.x 
and all older programs linked with an older libpng 1.6.x will benefit from the 
improvements in libpng. But any old programs linking with libpng 1.5.x cannot 
automatically use libpng16.16.dylib because there have been backward 
incompatible changes in the library. The program must be recompiled / relinked 
and the source code of the program might need to be updated in order to use 
libpng16.16.dylib.

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.

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: Using X11 for an older program

[Ryan Schmidt]

On Dec 21, 2020, at 20:55, Ken Cunningham wrote:

> There are likely to be more libraries missing after you fix this one, but you 
> can try.
> 
> EIther symlink a real library that is the same or as similar as you have into 
> the position being looked for:
> 
> sudo ln -s /opt/local/lib/libpng16.16.dylib /opt/X11/lib/libpng15.15.dylib
> 
> or
> 
> use install_name_tool to change /opt/local/lib/libpng16.16.dylib to 
> /opt/X11/lib/libpng15.15.dylib in your binary.
> 
> install_name_tool -change  /opt/local/lib/libpng16.16.dylib 
> /opt/X11/lib/libpng15.15.dylib /path/to/my/binary

Definitely do not do that. The filename has changed because version 15 and 
version 16 are not meant to be interchangeable.

Re: fpc

[Ryan Schmidt]

On Nov 21, 2020, at 15:42, Curtis Matz wrote:

> I’m receiving this error on Big Sur.  Does anyone have thoughts on how to fix 
> this?
> 
> sudo port clean fpc
> sudo port install fpc
> 
> :info:build 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.
> macports.org_release_tarballs_ports_lang_fpc/fpc/work/ppcx64 -Ur -Xs -O2 -n 
> -Fux
> 86_64 -Fusystems 
> -Fu/opt/local/var/macports/build/_opt_local_var_macports_source
> s_rsync.macports.org_release_tarballs_ports_lang_fpc/fpc/work/fpcbuild-3.2.0/fpc
> src/rtl/units/x86_64-darwin -Fix86_64 -FE. -FUx86_64/units/x86_64-darwin 
> -dRELEA
> SE-dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp
> :info:build ld: library not found for -lc
> :info:build An error occurred while linking 
> :info:build msg2inc.pp(822,51) Error: Error while linking
> :info:build msg2inc.pp(822,51) Fatal: There were 1 errors compiling module, 
> stopping
> :info:build Fatal: Compilation aborted
> 

Please file a bug report in our issue tracker as usual.

Re: p5.28-xml-entities-1.0.200_0.darwin_20.noarch.tbz2 does not seem to exist

[Ryan Schmidt]

On Nov 21, 2020, at 19:32, Vahid Askarpour wrote:

> In attempting to install grace, my Mac crashes losing internet connection. 
> The stall occurs when trying to fetch the following package:
> 
> Attempting to fetch p5.28-xml-entities-1.0.200_0.darwin_20.noarch.tbz2 from 
> https://packages.macports.org/p5.28-xml-entities
> --->  Attempting to fetch p5.28-xml-entities-1.0.200_0.darwin_20.noarch.tbz2 
> from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/perl5/p5.28-xml-entities
> --->  Attempting to fetch p5.28-xml-entities-1.0.200_0.darwin_20.noarch.tbz2 
> from https://lil.fr.packages.macports.org/p5.28-xml-entities

Sounds like this issue again:

https://trac.macports.org/ticket/60509

Do you have Little Snitch installed, or any other program that intercepts your 
network traffic? If so, try disabling it. If that works, it may need an update 
for Big Sur compatibility; check with its manufacturer.

We had another recent report of this problem on Big Sur in which the software 
Carbon Black might have been responsible:

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


> Checking these websites, the *.darwin_20.* does not appear to exist. The 
> highest package is *.darwin_19.*

That is normal. Big Sur was only just released, and we have barely made a dent 
in building Big Sur versions of the tens of thousands of ports we have. It will 
take weeks before we are done with those that we can build, and many will not 
be buildable at all at the moment.

https://lists.macports.org/pipermail/macports-users/2020-November/048940.html

Re: povray build error

[Ryan Schmidt]

On Dec 6, 2020, at 11:31, Murray Eisenberg wrote:

> Any chance of povray being fixed to avoid the fatal build errors reported 
> already at https://trac.macports.org/ticket/60961?
> 
> I note that no maintainer is listed (from sp info --maintainer povray or on 
> the ticket).

Working on it.


> I need it not only for itself, but in order to install the wims poart.

I'm not able to find any port named "wims" or any port that depends on povray.

Re: povray build error

[Ryan Schmidt]

On Dec 6, 2020, at 15:59, Murray Eisenberg wrote:

> My mistake in calling the learning system WIMS a port — it is not. Rather, it 
> is a separate download, from:
> 
>
> https://wims.matapp.unimib.it/wims/wims.cgi?session=86081EB7CC.1&+lang=en&+module=adm%2Flight&+phtml=download.phtml.en
> 
> However, the installation instructions at
> 
>   https://wiki.wimsedu.info/doku.php?id=installation:apple:macosx
> 
> specify that it needs:
> 
> sudo port install latex2html gnuplot octave maxima pari yacas povray wget 
> ImageMagick graphviz p5-uri fortune qrencode

Ok. Well the port should be fixed now (or in an hour or whenever it syncs to 
the public server) when compiling with new compilers. There may still be the 
problem in the ticket you referred to when using specific versions of Xcode 
clang which are apparently broken in some specific way that matters to povray.

Re: installing openscad

[Ryan Schmidt]

On Dec 5, 2020, at 19:51, Murray Eisenberg wrote:

> Those instructions say that if the older versions have been uninstalled — 
> which I did do — then to start by searching in the repositiry — which I did. 
> But I don’t see any History item for that port.

The history of the bison portfile is at

https://github.com/macports/macports-ports/commits/master/devel/bison/Portfile

Re: how change menus in openscad from Russian to English?

[Ryan Schmidt]

On Dec 6, 2020, at 12:23, Murray Eisenberg wrote:

> I just installed the openscad port and find that nearly all its menu items in 
> the installed GUI OpenSCAD.app are in Russian, in which I’m rather rusty.
> 
> How can that language be changed? I tried its preferences but found no 
> language setting (or at least didn’t recognize a Russian word or phrase for 
> doing that).

Check the list of languages you have configured for macOS in System 
Preferences: Language & Region, and check what values are set in your shell for 
the environment variables LANG, LC_ALL, LC_MESSAGES.


> I do note that the port is for a rather old version of openscad, namely, 
> 2015.03-3, whereas the current version of source listed at 
> https://www.openscad.org/downloads.html is 2019.05.

Please file a ticket in our issue tracker assigned to the port's maintainer 
asking them to update the port, or submit a pull request updating the port.

Re: Compiling a port statically

[Ryan Schmidt]

On Dec 6, 2020, at 15:52, Richard L. Hamilton wrote:

> I'm going to play devil's advocate on this and another post (with competing 
> positions, so don't feel bad).
> 
> MacPorts knows the library dependencies of a port. While it does not now 
> (AFAIK) record the specific versions of each used to build an installed port, 
> in principle, it could; at which point it could (also in principle) determine 
> whether any of them had changed, thus requiring a rebuild of the port that 
> depended on them, even if its version hadn't changed.
> 
> That's NOT a feature request, or probably even a practical idea. But IMO, it 
> does indicate that there are solutions such that the library ports would NOT 
> have to be aware of what used them.

You are correct, MacPorts does not work like this today. And as an example of 
something for you to think about, and not something to which I'm asking for 
answer: how would the binaries that we distribute get rebuilt under this 
hypothetical scenario?

Re: Compiling a port statically

[Ryan Schmidt]

On Dec 6, 2020, at 09:31, Riccardo Mottola wrote:

> I can think of two scenarios:
> 
> - building "always safe" binaries which can be used at system level, e.g. 
> login shells, tools, things put in launchd. That is things you want to always 
> work, even if you are during a MacPorts upgrade. NetBSD offers two packages 
> for the same thing, e.g. bash and bash-static, IIRC. perhaps in MacPorts it 
> could be a "variant"?

No, we should not offer a variant of any port to do a static build. Static 
build means all of the libraries that a program depends on are copied into the 
program executable. That means if we later update one of those libraries to a 
newer version, the statically-built program will not benefit from those fixes, 
unless its revision is increased to rebuild it, but whoever updated the library 
would not know that that needs to be done. We should not introduce more 
situations into MacPorts where developers updating library ports need to know 
about increasing the revisions of ports that use the library. Instead we should 
do the opposite, identifying those ports that only build a static library and 
fixing them so that they also or instead build a dynamic library so that ports 
that link with them can benefit from new versions without needing to be rebuilt.

Re: how change menus in openscad from Russian to English?

[Ryan Schmidt]

On Dec 6, 2020, at 16:00, Murray Eisenberg wrote:

> On 6 Dec2020, at 3:49 PM, Ryan Schmidt wrote:
>> 
>> 
>> 
>> On Dec 6, 2020, at 12:23, Murray Eisenberg wrote:
>> 
>>> I just installed the openscad port and find that nearly all its menu items 
>>> in the installed GUI OpenSCAD.app are in Russian, in which I’m rather rusty.
>>> 
>>> How can that language be changed? I tried its preferences but found no 
>>> language setting (or at least didn’t recognize a Russian word or phrase for 
>>> doing that).
>> 
>> Check the list of languages you have configured for macOS in System 
>> Preferences: Language & Region, and check what values are set in your shell 
>> for the environment variables LANG, LC_ALL, LC_MESSAGES.
> 
> In System Preferences > Languages & Region I have, in order, English, Greek, 
> and Russian as preferred (as I need the latter two for certain purposes when 
> using LaTeX).
> 
> Environment variables:
> 
>   [~] % echo $LANG
> en_US.UTF-8
>   [~] % echo $LC_ALL
> 
>   [~] % echo $LC_MESSAGES
> 
> I.e., the latter two variables are empty.
> 
> Removing Russian from the System Preferences list _does_ change the OpenScad 
> GUI’s menus to English. And then adding Russian back in, but in response to 
> prompt designating English as primary, leaves the OpenSCAD menus in English.

Ok great, then your problem is solved. This may be a gettext bug that was fixed 
in version 0.20, which we don't have in MacPorts yet. There is an open PR but 
there are some things we have to do before we can accept it.

Re: Compiling a port statically

[Ryan Schmidt]

On Dec 6, 2020, at 11:13, Richard L. Hamilton wrote:

> Of course, that also requires that every library port it depends on builds a 
> static version as well as a shared version.
> 
> So I would imagine, even given the argument in favor of limited static 
> executables, that there would be at most, very few indeed.

It is MacPorts policy that ports that can easily do so should provide both 
dynamic and static libraries. Most autotools-based build systems can do this, 
but most cmake-based build systems cannot, so as the number of projects that 
have migrated from autotools to cmake has increased, the number of ports that 
are able to provide this has decreased.


> Using MacPorts (or self-compiled) alternatives to the dropped functions of 
> macOS Server might, or might not, also be an area of concern. For myself, I'd 
> use self-built ones with no more dependencies than necessary, as similar as 
> possible to the ones Apple supplied back when they did, and strictly 
> following their suggestions for alternatives to their dropped functionality.

MacPorts now offers ports that help you replicate some of the setup that used 
to be possible with macOS Server. There is no need to introduce the distraction 
of static builds to this.

Re: Compiling a port statically

[Ryan Schmidt]

On Dec 6, 2020, at 15:27, Dave Horsfall wrote:

> On Sun, 6 Dec 2020, Riccardo Mottola via macports-users wrote:
> 
>> I can think of two scenarios [ for static binaries ]:
>> - building "always safe" binaries which can be used at system level, e.g. 
>> login shells, tools, things put in launchd. That is things you want to 
>> always work, even if you are during a MacPorts upgrade. NetBSD offers two 
>> packages for the same thing, e.g. bash and bash-static, IIRC. perhaps in 
>> MacPorts it could be a "variant"?
> 
> Agreed; FreeBSD has an "/sbin" directory (and "/usr/local/sbin") containing 
> stuff that absolutely must be available, even in the lack of absence of 
> shared libraries.

According to the FHS, sbin is for "Utilities used for system administration". 
There is no requirement, guarantee, or suggestion that they should be 
statically linked. We're not offering statically-linked programs in MacPorts.

Re: Compiling a port statically

[Ryan Schmidt]

On Dec 5, 2020, at 01:23, Ken Cunningham wrote:

> On 2020-12-04 11:07 p.m., Ryan Schmidt wrote:
>> I can't think of a reason why we would want to offer such a thing.
>> 
> You probably noticed some specifically asked how this would be done one 
> question before, which is why I volunteered this. MacPorts is quite flexible 
> for "power users".

Yes of course I saw that question. And I asked why the user needed a static 
build, and a reason was not provided.

> For me -- I have used this method to make a new replacement bash for systems 
> < 10.7, and to make a gmake binary that is self-contained to use on Tiger, 
> for my own experimentation.

Yes, since MacPorts has the facilities of the full Tcl programming language at 
its disposal it can do "anything" and what you do with your own private 
portfiles is your own business. As far as what types of portfiles MacPorts 
distributes, we should not distribute portfiles that perform static program 
builds.

Re: Compiling a port statically

[Ryan Schmidt]

On Dec 6, 2020, at 16:44, Richard L. Hamilton wrote:

> Why should that change? You don't pre-build binaries for more than a few very 
> common variants, so you wouldn't do so for static variants using such a 
> capability.

True, we only build the port's default variants (and universal, if some port 
depends on it being universal), so if the proposal is to hide this 
functionality in a "static" variant, and if we don't change the buildbot to 
build more than just the default variants, then there would not be a problem of 
how to rebuild the binaries on the buildbot.

Re: Compiling a port statically

[Ryan Schmidt]

On Dec 7, 2020, at 01:01, Jeffrey Walton wrote:

> Static linking also allows you to move binaries around the filesystem
> with dicking around with otool and install_name_tool.

Since programs are linked to libraries by their absolute path, you can move a 
program anywhere in the filesystem even if it is linked to dynamic libraries.

> Stack Overflow
> has several questions related to OS X programs that are linked to
> OpenSSL. The programs had a lot of trouble once bundled because of the
> antique version of OpenSSL supplied by Apple.

Don't see what that has to do with this thread.

Re: Compiling a port statically

[Ryan Schmidt]

On Dec 6, 2020, at 18:40, Richard L. Hamilton wrote:

> I was thinking about port mpkg or port mdmg as an alternative, but since it 
> looks like that may put its files in the same place as the MacPorts 
> installation on which it was created does, it's not practical for anything 
> except transferring e.g. a small set of ports (and with the m... variants, 
> those that they depend on) to another machine (same OS, or should later OS 
> probably work too, DEPENDING on quirks of components?) to another system on 
> which there won't be a complete MacPorts installation. Am I right about that? 
>  (see below for an OMG all the dependencies! listing of the xar mpkg file)

port pkg/dmg/mpkg/mdmg are a way to create macOS installer packages. Yes, they 
install to the same place that the ports would install, so please do not use 
port pkg/dmg/mpkg/mdmg if your prefix is /opt/local if you intend to distribute 
it to others; instead, build MacPorts in another prefix corresponding to your 
project name, such as /opt/myproject.

Ports built on one OS version very likely will work on subsequent OS versions 
but possibly without optional features that only became available on that new 
OS version.


> And to Make It Worse, I suspect ffmpeg may build with optimizations that may 
> be dependent on specific hardware (CPU instruction set extensions, etc), so 
> even aside from the possible license issues, it may not be particularly 
> portable anyway.

If so, we should fix that.

Re: Cannot install kmymoney4 due to gwenhywfar4 failure on Big Sur

[Ryan Schmidt]

On Dec 4, 2020, at 19:52, Timothy Allison wrote:

> I have been using kmymoney on my Macs for many years now.  I stupidly 
> upgraded to Big Sur a month ago, and have been paying the price with 
> kmymoney4 for about a month. 
> Now that qt4 installs, kmymoney4 fails because gwenhywfar4 fails to build.  
> The log file contains 3 errors: 
> :info:build libtest.m:57:2: error: implicit declaration of function 'test1' 
> is invalid in C99 [-Werror,-Wimplicit-function-declaration]:info:build
>  test1();:info:build ^:info:build libtest.m:88:6: error: implicit 
> declaration of function 'Cocoa_Gui_new' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]:info:build 
> gui=Cocoa_Gui_new();:info:build ^:info:build libtest.m:88:5: 
> warning: incompatible integer to pointer conversion assigning to 'GWEN_GUI *' 
> (aka 'struct GWEN_GUI *') from 'int' [-Wint-conversion]:info:build 
> gui=Cocoa_Gui_new();:info:build^~~~:info:build 
> libtest.m:93:6: error: implicit declaration of function 'Dlg_Test1_new' is 
> invalid in C99 [-Werror,-Wimplicit-function-declaration]:info:build 
> dlg=Dlg_Test1_new();:info:build ^ 
> 
> Unlike qt4-mac, I haven’t found any MacPorts tickets on this issue.  Is there 
> a workaround?  I’d really like to go back to kmymoney, and a month is a long 
> time to wait.

Each instance of implicit function declarations needs to be fixed individually. 
If there is not a ticket for the port with which you're seeing a failure, 
please file one.

Re: info

[Ryan Schmidt]

On Dec 4, 2020, at 09:18, Alejandro Imass wrote:

> quick question: is Apple using more or less the same stack and toolchain i.e. 
> Mach + FBSD backbone and LLVM, etc. ? or has something very important changed 
> for Apple silicon?

The very important thing that has changed is that Apple Silicon is arm64 
architecture. Many existing ports have build systems that assume Macs don't use 
arm64 architecture and fail to build as a result. These will need to be 
identified and fixed, hopefully in consultation with the developers of the 
software.

The OS kernel is still Mach, the userland software is still largely BSD based, 
LLVM is still used as the compiler, on macOS 11 on any architecture, just as it 
was on macOS 10.x for a long time.

I hear the process of booting the operating system is quite different on Apple 
Silicon: it's more similar to how iOS devices boot. But these are details that 
do not affect us in MacPorts since we deal only in user installable software.

Re: Cannot install kmymoney4 due to gwenhywfar4 failure on Big Sur

[Ryan Schmidt]

On Dec 4, 2020, at 20:24, Jeffrey Walton wrote:

> On Fri, Dec 4, 2020 at 8:53 PM Timothy Allison wrote:
>> 
>> I have been using kmymoney on my Macs for many years now.  I stupidly 
>> upgraded to Big Sur a month ago, and have been paying the price with 
>> kmymoney4 for about a month.
>> Now that qt4 installs, kmymoney4 fails because gwenhywfar4 fails to build.  
>> The log file contains 3 errors:
>> :info:build libtest.m:57:2: error: implicit declaration of function 'test1' 
>> is invalid in C99 [-Werror,-Wimplicit-function-declaration]:info:build   
>>   test1();:info:build ^:info:build libtest.m:88:6: error: implicit 
>> declaration of function 'Cocoa_Gui_new' is invalid in C99 
>> [-Werror,-Wimplicit-function-declaration]:info:build 
>> gui=Cocoa_Gui_new();:info:build ^:info:build libtest.m:88:5: 
>> warning: incompatible integer to pointer conversion assigning to 'GWEN_GUI 
>> *' (aka 'struct GWEN_GUI *') from 'int' [-Wint-conversion]:info:build
>>  gui=Cocoa_Gui_new();:info:build^~~~:info:build 
>> libtest.m:93:6: error: implicit declaration of function 'Dlg_Test1_new' is 
>> invalid in C99 [-Werror,-Wimplicit-function-declaration]:info:build 
>> dlg=Dlg_Test1_new();:info:build ^
>> 
>> Unlike qt4-mac, I haven’t found any MacPorts tickets on this issue.  Is 
>> there a workaround?  I’d really like to go back to kmymoney, and a month is 
>> a long time to wait.
> 
> After you configure, run the following script before running make.
> 
> IFS="" find "./" -iname 'Makefile' -print | while read -r file
> do
> 
>touch -a -m -r "$file" "$file.timestamp"
>chmod a+w "$file"
>sed -e "s/-Werror//g" "$file" > "$file.fixed" && \
>mv "$file.fixed" "$file"
> 
>chmod a-w "$file"
>touch -a -m -r "$file.timestamp" "$file"
>rm "$file.timestamp"
> done

Dunno what you're suggesting here, but it's not the correct fix. The correct 
fix is to fix the implicit function declarations, which I've explained at 
length in an email on macports-dev.

Re: info

[Ryan Schmidt]

On Dec 4, 2020, at 21:32, Ken Cunningham wrote:

> On 2020-12-04 6:56 p.m., Ryan Schmidt wrote:
>> The reason for this is that ports.macports.org only shows status for ports 
>> that were built directly. It does not show status for ports that were built 
>> indirectly
> 
> 
> Hah! We should certainly prioritize that deficiency for fixing... I had no 
> idea that it worked like that.

It's not easy to fix with the way it currently works. Currently 
ports.macports.org takes the status information from each build on 
build.macports.org. Each build is for a port. But if that port's dependencies 
weren't already built, they will be built as well, but there is no way in the 
buildbot API to ask which of the dependencies needed to be built (vs. which 
were already built) nor whether that build succeeded or failed.

This is probably a topic we should revisit after we have upgraded to buildbot 
2. Trying to fix it now would just make more work for us as we try to convert 
to buildbot 2.

Re: More old upgrade issues (was: Re: Libgcc: new version won't deactivate the old version)

[Ryan Schmidt]

> On Dec 4, 2020, at 21:19, Michael wrote:
> 
>> Error: Can't install oniguruma6 because conflicting ports are active: 
>> oniguruma5
>> Error: Problem while installing oniguruma6
>> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
>> bash-3.2# 
> 
> What is "Oniguruma", and what do I need to worry about here?
> 
>> Description:  Oniguruma is a regular expressions library in which 
>> different character encoding can be specified for every expression. Supports 
>> Unicode Porperty/Script.

You've answered your own question about what it is.

You have oniguruma5 installed and are now trying to install oniguruma6, and you 
can't do that because they conflict.

Since you are asking about it, I assume you did not deliberately install 
oniguruma but that it was installed for you as a dependency of another port, 
and that that other port has switched from 5 to 6 since the last time you 
updated. You may need to deactivate oniguruma5 to proceed with the upgrade, 
assuming it is not needed by any other ports. See 
https://trac.macports.org/ticket/60788. 

> ... does this mean that the normal RE libraries assume a single encoding for 
> everything? Like if you work with UTF-8 text, you can't then use windows- or 
> UTF-16 text encodings without restarting the program?

Don't know. Just because oniguruma advertises that it offers a feature does not 
mean that no other software also offers that feature.

Re: Compiling a port statically

[Ryan Schmidt]

On Dec 5, 2020, at 00:09, Ken Cunningham wrote:

> There was a nice tweak put forth by -- I think it was Bill Cole -- to link a 
> port statically. I used it for bash and gmake, but the idea might work for 
> other ports too.
> 
> 
> See 
> 
>  for an idea how it works.
> 
> 
> Obviously the block would need some tweaking for a given port, it gives the 
> idea.

I can't think of a reason why we would want to offer such a thing.

Re: Libgcc: new version won't deactivate the old version

[Ryan Schmidt]

On Dec 4, 2020, at 02:58, Christopher Jones wrote:

> On 4 Dec 2020, at 2:36 am, Michael wrote:
> 
>>> --->  Computing dependencies for libgcc
>>> The following dependencies will be installed:  libgcc10
>>> Continue? [Y/n]: y
>>> --->  Activating libgcc10 @10.2.0_3
>>> Error: Failed to activate libgcc10: Image error: 
>>> /opt/local/include/gcc/c++/algorithm is being used by the active libgcc 
>>> port.  Please deactivate this port first, or use 'port -f activate 
>>> libgcc10' to force the activation.
>> 
>> Is there a reason that trying to activate the new libgcc does not deactivate 
>> the old libgcc?
>> 
> 
> 
> That particular message can only occur if you have not updated your ports in 
> a very long time, as the change that made libgcc a stub port happened several 
> years ago now If you don’t update regularly you can run into issues like 
> this.
> 
> In this case, just follow the instructions as given and force deactivate.

Well, yes, deactivate libgcc, but do not run the command mentioned in the error 
message which would force activate libgcc10.

Re: Cannot install kmymoney4 due to gwenhywfar4 failure on Big Sur

[Ryan Schmidt]

On Dec 4, 2020, at 20:27, Jeffrey Walton wrote:

> On Fri, Dec 4, 2020 at 9:26 PM Ryan Schmidt wrote:
> 
>> On Dec 4, 2020, at 20:24, Jeffrey Walton wrote:
>> 
>>> On Fri, Dec 4, 2020 at 8:53 PM Timothy Allison wrote:
>>>> 
>>>> I have been using kmymoney on my Macs for many years now.  I stupidly 
>>>> upgraded to Big Sur a month ago, and have been paying the price with 
>>>> kmymoney4 for about a month.
>>>> Now that qt4 installs, kmymoney4 fails because gwenhywfar4 fails to build. 
>>>>  The log file contains 3 errors:
>>>> :info:build libtest.m:57:2: error: implicit declaration of function 
>>>> 'test1' is invalid in C99 
>>>> [-Werror,-Wimplicit-function-declaration]:info:build 
>>>> test1();:info:build ^:info:build libtest.m:88:6: error: implicit 
>>>> declaration of function 'Cocoa_Gui_new' is invalid in C99 
>>>> [-Werror,-Wimplicit-function-declaration]:info:build 
>>>> gui=Cocoa_Gui_new();:info:build ^:info:build libtest.m:88:5: 
>>>> warning: incompatible integer to pointer conversion assigning to 'GWEN_GUI 
>>>> *' (aka 'struct GWEN_GUI *') from 'int' [-Wint-conversion]:info:build  
>>>>gui=Cocoa_Gui_new();:info:build^~~~:info:build 
>>>> libtest.m:93:6: error: implicit declaration of function 'Dlg_Test1_new' is 
>>>> invalid in C99 [-Werror,-Wimplicit-function-declaration]:info:build
>>>>  dlg=Dlg_Test1_new();:info:build ^
>>>> 
>>>> Unlike qt4-mac, I haven’t found any MacPorts tickets on this issue.  Is 
>>>> there a workaround?  I’d really like to go back to kmymoney, and a month 
>>>> is a long time to wait.
>>> 
>>> After you configure, run the following script before running make.
>>> 
>>> IFS="" find "./" -iname 'Makefile' -print | while read -r file
>>> do
>>> 
>>>   touch -a -m -r "$file" "$file.timestamp"
>>>   chmod a+w "$file"
>>>   sed -e "s/-Werror//g" "$file" > "$file.fixed" && \
>>>   mv "$file.fixed" "$file"
>>> 
>>>   chmod a-w "$file"
>>>   touch -a -m -r "$file.timestamp" "$file"
>>>   rm "$file.timestamp"
>>> done
>> 
>> Dunno what you're suggesting here, but it's not the correct fix.
> 
> The script above removes the DoS the user is currently suffering.

It looks like the script removes "-Werror" from any Makefile. The problem the 
user is experiencing is not the result of any "-Werror" in any Makefile; 
rather, it is the result of the fact that Apple changed implicit declaration of 
functions from a warning to an error in Xcode 12. The fix is not to attempt to 
turn the error back into a warning again. The fix is to define functions before 
you use them.

Re: info

[Ryan Schmidt]

On Dec 4, 2020, at 15:50, Mojca Miklavec wrote:
> 
> You should be able to install MacPorts and many ports. But you should
> not be surprised if you hit some that will refuse to build and you may
> need to wait for upstream to fix the issue (or try to fix it yourself
> and submit a patch or find someone else capable of fixing it ...).
> 
> You brought up an interesting point though, we should probably publish
> some official statement about arm support on our main website.

I don't think our statement would be very different from our stance with any 
other new Apple product release, be it a new OS version or a new Xcode version: 
probably some things are broken as a result and need to be fixed as the 
problems are identified.


> A lot of relatively simple, well-written software with a well-written
> build system should often work out of the box.

Yes and no. Autotools is one of the oldest and still most widely used build 
systems, yet until automake 1.16.3 which was just released a couple weeks ago 
it misidentified Apple Silicon systems, so any port whose build system was 
built with automake 1.16.2 or earlier may need to be autoreconfed to build 
properly on Apple Silicon. libtool, which many autotools projects use, 
misidentifies macOS 11 and later. Developers have not yet acknowledged the 
problem, much less accepted our patch, so any software using autotools and 
libtool and relying on undefined symbols being resolved at runtime will fail to 
build on macOS 11 and will need to be either autoreconfed or patched or have 
the deployment target set to 10.16. And then there's the implicit function 
declaration problem biting lots of projects as of Xcode 12. Apple Silicon 
systems are affected by all three issues, so in my opinion we have never had a 
time in MacPorts history when more ports were broken at one time on a new 
system than we have now. My recommendation continues to be if you want MacPorts 
to work smoothly then do not upgrade to Xcode 12, do not upgrade to macOS 11, 
and do not buy an Apple Silicon Mac. Or, if you do upgrade, be prepared to help 
us resolve the issues you will inevitably encounter. Filing bug reports about 
what's broken is a great start but we have a zillion open tickets already. What 
we really need is for people to read those tickets and submit pull requests to 
fix them properly.


> But a lot of software may either have some hard-coded assumptions in
> either their build system or the source, it may require some
> intel-specific intrinsics, or it may depend on some complex
> third-party library that doesn't compile. Apple also likes to increase
> security standards each year which may break many ports in various
> ways.

Yup, there are limitless ways that individual software packages could have done 
it wrong in a way that doesn't work on Apple Silicon, above and beyond the big 
three above.


> If you have your favourite port, you can quickly check the build
> results on, say,
>https://ports.macports.org/port/wget/stats
> and check for either green port status or some reported installations
> on arm64, check for open tickets etc. Keep in mind that many port
> builds haven't been attempted yet.
> 
> (I also see that some builds like wget were successful, but missing on
> the list, while some like youtube-dl are redirected to the x86_64
> builder and also don't end up on that list.)

On Dec 4, 2020, at 17:34, Ken Cunningham wrote:

> Go here  and enter your favourite port.
> 
> eg:
> 
> 
> 
> by the way, a “grey” box means untested as yet, not failing.

But please understand that the information on ports.macports.org is not 
authoritative or complete.

A grey box does not mean untested. It means no information is available. Grey 
means we might have built the port and it succeeded or failed, or we might not 
have built the port yet.

Similarly, green or red does not guarantee that the most recent build succeeded 
or failed. It just means that the most recent build *for which data was sent to 
ports.macports.org* succeeded or failed. There may have been a more recent 
build with a different status but which is not shown on the web site.

The reason for this is that ports.macports.org only shows status for ports that 
were built directly. It does not show status for ports that were built 
indirectly, for example as a dependency of another port. This situation is most 
likely to arise when we first start building packages for a particular os/arch, 
and happens less often after everything has been built once.

Authoritative information is the directory listings of 
https://packages.macports.org. If there is a file, the build succeeded. If 
there is not a file, then the build either did not succeed or was not attempted 
or did succeed but the file is not legally distributable.

Re: Cannot install kmymoney4 due to gwenhywfar4 failure on Big Sur

[Ryan Schmidt]

> On Dec 4, 2020, at 20:51, Jeffrey Walton wrote:
> 
> On Fri, Dec 4, 2020 at 9:38 PM Ryan Schmidt wrote:
>> 
>> On Dec 4, 2020, at 20:27, Jeffrey Walton wrote:
>> 
>>> On Fri, Dec 4, 2020 at 9:26 PM Ryan Schmidt wrote:
>>> 
>>>> On Dec 4, 2020, at 20:24, Jeffrey Walton wrote:
>>>> 
>>>>> On Fri, Dec 4, 2020 at 8:53 PM Timothy Allison wrote:
>>>>>> 
>>>>>> I have been using kmymoney on my Macs for many years now.  I stupidly 
>>>>>> upgraded to Big Sur a month ago, and have been paying the price with 
>>>>>> kmymoney4 for about a month.
>>>>>> Now that qt4 installs, kmymoney4 fails because gwenhywfar4 fails to 
>>>>>> build.  The log file contains 3 errors:
>>>>>> :info:build libtest.m:57:2: error: implicit declaration of function 
>>>>>> 'test1' is invalid in C99 
>>>>>> [-Werror,-Wimplicit-function-declaration]:info:build 
>>>>>> test1();:info:build ^:info:build libtest.m:88:6: error: implicit 
>>>>>> declaration of function 'Cocoa_Gui_new' is invalid in C99 
>>>>>> [-Werror,-Wimplicit-function-declaration]:info:build 
>>>>>> gui=Cocoa_Gui_new();:info:build ^:info:build libtest.m:88:5: 
>>>>>> warning: incompatible integer to pointer conversion assigning to 
>>>>>> 'GWEN_GUI *' (aka 'struct GWEN_GUI *') from 'int' 
>>>>>> [-Wint-conversion]:info:build gui=Cocoa_Gui_new();:info:build
>>>>>> ^~~~:info:build libtest.m:93:6: error: implicit 
>>>>>> declaration of function 'Dlg_Test1_new' is invalid in C99 
>>>>>> [-Werror,-Wimplicit-function-declaration]:info:build 
>>>>>> dlg=Dlg_Test1_new();:info:build ^
>>>>>> 
>>>>>> Unlike qt4-mac, I haven’t found any MacPorts tickets on this issue.  Is 
>>>>>> there a workaround?  I’d really like to go back to kmymoney, and a month 
>>>>>> is a long time to wait.
>>>>> 
>>>>> After you configure, run the following script before running make.
>>>>> 
>>>>> IFS="" find "./" -iname 'Makefile' -print | while read -r file
>>>>> do
>>>>> 
>>>>>  touch -a -m -r "$file" "$file.timestamp"
>>>>>  chmod a+w "$file"
>>>>>  sed -e "s/-Werror//g" "$file" > "$file.fixed" && \
>>>>>  mv "$file.fixed" "$file"
>>>>> 
>>>>>  chmod a-w "$file"
>>>>>  touch -a -m -r "$file.timestamp" "$file"
>>>>>  rm "$file.timestamp"
>>>>> done
>>>> 
>>>> Dunno what you're suggesting here, but it's not the correct fix.
>>> 
>>> The script above removes the DoS the user is currently suffering.
>> 
>> It looks like the script removes "-Werror" from any Makefile. The problem 
>> the user is experiencing is not the result of any "-Werror" in any Makefile; 
>> rather, it is the result of the fact that Apple changed implicit declaration 
>> of functions from a warning to an error in Xcode 12. The fix is not to 
>> attempt to turn the error back into a warning again. The fix is to define 
>> functions before you use them.
> 
> The user does not care what the developer's fix is. He just wants the
> DoS gone so he can use his software.

Your suggestion will not fix the user's issue.

Re: info

[Ryan Schmidt]

On Dec 4, 2020, at 21:09, Richard L. Hamilton wrote:

> If there was a port-level view of how the buildbots are doing (maybe there is 
> and I haven't found it?) that might come close.

There is no such feature at this time.

> But from what little I figured out looking at the buildbot pages, it looks 
> like something is failing in an early dependency for arm64.

That is very likely. There are a zillion ports failing to build on Apple 
Silicon and macOS 11 and Xcode 12 for numerous reasons as previously discussed. 
Help wanted.

Re: Compile ffmpeg static file from Macports?

[Ryan Schmidt]

On Dec 3, 2020, at 11:44, K Hindall wrote:

> I have never been a coder, which is why I have Macports.
> 
> Now I need a static ffmpeg file (to run ff·Works, thereby proving that I am 
> not a coder!). I know that Macports uses dynamic libraries rather than static 
> ones and somehow that complicates the process, but ... that's as far as my 
> understanding goes.
> 
> I would need either a port that would do it for me or *very* precise 
> instructions on how to do it.
> 
> Does anyone know of either? I've poked around on the Web, but haven't found 
> anything that I can make sense of.

So you would like an ffmpeg program that is statically linked to all of the 
libraries that it depends on, rather than dynamically? We don't and wouldn't 
offer that in MacPorts.

Why do you need this? I haven't heard of ff·Works, but why would it need a 
statically linked ffmpeg? Why can't it use our dynamically-linked ffmpeg? Why 
would it care?

Re: info

[Ryan Schmidt]

On Dec 4, 2020, at 16:00, James Secan wrote:

> I think a large number of us are very interested in the status of ports 
> vis-a-vis both Apple Silicon (M1) and Big Sur.  Some sort of simple 
> red-yellow-green status board for ports that have been checked would be very 
> useful.

Unfortunately that information is not reliably available for now.

> Verified support for the MacPorts codes I use regularly is a major check-box 
> on my buy-now list for a new M1 machine.  I suspect this is more easily 
> visualized than actually produced and maintained.

Feel free to give us a list of the ports that are important to you and we can 
try to find out and/or schedule builds of those ports on our Apple Silicon 
build machine and see what happens.

Re: Removing all non-requested ports?

[Ryan Schmidt]

On Dec 4, 2020, at 08:58, Jonathan Stickel wrote:

> I'm not sure why `reclaim` doesn't provide such an option.

Because nobody has contributed the code to implement it.

https://trac.macports.org/ticket/60754

Re: Running X11 in MacOS-window-as-X11-display mode?

[Ryan Schmidt]

On Dec 8, 2020, at 02:42, Ken Preslan wrote:

> On Mon, Dec 07, 2020 at 03:41:57PM -0500, Justin Vallon wrote:
>> I currently use a VNC server on a debian machine, and a VNC client on my
>> Mac.  I am trying to configure my Mac to run the Xserver/VNC server so that
>> I don't need to remote-connect to my Linux host.
> 
> Before Catalina, I was a big XQuartz user.

Do you mean you were actually using the installer from xquartz.org? If so, you 
should switch to the corresponding ports provided by MacPorts. The xorg-server 
port contains X11.app, for example. The installer from xquartz.org hasn't been 
updated in four years, while our ports are updated all the time.

> Performance and compatibility 
> got so bad in Catalina that I switched to exactly what you're doing now.

I haven't heard of performance or compatibility problems with X11 on macOS 
Catalina. If you're seeing this with the software from xquartz.org, switch to 
the MacPorts ports. If you're seeing this problem with the MacPorts ports, file 
bug reports.

Re: Running X11 in MacOS-window-as-X11-display mode?

[Ryan Schmidt]

On Dec 8, 2020, at 23:44, Ken Preslan wrote:

> My main problem was performance.  In the Mojave time-frame the xorg server 
> was updated from 1.18 to 1.20.  Performance for xterm scrolling tanked.  It 
> was unusable.  I complained on macports-users on April 1st 2019.  There was a 
> thread about it and Christopher Jones created a xorg-server-1.18 port, which 
> made things better for me.

Oh yes I do remember that. I've stayed on High Sierra so I haven't seen these 
problem myself.


> When I upgrade to Catalina, the xorg-server-1.18 port stopped working.

I don't see any open tickets about xorg-server-1.18.

Re: macports-users Digest, Vol 172, Issue 7

[Ryan Schmidt]

On Dec 8, 2020, at 07:54, James Linder wrote:

> Sorry about the subject line: macports is my only digest mail and I keep 
> forgetting :-(

Note that just changing the subject line of your reply to match the thread's 
subject is not enough to preserve threading. You would also have to use the 
correct In-Reply-To header. If you wish to reply to messages, it is best not to 
subscribe in digest mode.

Re: local *single* Portfile

[Ryan Schmidt]

On Dec 7, 2020, at 13:56, Dominik Reichardt wrote:

> Thank you, that helps the first step, but does it need to be a patch with 
> source in the net, or can I manage this with local source as well?

You can put a patchfile in a "files" directory (in the same directory as the 
Portfile) (this is what we usually do), or you can have MacPorts download it 
from a URL (set in patch_files). If you have MacPorts download the file, the 
file's checksums must be specified.

Re: MacPorts on Apple Silicon Macs (was: Re: info)

[Ryan Schmidt]

On Nov 27, 2020, at 09:15, Giovanni Cantele wrote:

> is there any ongoing project for porting the whole macports staff on the new 
> Apple silicon architecture?
> What happens to those who extensively make use of macports and have bought 
> the recent released MacBook Pro running on the new processors?

Right now we have probably thousands ports that are broken due to three 
different issues, and Apple Silicon machines are affected by all three issues:

1. Xcode 12 makes implicit declaration of functions an error instead of a 
warning. Apple made this change in order to prevent problems that would 
otherwise occur on Apple Silicon machines but it will take a long time before 
either we or the developers of the software patch all of our ports to 
accommodate this change. Instructions for developers wishing to help fix these 
problems are here: 
https://lists.macports.org/pipermail/macports-dev/2020-November/042647.html and 
in my follow-up to that message.

2. macOS Big Sur is version 11, and a lot of software did not anticipate that 
such a version number of macOS would ever exist and fail to build as a result. 
All software that uses autotools and libtool and relies on the use of symbols 
that are undefined at build time is affected, for example, but there are 
limitless other ways that developers could have and did write their software so 
that it would only work on macOS 10.x. The libtool issue may have a simple fix 
that we could use: https://trac.macports.org/ticket/61584 but we have not 
employed that yet.

3. Many ports fail to build on Apple Silicon machines for a variety of other 
reasons which we will need to investigate and fix as we encounter them one by 
one.

MacPorts volunteers are working with the developers of the affected software to 
fix it and fix our ports as time permits. You or anyone interested can help by 
reporting bugs, either to us in the case of ancient software or to the 
developers of the software if it is still being developed, or by fixing the 
problem and sending us or the developers the fix. We have tens of thousands of 
ports in MacPorts and it's not always clear to us which ones people use. By 
filing a bug report about a port or Cc'ing yourself on an existing report about 
a problem, you can help us identify which problems we need to focus on fixing.

I previously advised that if you want to avoid issues with MacPorts ports while 
we try to work this all out, don't upgrade to Big Sur yet. See 
https://lists.macports.org/pipermail/macports-users/2020-November/048940.html. 
I would also advise not upgrading to Xcode 12 yet on Catalina. Since Apple 
Silicon Macs require Big Sur and Xcode 12.2, my recommendation extends to not 
buying an Apple Silicon Mac yet, despite how fantastic I'm sure they will be.

Re: Migration doc suggestion - chsh

[Ryan Schmidt]

On Nov 27, 2020, at 15:50, Kevin Horton wrote:

> I'm apparently a slow learner, but once again I forgot to change my login 
> shell back to one supplied by Apple before migrating to Big Sur (I had been 
> using.
> 
> Suggestion - add a step to the Migration docs, before the step that removes 
> all ports.  If the user is using a default shell provided by Macports, do a 
> 'chsh -s /bin/bash' (or other Apple supplied shell) before removing all ports.

The wiki can be edited by anyone.

Re: Port Application Issues (Launching Issues)

[Ryan Schmidt]

On Nov 27, 2020, at 18:25, Riccardo Mottola wrote:

> However, only native Cocoa apps wil install an .app bundle inside the 
> MacPorts folder. E.g. emacs, gimp do that if they are compiled in the 
> "+quartz" variant. Other apps if not Mac native will have their own launch 
> method which will not be as straight-forward.

There are some ports that install app bundles in the /Applications/MacPorts 
folder even though they are not native Cocoa apps. These app bundles are 
intended as a convenience that can be used to launch applications from the 
Finder, Dock, LaunchPad, Spotlight, etc., but other than that they don't behave 
like normal Mac apps. For example, dragging a document icon to it won't open it 
into the application, the application icon may continue bouncing in the Dock 
after the app is launched, clicking the icon in the Dock after the app is 
launched won't switch to the app, etc.

Usually though, software that is not a native Mac Cocoa app will not have an 
app bundle in /Applications/MacPorts and you'll usually run it from the 
terminal. The "port contents" command tells you what was installed and where so 
that you know what to run.

Re: MacPorts on Apple Silicon Macs (was: Re: info)

[Ryan Schmidt]

On Nov 28, 2020, at 08:32, Joshua Root wrote:

> Ryan Schmidt wrote:
>> We have tens of thousands of ports in MacPorts and it's not always clear to 
>> us which ones people use.
> 
> That at least can be easily remedied by installing the mpstats port. You
> should still file a ticket if something is broken (and there isn't an
> existing ticket) of course.
> 
> The stats naturally have their limitations, but mpstats is an easy and
> effective way of letting us know which ports matter to you.

Yes. But when I am looking at bug reports on Trac or build failures on the 
Buildbot, there is no easy way for me to see the associated stats for that 
port, and even if I look up the stats manually, I must admit I'm not really 
sure how to interpret the results. An issue doesn't always affect every user 
who installs a port.

On the other hand, if we get a bug report that has 20 people Cc'd on it, that 
makes it clear that many people are experiencing that specific issue and that 
it would help many people if we fix it.

Re: Problem installing php73-zip

[Ryan Schmidt]

On Nov 23, 2020, at 21:27, Jeff Greenberg wrote:

> :debug:archivefetch openssl output: couldn't create error file for command: 
> permission denied

This message has been seen a few times before and a common cause seems to be 
that your tmp directory does not have the right permissions. See:

https://trac.macports.org/ticket/50867

Restarting the computer could fix the tmp directory's permissions or you may 
need to fix them manually.

Re: rebuild a package without an update

[Ryan Schmidt]

On Nov 29, 2020, at 06:24, Riccardo Mottola wrote:

> On 2020-11-17 00:30:33 +0000 Ryan Schmidt wrote:
> 
>> On Nov 16, 2020, at 17:58, Riccardo Mottola wrote:
> 
>>> Here were are in the situation that if, for some upstream reason, libxml2 
>>> stops compiling with gcc 4.2, the user has no workaround and is stuck in an 
>>> endless dependency.
>> If such a situation were to arise, then indeed we would want to do something 
>> about it. We do have automated build machines for Mac OS X 10.6 and later so 
>> if such a situation did arise we would probably notice it on the build 
>> machines. As far as I know, we do not have such a situation at present.
> 
> No, luckily we don't - some packages still compile with Apple system.
> 
> The only issue is that to do that build of libxml2 successfully, I had to 
> deactivate all clang compilers. Something similar I had to do more recently 
> to compile gcc48 and gcc6, although coming from a different error).

Then we may have a bug that needs to be fixed, because you're not supposed to 
need to do that.


> Maybe a 10.5 autobuilder wouldn't be a bad idea, 32bit.

We used to have a 10.5 PowerPC builder but the hardware failed. I may revive it 
some day. We have never had a 10.5 Intel builder because all Intel Macs can and 
should be upgraded to Snow Leopard or later. I have no plans to add a 10.5 
Intel builder at this time.

Re: YouTube-DL is no more

[Ryan Schmidt]

On Dec 18, 2020, at 13:32, DaveC wrote:

> The primary failure yesterday of youtube-dl gave this verbose output.
> 
> Dave
> - - -
> Daves-Mac-mini:~ davec$ youtube-dl -v -x 
> https://www.youtube.com/watch?v=RXawa90YU2s
> [debug] System config: []
> [debug] User config: ['--output', '~/Downloads/youtube-dl/%(title)s.%(ext)s']
> [debug] Custom config: []
> [debug] Command-line args: ['-v', '-x', 
> 'https://www.youtube.com/watch?v=RXawa90YU2s']
> [debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
> [debug] youtube-dl version 2020.05.08
> [debug] Python version 3.6.10 (CPython) - Darwin-16.7.0-x86_64-i386-64bit
> [debug] exe versions: ffmpeg 4.2.4, ffprobe 4.2.4
> [debug] Proxy map: {}
> [youtube] RXawa90YU2s: Downloading webpage
> ERROR: RXawa90YU2s: YouTube said: Unable to extract video data
> Traceback (most recent call last):
>  File "/opt/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 797, in 
> extract_info
>ie_result = ie.extract(url)
>  File "/opt/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 530, 
> in extract
>ie_result = self._real_extract(url)
>  File "/opt/local/bin/youtube-dl/youtube_dl/extractor/youtube.py", line 1820, 
> in _real_extract
>'YouTube said: %s' % unavailable_message, expected=True, video_id=video_id)
> youtube_dl.utils.ExtractorError: RXawa90YU2s: YouTube said: Unable to extract 
> video data

Not surprising, since your youtube-dl version was 7 months old (2020.05.08). An 
update 5 months ago was needed to restore the ability to extract from YouTube:

https://trac.macports.org/ticket/60915

Re: YouTube-DL is no more

[Ryan Schmidt]

On Dec 18, 2020, at 14:28, Clemens Lang wrote:

>> 2. Next time(?) I update MP I presume YouTube-dl won’t update. Will it
>> be removed? Will it no longer work? Is there a way to keep the port I
>> have currently functioning?
> 
> MacPorts mirrors the upstream files, so even if youtube-dl were removed
> from GitHub, the port would continue to work.

Even if we were to remove a port from MacPorts, if you had installed it, you 
would continue to have it installed until you decide to uninstall it, either 
explicitly with `sudo port uninstall youtube-dl` or by running cleanup 
operations like `sudo port reclaim`. But what Clemens said is true: software 
bitrots over time, so even if a port works today, especially a port that 
communicates with services over the network, that doesn't guarantee that it 
will work tomorrow. Similarly, software that works with today's version of 
macOS and the versions of the libraries it depends on that are in MacPorts 
today, that doesn't guarantee that an update to the OS or Xcode or the 
libraries it needs won't break it in the future.

> Additionally, the
> youtube-dl source code was always available from youtube-dl.org, so even
> if the GitHub repository would not have been restored, we would just
> have switched the port to use that source instead.

At the time that the DMCA takedown request was issued, the youtube-dl web site 
was hosted on GitHub Pages, so it got taken down as well, and the source code 
was only hosted on GitHub Releases, so it was not available there either, 
though it continued to be available from the MacPorts distfile mirrors. They 
then moved to a different web host to restore the web site and added the source 
code download to the web site. During that time, the youtube-dl port was 
switched to download from that web site. Now that the GitHub repo has been 
restored, the port has switched back to downloading from GitHub.

Our ticket tracking the situation was https://trac.macports.org/ticket/61369

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

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: rebuild a package without an update

[Ryan Schmidt]

On Nov 7, 2020, at 12:46, Riccardo Mottola wrote:

> I need to rebuild a package which is not working due to a dependency upgrde. 
> revdep "catches" it but revdep fails to build it because it uses the wrong 
> compiler and I need to force it (also because the compiler itself is broken 
> because it is broken because the library is broken)
> 
> I usually in these cases just run "port upgrade  configure.compiler=xxx" 
> but in this case there is nothing to upgrade, I need to rebuild in place.
> 
> How can I do?

This situation should not arise. But: you can force a rebuild of a port using:

sudo port -ns upgrade --force theportname

and add whatever extra variables you want to set after that.

Re: Issues with MacPorts migration from 10.12.6 Sierra to 10.14.6 Mojave

[Ryan Schmidt]

On Nov 9, 2020, at 16:51, Greg Earle wrote:

> On 7 Nov 2020, at 1:43 AM, Ryan Schmidt wrote:
> 
>> Do what it says and clean the affected ports.
>> 
>> sudo port clean expat
>> 
>> sudo port clean db48
> 
> Thanks Ryan.  That just pushed it down the road a bit, I kept getting other 
> errors like these.  I ended up doing a
> 
> sudo port clean all
> 
> and those particular errors stopped.
> 
> I am scratching my head though - I was running things from scratch with no 
> ports installed, so I don't know why the "./restore_ports.tcl myports.txt" 
> stage would generate a bunch of errors where a port needed to be "cleaned".

When you say "from scratch" do you mean that you really removed the /opt/local 
directory entirely? The normal migration steps do not include doing that, nor 
is it recommended or required. But keeping that directory does imply that 
you'll be keeping any partial build attempts that you may have had in 
/opt/local/var/macports/build. You can of course remove them if desired, either 
manually or by cleaning the affected ports, or cleaning all. In MacPorts 2.7.0, 
port reclaim will also clean this for you.


> One last side question: in the
> 
> port echo requested | cut -d ' ' -f 1 > requested.txt
> 
> step, I found that several lines in the resulting "requested.txt" file were 
> repeated.  Should this command be
> 
> port echo requested | cut -d ' ' -f 1 | sort | uniq > requested.txt
> 
> instead?

That sounds like a good change to make.


> --->  Building db48
> Error: Failed to build db48: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_private_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_db48/db48/main.log
>  for details.

Can't tell why without seeing the log.


> --->  Fetching archive for db53
> --->  Attempting to fetch db53-5.3.28_0+java+sql.darwin_18.x86_64.tbz2 from 
> https://cph.dk.packages.macports.org/db53
> --->  Attempting to fetch db53-5.3.28_0+java+sql.darwin_18.x86_64.tbz2 from 
> https://nue.de.packages.macports.org/db53
> --->  Attempting to fetch db53-5.3.28_0+java+sql.darwin_18.x86_64.tbz2 from 
> https://packages.macports.org/db53
> --->  Configuring db53
> Error: db53 requires the Java for Mac OS X development headers.
> Error: Make sure your Xcode installation is complete.

Install Java.


> --->  Configuring tripwire
> Error: Failed to configure tripwire, consult 
> /private/opt/local/var/macports/build/_private_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_security_tripwire/tripwire/work/tripwire-2.4.2.2-src/config.log
> Error: Failed to configure tripwire: configure failure: command execution 
> failed
> Error: See 
> /opt/local/var/macports/logs/_private_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_security_tripwire/tripwire/main.log
>  for details.

Can't tell without seeing the logs.


> --->  Computing dependencies for nodejs10
> Error: Can't install nodejs10 because conflicting ports are active: nodejs14

The various node versions conflict with one another. Pick the single version 
that you want.


> --->  Fetching distfiles for wine
> Error: wine cannot be built on macOS 10.14 or later.
> Error: Failed to fetch wine: incompatible macOS version
> Error: See 
> /opt/local/var/macports/logs/_private_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_wine/wine/main.log
>  for details.

The message is accurate. There will be an update to allow wine to be built on 
10.14 and later.


> --->  Computing dependencies for qt513-qtbase
> Error: Can't install qt513-qtbase because conflicting ports are active: 
> qt5-qtbase
> --->  Computing dependencies for qt513-qtmacextras
> Error: Can't install qt513-qtmacextras because conflicting ports are active: 
> qt5-qtbase
> --->  Computing dependencies for qt513-qtsvg
> Error: Can't install qt513-qtsvg because conflicting ports are active: 
> qt5-qtbase
> --->  Computing dependencies for qt513-sqlite-plugin
> Error: Can't install qt513-sqlite-plugin because conflicting ports are 
> active: qt5-qtbase
> 
> --->  Computing dependencies for qt513-qtdeclarative
> Error: Can't install qt513-qtdeclarative because conflicting ports are 
> active: qt5-qtbase
> --->  Computing dependencies for qt513-qtmultimedia
> Error: Can't install qt513-qtmultimedia because conflicting ports are active: 
> qt5-qtbase
> --->  Computing dependencies for qt513-qttools
> Error: Can't install qt513-qttools because conflicting ports are active: 
> qt5-qtbase
> --->  Computing dependencies for qt513-qttranslations
> Error: Can't install qt513-qttranslations because conflicting ports are 
> active: qt5-qtbase
> --->  Computing dependencies for qt513-qtxmlpatterns
> Error: Can't install qt513-qtxmlpatterns because conflicting ports are 
> active: qt5-qtbase

Use qt5-whatever, not qt513-whatever. You were only using qt513-whatever on 
10.12 because 10.12 could not use the latest version of qt, but 10.14 can.

Re: macOS 11 Big Sur and MacPorts

[Ryan Schmidt]

On Nov 11, 2020, at 22:27, Dave Horsfall wrote:

> On Wed, 11 Nov 2020, Ryan Schmidt wrote:
> 
>> Apple has announced that macOS 11 Big Sur will be released tomorrow, 
>> November 12, 2020. In the coming days we will either release an installer 
>> for MacPorts 2.6.3 for macOS 11 or will release a new version of MacPorts 
>> with installers for all OS versions including macOS 11.
> 
> Thanks for the heads-up; I think my MacBook Pro will be stuck forever on 
> Sierra 10.12.6 (although admittedly I haven't tried High Sierra on this one) 
> and MacPorts 2.6.3 is likely as far as it will go.

Future versions of MacPorts base will be compatible with macOS 10.12 for a long 
time; we're still compatible with Mac OS X 10.4 even and try not to break 
compatibility with old OS versions if we can avoid it.

You should always run the latest version of MacPorts base. A few weeks after a 
new version of MacPorts is released, we might start updating ports to take 
advantage of new features introduced in that version, so if you update your 
ports collection but don't update MacPorts base, some ports might not work. 
This is why MacPorts reminds you every few weeks to selfupdate since that will 
update both ports and base.

Re: Any reason not to update to Xcode 12.2 on Catalina?

[Ryan Schmidt]

On Nov 12, 2020, at 23:08, Richard L. Hamilton wrote:

> One or two times past, an Xcode version around the time of a new OS release 
> has been a problem on the older OS.
> 
> I don't see anything likely to be that way with Xcode 12.2 (and MacPorts) on 
> Catalina, but I'm looking for alternative opinions; reverting is a nuisance.
> 
> I'm in no hurry for Big Sur at this point; maybe I'll wait for the .1 or .2 
> of it, unless a compelling reason to update emerges.
> 

Xcode 12.0 contains only the macOS 10.15 SDK. As such, it is suitable for using 
with macOS 10.15. I believe Xcode 12.1 was the same.

Xcode 12.2 contains only the macOS 11 SDK. As such, it has the potential to 
cause problems when building some software on macOS 10.15 and you would be 
safer to stick with Xcode 12.1. For software that does not require Xcode to 
build, you can mitigate the problem by installing the Command Line Tools for 
Xcode 12.2, because it contains both the macOS 10.15 SDK and the macOS 11 SDK. 
For software that does require Xcode to build, with Xcode 12.2 on macOS 10.15, 
you would be at the mercy of the developers of that software having written it 
correctly to anticipate differences between the SDK version and the OS version, 
which not all developers do correctly.

(Xcode 12.0 betas contained the macOS 11 SDK, but it was changed back to the 
macOS 10.15 SDK when Xcode 12.0 final was released, presumably because macOS 11 
was not released yet.)

On macOS 10.15, you can avoid even more problems by limiting yourself to Xcode 
11.7 and the Xcode 11.5 version of the command line tools. Upgrading to Xcode 
12 or the Xcode 12 version of the command line tools will cause some ports to 
fail to build with implicit declaration of function errors or other errors that 
are a consequence of earlier implicit declaration of function errors. This 
problem is pervasive and although we have fixed many ports already, there are 
many many more that have yet to be identified and fixed.

Re: rebuild a package without an update

[Ryan Schmidt]

On Nov 13, 2020, at 17:45, Riccardo Mottola wrote:

> On 2020-11-08 08:18:22 +0100 Ryan Schmidt wrote:
> 
>> On Nov 7, 2020, at 12:46, Riccardo Mottola wrote:
>>> I need to rebuild a package which is not working due to a dependency 
>>> upgrde. revdep "catches" it but revdep fails to build it because it uses 
>>> the wrong compiler and I need to force it (also because the compiler itself 
>>> is broken because it is broken because the library is broken)
>>> I usually in these cases just run "port upgrade  
>>> configure.compiler=xxx" but in this case there is nothing to upgrade, I 
>>> need to rebuild in place.
>>> How can I do?
>> This situation should not arise. But: you can force a rebuild of a port 
>> using:
> 
> Indeed, but we have an issue that ICU upgrades break libxml2 and that one 
> breaks *all* clang compilers.
> Since gcc now links using clang also al macports clangs are broken!
> 
> So I have to force the "gcc-4.2" of xcode... that one works (and, luckily, 
> libxml2 still compiles with it)

My point is that "sudo port upgrade outdated" should work. If it does not, we 
may have a bug somewhere that we need to fix, and what you're describing above 
sounds like we haven't declared dependencies correctly somewhere, or maybe we 
have a circular dependency. Forcibly rebuilding a port is nice to know how to 
do, I just wanted to emphasize that it is not a task we expect users to need to 
do on a regular basis.

Re: macOS 11 Big Sur and MacPorts

[Ryan Schmidt]

Hm. As far as I knew, the "components" that Xcode updates at first launch are 
only related to on-device iOS/iPadOS/watchOS/tvOS development.

> On Nov 15, 2020, at 20:39, John Chivian  wrote:
> 
> @Ryan - When I start Xcode after updating it tells me it is installing needed 
> components, and command line tools *is* one of the components updated.  It 
> tells me that explicitly during the install.  Again, the "xcode-select 
> install" is not something I've done manually either of the last two times 
> I've updated MacPorts.  For me, that step was not required when I did the 
> MacPorts update after the Catalina install, or just now after the Big Sur 
> install.  MacPorts continues to function as expected retrieving and building 
> packages as needed.  I don't mean to argue, I am just relaying what I've 
> personally experienced.  Perhaps the action is remembered somewhere in Xcode?
> 
> On 11/15/20 17:28, Ryan Schmidt wrote:
>> 
>> On Nov 15, 2020, at 16:53, John Chivian wrote:
>> 
>>> For me, every time Xcode is updated, the first time I start it following 
>>> its update I am prompted to update components,
>> Yes.
>> 
>>> and the current version command line tools are installed.
>> No. "Components" are not "command line tools". You must also update the 
>> command line tools separately.
>> 
>>> Perhaps the manual xcode-select is required if you don't actually start 
>>> Xcode the application following its update.
>>> 
>>> My experience with MacPorts and Big Sur (as before with Catalina) was to 
>>> simply follow the MacPorts update instructions, after updating and starting 
>>> Xcode as described above, but without that manual xcode-select step.
>> You *MUST* update the Xcode command line tools separately in addition to 
>> updating Xcode.
>> 
> 

Re: macOS 11 Big Sur and MacPorts

[Ryan Schmidt]

On Nov 15, 2020, at 16:53, John Chivian wrote:

> For me, every time Xcode is updated, the first time I start it following its 
> update I am prompted to update components,

Yes.

> and the current version command line tools are installed.

No. "Components" are not "command line tools". You must also update the command 
line tools separately.

> Perhaps the manual xcode-select is required if you don't actually start Xcode 
> the application following its update.
> 
> My experience with MacPorts and Big Sur (as before with Catalina) was to 
> simply follow the MacPorts update instructions, after updating and starting 
> Xcode as described above, but without that manual xcode-select step.

You *MUST* update the Xcode command line tools separately in addition to 
updating Xcode.

Re: failure to link most programs on Leopard

[Ryan Schmidt]

On Nov 14, 2020, at 14:31, Ken Cunningham wrote:

> I’m not positive, but I think at one point in time macports base added this 
> flag to most or all builds, but that went by the wayside when most builds 
> became 64bit intel. 
> 

I have no recollection of that being the case, and searching the macports-base 
repository via the GitHub web interface for read_only_relocs gives me no hits. 
We try not to break compatibility with older systems in MacPorts base.

Re: Port Application Issues (Launching Issues)

[Ryan Schmidt]

On Nov 14, 2020, at 17:53, Jonathan Allen wrote:

> I fully installed the Mac Ports application successfully, and then once that 
> was finished I entered “sudo port install homebank” in the command line, no 
> errors were presented. I then went to the “MacPorts” folder in the 
> Application Folder and didn’t see the “HomeBank” application icon in there at 
> all, as if it wasn’t installed. I double-checked using “port info homebank” 
> and the output stated it had been installed.
> 
> The problem is, I can’t find the application icon at all and even searched 
> the MacPorts help pages to see if there was a “launch this application” 
> command and didn’t see one. I am a first time MacPorts user. How do I fix 
> this so I can launch the HomeBank application, or have it show up in the 
> MacPorts folder of the applications folder.
> 
> If it helps, I am using the BigSur version of MacPorts.

MacPorts is not an application, and not all ports install applications either. 
Use "port contents homebank" to see what it did install. You should find that 
it installed a program /opt/local/bin/homebank which you can launch from your 
Terminal.

Re: macOS 11 Big Sur and MacPorts

[Ryan Schmidt]

On Nov 16, 2020, at 02:55, Dominik Reichardt wrote:

> Yes, everyone replying that you have the CLT installed, check if it’s 
> actually the correct one. Because apparently there is a bug that makes Xcode 
> report that the CLTs are installed *without* checking whether it is the 
> correct version.


On OS X 10.9 Mavericks and later you can run:

pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version

This will tell you the installed version of the command line tools. On Big Sur 
I get:

version: 12.2.0.0.1.1604076827

If you are on Big Sur and you have a version older than 12.2, please download 
and install the Xcode 12.2 command line tools from:

https://developer.apple.com/download/more/?=Command%20Line%20Tools

If it says:

No receipt for 'com.apple.pkg.CLTools_Executables' found at '/'.

then you either do not have the command line tools installed or you are 
affected by the Apple bug that deletes the command line tools receipt described 
here:

https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt

To fix this, download and install the Xcode 12.2 command line tools from:

https://developer.apple.com/download/more/?=Command%20Line%20Tools

Re: QLColorCode update and issue

[Ryan Schmidt]

On Nov 16, 2020, at 02:40, Andrew Udvare wrote:

> I have a PR here to update the QLColorCode port 
> https://github.com/macports/macports-ports/pull/9138 and while everything 
> builds, the highlight functionality of this does not work.
> 
> One observation: /opt/local/lib/liblua.dylib (port: lua) was installed with 
> permissions 0644. I have since fixed this to be 0755 but it has made no 
> difference, nor am I sure this is related to the cause.

Libraries don't get executed so they don't need the execute bit.


> I get this error from dyld:
> 
> Dyld Error Message:
>  Library not loaded: /opt/local/lib/liblua.dylib
>  Referenced from: /opt/local/bin/highlight
>  Reason: no suitable image found.  Did find:
>   file system sandbox blocked open() of '/opt/local/lib/liblua.dylib'
>   /opt/local/lib/liblua.dylib: stat() failed with errno=1
>   file system sandbox blocked open() of '/opt/local/lib/liblua.dylib'
> 
> The highlight program itself works fine in CLI, where I have added iTerm2 and 
> a number of apps to the Security & Privacy section in System Preferences. I 
> added highlight as well to there and it has not changed anything. I tried to 
> run `qlmanage -r` (root and non-root) multiple times. And lastly I tried 
> rebooting.
> 
> Has anyone seen this issue before? And solved it for a port?

You get this error when doing what?

Re: Any reason not to update to Xcode 12.2 on Catalina?

[Ryan Schmidt]

On Nov 16, 2020, at 17:32, raf wrote:

> On Sun, Nov 15, 2020 at 11:56:54AM -0600, Ryan Schmidt wrote:
> 
>> You should definitely never run with a mismatched set of Xcode and its
>> command line tools. Either update the command line tools to the Xcode
>> 12.2 version or downgrade Xcode to whatever it was before. Using Xcode
>> 11.x and matching CLT on macOS 10.15 will keep you from encountering
>> some build failures.
> 
> Hi,
> 
> I have "XCode 11.3 (11C29)" (on macos-10.14.6) and,
> in its Preferences / Locations, it says
> "Command Line Tools: XCode 11.3 (11C29)".
> 
> But pkgutil seems to say otherwise:
> 
>  $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
>  version: 10.3.0.0.1.1562985497
> 
> I haven't noticed any problem (yet), but that looks
> like a mismatch. Should I upgrade the command line
> tools anyway? Note that I never actually use the XCode
> app itself, just the command line tools. I suppose the
> answer is yes.
> 
> Also, is the XCode app mistaken about which version of
> the command line tools are there, or is it just
> referring to its embedded version of them?

This poorly-named Xcode preferences setting is showing you the same information 
as running "xcode-select -p". This tells you what you will be running if you 
run e.g. "clang" on the command line: will you get the one that's in Xcode or 
the one in the standalone command line tools package? In your case, it is 
telling you that you will get the one from Xcode 11.3.

As the pkgutil command shows, your standalone command line tools version is 
10.3. Because this does not match your Xcode version, you should update it.

MacPorts will use the commands from Xcode if the port indicates that it 
requires that ("use_xcode yes") or if the standalone command line tools are not 
installed, otherwise it will use the commands from the command line tools. To 
avoid problems, make sure the two are the same version.

Re: rebuild a package without an update

[Ryan Schmidt]

On Nov 16, 2020, at 17:58, Riccardo Mottola wrote:
> 
> Ryan Schmidt wrote:
>>> So I have to force the "gcc-4.2" of xcode... that one works (and, luckily, 
>>> libxml2 still compiles with it)
>> My point is that "sudo port upgrade outdated" should work. If it does not, 
>> we may have a bug somewhere that we need to fix, and what you're describing 
>> above sounds like we haven't declared dependencies correctly somewhere, or 
>> maybe we have a circular dependency. Forcibly rebuilding a port is nice to 
>> know how to do, I just wanted to emphasize that it is not a task we expect 
>> users to need to do on a regular basis.
>> 
> 
> you are perfectly right! Since I'm am on an old (even is "beloved") OS 
> version, I expect some hiccups, but this is harder.
> However, as I tried to explain, the problem is a bit deep - causing all 
> MacPorts compiler to break is a pain on systems which have an older 
> toolchain. Probably this goes unnoticed on newer macs where the system 
> clang/gcc is "new enough".
> Here were are in the situation that if, for some upstream reason, libxml2 
> stops compiling with gcc 4.2, the user has no workaround and is stuck in an 
> endless dependency.

If such a situation were to arise, then indeed we would want to do something 
about it. We do have automated build machines for Mac OS X 10.6 and later so if 
such a situation did arise we would probably notice it on the build machines. 
As far as I know, we do not have such a situation at present.

Re: Any reason not to update to Xcode 12.2 on Catalina?

[Ryan Schmidt]

> On Nov 18, 2020, at 10:39, Peter Hancock wrote:
> 
> On 13/11/2020 10:42, Ryan Schmidt wrote:
>> On macOS 10.15, you can avoid even more problems by limiting yourself to 
>> Xcode 11.7 and the Xcode 11.5 version of the command line tools. Upgrading 
>> to Xcode 12 or the Xcode 12 version of the command line tools will cause 
>> some ports to fail to build with implicit declaration of function errors or 
>> other errors that are a consequence of earlier implicit declaration of 
>> function errors. This problem is pervasive and although we have fixed many 
>> ports already, there are many many more that have yet to be identified and 
>> fixed.
> 
> Im on:
> Catalina 10.15.7, with Xcode 12.2 (12B45b).
> "pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version" gives 
> "version: 12.2.0.0.1.1604628099"
> 
> I have encountered "This problem".
> It was in the port "man" (that I don't actually need, on reflection). 
> I found (and can't any longer...) a recent ticket on trac, closed, fixing (on 
> big Sur?) what looked like
> the same problem (an undefined use of uint_t in signal.h) but the new version 
> doesn't build for me. 
> I'll open a new ticket, with my build log, if that's the right thing to do.

The ticket about the implicit declaration of function error in the man port was:

https://trac.macports.org/ticket/61446

I thought I fixed it, though I only tested on macOS 10.13.

The problem you're describing sounds different. uint_t is a type, not a 
function, so it wouldn't be an implicit declaration of function error. Please 
report the problem to us in a ticket and attach the main.log as usual.


> However, I'd like to ask for some general advice/guidance. 
> 1. My machine won't upgrade beyond Catalina.
> 2. I need (hopefully) only the Command Line Tools, and that for MacPorts. 
>   I seem to have receipts for a whole slew of ancient Xcodes, CLT's etc. It 
> would be a joy to 
>   consign them all to the Trash, and somehow to persuade "Software Updates" 
> to 
>   shutup scolding me to update to something useless and damaging.
>   (ie. causing macports to fail building things actually important to me.)
> 
> What version of the CLT's should I download and install from Apple's 
> developer site?
> They are described as, eg. "Command Line Tools for Xcode 11.5", suggesting 
> they are no
> good to me without Xcode 11.5. 
> 
> But would macports, reinstalled if advisable, likely work fine if I first 
> uninstall 
> and trash all the other stuff and just install that?
> (I anticipate dragging /Applications/Xcode.app" to the trash, and running a 
> script I
> found in /Library/Developer/3.0/uninstall-devtools.  I don't mind some 
> lingering
> debris if only Software Update will shutup.)

If you don't need Xcode 12 for other reasons outside of MacPorts, you can save 
yourself the trouble of encountering implicit declaration of function errors by 
downgrading to Xcode 11 and the Xcode 11 command line tools. You should always 
use as matched a set as possible. The last version of Xcode 11 was 11.7 and the 
last version of the Xcode 11 command line tools was 11.5, so those are the 
versions I recommend for Catalina. It's what we use on the Catalina buildbot 
worker. If you don't want to install any of the ports that require Xcode, then 
you don't need to install Xcode.

If you install Xcode by downloading from the Apple developer site rather than 
using the App Store, I believe you will not be prompted about updating to the 
latest version.

I'm not sure how you would prevent software update from suggesting to you that 
you should update to the Xcode 12 version of the CLT. Deleting the receipt 
might do that, and in fact a bug in Catalina causes the receipt to be deleted 
automatically at some point, but that prevents MacPorts from being able to tell 
what version of the CLT you have installed, and MacPorts will ask you to 
reinstall the CLT so that the receipt is present.

Re: MacPorts 2.6.4 has been released

[Ryan Schmidt]

On Nov 14, 2020, at 06:05, Joshua Root wrote:

> The MacPorts Project is pleased to announce the release of version
> 2.6.4. This is a bugfix release with small changes only. See the
> ChangeLog [1] for the list of changes.

Thank you, Josh, for doing this release. I know it takes time to cherry-pick 
the needed fixes from master, to write up the changelog entries and the news 
announcement, and to build and sign and upload all of the installer packages, 
and I really appreciate it.

Re: QLColorCode update and issue

[Ryan Schmidt]

On Nov 16, 2020, at 13:17, Andrew Udvare wrote:

> On 16/11/2020 11:45, Ryan Schmidt wrote:
>> You get this error when doing what?
> 
> This happens when I try to load a preview.
> 
> 1. Load Finder
> 2. Pick a file that would load a preview with it like a shell script that 
> ends with .sh
> 3. Use the space-bar to trigger a full preview with Quick Look
> 
> Compatible files: 
> https://github.com/anthonygelibert/QLColorCode/blob/master/Info.plist#L14
> 

I see in the PR that you're on macOS 11. I haven't seen these kinds of sandbox 
errors before. Maybe they're something new in macOS 11.

Re: What does "Warning: No port … found in index" mean?

[Ryan Schmidt]

On Nov 17, 2020, at 20:04, Jim DeLaHunt wrote:

> Hi, folks:
> 
> In doing my daily `sudo port selfupdate` on 16 November UTC, I encountered a 
> warning which is new to me:
> 
> "Warning: No port […portname…] found in index"
> 
> In redoing `sudo port selfupdate`, this warning did not reoccur.
> 
> What is the significance of this warning?  What, if anything, should I do 
> about it?
> 
> The MacPorts output was something like this:
> 
> % sudo port selfupdate
> Password:
> Warning: No port libiconv found in the index.
> Warning: No port libiconv found in the index.
> Warning: No port expat found in the index.
> Warning: No port libiconv found in the index.
> --->  Fetching archive for jbig2dec
> …[elided remaining 170 lines]…
> 
> 
> The set of ports mentioned in the warnings were: expat, fribidi, libiconv, 
> libunistring, libxml2, p11-kit, pango, python_select, python3_select, 
> urw-fonts, xorg-libsm, xorg-libX11, xorg-libXaw, xorg-libxcb, 
> xorg-libXcursor, xorg-libXext, xorg-libXfixes, xorg-libXi, xorg-libXinerama, 
> xorg-libXrandr, xorg-libXScrnSaver, xorg-libXt, xorg-libXxf86vm, 
> xorg-xcb-util, xpm, xrender.
> 
> I spot-checked a few of the ports. They are currently valid, installed ports, 
> with one version active and one older version inactive.
> 
> What is this "index"?
> 
> Is this warning related to the upgrade of MacPorts base recently?
> 
> What is the significance of this warning?  What, if anything, should I do 
> about it?


MacPorts uses a file on your computer called PortIndex to know what ports 
exist. When you run "port info" or "sudo port install" or any other command 
that refers to a port, MacPorts looks the port up in the index.

When you sync or selfupdate, you receive updated Portfiles from our server, and 
you receive a PortIndex that we generated on our server for your OS version.

Yesterday we had server problems that caused some of the PortIndex files we 
generated to be empty or incomplete, which would cause the warnings you 
experienced. The consequence is that you would not be able to install or 
upgrade those ports at that time. It has no effect on ports you have already 
installed.

We solved the server problem later in the day, so if you synced or selfupdated 
after we fixed it, that would have given you a correct PortIndex again.

See https://trac.macports.org/ticket/61507

Re: p5.28-xml-entities-1.0.200_0.darwin_20.noarch.tbz2 does not seem to exist

[Ryan Schmidt]

On Nov 22, 2020, at 05:34, Vahid Askarpour wrote:

> I have AMP for endpoints but disabling it did not change the outcome. I will 
> just wait until the .darwin_20.* package becomes available and then try again.

I'm hoping the perl modules will be done in a couple days.

You can also try building MacPorts from our git master. It includes an 
additional fix for this that limits the number of ping processes that we start 
at one time to 50.

https://github.com/macports/macports-base/commit/0a000c436ce0f8bc7da7bb34efad896dca6a1e59

50 was just a guess so if that doesn't work you can edit the source to reduce 
50 even further:

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

Finally, if none of that works, or if you don't want to bother building master, 
you can always download the distfile manually and put it where MacPorts wants 
it:

https://trac.macports.org/wiki/ProblemHotlist#fetch-failures

Re: macOS 11 Big Sur and MacPorts

[Ryan Schmidt]

On Nov 11, 2020, at 10:06, Ryan Schmidt wrote:

> Apple has announced that macOS 11 Big Sur will be released tomorrow, November 
> 12, 2020. In the coming days we will either release an installer for MacPorts 
> 2.6.3 for macOS 11 or will release a new version of MacPorts with installers 
> for all OS versions including macOS 11.
> 
> It is likely that many ports will still fail to build on macOS 11 at this 
> point. And for those that do build, we won't start building archives for 
> macOS 11 until after it's released, and once we start it will take weeks to 
> build everything, meaning if you upgrade early, it's likely you'll have to 
> build ports from source, which takes time.
> 
> So as with all other major OS versions, I encourage you to wait awhile before 
> upgrading to macOS 11 if you want a smoother transition for your MacPorts 
> software.
> 
> Once you do upgrade, as always, you should follow the migration instructions:
> 
> https://trac.macports.org/wiki/Migration
> 
> And if you find a problem, search our issue tracker and file a ticket if 
> there isn't already one, or submit a pull request if you know the fix. Thanks.

macOS 11 is released, MacPorts 2.6.4 is released to be compatible with it.

I still urge you to wait some weeks before upgrading to give us time to sort 
out the issues.

When you upgrade, PLEASE UPGRADE XCODE AND THE XCODE COMMAND LINE TOOLS. They 
are SEPARATE software packages that need to be updated SEPARATELY. It's in the 
migration instructions; please follow them. Software Update might not tell you 
to update them; seek out the installers manually. We are getting TONS of bug 
reports from people who have failed to upgrade the command line tools and are 
getting build failures as a result. PLEASE save us the time of troubleshooting 
your issue and let us work on actual issues by upgrading your Xcode *AND* the 
command line tools. Thanks.

Re: Any reason not to update to Xcode 12.2 on Catalina?

[Ryan Schmidt]

Please keep the discussion on the mailing list by using the Reply All button in 
your mail program.


On Nov 15, 2020, at 11:18, Kevin Horton wrote:

> Caution - It looks like some recent macOS update fiddled with the preferences 
> in Software Update.  I found this morning that XCode on one Mac had been 
> unexpectedly updated to v12.2, and I found the box ticked for "Install app 
> updates from the App Store" in System Preferences -> Software Update -> 
> Advanced.  I managed to catch this before the second Mac had updated XCode

Apple loves to push automatic updates on users, which is often great, but in 
the case of Xcode and its command line tools it's not always desirable.


> Now one of my Macs is running Catalina, with XCode 12.2, but without having 
> upgraded the Command Line Tools.  And I ran "sudo port selfupdate; sudo port 
> upgrade outdated" before I discovered that XCode had been updated.
> 
> What is my best path forward?  Should I downgrade XCode?  Update the machine 
> to Big Sur?  Just leave it as is and let the MacPorts team work on ports for 
> a few weeks, then upgrade to Big Sur?

You should definitely never run with a mismatched set of Xcode and its command 
line tools. Either update the command line tools to the Xcode 12.2 version or 
downgrade Xcode to whatever it was before. Using Xcode 11.x and matching CLT on 
macOS 10.15 will keep you from encountering some build failures.

You don't have the option of using Xcode 11.x on Big Sur, so you can't avoid 
those build failures there; you have to wait for us to fix them. So if you want 
to avoid problems, don't upgrade to Big Sur yet.

Re: Catalina xcode-select --install and MacPorts installation

[Ryan Schmidt]

On Oct 28, 2020, at 02:31, Fielding, Eric J (US 329A) wrote:

> I just upgraded my MacBook to Catalina 10.15.7 from 10.14.6 and I installed 
> the latest Xcode 12.1. I started Xcode and agreed for it to install required 
> components. When I tried to run “xcode-select –install” it asked me to agree 
> to the license for the command-line tools and tried to install but then said 
> “Can’t install the software because it is not currently available from the 
> Software Update server.” I went to the Software Update control panel and it 
> said that it had an update for my command-line tools, and I told it to go 
> ahead and update them. After a while, it said that the command-line tools are 
> no longer required or something like that.
>  
> I decided to go ahead and try to install MacPorts with the Catalina MacPorts 
> installer and it showed me the license, asked about the installation type and 
> destination, but then when it got to the install step it says “Waiting for 
> other installations to complete”. I don’t think I have any other 
> installations still going on. Wait, after twenty minutes, it now says it is 
> “running package scripts” and then finished. I guess it was installing 
> something after all.
>  
> Maybe the Xcode installation instructions need an update for Catalina?
>  

As far as I know, the installation instructions are correct, and your 
experience is unique and I cannot explain it.

Re: ARM gdb compilation fails with implicit function declaration error ioctl

[Ryan Schmidt]

Don't forget to Reply All so the conversation stays on the list.

On Dec 26, 2020, at 05:06, Christoph Kukulies wrote:

> There were times in history where implicit function declarations  were not 
> considered as an error (consulting my book „The C programming language by 
> Kernighan/Ritchie“
> and my question actually aimed at that, like making the compiler a bit more 
> tolerant.
> 
> I would consider it difficult to get my problem quickly solved when reporting 
> to the author(s) of gnu readline that their code is in error.

Yes, there was such a time, prior to the introduction of the C99 standard 21 
years ago.

These days, implicit function declarations are not allowed. Developers must 
declare functions or their prototypes before using them. This requirement 
should not be controversial.

Apple turned this warning into an error in Xcode 12 because of the introduction 
of Macs using Apple Silicon. ARM uses different machine code for calling a 
function depending on whether the function takes a variable or fixed number of 
arguments. The compiler needs to know, via the function declaration or 
prototype, what type of function it is before you call it. Otherwise it has to 
guess, and if it guesses wrong, the program will crash at runtime.

For you own debugging on your own system, you can temporarily suppress the 
error and turn it back into a warning by adding 
-Wno-error=implicit-function-declaration to CFLAGS. Do not do this on Apple 
Silicon machines, don't commit this to other projects, don't commit this to 
MacPorts.

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: 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: 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: macOS symbol/conditional for Makefiles (porting)

[Ryan Schmidt]

On Dec 28, 2020, at 06:12, Christoph Kukulies wrote:

> I’m trying to compile a package „blackmagic“ (a microcontroller gdb debugging 
> and flashing program addendum to gdb).
> 
> It has some issues like missing packages (libftdi1 - I was able to add that 
> via macports)
> 
> Now I want to add some condional in the Makefile like this:
> 
> ifdef macOS
> 
> CFLAGS += -I/opt/local/include
> 
> endif
> 
> Only, macOS isn’t just the variable that works. Does macOS supply any 
> built-in variable for building that if block?

You should not need to do this.

Most build systems should accept additional flags on the command line. For 
example, autotools-based build systems usually accept something like:

CPPFLAGS="-I/opt/local/include" LDFLAGS="-L/opt/local/lib" ./configure

If blackmagic doesn't do it that way, consult their documentation to find out 
how they do it. In the unlikely event that their build system does not support 
user-supplied flags, file that as a bug in their bug tracker. You may then need 
to resort to modifying their Makefile or other build files manually, and if so, 
since the modification is just for you, you don't need to make it conditional 
on macOS or anything else; just make the change unconditionally.

If you were thinking of proposing a change to the developers of blackmagic 
where they automatically add /opt/local paths on macOS, don't. That would annoy 
users trying to build it with Homebrew, Fink, or manually, and it would even 
annoy MacPorts users trying to build with MacPorts in a prefix other than 
/opt/local.

Re: How to build a port with a different compiler

[Ryan Schmidt]

Please Reply All so that the conversation stays on the list.

On Dec 28, 2020, at 20:04, Tom wrote:

> Because nearly no port is building here, I wanted to try a different 
> compiler. But that is not the problem.
> And because of this error:
> 
> 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’.
> 
> I don’t want to install the cli tools over and over again.

Neither does anyone else, but there is or was a bug in macOS that deletes the 
CLT receipt. If that's still happening, file a bug report with Apple so that 
they fix it. We require the receipt to be present because that's the only way 
we know of to determine what version of the CLT you have installed. The receipt 
is also what Apple uses to know when your CLT is outdated, and without the 
receipt Apple won't invite you to update to later versions of the CLT.

A very small number of ports do some inadvisable things that cause that warning 
to appear, even if the SDK is present, for example qt5 and its subports: 
https://trac.macports.org/ticket/61736


On Dec 28, 2020, at 20:10, Tom wrote:

> and gcc builds faster executables than llvm.

I'm don't know anything about that. But llvm/clang is the official toolchain 
for use on macOS and has been for almost a decade so trying to contravene that 
is probably counterproductive.

Especially, trying to use g++ to build C++ software will cause tremendous 
problems due to a mismatch of C++ standard libraries. Use clang++ to build C++ 
software on macOS.

Re: qt5-qtwebengine on macOS 10.13, Xcode version

[Ryan Schmidt]

On Dec 27, 2020, at 10:11, Ken Cunningham wrote:

> However, I would float the idea it's time the buildbot and all 10.13 users 
> moved to Xcode 10.
> 
> Xcode 10's issues have largely been worked around by this point it seems, 
> although there a couple of stragglers still.

I intentionally keep most of the buildbot workers' Xcode versions at the last 
version that contains the SDK that matches the OS version. On macOS 10.13, 
that's Xcode 9.4.1.

Re: qt5-qtwebengine on macOS 10.13, Xcode version

[Ryan Schmidt]

On Dec 28, 2020, at 23:05, Ken Cunningham wrote:

> On Dec 28, 2020, at 3:35 PM, Ryan Schmidt wrote:
> 
>> On Dec 27, 2020, at 10:11, Ken Cunningham wrote:
>> 
>>> However, I would float the idea it's time the buildbot and all 10.13 users 
>>> moved to Xcode 10.
>>> 
>>> Xcode 10's issues have largely been worked around by this point it seems, 
>>> although there a couple of stragglers still.
>> 
>> I intentionally keep most of the buildbot workers' Xcode versions at the 
>> last version that contains the SDK that matches the OS version. On macOS 
>> 10.13, that's Xcode 9.4.1.
> 
> I do fully get this idea, however:
> 
> Once Xcode 10 came out, 10.13 users around the world moved to use it. 90% of 
> users are on homebrew, and they do not hold back their Xcode version on 10.13 
> to Xcode 9.
> 
> So —
> 
> If software had an issue artificially finding 10.14 features that were not 
> supported on 10.13, and we have seen that some did, these have by now been 
> managed by appropriate tests and fixes. We have seen this in many cases with 
> the clock functionality features, etc.
> 
> So - now, some years in — I believe there is more to lose by not having the 
> current Xcode and the slightly newer SDK than there is to be gained by 
> holding back to Xcode 9 and the 10.13 SDK.

I'm pretty sure that Homebrew does not have exactly the same set of software 
that MacPorts does, so it seems likely that we still have some ports that would 
be affected by this that have not already been fixed by Homebrew's efforts.

My other concern specific to Xcode 10 on macOS 10.13 is whether this would 
remove the ability to build i386 software, which is something I want to retain.

Re: How to build a port with a different compiler (was: Re: macports-users Digest, Vol 172, Issue 20)

[Ryan Schmidt]

On Dec 27, 2020, at 20:06, Tom wrote:

> how can I build a port with a MacPorts gcc compiler?
> For example gcc9.

Normally, ports choose what compiler to use and you should not attempt to 
override it. Why do you want to?

Re: odd problem trying to use Macports ...

[Ryan Schmidt]

On Dec 30, 2020, at 17:10, raf wrote:

>  Error: Error installing new MacPorts base: command execution failed
>  Please run `port -v selfupdate` for details.
>  Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
> MacPorts base: command execution failed
> 
>  (it was "configure: error: no configure found in vendor/tcl/unix")

Many years ago now, we made a change to how we distribute MacPorts via rsync, 
which inadvertently caused selfupdates to break in this manner. We never 
resolved the issue because users worked around it by installing the latest 
MacPorts using the installer you can download from our web site, which is how 
you should fix it as well.

MacPorts is designed with the assumption that you will selfupdate and update 
your ports at least once a year. Not doing so will likely result in greater 
difficulties when you eventually do update, because we start removing port 
upgrade paths after they have been in place for a year. Base upgrade paths 
should stay in place for many years however; we try not to remove the ability 
to selfupdate base unless we absolutely have to.

Re: odd problem trying to use Macports ...

[Ryan Schmidt]

Remember to Reply All so the conversation stays on the list.

On Dec 30, 2020, at 10:36, Richard Bonomo TDS personal wrote:

> Here are the outputs:
> 
> Aquinas-276:bonomo$ lipo -info 
> /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib
> Architectures in the fat file: 
> /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib are: ppc7400 i386 
> Aquinas-276:bonomo$ 
> Aquinas-276:bonomo$ ls -l 
> /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib
> -rw-rw-r--  1 root  admin  35088 Sep  6  2011 
> /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib
> Aquinas-276:bonomo$ 
> 
> Yes, it is pre-2014!

Not only pre-2014, but pre-Mac OS X 10.6. For Mac OS X 10.5 and 10.4 we compile 
ppc and i386, but for Mac OS X 10.6 and later we compile i386 and x86_64.

Hopefully whatever put this ancient part of MacPorts on your system recently 
didn't also replace other files you needed with older versions.

I still suspect that reinstalling MacPorts using our installer will delete 
/opt/local/share/macports/Tcl and set this right. If not, try deleting 
/opt/local/share/macports/Tcl yourself.

Re: Why is ${prefix}/var/macports/home not owned by the macports user?

[Ryan Schmidt]

On Jan 7, 2021, at 16:26, Andrew Udvare wrote:

> Sometimes the release tarball will come with the submodule source 
> https://github.com/macports/macports-ports/pull/9612#issuecomment-756376258 
> but this probably depends on the project.

If a release tarball doesn't come with everything needed to build the source 
(i.e. with submodules included), then it's of no use to anyone. So that would 
be a bug to report to whoever prepared that tarball.

Re: syntax for "and not"

[Ryan Schmidt]

On Jan 20, 2021, at 16:44, Murray Eisenberg wrote:

> Given that neither openscad nor kdelibs4 is currently upgrading successfully, 
> what is the correct syntax to upgrade all other outdated ports?
> 
> I’ve tried each of the following, but in each case it either still tries to 
> upgrade one of those two exceptions or causes a syntax error:
> 
> port upgrade outdated and not kdelibs4 or openscad
> 
> port upgrade outdated and not kdelibs4 and openscad
> 
> port upgrade outdated and not (kdelibs4 or opescad)

port upgrade outdated and not \( kdelibs4 openscad \)

If any of your other outdated ports depend on kdelibs4 or openscad, list them 
inside the escaped parentheses as well.

Re: Kernel panic when trying to install git dependency p5.28-mozilla-ca

[Ryan Schmidt]

On Jan 16, 2021, at 17:05, Kennedy, Smith (Wireless & IPP Standards) wrote:

> Did the update to BigSur last week on my MacBook Pro (13-inch, 2016, Four 
> Thunderbolt 3 Ports), then tried to do my usual routine whenever there is an 
> OS major version update:
> 
> A. Delete /opt with a "sudo rm -rf /opt"
> B. Install latest version of Xcode and MacPorts
> C. Run my "macportsup" script with the "--reinstall" option that will 
> reinstall all previously installed requested ports listed in the most recent 
> log file produced by the last run of that script.
> 
> The most significant problem I experienced was witnessing a _kernel panic_ 
> whenever I try to install the "git" port. The KP occurs at the point when the 
> "p5.28-mozilla-ca" port dependency has been downloaded and is starting to 
> install - the screen goes black and I'm invited to hit any key to restart. A 
> "Problem Report" is presented once I restart. I've looked at these reports 
> when I hit space and restart, but don't see anything obviously pointing back 
> to MacPorts.
> 
> But I'm pretty alarmed that somehow installing a port can KP my system. I've 
> tried disabling some accessory software (Little Snitch, Karabiner Elements, 
> TunnelBlick) but I can still KP the system even when those are disabled. And 
> I don't understand what the "p5.28-mozilla-ca" port could be doing. I'm not a 
> MacPorts developer and while I could start peeling the onion on what exactly 
> the port is doing, I'd rather that someone else do that.
> 
> Anybody else KP'ed their system installing a port on BigSur?

Yes, several other users have reported this bug in Big Sur. It is tracked here:

https://trac.macports.org/ticket/61683

A kernel panic is a bug in the operating system. You should report it to the 
operating system vendor so that they can fix it.

> p.s. I was also unable to do a "sudo rm -rf /opt". Removing the macports user 
> and group as per 
> https://guide.macports.org/chunked/installing.macports.uninstalling.html 
> mostly resolved this issue.

Great, then there's no issue. :)

> Adding an "uninstall" sub-package to the MacPorts installer might be a good 
> idea.

https://trac.macports.org/ticket/42207

Re: odd problem trying to use Macports ...

[Ryan Schmidt]

On Jan 12, 2021, at 00:34, raf wrote:

> I treated this like a migration, recorded and uninstalled existing ports,
> then installed/upgraded macports, and then restored the ports.
> 
>  Mac OS X 10.6 (darwin/10.8.0) arch i386
>  MacPorts 2.6.4
>  Xcode 3.2.6
>  SDK 10.6
>  MACOSX_DEPLOYMENT_TARGET: 10.6
> 
> I'm having some trouble. I'm getting errors with several ports:
> 
>  daemon:
> unrecognized command line option "-Wno-gnu-folding-constant"

We see this on our 10.6 build server too. I didn't file a bug for that error 
specifically, but for a different and possibly related problem:

https://trac.macports.org/ticket/61585


>  tk:
>invalid operands to binary expression ('id' and 'double')

I don't see a ticket filed for this, and I don't think we've seen this problem 
with this port. File a ticket and attach your main.log.


>  MacVim:
> MacVim only runs on OS X 10.8 or greater
>(Used to work on 10.6. Tragic! I'll have to compile that myself)

Ports get updated over time, and developers drop support for older operating 
systems.

The 10.8 requirement was noticed in https://trac.macports.org/ticket/52505. 
That ticket also tells you what the last version that works on 10.6 was, and 
how to use MacPorts to install it.


>  dirac:
>non-constant-expression cannot be narrowed from type 'int' to 
> 'dirac::ValueType' (aka 'short') in initializer list [-Wc++11-narrowing]
>  wxWidgets-2.8
>non-constant-expression cannot be narrowed from type 'short' to 'CGFloat' 
> (aka 'float') in initializer list [-Wc++11-narrowing]
>non-constant-expression cannot be narrowed from type 'FontFamilyID' (aka 
> 'short') to 'UInt32' (aka 'unsigned long') in initializer list 
> [-Wc++11-narrowing]

I don't see tickets filed for these yet.

The compilers included in Xcode on 10.6 are so old that we tend not to use them 
for most ports anymore, and use a much newer MacPorts clang instead, one which 
defaults to C++11. This has the paradoxical effect of causing problems on 10.6 
with software like apparently dirac and wxWidgets-2.8 that is not C++11 
compliant, problems which we do not observe on newer OS versions because on 
newer OS versions we can use the compilers provided by Xcode which are older 
than the newest MacPorts clangs and don't default to C++11.


>  openjade:
>ISO C++11 does not allow access declarations; use using declarations 
> instead

Already filed as https://trac.macports.org/ticket/60158


> Should I file bug reports for all of these (apart from MacVim)?

You can file bug reports when things don't work, but please understand that for 
very old OS versions like 10.6, many maintainers will not invest any time in 
solving such problems. If you can provide a fix, ideally in a pull request, 
that will increase the likelihood of getting the problem fixed for you and 
other 10.6 users.


> Another openjade/tk error is:
> 
>  Error: Requested variants "+x11" do not match those the build was started 
> with: "+quartz".
>  Error: Please use the same variants again, or run 'port clean tk' first to 
> remove the existing partially completed build.
> 
> I didn't specify any variants for those. They're not requested ports.

The last time you tried to install the tk port, you did so using the variant 
+quartz, either because you had requested it or because that used to be the 
default. That build was interrupted or failed, leaving a work directory that 
includes a record of what variants you had selected. You are now trying to 
install the tk port with the +x11 variant, either because you requested it or 
because it is now the default, which does not match what you selected 
previously. Either select what you selected previously (+quartz), or clean tk 
before trying again.


> I wrote daemon, so I want to fix that myself. Can anyone tell me
> how to tell, from a shell script, whether or not the compiler
> supports -Wno-gnu-folding-constant? Or should I just not include
> it on macos? I suppose I should just try to run gcc with it. :-)
> I'll do that.

daemon builds fine on OS X 10.8 and later, so there is no general problem with 
-Wno-gnu-folding-constant not working on macOS. But for best portability, for 
flags that not all compilers support, you should only use a flag if you 
determine that the compiler supports it.

Normally a configure script is used to determine what features are available on 
the current system. I see that daemon has a configure script but that it is a 
simple shell script written manually by you, rather than something generated by 
autoconf. Autoconf has features that help you detect what flags a compiler 
supports, but if you want to continue to use your manually-written script, 
you'll have to figure out how to replicate that functionality of autoconf. 
Here's how you might do that.

Here's an example showing that on my system, the compiler cc supports 
-Wno-gnu-folding-constant, indicated by the exit code being 0:

$ ${CC:-cc} -E -xc /dev/null -Werror 

Re: XQuartz and xorg-server

[Ryan Schmidt]

On Jan 16, 2021, at 08:18, Peter West wrote:

> Following some general advice given earlier on the list, I had removed 
> XQuartz and installed xorg-server. Now I am trying to load the rgl R library. 
> At the end of the error message is
> This build of rgl depends on XQuartz, which you can download from xquartz.org.
> 
> Am  stuck with using XQuartz if I want to run this package, or is it possible 
> to switch between the two?

XQuartz and xorg-server are the same software, except that xorg-server is 
several years more up to date. There would be no advantage to installing 
XQuartz instead of xorg-server.

If the rgl R library is something you are installing outside of MacPorts, then 
perhaps it is looking specifically for XQuartz in its install location of 
/opt/X11. You may need to inform it that you have installed it to the MacPorts 
prefix /opt/local instead.

Re: XQuartz and xorg-server

[Ryan Schmidt]

On Jan 20, 2021, at 17:32, Peter West wrote:

> I tried specifically building rgl from source. The source is available at 
> https://cran.r-project.org/src/contrib/rgl_0.104.16.tar.gz.
> 
> In R.app console, remove rgl package.
> 
> > remove.packages(“rgl”)
> > install.packages(, repos = NULL, type = “source”)
> 

> It doesn’t find X, so it skips OpenGL; configure in the source needs 
> tinkering.

I didn't have much luck with your command at first:


> install.packages("/tmp/rgl_0.104.16.tar.gz", repos = NULL, type = "source")
Warning in install.packages("/tmp/rgl_0.104.16.tar.gz", repos = NULL, type = 
"source") :
  'lib = 
"/opt/local/Library/Frameworks/R.framework/Versions/4.0/Resources/library"' is 
not writable
Would you like to use a personal library instead? (yes/No/cancel) y
Would you like to create a personal library
‘~/Library/R/4.0/library’
to install packages into? (yes/No/cancel) y
ERROR: dependencies ‘htmlwidgets’, ‘htmltools’, ‘knitr’, ‘jsonlite’, ‘shiny’, 
‘magrittr’, ‘crosstalk’, ‘manipulateWidget’ are not available for package ‘rgl’
* removing ‘/Users/rschmidt/Library/R/4.0/library/rgl’
Warning message:
In install.packages("/tmp/rgl_0.104.16.tar.gz", repos = NULL, type = "source") :
  installation of package ‘/tmp/rgl_0.104.16.tar.gz’ had non-zero exit status
> 


I found that I had to run


> install.packages("rgl")


which installed the dependencies first, and then rgl. In the configure output, 
I indeed see:


checking for X... no
configure: compiling without OpenGL support
configure: WARNING: X11 not found, continuing without OpenGL support.


It builds and installs, but evidently without X11 and OpenGL support.


I found the rgl source code at https://github.com/cran/rgl. I found in its 
configure.ac file that on macOS it explicitly adds /opt/X11 to the list of 
places where it looks for things. Since your X11 isn't there but is instead 
provided by MacPorts in /opt/local, you have to tell it that. It's pretty 
normal when building any software to have to tell it where the dependencies 
are. When you use MacPorts to build your software, we do this kind of thing for 
you so that any software you install with MacPorts can find any other software 
it needs that was also installed with MacPorts.

In the rgl readme, it mentions that the configure script supports these flags:


>   X11 WINDOWING SYSTEM OPTIONS
>   
> 
>   --x-includes=
> X11 C header files include path
> 
>   --x-libraries=
> X11 library linkage path


You can also learn this if you download the rgl source code manually, extract 
it, cd into its directory, and run ./configure --help.

I also found by searching that the r install.packages command accepts a 
configure.args argument for specifying arguments to pass to the configure 
script. So I tried this:


> install.packages("rgl", configure.args=c(rgl="--x-includes=/opt/local/include 
> --x-libraries=/opt/local/lib"))


This failed:


configure: error: in 
`/private/var/folders/0_/y8x8nfkh8xj125006s6dfkshgp/T/RtmpUbm2PQ/R.INSTALL128833eb7f828/rgl':
configure: error: C compiler cannot create executables
See `config.log' for more details
ERROR: configuration failed for package ‘rgl’
* removing ‘/Users/rschmidt/Library/R/4.0/library/rgl’


Unfortunately I don't know why because I can't look in the config.log because I 
don't know where it is.

Another possibility might be:


> install.packages("rgl", configure.vars=c(rgl="CPPFLAGS=-I/opt/local/include 
> LDFLAGS=-L/opt/local/lib"))


This would be a more general purpose solution that would work with any library 
dependencies, not just X11. But that failed the same way.

Perhaps these are problems specific to my computer and one of the above methods 
will work for you. If not, maybe you will know where r puts the build directory 
when it builds packages or, if it puts it in a temporary directory that it 
deletes automatically, how to tell it not to delete it so that we can have a 
look at it.

Re: p5.28-dbd-mysql fails to build

[Ryan Schmidt]

On Jan 19, 2021, at 09:52, ximon wrote:

> Hi, I have a new install of macports on 11.1 BigSur. mysql8 is installed and 
> works, as does the mysql client, perl 5.28 installed also. When I try to 
> install p5.28-dbd-mysql +mysql8 it fails with the below log messages.

See the last paragraph of https://trac.macports.org/ticket/62086#comment:6 for 
the workaround.

Re: building clang

[Ryan Schmidt]

On Jan 18, 2021, at 19:38, Tom wrote:

> how can I build clang with -ilocal option support in order to build CrossOver 
> Wine for 32on64?

That's an option that Crossover added to clang. When I last looked into the 
issue last year, you had to use Crossover's special version of clang, which was 
bundled with the Crossover source download, to be able to get this option. I 
don't know if their work has in the mean time been merged into the official 
clang sources.

Last year I worked on updating the wine-crossover port to support wine32on64, 
through a new clang-wine-crossover subport that includes this option. That work 
has not yet been committed to MacPorts.

Re: Unable to load nib file / Problem with CompileXIB

[Ryan Schmidt]

On Jan 18, 2021, at 06:40, Janosch Peters wrote:

> I need sparkle as a dependency for the new MacPass port. Your points about 
> sparkle are of course valid. When I wrote the message I thought it might 
> still be nice to give users the choice to use it or not - via a variant for 
> instance.

No, we would not accept such a variant. Ports should not update their own 
files. MacPorts updates the files when the user asks it to.

Re: XQuartz and xorg-server

[Ryan Schmidt]

On Jan 18, 2021, at 04:56, Peter West wrote:

> I’ve removed XQuartz (again), and installed R and R-app from MacPorts. The R 
> install warned me that
> Clang compilers provided by Xcode do not support OpenMP. Some R packages 
> using OpenMP may require additional
>   flags in the Makevar file (e.g. data.table) to build. Please consult 
> package documentation.
> 
> I install.package’d data.table without whinging, then did the same for rgl. 
> It built, but when I loaded the library, I was informed that
> This build of rgl does not include OpenGL functions.
> 
> Looking around for mentions of OpenGL, I couldn’t se anything that looked 
> like an OpenGL library.

I don't know anything about R or rgl. I tried "port search rgl" and I'm not 
sure if any of those are what you're referring to.

If you can provide an exact step-by-step list of commands to run to observe the 
problem, then I could try them on my system and see if I can figure out what 
needs to be changed.

Re: libjpeg-turbo not building (+universal) on Snow Leopard

[Ryan Schmidt]

On Jan 18, 2021, at 21:11, Richard L. Hamilton wrote:

> ...which is a problem given that a lot of ports were apparently changed to 
> use it.
> 
> 

Yes, all ports that depend on jpeg were changed to depend on libjpeg-turbo 
yesterday. This had been requested for years but hadn't been done because it 
was a lot of work to modify all affected ports, so we thank Josh for doing it.

I believe the problem you're experiencing is the one described here:

https://trac.macports.org/ticket/60018

Re: Sharing the Xserver with docker container

[Ryan Schmidt]

On Jan 24, 2021, at 21:26, Tong Sun wrote:

> On Sun, Jan 24, 2021 at 10:24 PM Ryan Schmidt wrote:
>> 
>> On Jan 24, 2021, at 21:15, Tong Sun wrote:
>> 
>>> On Sun, Jan 24, 2021 at 9:30 PM Ryan Schmidt wrote:
>>> 
>>>> On Jan 24, 2021, at 18:01, Tong Sun wrote:
>>>> 
>>>>> For any Xserver in host, I normally just do the following in the
>>>>> docker container
>>>>> 
>>>>> export DISPLAY=':0'
>>>>> xterm &
>>>>> 
>>>>> and I'll be all set.
>>>>> 
>>>>> However, I found that it is not the case for Xserver from macport, as
>>>>> I see my DISPLAY in my host is
>>>>> 
>>>>> DISPLAY=/private/tmp/com.apple.launchd.DiHpGrxgFr/org.macports:0
>>>>> 
>>>>> How can I share that with my docker container?
>>>> 
>>>> I'm not sure. Did you try first starting the X server on your Mac, and 
>>>> then doing what you did before in Docker?
>>> 
>>> I'm very new to both Mac and macport. how to start the X server on Mac?
>>> 
>>> I used macport to install xorg-server, then tried to start xterm.
>>> xterm started fine, meaning my xorg-server started fine,
>>> then I checked the DISPLAY in xterm, which is the above value.
>> 
>> Starting any X11 program, such as xterm, will start the X11 server. Or you 
>> can manually launch /Applications/MacPorts/X11.app.
>> 
>> Now that X11.app is running on macOS, what happens if you try to use X11 
>> from your Docker container, with DISPLAY set to ":0"?
> 
> Error: Can't open display: :0


I found this article about how to do this. Maybe it will help?

https://medium.com/@mreichelt/how-to-show-x11-windows-within-docker-on-mac-50759f4b65cb

Where it says "install XQuartz", don't, since you already have the MacPorts 
X11.app which is equivalent to but newer than XQuartz.

It sounds like the key may be to set "Allow connections from network clients" 
in X11.app's Preferences window, close and reopen X11.app, and run "xhost + 
127.0.0.1" and "export DISPLAY=host.docker.internal:0" in the Docker image.

Re: Sharing the Xserver with docker container

[Ryan Schmidt]

On Jan 24, 2021, at 21:42, Tong Sun wrote:

> On Sun, Jan 24, 2021 at 10:31 PM Ryan Schmidt wrote:
> 
>> I found this article about how to do this. Maybe it will help?
>> 
>> https://medium.com/@mreichelt/how-to-show-x11-windows-within-docker-on-mac-50759f4b65cb
>> 
>> Where it says "install XQuartz", don't, since you already have the MacPorts 
>> X11.app which is equivalent to but newer than XQuartz.
>> 
>> It sounds like the key may be to set "Allow connections from network 
>> clients" in X11.app's Preferences window, close and reopen X11.app, and run 
>> "xhost + 127.0.0.1" and "export DISPLAY=host.docker.internal:0" in the 
>> Docker image.
> 
> Hmm... I've looked everywhere but cannot find this "Allow connections
> from network clients" in X11.app's Preferences window. Where can I
> find it?
> 
> Without such step, I'm getting
> 
> $ xhost + 127.0.0.1
> xhost:  unable to open display "127.0.0.1:0"

Open X11.app. Choose Preferences from the X11 menu. Select the Security tab.

Re: Sharing the Xserver with docker container

[Ryan Schmidt]

On Jan 24, 2021, at 18:01, Tong Sun wrote:

> For any Xserver in host, I normally just do the following in the
> docker container
> 
> export DISPLAY=':0'
> xterm &
> 
> and I'll be all set.
> 
> However, I found that it is not the case for Xserver from macport, as
> I see my DISPLAY in my host is
> 
> DISPLAY=/private/tmp/com.apple.launchd.DiHpGrxgFr/org.macports:0
> 
> How can I share that with my docker container?

I'm not sure. Did you try first starting the X server on your Mac, and then 
doing what you did before in Docker?

Re: Sharing the Xserver with docker container

[Ryan Schmidt]

On Jan 24, 2021, at 21:15, Tong Sun wrote:

> On Sun, Jan 24, 2021 at 9:30 PM Ryan Schmidt wrote:
> 
>> On Jan 24, 2021, at 18:01, Tong Sun wrote:
>> 
>>> For any Xserver in host, I normally just do the following in the
>>> docker container
>>> 
>>> export DISPLAY=':0'
>>> xterm &
>>> 
>>> and I'll be all set.
>>> 
>>> However, I found that it is not the case for Xserver from macport, as
>>> I see my DISPLAY in my host is
>>> 
>>> DISPLAY=/private/tmp/com.apple.launchd.DiHpGrxgFr/org.macports:0
>>> 
>>> How can I share that with my docker container?
>> 
>> I'm not sure. Did you try first starting the X server on your Mac, and then 
>> doing what you did before in Docker?
> 
> I'm very new to both Mac and macport. how to start the X server on Mac?
> 
> I used macport to install xorg-server, then tried to start xterm.
> xterm started fine, meaning my xorg-server started fine,
> then I checked the DISPLAY in xterm, which is the above value.

Starting any X11 program, such as xterm, will start the X11 server. Or you can 
manually launch /Applications/MacPorts/X11.app.

Now that X11.app is running on macOS, what happens if you try to use X11 from 
your Docker container, with DISPLAY set to ":0"?

Re: Start the Xserver automatically

[Ryan Schmidt]

On Jan 24, 2021, at 22:35, Tong Sun wrote:

> I checked the x11.app's preference, but it seems to be missing the
> capability to start the Xserver automatically when user logs in.
> 
> Is it so? Any plan to add it?

The X server will start automatically when you launch any X11-using program. 
This is better than having the X server running all the time. This change to 
the X server was made by Apple in Mac OS X 10.5 in pursuit of their goal of not 
having services running when they're not needed.

Re: apache2 IPv6 Big Sur

[Ryan Schmidt]

On Jan 12, 2021, at 02:31, Steve Wardle wrote:

> On 12 Jan 2021, at 01:37, Ryan Schmidt wrote:
> 
>> On Jan 9, 2021, at 12:16, Steve Wardle wrote:
>> 
>>> I’ve got apache2 2.4.46 running on Big Sur 11.1 and it’s not listening on 
>>> the IPv6 interfaces. I’m sure this was working last year and it would help 
>>> to know if it’s a general apache2 2.4.46 issue or confined to Big Sur or 
>>> maybe just my system.
>> 
>> I haven't heard of any such issues but am not necessarily in the loop. You 
>> might ask in an Apache support venue.
>> 
> 
> I did a bit more digging on my system yesterday.
> The Apple supplied apache is the same version and does listen on IPv4 and 
> IPv6.
> 
> /usr/sbin/apachectl -V
> 
> Server compiled with
>  -D APR_HAS_SENDFILE
>  -D APR_HAS_MMAP
>  -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>  -D APR_USE_FLOCK_SERIALIZE
>  -D APR_USE_PTHREAD_SERIALIZE
> 
> /opt/local/sbin/apachectl -V
> 
> Server compiled with
>  -D APR_HAS_SENDFILE
>  -D APR_HAS_MMAP
>  -D APR_USE_SYSVSEM_SERIALIZE
>  -D APR_USE_PTHREAD_SERIALIZE
> 
> macports apache was working with IPv6 on Catalina. I only found out about the 
> failure because the certbot validators attempt to use an IPv6 address for 
> https if there’s a domain  record and don’t fall back to trying the A 
> record.

I figured out why this is happening and filed a bug report for you:

https://bz.apache.org/bugzilla/show_bug.cgi?id=65087

It's a bug in the apr configure script. apr is a library that apache uses.

Re: Warning: All compilers are either blacklisted or unavailable

[Ryan Schmidt]

On Dec 31, 2020, at 03:12, Michael Newman wrote:

> Some months ago I upgraded the OS on a remote 2010 MacBook (the white one) to 
> High Sierra (10.13.16). After the upgrade I did the recommended MacPorts 
> migration without problems.
> 
> I don’t visit this machine very regularly, so only recently remembered to run 
> port clean all after doing a selfupdate/upgrade. Both of the latter ran 
> without error, but the clean produced many like the following:
> 
> --->  Cleaning wxsvg
> Warning: All compilers are either blacklisted or unavailable; defaulting to 
> first fallback option
> 
> I’m not sure how to deal with this. There’s no indication that any ports 
> failed to build, but the presence of the warning bothers me. I don’t see any 
> recent list mentions of this issue.
> 
> Is there anything that I should do?
> 
> (Sorry for the New Year’s Eve interruption.)

If you see this warning when doing actions other than 
configuring/building/installing (such as when cleaning) ignore it. Maybe we 
shouldn't even display the warning in those cases, though I'm not sure if 
there's a good way for us to do that.


If you see it while configuring/building/installing, then here's an explanation 
of why the warning appears and what to do about it.

MacPorts has a list of possible compilers that ports could use to compile, 
which varies based on various criteria including Xcode version.

Individual ports can blacklist compilers from that list if they are known not 
to work for that port. MacPorts then picks the next best compiler from its list.

Ports can also add additional compilers to the list of possible compilers if 
needed.

If a port blacklists all of the compilers in the list, that means no compilers 
remain that can compile this software. MacPorts prints the warning you saw in 
this case. It is expected that trying to build the port in this situation will 
fail. If the build does not fail, that means the port's blacklist is incorrect 
(it claims a compiler won't work but it actually did) and should be fixed. File 
a bug report and provide as much information as possible about your OS version, 
Xcode version, and which compiler got used.