Re: is there a Fortran-90 compiler port? Where to get a FOSS Fortran-90 compiler?

[Chris Jones]

On 02/03/2024 4:43 am, Dave Allured - NOAA Affiliate via macports-users 
wrote:
Yes, that is it.  Macports implementation decided to decorate the name 
of the executable.  There is no naked "gfortran".  It is gfortran-mp-12, 
gfortran-mp-13, etc.  This way you can have multiple versions installed 
side by side, if you wish.  For convenience, I usually sym link 
"gfortran" to the latest MP version.


You should not sym link manually yourself. That is precisely what `sudo 
port select gcc` is there for 





On Fri, Mar 1, 2024 at 9:35 PM Kenneth Wolcott > wrote:


Should I be using gfortran-mp-13?

ls /opt/local/bin | grep fortran
arm64-apple-darwin23-gfortran-mp-12
arm64-apple-darwin23-gfortran-mp-13
gfortran-mp-12
gfortran-mp-13
lfortran

On Fri, Mar 1, 2024 at 8:28 PM Kenneth Wolcott
mailto:kennethwolc...@gmail.com>> wrote:
 >
 > I do have a GNAT Ada compiler located at:
 >
 > /opt/gcc-13.2.0-aarch64
 >
 > Does the existence of this confuse or mislead MacPorts?
 >
 > Thanks,
 > Ken W.
 >
 > On Fri, Mar 1, 2024 at 8:24 PM Kenneth Wolcott
mailto:kennethwolc...@gmail.com>> wrote:
 > >
 > > Hi Joshua;
 > >
 > > port contents gcc13 | grep gfortran
 > >   /opt/local/bin/arm64-apple-darwin23-gfortran-mp-13
 > >   /opt/local/bin/gfortran-mp-13
 > >   /opt/local/lib/gcc13/libgfortran.5.dylib
 > >   /opt/local/lib/gcc13/libgfortran.a
 > >   /opt/local/lib/gcc13/libgfortran.dylib
 > >   /opt/local/lib/gcc13/libgfortran.spec
 > >   /opt/local/share/info/gfortran-mp-13.info

 > >   /opt/local/share/man/man1/gfortran-mp-13.1.gz
 > > ~:
 > >
 > > But "ls /usr/local/bin | grep -i fortran"
 > >
 > > Has no output. ??!!
 > >
 > > Thanks,
 > > Ken W.
 > >
 > > On Fri, Mar 1, 2024 at 7:19 PM Joshua Root mailto:j...@macports.org>> wrote:
 > > >
 > > > Are you sure of that? Check e.g. 'port contents gcc13 | grep
gfortran'.
 > > >
 > > > - Josh
 > > >
 > > > Kenneth Wolcott wrote:
 > > >
 > > > > Hi Noam;
 > > > >
 > > > >    I do not have gfortran, therefore I must not have gcc?
 > > > >
 > > > > Here is a filtered list of the ports that I have installed
that pertain to gcc:
 > > > >    gcc12 @12.3.0_4+stdlib_flag (active)
 > > > >    gcc12-libcxx @12.3.0_4+clang14 (active)
 > > > >    gcc13 @13.2.0_4+stdlib_flag (active)
 > > > >    gcc13-libcxx @13.2.0_4+clang16 (active)
 > > > >    gcc_select @0.1_10 (active)
 > > > >    libgcc @7.0_0 (active)
 > > > >    libgcc12 @12.3.0_4+stdlib_flag (active)
 > > > >    libgcc13 @13.2.0_4+stdlib_flag (active)
 > > > >    mpich-default @4.1.2_2+gcc13 (active)
 > > > >
 > > > > Still confused...
 > > > >
 > > > > Thanks,
 > > > > Ken W.
 > > > >
 > > > > On Fri, Mar 1, 2024 at 6:03 PM Bernstein, Noam CIV USN NRL
WASHINGTON
 > > > > DC (USA)  
>> wrote:
 > > > > >//>/Pretty sure that macports gcc installs gfortran by
default, which is
 > > > > a f90 (and 95, and maybe f2003) compiler./
 > > >

Re: Quartz no longer launching when an X application is invoked

[Chris Jones]

Users should not need to do *anything* to get DISPLAY correctly set. 
Anything you have in your personal environment configuration should be 
removed. If you aren't getting DISPLAY set with the correct launchd 
socket by default then you must have something that is interfering with 
this.


On 04/12/2023 2:15 pm, Pieter van Oostrum wrote:

On my machine I have:
export DISPLAY=$(launchctl getenv DISPLAY)
I don't know if that is the canonical way to do it but for me it works.

Re: Quartz no longer launching when an X application is invoked

[Chris Jones]

Hi,

'Quartz' has nothing to do with X11, its the primary compositor used by 
macOS itself to render graphics.


I assume you are actually taking about the X11 server, which in MacPorts 
is provided by the 'xorg-server' port and historically was provided by 
the 'XQuartz' package.


Some basic questions.

1. What installation of the X11 server are you using ? the MacPorts 
provided one or something else ?


2. Regardless of your answer to 1., try (re)installing the MacPorts 
provided one


 > sudo port uninstall xorg-server
 > sudo port install xorg-server

Then log out and back in again. This step is important as if you skip it 
things do not work correctly.


3. Finally, in order for the automatic starting of the X11 server on 
demand to work, you need your DISPLAY variable set correctly. It should 
look something like


$ echo $DISPLAY
/private/tmp/com.apple.launchd.TwDg8TRtvI/org.macosforge.xquartz:0

i.e. it needs to refer to a launchd socket. If you see something else 
instead you like are overriding this somewhere and you need to find and 
remove this.


Chris

On 30/11/2023 5:30 am, Kenneth Wolcott wrote:

Hi;

Quartz no longer launching when an X application is invoked

The first time I had installed some ports that were dependent on
Quartz I had difficulty getting them to start because Quartz was not
running.

The first solution was to manually invoke Quartz, which worked ok.

I then was able to get Quartz to start via Launch when an X
application was invoked.

Recently (?) it stopped working and I'm not sure why.

All research I've done so far has been fruitless, I'm just not asking
the right questions...

I'm back to manually starting Quartz.

Please show me how to diagnose the problem and also to solve it.

Thanks,
Ken Wolcott

Re: ruby-select problem - Sonoma

[Chris Jones]

> On 20 Oct 2023, at 6:13 pm, Bill Cole 
>  wrote:
> 
> On 2023-10-19 at 18:47:01 UTC-0400 (Fri, 20 Oct 2023 11:47:01 +1300)
> Chris F 
> is rumored to have said:
> 
>>> On 20/10/23 11:17 am, Chris Jones wrote:
>>> 
>>> 
>>>> On 19 Oct 2023, at 10:58 pm, Chris F  wrote:
>>>> 
>>>> 
>>>> 
>>>> I've just migrated to Sonoma 14.0 via a clean OS install plus Migration 
>>>> Assistant and I'm now reinstalling my ports one at a time.
>>>> 
>>>> Port ruby31 installed without problems but ruby-select doesn't seem to 
>>>> work/be effective - after ruby-select ruby31 runs successfully, command 
>>>> "ruby" still starts the OS default ruby 2.6.10
>>>> 
>>>> I've checked /opt/local/bin/ruby and it points (correctly?) to ruby3.1.
>>>> 
>>>> Any advice would be appreciated.
>>>> 
>>> Did you start a new terminal session after run port select for ruby ?
>> 
>> Yes I did, Chris - I shut terminal down and restarted it a couple of times 
>> as well.  Chris F
> 
> Check the order of directories in your $PATH environment variable. If the 
> sub-directories under /usr are listed before those under /opt/local, you will 
> use the base install executables instead oF those installed by MacPorts.

Exactly. If once you have started a fresh terminal 

 > which ruby

Doesn’t list the macports provided one, the issue is your personal PATH is not 
set correctly.

Chris

> 
> 
> 
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire

Re: ruby-select problem - Sonoma

[Chris Jones]

> On 19 Oct 2023, at 10:58 pm, Chris F  wrote:
> 
> 
> I've just migrated to Sonoma 14.0 via a clean OS install plus Migration 
> Assistant and I'm now reinstalling my ports one at a time. 
> 
> Port ruby31 installed without problems but ruby-select doesn't seem to 
> work/be effective - after ruby-select ruby31 runs successfully, command 
> "ruby" still starts the OS default ruby 2.6.10
> 
> I've checked  /opt/local/bin/ruby and it points (correctly?) to ruby3.1.
> 
> Any advice would be appreciated.
> 
Did you start a new terminal session after run port select for ruby ?

> 
> Chris F
> 
> Ruby Bay, New Zealand
> 
> 
> 
> 

Re: problem with py311-scipy on M1 MacBook Pro

[Chris Jones]

On 19/10/2023 3:59 pm, Chris Jones wrote:



On 19/10/2023 3:09 pm, Artemio González López via macports-users wrote:
I just realized that my problem could exactly be the one reported in 
ticket #68329 (py311-scipy @1.10.1_0+gfortran+openblas not building on 
Sonoma apple silicon). Indeed, I just spotted the following lines in 
my main.log:


:info:build ld: duplicate LC_RPATH '/opt/local/lib/libgcc' in 
'/opt/local/lib/libopenblas-r1.dylib'
:info:build clang: error: linker command failed with exit code 1 (use 
-v to see invocation)


Short of waiting for Apple to release XCode 15.1, is there any quick 
fix for this?


The canocial fix is to tell the build to use the classic linker option. 
'Well behaved' builds will respect the following setting in the Portfile


configure.ldflags-append  -Wl,-ld_classic

This has worked for me in a few places, like the root6 port. I did 
actually try it in py-scipy and there it did not work, and nor did a 
handful of other tricks I have to get the build to use a certain linker.


In my experience python based builds are not that well behaved when it 
comes to things like respecting the macports build flags...


At this point I am in the 'wait for Xcode 15.1' camp. Usually the first 
X.1 OS release comes along relatively soon after the initial X.0 
release, so I would anticipate it relatively soon, most likely.


b.t.w. If it is urgent for you, there is I believe a beta version of 
Xcode 15.1 available you could try. Its not the urgent for me so I am 
just waiting for it to become public..




cheers Chris

Re: problem with py311-scipy on M1 MacBook Pro

[Chris Jones]

On 19/10/2023 3:09 pm, Artemio González López via macports-users wrote:
I just realized that my problem could exactly be the one reported in 
ticket #68329 (py311-scipy @1.10.1_0+gfortran+openblas not building on 
Sonoma apple silicon). Indeed, I just spotted the following lines in my 
main.log:


:info:build ld: duplicate LC_RPATH '/opt/local/lib/libgcc' in 
'/opt/local/lib/libopenblas-r1.dylib'
:info:build clang: error: linker command failed with exit code 1 (use -v 
to see invocation)


Short of waiting for Apple to release XCode 15.1, is there any quick fix 
for this?


The canocial fix is to tell the build to use the classic linker option. 
'Well behaved' builds will respect the following setting in the Portfile


configure.ldflags-append  -Wl,-ld_classic

This has worked for me in a few places, like the root6 port. I did 
actually try it in py-scipy and there it did not work, and nor did a 
handful of other tricks I have to get the build to use a certain linker.


In my experience python based builds are not that well behaved when it 
comes to things like respecting the macports build flags...


At this point I am in the 'wait for Xcode 15.1' camp. Usually the first 
X.1 OS release comes along relatively soon after the initial X.0 
release, so I would anticipate it relatively soon, most likely.


cheers Chris

Re: gfortran and ifort do not work after upgrading to Sonoma

[Chris Jones]

_malloc.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[75](tbk_display.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[76](tbk_backtrace.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[79](cpu_feature_disp.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[82](ia32_memcmp.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[83](fast_mem_ops.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[84](fastmemcpy.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[86](fastmemset.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[99](proc_init_utils.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[102](new_proc_init.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[103](ia32_addsubq.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[105](ia32_divq.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[116](sse2_strlen.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[117](sse2_strchr.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[119](sse2_strncmp.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[122](sse2_strncat.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[125](ssse3_strcpy.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[126](ssse3_strncpy.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[158](intel_mic_avx512f_memcpy.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[159](intel_mic_avx512f_memset.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[162](intel_avx_rep_memcpy.o)',
>  assuming: macOS
> ld: warning: no platform load command found in 
> '/opt/intel/oneapi/compiler/2022.1.0/mac/bin/intel64/../../compiler/lib/libirc.a[164](intel_avx_rep_memset.o)',
>  assuming: macOS
> 
> 
> 
>> On 10/9/23 3:43 AM, Chris Jones wrote:
>> 
>> Your system is screwed up. You must use Xcode 15 with macOS14.
>> 
>> Please do not mail my privately and keep your mails on the mailing list.
>> 
>> Chris
>> 
>>> On 08/10/2023 10:44 pm, Tao Zhang wrote:
>>> Hi Chris,
>>>gfortran and ifort  do not work after upgrading to Sonoma. see below.
>>>Should I upgrade to the latest Xcode15 or old Xcode14 to fix this 
>>> problem?
>>>It is reported that Xcode15 does not work well with Macport, right?
>>> 
>>>   Thanks
>>>   Tao
>>> 
>>> 1)
>>> /Users/tzhang> gfnew aaa.f
>>> sh: line 1: 12185 Bus error: 10 
>>> /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
>>>  -find clang 2> /dev/null
>>> clang: error: unable

Re: X11 and grads do not work after upgrading to Sonoma

[Chris Jones]

> On 7 Oct 2023, at 4:25 pm, Tao Zhang  wrote:
> 
> Hi Chris,
>  I am using time machine to transfer them from a Mojave Macbook pro to the 
> present Sonoma machine.
>  Is there a new version of X11 that can be installed into /usr/X11?

Not provided by macports, no.

I do not recommend what you are doing above as having anything in /usr/local is 
not supported by macports

 https://trac.macports.org/wiki/FAQ#usrlocal

Remove what you are putting in these locations and instead just use the 
macports versions

> sudo port install grads xorg-server

Chris
> 
>  Thanks
>  Tao
> 
> 
>> On 10/7/23 9:16 AM, Chris Jones wrote:
>> Hi,
>> 
>> /usr/local and /usr/X11 are not locations macports will install anything 
>> into, so you are not using a macports provided build of grads.
>> 
>> You should remove everything from these locations, and then install instead 
>> macports grads port. Also, in order to have a X11 server you should install 
>> macports xorg-server port.
>> 
>> Chris
>> 
>>>> On 7 Oct 2023, at 4:10 pm, Tao Zhang  wrote:
>>> 
>>> Hi,
>>> 
>>>  I have problem in X11 and grads after upgrading to  Sonoma. I am using 
>>> intel i9 chip.
>>> 
>>>  see below.
>>> 
>>>  Do you know how to fix it?
>>> 
>>>  Thanks
>>> 
>>> Tao
>>> 
>>> 
>>> “XQuartz” is damaged and can’t be opened.
>>> 
>>> MacBook-Pro-2018:~ 33;grads
>>> dyld[6709]: Library not loaded: /usr/X11/lib/libX11.6.dylib
>>>   Referenced from:  
>>> /usr/local/bin/grads
>>>   Reason: tried: '/usr/X11/lib/libX11.6.dylib' (no such file), 
>>> '/System/Volumes/Preboot/Cryptexes/OS/usr/X11/lib/libX11.6.dylib' (no such 
>>> file), '/usr/X11/lib/libX11.6.dylib' (no such file), 
>>> '/usr/local/lib/libX11.6.dylib' (no such file), '/usr/lib/libX11.6.dylib' 
>>> (no such file, not in dyld cache)
>>> Abort
>>> 
> 

Re: X11 and grads do not work after upgrading to Sonoma

[Chris Jones]

Hi,

/usr/local and /usr/X11 are not locations macports will install anything into, 
so you are not using a macports provided build of grads. 

You should remove everything from these locations, and then install instead 
macports grads port. Also, in order to have a X11 server you should install 
macports xorg-server port.

Chris

> On 7 Oct 2023, at 4:10 pm, Tao Zhang  wrote:
> 
> Hi,
> 
>  I have problem in X11 and grads after upgrading to  Sonoma. I am using intel 
> i9 chip.
> 
>  see below.
> 
>  Do you know how to fix it?
> 
>  Thanks
> 
> Tao
> 
> 
> “XQuartz” is damaged and can’t be opened.
> 
> MacBook-Pro-2018:~ 33;grads
> dyld[6709]: Library not loaded: /usr/X11/lib/libX11.6.dylib
>   Referenced from:  /usr/local/bin/grads
>   Reason: tried: '/usr/X11/lib/libX11.6.dylib' (no such file), 
> '/System/Volumes/Preboot/Cryptexes/OS/usr/X11/lib/libX11.6.dylib' (no such 
> file), '/usr/X11/lib/libX11.6.dylib' (no such file), 
> '/usr/local/lib/libX11.6.dylib' (no such file), '/usr/lib/libX11.6.dylib' (no 
> such file, not in dyld cache)
> Abort
> 

Re: Status of Macports on Sonoma?

[Chris Jones]

Hi,On 7 Oct 2023, at 3:40 pm, Murray Eisenberg  wrote:OnFri, 6 Oct 2023 19:10:39 -0500,Kevin Horton  wrote:I'm pondering whether I should upgrade to macOS Sonoma now, or continue to wait.  Generally speaking, how well is Macports working on Sonoma?  I have seen a surprising small number of issues posted on this list, and am wondering whether that is a good reflection of the status.It depends on which ports you require. Most of those I had under Ventura I could finally get installed under Sonoma. But a number of ports will not as yet re-install under Sonoma owing to a change in C compiler flags in Xcode 15 (and Sonoma seems not to allow using an earlier version of Xcode).Not wishing to be pedantic, but the issue is not relating to the compiler, but instead the linker. Xcode 15 switched to a new implementation which has issues in some scenarios, for instance whenever asked to link against object files or dylibs created with GCC. A common reason for this is ports that need to use GCC to build fortran source code. OpenBLAS is a specific example that a number of ports use and thus are having issues linking against. Workarounds exist, basically by using specific linker options to go back to using the so called ‘classic’ linker. The problem is not all builds are easy to convince to use these flags.Cheers ChrisAmong those troublesome ports is sbcl, and unfortunately the maxima port depends on sbcl.
---Murray Eisenberg		murrayeisenb...@gmail.comMobile (413)-427-5334503 King Farm Blvd #101		Rockville, MD 20850-6667	

Re: Status of Macports on Sonoma?

[Chris Jones]

Hi,On 7 Oct 2023, at 1:12 am, Kevin Horton  wrote:I'm pondering whether I should upgrade to macOS Sonoma now, or continue to wait.  Generally speaking, how well is Macports working on Sonoma?  I have seen a surprising small number of issues posted on this list, and am wondering whether that is a good reflection of the status.I would not base your opinion on messages to this list, as that is not the recommended way of reporting issues. You should instead check trac for issue related to the new OS. See the link fromMacPortstrac.macports.orgChrisThanks,Kevin Horton

Re: work-around for Xcode 15 linker issue?

[Chris Jones]

Hi,

On 04/10/2023 11:08 am, Maxim Abalenkov wrote:

Dear Murray, Chris et al.,

How are you? I’m very sorry. I didn’t mean to mislead anybody. I’m also 
learning. What user does MacPorts run as? Maybe it would be possible to 
pass these environment variables to that ‘MacPorts’ user?


Its possible for ports to define specific environment variables, which 
will get set during the variable phases as that port builds. see


https://guide.macports.org/#reference.phases.configure

for more details.

for the specific issue here though, the canonical fix would be to add 
the linker option to the ldflags for a specific port. e.g.


configure.ldflags-append  -Wl,-ld_classic

that should be done inside a check on the Xcode version, so its only 
applied when needed. See e.g.


https://github.com/macports/macports-ports/commit/41cce53c601d6c407a48eaf7c705b45bec848dcb

where I did just this for the root6 port, and there it fixed the issues.

This will work for ports that are well behaved and respect the build 
flags macports sets. Unfortunately not all ports are and I have run into 
a number where the above does not work (e.g. looking at you py-scipy...)


cheers Chris



—
Best wishes,
Maxim

Maxim Abalenkov \\ maxim.abalen...@gmail.com
+44 7 486 486 505 \\ www.maxim.abalenkov.uk


On 3 Oct 2023, at 21:25, Chris Jones  wrote:

Hi,

Just incase any one else reads this, anything you add to your user 
profile will nit have any effect on port builds, as these do not run 
as your user. So don’t try this expecting it to fix port builds.


Chris

On 2 Oct 2023, at 4:18 pm, Maxim Abalenkov 
 wrote:


Hello Murray,

How are you? As mentioned in the previous posts on this list, please 
see Apple’s comments on the new linker issue:



Xcode 15 Release Notes | Apple Developer Documentation 
<https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking>
developer.apple.com 
<https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking>


<https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking>

For now, use Xcode 15 and its command line tools and try to enforce 
the old linker by defining the following environment variables:


  export MACOSX_DEPLOYMENT_TARGET=12
  export OTHER_LDFLAGS=-Wl,-ld_classic

You may place them into your ~/.profile file. I hope this helps.

—
Best wishes,
Maxim

Maxim Abalenkov \\ maxim.abalen...@gmail.com
+44 7 486 486 505 \\ www.maxim.abalenkov.uk

On 2 Oct 2023, at 15:29, Murray Eisenberg 
 wrote:


As reported at grac.macports.org <http://grac.macports.org/>, a 
number of ports will no longer install because configure fails with 
Xcode 15, which apparently has a linker issues.


Some have suggested reverting to Xcode 14.3.1, to work around those 
issues.


But under macOS Sonoma, that does not seem to be an option: After 
replacing Xcode 15 with Xcode 14.3.1, and similarly for the 
command-line tools, if I open Xcode 14.3.1, I get an error that this 
version of Xcode will not work with the OS (Sonoma).


Is there some other work-around?

---
Murray eisenbergmurrayeisenb...@gmail.com
Mobile (413)-427-5334
503 King Farm Blvd #101
Rockville, MD 20850-6667

Re: work-around for Xcode 15 linker issue?

[Chris Jones]

Hi,Just incase any one else reads this, anything you add to your user profile will nit have any effect on port builds, as these do not run as your user. So don’t try this expecting it to fix port builds. ChrisOn 2 Oct 2023, at 4:18 pm, Maxim Abalenkov  wrote:Hello Murray,How are you? As mentioned in the previous posts on this list, please see Apple’s comments on the new linker issue:Xcode 15 Release Notes | Apple Developer Documentationdeveloper.apple.comFor now, use Xcode 15 and its command line tools and try to enforce the old linker by defining the following environment variables:  export MACOSX_DEPLOYMENT_TARGET=12  export OTHER_LDFLAGS=-Wl,-ld_classicYou may place them into your ~/.profile file. I hope this helps.—Best wishes,Maxim
Maxim Abalenkov \\ maxim.abalen...@gmail.com+44 7 486 486 505 \\ www.maxim.abalenkov.uk

On 2 Oct 2023, at 15:29, Murray Eisenberg  wrote:As reported at grac.macports.org, a number of ports will no longer install because configure fails with Xcode 15, which apparently has a linker issues.Some have suggested reverting to Xcode 14.3.1, to work around those issues.But under macOS Sonoma, that does not seem to be an option: After replacing Xcode 15 with Xcode 14.3.1, and similarly for the command-line tools, if I open Xcode 14.3.1, I get an error that this version of Xcode will not work with the OS (Sonoma).Is there some other work-around?
---Murray Eisenberg		murrayeisenb...@gmail.comMobile (413)-427-5334503 King Farm Blvd #101		Rockville, MD 20850-6667	

Re: work-around for Xcode 15 linker issue?

[Chris Jones]

On 3 Oct 2023, at 9:03 pm, Murray Eisenberg  wrote:Several ports I had been trying tore-ininstall under macOS Sonoma (in order to re-install, finally, maxima and wxMaxima,still seem to be failing configuration, even though I did add the two exports to my ~/.profile (and, of course, after restarting the shell), namely:ipopt, sbcl, scalapack, scotchI've updated existiing, or filed new, tickets about that.Anything else to try?Adding those exports to your personal profile was never going to help with macports builds, as those builds do not run as your user, but the macports one. So its not surprising they did not help.The only real way forward is for affected ports to be updated to explicitly use the classic linker option. If trac tickets do not exist for the issues you see please submit them so the maintainers in question can take a look.ChrisOn Oct 2023 16:18:25 +0100, Maxim Abalenkov  wrote:... As mentioned in the previous posts on this list, please see Apple?s comments on the new linker issue:https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking?Xcode 15 Release Notes | Apple Developer Documentationdeveloper.apple.comFor now, use Xcode 15 and its command line tools and try to enforce the old linker by defining the following environment variables: export MACOSX_DEPLOYMENT_TARGET=12 export OTHER_LDFLAGS=-Wl,-ld_classicYou may place them into your ~/.profile file. I hope this helps.On 2 Oct 2023, at 15:29, Murray Eisenberg  wrote:As reported at grac.macports.org , a number of ports will no longer install because configure fails with Xcode 15, which apparently has a linker issues.Some have suggested reverting to Xcode 14.3.1, to work around those issues.But under macOS Sonoma, that does not seem to be an option: After replacing Xcode 15 with Xcode 14.3.1, and similarly for the command-line tools, if I open Xcode 14.3.1, I get an error that this version of Xcode will not work with the OS (Sonoma).Is there some other work-around?
---Murray Eisenberg		murrayeisenb...@gmail.comMobile (413)-427-5334503 King Farm Blvd #101		Rockville, MD 20850-6667	

Re: Unable to build clang-14 under Sonoma

[Chris Jones]

Hi,

You haven’t posted enough information for anyone to really help. We need to see 
the complete log file.

However, before that, please first make sure your ports are completely up to 
date, as some fixes have recently gone in for clang 14 that should have 
resolved build issues on the new OS. If you still have problems, do not post 
the log here but please open a trac ticket instead and attach the complete log 
there.

Chris

> On 30 Sep 2023, at 4:06 pm, Artemio González López via macports-users 
>  wrote:
> 
> 
> When trying to rebuild my MacPort ports after installing MacOS 14 (Sonoma) in 
> an M1 MacBook Pro (arm), clang-14 failed to build with the following error 
> message 
> 
> make[2]: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-14/clang-14/work/build'
> [ 25%] Built target generate-cxx-headers
> make[1]: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-14/clang-14/work/build'
> make: *** [all] Error 2
> make: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-14/clang-14/work/build'
> Command failed:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-14/clang-14/work/build"
>  && /usr/bin/make -j8 -w all VERBOSE=ON 
> Exit code: 2
> Error: Failed to build clang-14: command execution failed
> DEBUG: Error code: CHILDSTATUS 26982 2
> DEBUG: Backtrace: command execution failed
> while executing
> "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
> invoked from within
> "command_exec -callback portprogress::target_progress_callback build"
> (procedure "portbuild::build_main" line 8)
> invoked from within
> "$procedure $targetname"
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-14/clang-14/main.log
>  for details.
> Error: Follow https://guide.macports.org/#project.tickets if you believe 
> there is a bug.
> Error: Processing of port emacs failed
> 
> Is there any known workaround for this?
> 
> Thanks in advance,
> 
> Artemio
> 
> 
> Artemio Gonzalez Lopez
> artem...@mac.com
> 
> 
> 
> Artemio Gonzalez Lopez
> artem...@mac.com
> 

Re: how do I fix this?

[Chris Jones]

> On 29 Sep 2023, at 4:49 am, Kenneth Wolcott  wrote:
> 
> sudo port diagnose
> Warning: No Xcode version info was found for your OS version.

Try reinstalling Xcode….

> 
> Thanks,
> Ken Wolcott

Re: Sonoma support?

[Chris Jones]

> On 26 Sep 2023, at 10:18 pm, Chris Jones  wrote:
> 
> 
> 
>>> On 26 Sep 2023, at 10:05 pm, Dave Horsfall  wrote:
>>> 
>>> On Tue, 26 Sep 2023, Chris Jones wrote:
>>> 
>>> B.t.w. Ryan sent a detailed email on this very point only last week.
>>> Please go back read the thread “ Timing of MacPorts Support for New
>>> macOS Versions” before posting any further follow up questions.
>> 
>> Odd; I never saw it...  Anyone else not see it?
> 
> Do you not see it now ?
> 
> It was on the users list just as this discussion, so there is no reason i can 
> see you would not have reciprocated it, if you are getting these emails to 
> the very same email group…

… have RECEIVED it…

Damn auto correct..

> 
> Chris
> 
>> 
>> -- Dave

Re: Sonoma support?

[Chris Jones]

> On 26 Sep 2023, at 10:05 pm, Dave Horsfall  wrote:
> 
> On Tue, 26 Sep 2023, Chris Jones wrote:
> 
>> B.t.w. Ryan sent a detailed email on this very point only last week.
>> Please go back read the thread “ Timing of MacPorts Support for New
>> macOS Versions” before posting any further follow up questions.
> 
> Odd; I never saw it...  Anyone else not see it?

Do you not see it now ?

It was on the users list just as this discussion, so there is no reason i can 
see you would not have reciprocated it, if you are getting these emails to the 
very same email group…

Chris

> 
> -- Dave

Re: Sonoma support?

[Chris Jones]

B.t.w. Ryan sent a detailed email on this very point only last week. Please go 
back read the thread “ Timing of MacPorts Support for New macOS Versions” 
before posting any further follow up questions.

> On 26 Sep 2023, at 9:48 pm, Chris Jones  wrote:
> 
> 
> 
> 
>>> On 26 Sep 2023, at 9:44 pm, Murray Eisenberg  
>>> wrote:
>>> 
>> So I guess my question should be refined to: When might the Sonoma 
>> installer become available?
> 
> That is indeed an entirely different question.
> 
>> 
>>> On Sep 26, 2023, at 4:42 PM, Chris Jones  wrote:
>>> 
>>> 
>>> 
>>>>> On 26 Sep 2023, at 9:38 pm, Murray Eisenberg  
>>>>> wrote:
>>>>> 
>>>> But at https://trac.macports.org/wiki/Migration, step 2 if the migration 
>>>> procedure is "Reinstall MacPorts base system. To reinstall, simply install 
>>>> the base MacPorts system for your new platform." But the link on the 
>>>> latter is to https://www.macports.org/install.php, and at that page the 
>>>> newest macOS version shown is Ventura.
>>>> 
>>>> Hence my question.
>>>> 
>>>> I certainly do not want to rebuild MacPorts from source.
>>> 
>>> That page lists numerous options for installing macports, which includes 
>>> building from source and which is an entirely valid option. If you choose 
>>> not to follow that route that is indeed a choice you are free totake, but 
>>> then you will have to wait until the installer is made available. I was 
>>> simply pointing out waiting for that installer is not a requirement, if you 
>>> just follow the install from source instructions instead, which frankly are 
>>> not at all hard to follow.
>>> 
>>> Chris
>>> 
>>>> 
>>>>> On Sep 26, 2023, at 4:33 PM, Chris Jones  wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> The installers are just there for convenience, they are not a necessity 
>>>>> for using MacPorts on any given OS, as you can also just follow the 
>>>>> install from source instructions to install and use macports on any OS. 
>>>>> These work, for the most part, on any OS release, including the early 
>>>>> beta versions. I for one always using the route installing form git as I 
>>>>> prefer to follow base  development more closely.
>>>>> 
>>>>> Chris
>>>>> 
>>>>>>> On 26 Sep 2023, at 9:24 pm, Murray Eisenberg 
>>>>>>>  wrote:
>>>>>>> 
>>>>>> What is the status of MacPorts support for the just-released macOS 
>>>>>> Sonoma (14.0)?
>>>>>> 
>>>>>> The  latest MacPorts installer listed at 
>>>>>> https://www.macports.org/install.php is for Ventura (13.x).
>>>>>> 
>>>>>> ---
>>>>>> Murray Eisenberg murrayeisenb...@gmail.com
>>>>>> Mobile (413)-427-5334
>>>>>> 503 King Farm Blvd #101  
>>>>>> Rockville, MD 20850-6667 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> ---
>>>> Murray Eisenberg   murrayeisenb...@gmail.com
>>>> Mobile (413)-427-5334
>>>> 503 King Farm Blvd #101
>>>> Rockville, MD 20850-6667   
>>>> 
>>>> 
>>>> 
>> 
>> ---
>> Murray Eisenberg murrayeisenb...@gmail.com
>> Mobile (413)-427-5334
>> 503 King Farm Blvd #101  
>> Rockville, MD 20850-6667 
>> 
>> 
>> 

Re: Sonoma support?

[Chris Jones]

> On 26 Sep 2023, at 9:44 pm, Murray Eisenberg  
> wrote:
> 
> So I guess my question should be refined to: When might the Sonoma installer 
> become available?

That is indeed an entirely different question.

> 
>>> On Sep 26, 2023, at 4:42 PM, Chris Jones  wrote:
>>> 
>>> 
>>> 
>>>> On 26 Sep 2023, at 9:38 pm, Murray Eisenberg  
>>>> wrote:
>>>> 
>>> But at https://trac.macports.org/wiki/Migration, step 2 if the migration 
>>> procedure is "Reinstall MacPorts base system. To reinstall, simply install 
>>> the base MacPorts system for your new platform." But the link on the latter 
>>> is to https://www.macports.org/install.php, and at that page the newest 
>>> macOS version shown is Ventura.
>>> 
>>> Hence my question.
>>> 
>>> I certainly do not want to rebuild MacPorts from source.
>> 
>> That page lists numerous options for installing macports, which includes 
>> building from source and which is an entirely valid option. If you choose 
>> not to follow that route that is indeed a choice you are free totake, but 
>> then you will have to wait until the installer is made available. I was 
>> simply pointing out waiting for that installer is not a requirement, if you 
>> just follow the install from source instructions instead, which frankly are 
>> not at all hard to follow.
>> 
>> Chris
>> 
>>> 
>>>> On Sep 26, 2023, at 4:33 PM, Chris Jones  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> The installers are just there for convenience, they are not a necessity 
>>>> for using MacPorts on any given OS, as you can also just follow the 
>>>> install from source instructions to install and use macports on any OS. 
>>>> These work, for the most part, on any OS release, including the early beta 
>>>> versions. I for one always using the route installing form git as I prefer 
>>>> to follow base  development more closely.
>>>> 
>>>> Chris
>>>> 
>>>>>> On 26 Sep 2023, at 9:24 pm, Murray Eisenberg  
>>>>>> wrote:
>>>>>> 
>>>>> What is the status of MacPorts support for the just-released macOS 
>>>>> Sonoma (14.0)?
>>>>> 
>>>>> The  latest MacPorts installer listed at 
>>>>> https://www.macports.org/install.php is for Ventura (13.x).
>>>>> 
>>>>> ---
>>>>> Murray Eisenberg  murrayeisenb...@gmail.com
>>>>> Mobile (413)-427-5334
>>>>> 503 King Farm Blvd #101   
>>>>> Rockville, MD 20850-6667  
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> ---
>>> Murray Eisenbergmurrayeisenb...@gmail.com
>>> Mobile (413)-427-5334
>>> 503 King Farm Blvd #101 
>>> Rockville, MD 20850-6667
>>> 
>>> 
>>> 
> 
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com
> Mobile (413)-427-5334
> 503 King Farm Blvd #101   
> Rockville, MD 20850-6667  
> 
> 
> 

Re: Sonoma support?

[Chris Jones]

> On 26 Sep 2023, at 9:38 pm, Murray Eisenberg  
> wrote:
> 
> But at https://trac.macports.org/wiki/Migration, step 2 if the migration 
> procedure is "Reinstall MacPorts base system. To reinstall, simply install 
> the base MacPorts system for your new platform." But the link on the latter 
> is to https://www.macports.org/install.php, and at that page the newest macOS 
> version shown is Ventura.
> 
> Hence my question.
> 
> I certainly do not want to rebuild MacPorts from source.

That page lists numerous options for installing macports, which includes 
building from source and which is an entirely valid option. If you choose not 
to follow that route that is indeed a choice you are free totake, but then you 
will have to wait until the installer is made available. I was simply pointing 
out waiting for that installer is not a requirement, if you just follow the 
install from source instructions instead, which frankly are not at all hard to 
follow.

Chris

> 
>> On Sep 26, 2023, at 4:33 PM, Chris Jones  wrote:
>> 
>> Hi,
>> 
>> The installers are just there for convenience, they are not a necessity for 
>> using MacPorts on any given OS, as you can also just follow the install from 
>> source instructions to install and use macports on any OS. These work, for 
>> the most part, on any OS release, including the early beta versions. I for 
>> one always using the route installing form git as I prefer to follow base  
>> development more closely.
>> 
>> Chris
>> 
>>>> On 26 Sep 2023, at 9:24 pm, Murray Eisenberg  
>>>> wrote:
>>>> 
>>> What is the status of MacPorts support for the just-released macOS Sonoma 
>>> (14.0)?
>>> 
>>> The  latest MacPorts installer listed at 
>>> https://www.macports.org/install.php is for Ventura (13.x).
>>> 
>>> ---
>>> Murray Eisenbergmurrayeisenb...@gmail.com
>>> Mobile (413)-427-5334
>>> 503 King Farm Blvd #101 
>>> Rockville, MD 20850-6667
>>> 
>>> 
>>> 
> 
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com
> Mobile (413)-427-5334
> 503 King Farm Blvd #101   
> Rockville, MD 20850-6667  
> 
> 
> 

Re: Sonoma support?

[Chris Jones]

Hi,

The installers are just there for convenience, they are not a necessity for 
using MacPorts on any given OS, as you can also just follow the install from 
source instructions to install and use macports on any OS. These work, for the 
most part, on any OS release, including the early beta versions. I for one 
always using the route installing form git as I prefer to follow base  
development more closely.

Chris

> On 26 Sep 2023, at 9:24 pm, Murray Eisenberg  
> wrote:
> 
> What is the status of MacPorts support for the just-released macOS Sonoma 
> (14.0)?
> 
> The  latest MacPorts installer listed at https://www.macports.org/install.php 
> is for Ventura (13.x).
> 
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com
> Mobile (413)-427-5334
> 503 King Farm Blvd #101   
> Rockville, MD 20850-6667  
> 
> 
> 

Re: Exa port dependencies

[Chris Jones]

Hi,

I agree they should be the default, ‘by default’, but there are some ports 
which have a docs variant that drags in minimum build deps and thus having 
enable by default is probably fine. Anything though that drags in pandoc and 
the vast array of deps it needs should probably be optional…

Chris

> On 9 Jun 2023, at 3:16 pm, Ken Cunningham  
> wrote:
> 
> I have long thought the doc variants should never be the default.
> 
> Lots of bloat and extra deps and build errors.
> 
> But I know others feel differently.
> 
> I know I can set -doc in variants.conf, but then you’re building everything.
> 
> 
> K
> 
>> On Jun 9, 2023, at 04:01, Joshua Root  wrote:
>> 
>> 
>>> 
>>> The list below is the current list of build dependencies when I do a
>>> port install of "exa +doc+git". The list seems pretty ridiculous though.
>>> I just cloned the exa repository and did a cargo build outside macports.
>>> None of these dependencies are required.
>> The vast majority of those are dependencies of pandoc, which is used by the 
>> exa port's doc variant. They won't be installed when installing exa from a 
>> binary archive. If you need to build locally and don't want all these deps, 
>> you can use -doc.
>> 
>> - Josh
>> 

Re: MacPorts Update Outdated Choking on libgcc9

[Chris Jones]

Hi,

gcc9 is indeed not available on 10.14.6

Uninstall it and libgcc9

> sudo port uninstall libgcc9 gcc9

if that complains because some port still thinks it needs it, then most 
likely you have that port (or port) installed with a old out of date 
variant. You will need to reinstall those ports with a newer variant 
(just use the defaults).


cheers Chris

On 20/03/2023 11:07 pm, Christopher Stone wrote:

Hey Folks,

Forgive me if this is well known – I've found some hits on “libgcc9” but 
nothing that's helped me fix the problem.


macOS 10.14.6
Xcode 11.3.1
2012 MacBook Air i7



I'm trying to upgrade my outdated ports...

sudo port -v selfupdate
sudo port -u -v upgrade outdated

Here's where it seems to be choking:



--->  Fetching distfiles for libgcc9
Error: gcc9 9.5.0 is not supported on Darwin 18 i386
Error: Failed to fetch libgcc9: incompatible macOS version



And that seems to be blocking all of these from getting updated:

The following installed ports are outdated:
libgcc9                        9.4.0_0 < 9.5.0_2
libmagic                       5.41_0 < 5.44_0
libpcap                        1.10.1_0 < 1.10.3_0
libutf8proc                    2.6.1_0 < 2.8.0_0
meson                          0.59.3_0 < 1.0.1_0
nasm                           2.15.05_0 < 2.16.01_0
ninja                          1.10.2_4 < 1.11.1_1
nmap                           7.92_3 < 7.93_0
nodejs17                       17.9.0_0 < 17.9.1_4
openssl11                      1.1.1n_0 < 1.1.1t_0
p5.28-cgi                      4.540.0_0 < 4.560.0_0
p5.28-clone                    0.450.0_0 < 0.460.0_0
p5.28-encode                   3.170.0_0 < 3.190.0_0
p5.28-html-parser              3.780.0_0 < 3.810.0_0
p5.28-http-message             6.360.0_0 < 6.440.0_0
p5.28-io-socket-ssl            2.74.0_0 < 2.81.0_0
p5.28-mozilla-ca               20211001_0 < 20221114_0
p5.28-test-warn                0.360.0_0 < 0.370.0_0
p5.28-uri                      5.100.0_0 < 5.170.0_0
pip_select                     0.1_2 < 0.1_3
py39-importlib-metadata        4.11.3_0 < 6.0.0_0
py39-mako                      1.2.0_0 < 1.2.4_0
py39-markdown                  3.3.7_0 < 3.4.1_0
py39-pip                       22.1_0 < 23.0.1_0
py39-pycryptodome              3.14.1_0 < 3.16.0_0
py39-setuptools                62.2.0_0 < 67.6.0_0
py39-zipp                      3.8.0_0 < 3.15.0_0
py310-pycryptodome             3.14.1_0 < 3.16.0_0
py310-setuptools               65.7.0_0 < 67.6.0_0
py311-setuptools               67.5.1_0 < 67.6.0_0
python39                       3.9.12_1 < 3.9.16_0



Any assistance would be greatly appreciated.

--
Best Regards,
Chris

Re: Ventura builders

[Chris Jones]

> On 28 Dec 2022, at 3:20 pm, Julien Salort  wrote:
> 
> Hello,
> 
> Forgive me if this is documented and I didn't find out. I just updated to 
> Ventura, and reinstalled MacPorts (as I always do when I upgrade the OS).
> 
> I notice that everything gets compiled from source.
> 
> Is it because there are no Ventura builders, or did I do something wrong ?

You don’t mention what architecture you are running ?

Builders are now available for x86_64 but not arm64 yet.

 https://build.macports.org/waterfall

Chris

> 
> Thanks,
> 
> Cheers,
> 
> Julien
> 

Re: building audacity from source fails

[Chris Jones]

> On 25 Dec 2022, at 1:40 am, Kenneth Wolcott  wrote:
> 
> Hi;
> 
>  I tried to build audacity from source on my Mac Mini (M1 chip) and it failed.
> 
>  Compressed log file attached.

 https://guide.macports.org/#project.tickets


> 
> Thanks,
> Ken Wolcott
> 

Re: "enscript" no longer working (fwd)

[Chris Jones]

I have no definite suggestions but just looking at

 https://ports.macports.org/port/enscript/builds/

I see the builds for old OSes are themselves a good few years old now. Its 
possible I guess something else has updated that broke the port, and perhaps 
forcing a rebuild from source might help. Have you tried forcing a build from 
source ?

Chris

> On 21 Dec 2022, at 8:22 pm, Dave Horsfall  wrote:
> 
> Anyone?  I'm guessing that an update to a library broke something...
> 
> -- Dave
> 
> -- Forwarded message --
> Date: Mon, 19 Dec 2022 12:44:47 +1100 (EST)
> From: Dave Horsfall 
> To: macports-users 
> Subject: "enscript" no longer working
> 
> MacPorts 2.8.0 on High Sierra.
> 
> Has anyone else found that "enscript" has stopped working after some 
> software update or other?  The symptom is that nothing is being printed, 
> although I can redirect the output to a file and print that instead so 
> it's obviously generating the correct PS output.
> 
> The installed version of "enscript" is 1.6.6, and reinstalling it makes no 
> difference; when I specify a dummy script in place of "lpr" it gets 
> invoked as it should, so the spawning mechanism seems to be OK.
> 
> Because it's a bit inconvenient to disable SIP right now I cannot trace 
> the thing to see exactly what's broken, so has anyone else noticed this 
> and can track it to a particular MP update?
> 
> Thanks.
> 
> -- Dave

Re: evince post install launch tweaks help needed

[Chris Jones]

> On 19 Dec 2022, at 12:31 pm, chilli.names...@gmail.com wrote:
> 
> oops, probably want to add
> 
> sudo port install xorg-server
> 
> 
> so, altogether, 
> 
> sudo port install xorg xorg-server; sudo port load dbus

If all you need is a X server, then installing everything brought in by ‘xorg’ 
is completely unnecessary. Just install xorg-server.

> 
> Log out. Log in.
> 
>> On Dec 19, 2022, at 07:03, chilli.names...@gmail.com wrote:
>> 
>> I just went through this on Mountain Lion and Mojave. I believe it's
>> 
>> sudo port install xorg
>> 
>> Installs XQuartz X11.app in /Applications/MacPorts
>> but I think also may need to 
>> 
>> sudo port load dbus
>> 
>> and log out and back in again.
>> 
>> IMO, Homebrew is a bloody mess. Good luck uninstalling it. Probably easier 
>> to reformat and reinstall the system. I don't understand the attraction to 
>> it. It's an exceptionally poor implementation of a package management system.
>> 
 On Dec 18, 2022, at 23:46, Kenneth Wolcott  
 wrote:
>>> 
>>> Hi;
>>> 
>>> I running MacPorts with MacOS Ventura 13.1 w/ M1 CPU.
>>> 
>>> I had previously installed evince but was getting periodic flashing
>>> on-and-off when trying to view a postscript file.
>>> 
>>> So I re-installed evince from source and the following is the output
>>> from the install.  I don't know how to make certain that evince will
>>> launch properly.
>>> 
>>> I installed xQuartz from homebrew, I'm not certain how to get an
>>> XWindows environment properly set up using MacPorts.  Perhaps that is
>>> part of my problem.
>>> 
>>> Thanks,
>>> Ken Wolcott
>>> 
>>> Warning: Schema “org.gnome.system.locale” has path “/system/locale/”.
>>> Paths starting with “/apps/”, “/desktop/” or “/system/” are
>>> deprecated.
>>> Warning: Schema “org.gnome.system.proxy” has path “/system/proxy/”.
>>> Paths starting with “/apps/”, “/desktop/” or “/system/” are
>>> deprecated.
>>> Warning: Schema “org.gnome.system.proxy.http” has path
>>> “/system/proxy/http/”.  Paths starting with “/apps/”, “/desktop/” or
>>> “/system/” are deprecated.
>>> Warning: Schema “org.gnome.system.proxy.https” has path
>>> “/system/proxy/https/”.  Paths starting with “/apps/”, “/desktop/” or
>>> “/system/” are deprecated.
>>> Warning: Schema “org.gnome.system.proxy.ftp” has path
>>> “/system/proxy/ftp/”.  Paths starting with “/apps/”, “/desktop/” or
>>> “/system/” are deprecated.
>>> Warning: Schema “org.gnome.system.proxy.socks” has path
>>> “/system/proxy/socks/”.  Paths starting with “/apps/”, “/desktop/” or
>>> “/system/” are deprecated.
>>> --->  Cleaning evince
>>> --->  Removing work directory for evince
>>> --->  Scanning binaries for linking errors
>>> --->  No broken files found.
>>> --->  No broken ports found.
>>> ~: evince ~/Blowin_in_the_Wind.ps
>>> dbus[29961]: Dynamic session lookup supported but failed: launchd did
>>> not provide a socket path, verify that
>>> org.freedesktop.dbus-session.plist is loaded!

Re: ports not working with sudo

[Chris Jones]

selfupdate requires sudo. try

sudo /opt/local/bin/port -v selfupdate

On 09/12/2022 1:16 pm, Kaustubh Bansal wrote:

I get following error

$ port 
Error: Insufficient privileges to write to MacPorts install prefix.


On Fri, Dec 9, 2022 at 1:49 PM chilli.names...@gmail.com 
 > wrote:


Try

port -v selfupdate

then try to install clang-15 again?

 > On Dec 9, 2022, at 07:40, Kaustubh Bansal
mailto:kaustubh.c...@gmail.com>> wrote:
 >
 > 
 > Hi
 >
 > I recently installed MacPorts on my machine (MacOs Ventura 13.0)
 > Installation succeeded.
 > I then added /opt/local/bin to PATH
 >
 > I am trying to install clang-15.
 >
 > Command:
 > $ sudo port install clang-15
 > Message: sudo: port: command not found
 >
 > Command:
 > $ port install clang-15
 > Message: Error: Insufficient privileges to write to MacPorts
install prefix.
 >
 > Command:
 > $ which port
 > Message: /opt/local/bin/port
 >
 > Any idea why por does not work with sudo?
 >
 > Thanks
 >
 >

Re: Installing Grace on Ventura fails due to llvm-10 configure failure: command execution failed

[Chris Jones]

Hi,

Your snippet below indicates that in fact you have not installed all the 
dependencies of grace, as it is failing in building llvm-10. Please run

port rdeps grace

To identify which port in the dependency tree of grace is bringing this in.

llvm-10 is quite old at this point, and only time will tell if building it on 
macOS13 will be possible or not. Ideally, it would be best to update whatever 
port is requiring this to use a newer llvm version.

Chris

> On 15 Nov 2022, at 9:59 pm, Vahid Askarpour  wrote:
> 
> Dear MacPorts Users,
> 
> MacPorts installs all the dependencies of Grace successfully but the 
> following error occurs while building Grace:
> 
> Configuring llvm-10
> Error: Failed to configure llvm-10: consult 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-10/llvm-10/work/build/CMakeFiles/CMakeError.log
> Error: Failed to configure llvm-10: configure failure: command execution 
> failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-10/llvm-10/main.log
>  for details.
> Error: rev-upgrade failed: Error rebuilding llvm-10
> 
> I have installed MacPorts for Ventura and Xcode 14.1.  Attached please see 
> the log file for the Error.
> 
> A similar ticket #66265 reports similar error for llvm-9.0.
> 
> Thanks you,
> Vahid
> 
> 

Re: C compiler not found after upgrade to macOS 13.0.1

[Chris Jones]

Looks like your ports are not up to date, please run

> sudo port -d sync
> sudo port upgrade outdated

Then report back.

> On 10 Nov 2022, at 7:12 pm, Artemio González López  wrote:
> 
> 
> 
>>> On 10 Nov 2022, at 20:05, Chris Jones  wrote:
>>> 
>>> Does
>>> 
>>>  /opt/local/lib/libicui18n.71.dylib
>>> 
>>> Actually exist in your system ?
>> 
>> No, but
>> 
>> /opt/local/lib/libicui18n.72.dylib
>> 
>> does. Also,
>> 
>> rtemio@mbp-13 ~ % otool -L /opt/local/lib/libxml2.2.dylib
>>   
>> /opt/local/lib/libxml2.2.dylib:
>>  /opt/local/lib/libxml2.2.dylib (compatibility version 13.0.0, current 
>> version 13.3.0)
>>  /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current 
>> version 1.2.13)
>>  /opt/local/lib/liblzma.5.dylib (compatibility version 8.0.0, current 
>> version 8.7.0)
>>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
>> version 1319.0.0)
>>  /opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current 
>> version 9.1.0)
>>  /opt/local/lib/libicui18n.71.dylib (compatibility version 71.0.0, 
>> current version 71.1.0)
>>  /opt/local/lib/libicuuc.71.dylib (compatibility version 71.0.0, current 
>> version 71.1.0)
>>  /opt/local/lib/libicudata.71.dylib (compatibility version 71.0.0, 
>> current version 71.1.0)
>> 
>> However, I am embarrassed to say that the problem with the compiler seems to 
>> have been cause by not updating the path to Xcode after replacing the RC2 by 
>> the final version. Indeed, after executing
>> 
>> sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer 
>> 
>> And doing a port update clang seems to be working again! (The Emacs.app 
>> problem still persists, though).
>> 
>> Sorry for the snafu,
>> 
>> Artemio
>> 
>>>> On 10 Nov 2022, at 7:02 pm, Artemio González López via macports-users 
>>>>  wrote:
>>>> 
>>> 
>>>> On 10 Nov 2022, at 18:52, Artemio González López  wrote:
>>>> 
>>>> After upgrading to macOS 13.0.1 (on an M1 MacBook Pro), port cannot find 
>>>> any C compiler:
>>>> 
>>>> checking for gcc... /opt/local/bin/clang-mp-14
>>>> checking whether the C compiler works... no
>>>> configure: error: in 
>>>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_libxml2/libxml2/work/libxml2-2.10.3':
>>>> configure: error: C compiler cannot create executables
>>>> 
>>>> However, the CLT seems to be installed:
>>>> 
>>>> artemio@mbp-13 ~ % pkgutil 
>>>> --pkg-info=com.apple.pkg.{CLTools_Executables,CLTools_Base,DeveloperToolsCLI,DeveloperToolsCLILeo}
>>>>  2>/dev/null | sed -n 's/^version: //p'
>>>> 14.1.0.0.1.1666437224
>>>> 
>>>> Does anybody know what’s going on here? (any help would be much 
>>>> appreciated!)
>>>> 
>>>> Thanks in advance,
>>>> 
>>>> Artemio
>>>> 
>>>> 
>>>> Artemio Gonzalez Lopez
>>>> artem...@mac.com
>>>> 
>>> 
>>> Actually, this problem is also related to the icu library referenced from 
>>> libxml. Indeed, looking in Console.app I found a bunch of clang crashes 
>>> (basically every time it was called in the configure process) like the 
>>> following:
>>> 
>>> Crashed Thread:0
>>> 
>>> Exception Type:EXC_CRASH (SIGABRT)
>>> Exception Codes:   0x, 0x
>>> 
>>> Termination Reason:Namespace DYLD, Code 1 Library missing
>>> Library not loaded: /opt/local/lib/libicui18n.71.dylib
>>> Referenced from: <45F9A0DF-B06D-34C8-946F-88FFA574E722> 
>>> /opt/local/lib/libxml2.2.dylib
>>> Reason: tried: '/opt/local/lib/libicui18n.71.dylib' (no such file), 
>>> '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libicui18n.71.dylib' 
>>> (no such file), '/opt/local/lib/libicui18n.71.dylib' (no such file), 
>>> '/usr/local/lib/libicui18n.71.dylib' (no such file), 
>>> '/usr/lib/libicui18n.71.dylib' (no such file, not in dyld cache)
>>> 
>>> Cheers,
>>> 
>>> Artemio
>>> 
>>> 
>>> Artemio Gonzalez Lopez
>>> artem...@mac.com
>>> 
> 
> Artemio Gonzalez Lopez
> artem...@mac.com
> 

Re: C compiler not found after upgrade to macOS 13.0.1

[Chris Jones]

Does

 /opt/local/lib/libicui18n.71.dylib

Actually exist in your system ?

> On 10 Nov 2022, at 7:02 pm, Artemio González López via macports-users 
>  wrote:
> 
> 
>> On 10 Nov 2022, at 18:52, Artemio González López  wrote:
>> 
>> After upgrading to macOS 13.0.1 (on an M1 MacBook Pro), port cannot find any 
>> C compiler:
>> 
>> checking for gcc... /opt/local/bin/clang-mp-14
>> checking whether the C compiler works... no
>> configure: error: in 
>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_libxml2/libxml2/work/libxml2-2.10.3':
>> configure: error: C compiler cannot create executables
>> 
>> However, the CLT seems to be installed:
>> 
>> artemio@mbp-13 ~ % pkgutil 
>> --pkg-info=com.apple.pkg.{CLTools_Executables,CLTools_Base,DeveloperToolsCLI,DeveloperToolsCLILeo}
>>  2>/dev/null | sed -n 's/^version: //p'
>> 14.1.0.0.1.1666437224
>> 
>> Does anybody know what’s going on here? (any help would be much appreciated!)
>> 
>> Thanks in advance,
>> 
>> Artemio
>> 
>> 
>> Artemio Gonzalez Lopez
>> artem...@mac.com
>> 
> 
> Actually, this problem is also related to the icu library referenced from 
> libxml. Indeed, looking in Console.app I found a bunch of clang crashes 
> (basically every time it was called in the configure process) like the 
> following:
> 
> Crashed Thread:0
> 
> Exception Type:EXC_CRASH (SIGABRT)
> Exception Codes:   0x, 0x
> 
> Termination Reason:Namespace DYLD, Code 1 Library missing
> Library not loaded: /opt/local/lib/libicui18n.71.dylib
> Referenced from: <45F9A0DF-B06D-34C8-946F-88FFA574E722> 
> /opt/local/lib/libxml2.2.dylib
> Reason: tried: '/opt/local/lib/libicui18n.71.dylib' (no such file), 
> '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libicui18n.71.dylib' (no 
> such file), '/opt/local/lib/libicui18n.71.dylib' (no such file), 
> '/usr/local/lib/libicui18n.71.dylib' (no such file), 
> '/usr/lib/libicui18n.71.dylib' (no such file, not in dyld cache)
> 
> Cheers,
> 
> Artemio
> 
> 
> Artemio Gonzalez Lopez
> artem...@mac.com
> 

Re: Emacs.app does not run after upgrade to macOS 13.0.1

[Chris Jones]

Please run

 > otool -L /opt/local/lib/libxml2.2.dylib

and paste the output here, and also for each lib it references check it exists 
(and recursively check with otool for the libs they use).

> On 10 Nov 2022, at 7:00 pm, Artemio González López via macports-users 
>  wrote:
> 
> 
> 
>> On 10 Nov 2022, at 19:57, Sriranga Veeraraghavan  
>> wrote:
>> 
>> Hi,
>> 
>> On my Monterey (12.6.1) system, 'port provides' says that the missing 
>> library is provided by the 'icu' port:
>> 
>> $ port provides /opt/local/lib/libicui18n.71.dylib
>> /opt/local/lib/libicui18n.71.dylib is provided by: icu
>> 
>> Perhaps the 'icu' port is not properly installed on your system (you can 
>> check with 'port installed icu').  Or you may need to rebuild it for MacOS 
>> 13.0.1.
>> 
>> Best,
>> 
>> -ranga
> 
> 
> Hi, Sriranga,
> 
> Thank you for your input. However, I’m afraid that’s not the problem, since 
> Emacs.app worked perfectly well right before the update. In any case, icu is 
> still installed:
> 
> artemio@mbp-13 ~ % port installed icu
> The following ports are currently installed:
>   icu @72.1_0 (active)
> 
> Thanks a lot anyway,
> 
> Artemio
> 
> 
> Artemio Gonzalez Lopez
> artem...@mac.com
> 

Re: Emacs.app does not run after upgrade to macOS 13.0.1

[Chris Jones]

Does libxml2 declare a dependency against icu ?On 10 Nov 2022, at 6:57 pm, Sriranga Veeraraghavan  wrote:Hi,On my Monterey (12.6.1) system, 'port provides' says that the missing library is provided by the 'icu' port:$ port provides /opt/local/lib/libicui18n.71.dylib/opt/local/lib/libicui18n.71.dylib is provided by: icuPerhaps the 'icu' port is not properly installed on your system (you can check with 'port installed icu').  Or you may need to rebuild it for MacOS 13.0.1.Best,-rangaOn Nov 10, 2022, at 10:48, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:On 10 Nov 2022, at 6:43 pm, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:Hi,Mac OS 13.0.1 predominantly addresses an issue with libxml2, so its not a coincidence i think you see something relating to this (and you aren’t the only one), Correction. The other message is also from you.I am afraid until someone else reports the same issue and is willing to investigate, you might have to do some digging yourself to figure out what is going on.Chrisalthough I cannot say how the OS update could affect macports builds of this library. I do not personally run macOS13 yet so cannot investigate, and I fear someone running this OS is going to have to do some leg work to figure out whats going on.ChrisOn 10 Nov 2022, at 5:56 pm, Artemio González López via macports-users <macports-users@lists.macports.org> wrote:After installing the 13.0.1 update on my M1 MacBooPro I emacs.app crashes on launch. Apparently, the problem is that it cannot find a library:Crashed Thread:        0Exception Type:        EXC_CRASH (SIGABRT)Exception Codes:       0x, 0xTermination Reason:    Namespace DYLD, Code 1 Library missingLibrary not loaded: /opt/local/lib/libicui18n.71.dylibReferenced from: <45F9A0DF-B06D-34C8-946F-88FFA574E722> /opt/local/lib/libxml2.2.dylibReason: tried: '/opt/local/lib/libicui18n.71.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libicui18n.71.dylib' (no such file), '/opt/local/lib/libicui18n.71.dylib' (no such file), '/usr/local/lib/libicui18n.71.dylib' (no such file), '/usr/lib/libicui18n.71.dylib' (no such file, not in dyld cache)(terminated at launch; ignore backtrace)Does anybody know how to fix this? (I depend on Emacs.app for all my LaTeX editing, so this is quite a problem for me).Thanks in advance,Artemio
Artemio Gonzalez Lopezartem...@mac.com

Re: Emacs.app does not run after upgrade to macOS 13.0.1

[Chris Jones]

> On 10 Nov 2022, at 6:43 pm, Chris Jones  wrote:
> 
> 
> Hi,
> 
> Mac OS 13.0.1 predominantly addresses an issue with libxml2, so its not a 
> coincidence i think you see something relating to this (and you aren’t the 
> only one),

Correction. The other message is also from you.

I am afraid until someone else reports the same issue and is willing to 
investigate, you might have to do some digging yourself to figure out what is 
going on.

Chris

> although I cannot say how the OS update could affect macports builds of this 
> library. 
> 
> I do not personally run macOS13 yet so cannot investigate, and I fear someone 
> running this OS is going to have to do some leg work to figure out whats 
> going on.
> 
> Chris
> 
>>> On 10 Nov 2022, at 5:56 pm, Artemio González López via macports-users 
>>>  wrote:
>>> 
>> After installing the 13.0.1 update on my M1 MacBooPro I emacs.app crashes 
>> on launch. Apparently, the problem is that it cannot find a library:
>> 
>> Crashed Thread:0
>> 
>> Exception Type:EXC_CRASH (SIGABRT)
>> Exception Codes:   0x, 0x
>> 
>> Termination Reason:Namespace DYLD, Code 1 Library missing
>> Library not loaded: /opt/local/lib/libicui18n.71.dylib
>> Referenced from: <45F9A0DF-B06D-34C8-946F-88FFA574E722> 
>> /opt/local/lib/libxml2.2.dylib
>> Reason: tried: '/opt/local/lib/libicui18n.71.dylib' (no such file), 
>> '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libicui18n.71.dylib' (no 
>> such file), '/opt/local/lib/libicui18n.71.dylib' (no such file), 
>> '/usr/local/lib/libicui18n.71.dylib' (no such file), 
>> '/usr/lib/libicui18n.71.dylib' (no such file, not in dyld cache)
>> (terminated at launch; ignore backtrace)
>> 
>> Does anybody know how to fix this? (I depend on Emacs.app for all my LaTeX 
>> editing, so this is quite a problem for me).
>> 
>> Thanks in advance,
>> 
>> Artemio
>> 
>> 
>> Artemio Gonzalez Lopez
>> artem...@mac.com
>> 

Re: Emacs.app does not run after upgrade to macOS 13.0.1

[Chris Jones]

Hi,

Mac OS 13.0.1 predominantly addresses an issue with libxml2, so its not a 
coincidence i think you see something relating to this (and you aren’t the only 
one), although I cannot say how the OS update could affect macports builds of 
this library. 

I do not personally run macOS13 yet so cannot investigate, and I fear someone 
running this OS is going to have to do some leg work to figure out whats going 
on.

Chris

> On 10 Nov 2022, at 5:56 pm, Artemio González López via macports-users 
>  wrote:
> 
> After installing the 13.0.1 update on my M1 MacBooPro I emacs.app crashes on 
> launch. Apparently, the problem is that it cannot find a library:
> 
> Crashed Thread:0
> 
> Exception Type:EXC_CRASH (SIGABRT)
> Exception Codes:   0x, 0x
> 
> Termination Reason:Namespace DYLD, Code 1 Library missing
> Library not loaded: /opt/local/lib/libicui18n.71.dylib
> Referenced from: <45F9A0DF-B06D-34C8-946F-88FFA574E722> 
> /opt/local/lib/libxml2.2.dylib
> Reason: tried: '/opt/local/lib/libicui18n.71.dylib' (no such file), 
> '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libicui18n.71.dylib' (no 
> such file), '/opt/local/lib/libicui18n.71.dylib' (no such file), 
> '/usr/local/lib/libicui18n.71.dylib' (no such file), 
> '/usr/lib/libicui18n.71.dylib' (no such file, not in dyld cache)
> (terminated at launch; ignore backtrace)
> 
> Does anybody know how to fix this? (I depend on Emacs.app for all my LaTeX 
> editing, so this is quite a problem for me).
> 
> Thanks in advance,
> 
> Artemio
> 
> 
> Artemio Gonzalez Lopez
> artem...@mac.com
> 

Re: C compiler not found after upgrade to macOS 13.0.1

[Chris Jones]

> On 10 Nov 2022, at 5:53 pm, Artemio González López via macports-users 
>  wrote:
> 
> After upgrading to macOS 13.0.1 (on an M1 MacBook Pro),

Upgrading from what OS ?

> port cannot find any C compiler:
> 
> checking for gcc... /opt/local/bin/clang-mp-14
> checking whether the C compiler works... no
> configure: error: in 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_libxml2/libxml2/work/libxml2-2.10.3':
> configure: error: C compiler cannot create executables
> 
> However, the CLT seems to be installed:
> 
> artemio@mbp-13 ~ % pkgutil 
> --pkg-info=com.apple.pkg.{CLTools_Executables,CLTools_Base,DeveloperToolsCLI,DeveloperToolsCLILeo}
>  2>/dev/null | sed -n 's/^version: //p'
> 14.1.0.0.1.1666437224
> 
> Does anybody know what’s going on here? (any help would be much appreciated!)
> 
> Thanks in advance,
> 
> Artemio
> 
> 
> Artemio Gonzalez Lopez
> artem...@mac.com
> 

Re: how to move "Python Launcher" away from /Application folder?

[Chris Jones]

May I ask, what exactly is your problem with having the Apps installed 
by MacPorts under /Applications/MacPorts ? I am not really sure I see 
what the problem is you are trying to fix.


Chris

On 09/11/2022 11:57 pm, supervisitor via macports-users wrote:

... ups, this I have probably overlooked. (have made the installation from 
source).

But before I now uninstall everything to perform a reinstall, some further 
questions:

Can I do an installation with parameter "--with-applications-dir" carefree over the 
existing installation... without losing the information about installed apps, e.g. inside 
"registry.db"?
The documentation for upgrading a source installation is described as follows 
in the documentation:
MacPorts Guide, Chapter: 2.3:
"To upgrade a copy of MacPorts that was installed from source to the newer 
release of the source code, simply repeat the source install with the newer version of 
the MacPorts source code."
But does this also apply if I specify an additional parameter like 
"--with-applications-dir"?

Or can I change the path afterwards in configuration file(s), e.g. 
'/opt/local/etc/macports/macports.conf:applications_dir
/Applications/MacPorts'?
(of course after a 'sudo mv /Applications/MacPorts /opt/local/.')

Does anyone have any experience or reliable information on this?


Thanks and cheers!




On 9 Nov 2022, at 16:54, Langer, Stephen A. (Fed)  
wrote:

Build MacPorts from source and use the --with-applications-dir option when 
configuring it.

-- Steve

-Original Message-
From: macports-users  on behalf of 
supervisitor via macports-users 
Reply-To: supervisitor 
Date: Wednesday, November 9, 2022 at 10:38 AM
To: "macports-users@lists.macports.org" 
Subject: how to move "Python Launcher" away from /Application folder?

Hi.

This "MacPorts" folder inside Applications, where the Python Launcher is inside, 
looks useless for me... but is needed when I launch "port -v upgrade outdated" from 
terminal.
=> does someone know a solution to move this folder and files inside away 
from there, best would be inside /opt/...

Cheers...

Re: Texmaker installation failed due to inability to build qt5 web engine

[Chris Jones]

Apart from the glacial place of OS update migration (*every *app and 
dependency  is downloaded and built from source),


Just on this point, if you don't want to have to build everything from 
source, then you should not update your OS before MacPorts has deployed 
buildbots for the new OS. You can check this at e.g.


https://build.macports.org/waterfall

and yes we do not yet have macOS13 in place. Ryan might be able to give 
an idea of a timeline for this.


Chris

Re: Questions on migration to macOS Ventura

[Chris Jones]

> On 25 Oct 2022, at 7:15 pm, Artemio González López  wrote:
> 
> 
>> On 25 Oct 2022, at 20:09, Chris Jones  wrote:
>> 
>> Hi,
>> 
>> Theres no reason to wait for an official installer, the build from source 
>> route works just fine, and once complete gives you functionally as good a 
>> macports installation as the installer does. If you go this route, there is 
>> also no need to reinstall once the official installer is out.
>> 
>> Also, any ports you install, regardless of how you installed macports, and 
>> perfectly valid and do not need reinstalling if you subsequently change (or 
>> e.g. update at some later time) your macports installation.
>> 
>> Cheers Chris
>> 
>>>> On 25 Oct 2022, at 6:58 pm, Artemio González López via macports-users 
>>>>  wrote:
>>>> 
>>> 
>>> I just upgraded to macOS Ventura, and would like to migrate my MacPorts 
>>> installation accordingly. However, when following the instructions at 
>>> https://trac.macports.org/wiki/Migration I realized that the MacPorts 
>>> installer for Ventura has not been released yet. My questions are the 
>>> following:
>>> 
>>> 1. Should I build MacPorts from source on my machine, or is it better to 
>>> wait for the “official” installer?
>>> 
>>> 2. Should I choose the latter option, would it be safe to keep using in the 
>>> meantime the ports I have already installed (w/o trying to update ports or 
>>> install new ones)?
>>> 
>>> Thanks a lot in advance, and thank you for your great work,
>>> 
>>> Artemio Gonzalez Lopez
>>> artem...@mac.com
>>> 
> 
> 
> Thanks a lot for your reply, Chris! If I understood correctly, even if I 
> upgrade MacPorts to the latest version (compatible with Ventura), I don’t 
> need to reinstall the ports I have previously installed under Monterey (macOS 
> 12)?

No, thats not what I said, sorry if it confused you.

Whenever you upgrade your OS to a new major version you should always reinstall 
your ports complete, as per the migration instructions.

What I said was you do not need to reinstall your ports if you first install 
them with a from source macports base install, but then switch to an installer 
base install (or upgrade base)

Chris


> 
> Thanks a lot again,
> 
> Artemio
> 
> 

Re: Questions on migration to macOS Ventura

[Chris Jones]

Hi,

Theres no reason to wait for an official installer, the build from source route 
works just fine, and once complete gives you functionally as good a macports 
installation as the installer does. If you go this route, there is also no need 
to reinstall once the official installer is out.

Also, any ports you install, regardless of how you installed macports, and 
perfectly valid and do not need reinstalling if you subsequently change (or 
e.g. update at some later time) your macports installation.

Cheers Chris

> On 25 Oct 2022, at 6:58 pm, Artemio González López via macports-users 
>  wrote:
> 
> 
> I just upgraded to macOS Ventura, and would like to migrate my MacPorts 
> installation accordingly. However, when following the instructions at 
> https://trac.macports.org/wiki/Migration I realized that the MacPorts 
> installer for Ventura has not been released yet. My questions are the 
> following:
> 
> 1. Should I build MacPorts from source on my machine, or is it better to wait 
> for the “official” installer?
> 
> 2. Should I choose the latter option, would it be safe to keep using in the 
> meantime the ports I have already installed (w/o trying to update ports or 
> install new ones)?
> 
> Thanks a lot in advance, and thank you for your great work,
> 
> Artemio Gonzalez Lopez
> artem...@mac.com
> 

Re: Guile-2.2.7

[Chris Jones]

What you report makes no sense, as openssl3 does not depend at all on guile.

If you have a problem, with either guile or openssl3 you should first 
search for an existing trac ticket for the port you have having issues 
with, and if that does not exist submit one.


https://guide.macports.org/#project.tickets

On 24/10/2022 2:43 pm, Raoul MEGELAS wrote:

Hello,

Openssl3 does not build because guile-2.2.7 fails to configure.

Here is the excerpt:
configure:4766: checking build system type
configure:4780: result: x86_64-apple-darwin21
configure:4800: checking host system type
configure:4813: result: x86_64-apple-darwin21
configure:5147: checking for x86_64-apple-darwin21-gcc
configure:5174: result: /usr/bin/clang
configure:5443: checking for C compiler version
configure:5452: /usr/bin/clang --version >&5
Apple clang version 14.0.0 (clang-1400.0.29.102)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
configure:5463: $? = 0
configure:5452: /usr/bin/clang -v >&5
Apple clang version 14.0.0 (clang-1400.0.29.102)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
configure:5463: $? = 0
configure:5452: /usr/bin/clang -V >&5
clang: error: argument to '-V' is missing (expected 1 value)
clang: error: no input files
configure:5463: $? = 1
configure:5452: /usr/bin/clang -qversion >&5
clang: error: unknown argument '-qversion'; did you mean '--version'?
clang: error: no input files
configure:5463: $? = 1

Any idea will help.
Thanks in advance

Raoul MEGELAS

Re: port history

[Chris Jones]

On 26/09/2022 4:21 pm, Ralph Seichter via macports-users wrote:

* Chris Jones:


Cloning is not not necessary for this. Just use the web interface to
navigate to the port of interest and then Examine the history for that
file.


Your assumption that the WebUI offers sufficient means of analysis is
quite a stretch, IMO. Hence my suggestion to clone the repository and
use the Git command line client.


For the purposes of the original question here, its more than good enough.

Re: port history

[Chris Jones]

> On 25 Sep 2022, at 9:10 pm, Ralph Seichter via macports-users 
>  wrote:
> 
> * chilli:
> 
>> Is it possible to see the version history of a port?
> 
> You can clone the publicly available MacPorts Git repository from
> g...@github.com:macports/macports-ports.git and then use 'git log ...'
> to examine ports/subtrees as desired.

Cloning is not not necessary for this. Just use the web interface to navigate 
to the port of interest and then Examine the history for that file. E.g.

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

> 
> -Ralph

Re: Cannot build DOSBOX

[Chris Jones]

> On 19 Sep 2022, at 5:40 am, Dave Horsfall  wrote:
> 
> Sigh; it never rains but it pours...
> 
> Trying to build DOSBOX I get:
> 
>--->  Computing dependencies for dosbox
>Error: Cannot install dosbox for the arch 'i386' because
>Error: its dependency libsdl does not build for the required arch by 
> default
>Error: and the configured universal_archs '' are not sufficient.
> 
> macports.conf:
> 
># Space-delimited list of CPU architectures to target when building
># universal. Defaults to "i386 ppc" on Mac OS X 10.5 and earlier,
># "x86_64 i386" on Mac OS X 10.6 through macOS 10.13, "x86_64" on
># macOS 10.14 and 10.15 (these SDKs are not universal), and
># "arm64 x86_64" on macOS 11 and later. Set an empty value to disable
># universal building.
>#universal_archsx86_64 i386
>universal_archs
> 
> Should I hardwire it to those?  I ain't likely to use PPC etc.

By default macports.conf does not explicitly set universal_archs at all, so you 
must have manually adding that setting yourself at some point. Presumably you 
cannot remember why ? If not, i suggest just removing it and thus go back to 
using the default settings.
> 
> I vaguely remember seeing the same thing with WINE and was going to
> report it.
> 
> -- Dave

Re: Unable to build XV

[Chris Jones]

> On 19 Sep 2022, at 4:21 am, Bill Cole 
>  wrote:
> 
> On 2022-09-18 at 21:33:32 UTC-0400 (Mon, 19 Sep 2022 11:33:32 +1000 (EST))
> Dave Horsfall 
> is rumored to have said:
> 
>> And because XV is broken I can't continue with upgrading following ports
> 
> You can get around that by explicitly excluding xv, e.g.:
> 
> port -v upgrade active and not xv

Thats not advisable, as xv needs to be rebuilt. For now, as I previously posted 
deactivating jasper before updating xv is the best option.

> 
> 
> 
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire

Re: Unable to build XV

[Chris Jones]

jasper was recently updated to provide version  3.x, previously it was 2.x

A new port jasper2 was made providing the older version, and ports like xv 
updated to use it. Unfortunately though it appears if you attempt to build xv 
whilst having the newer jasper port installed it opportunistically finds and 
uses headers from that port, and thus ends up with conflicting defines.

Until someone provides a fix for this, you can work around it by deactivating 
jasper

sudo port deactivate jasper

Then build xv. You can then reactivate jasper safely afterwards.

Chris

> On 19 Sep 2022, at 1:44 am, Dave Horsfall  wrote:
> 
> On Sun, 18 Sep 2022, Richard L. Hamilton wrote:
> 
>> I’ve not only seen that across various macOS versions, but something 
>> else broke the existing xv because one of the ports the older version 
>> depended on changed where it keeps some libraries. Specifically, the 
>> older version of xv expects
> 
> [..]
> 
> Grumble...  So I see :-(
> 
> I like XV (been using it since SunOS) so I'll try your fix.
> 
> -- Dave

Re: missing pre-compiled packages

[Chris Jones]

Hi,

Binaries aren’t available if the licenses of the port, and its dependencies, do 
not allow it.

To check if this is the case you should refer to the build logs which you can 
find from the ports site. E.g.

https://ports.macports.org/port/git

Then check the builds tab. Pick one, and then check the gather archives log

https://build.macports.org/builders/ports-12_arm64-builder/builds/61881/steps/gather-archives/logs/stdio

"git" is not distributable because its license "GPL-2" conflicts with license 
"GPL-3+" of dependency "gdbm"




> On 18 Sep 2022, at 7:32 am, Werner LEMBERG  wrote:
> 
> 
> Folks,
> 
> 
> I wonder why some pre-compiled packages are missing:
> 
> * ccache – the directory `https://packages.macports.org/ccache/` is
>  empty
> 
> * git – the directory `https://packages.macports.org/git/` doesn't
>  exist at all
> 
> If this is expected, where is it documented?
> 
> 
>   Werner

Re: Problem with rsync.macports.org mirror?

[Chris Jones]

> On 31 Jul 2022, at 9:05 am, Gerben Wierda via macports-users 
>  wrote:
> 
> 
> gerben@hermione macports-ports % sudo port -v selfupdate
> --->  Updating MacPorts base sources using rsync
> 
> Willkommen auf dem RSYNC-server auf ftp.fau.de.
> Nicht all unsere Mirror sind per rsync verfuegbar.
> 
> Welcome to the RSYNC daemon on ftp.fau.de.
> Not all of our mirrors are available through rsync.
> 
> 
> receiving file list ... done
> 
> sent 16 bytes  received 55 bytes  142.00 bytes/sec
> total size is 85861888  speedup is 1209322.37
> 
> Willkommen auf dem RSYNC-server auf ftp.fau.de.
> Nicht all unsere Mirror sind per rsync verfuegbar.
> 
> Welcome to the RSYNC daemon on ftp.fau.de.
> Not all of our mirrors are available through rsync.
> 
> 
> receiving file list ... done
> 
> sent 16 bytes  received 62 bytes  52.00 bytes/sec
> 
> Seems to be a problem. 

Why do you say that ?

> 
> Gerben Wierda (LinkedIn)
> R IT Strategy (main site)
> Book: Chess and the Art of Enterprise Architecture
> Book: Mastering ArchiMate
> 

Re: Has anyone been using Monterey 12.5 yet?

[Chris Jones]

Yes, using it just fine for a short whole now…

> On 31 Jul 2022, at 10:09 am, Gerben Wierda via macports-users 
>  wrote:
> 
> Has anyone been using Monterey 12.5 yet?
> 
> Gerben Wierda (LinkedIn)
> R IT Strategy (main site)
> Book: Chess and the Art of Enterprise Architecture
> Book: Mastering ArchiMate
> 

Re: problem compiling libzzip (PPC, Sorbet Leopard)

[Chris Jones]

On 27/07/2022 8:52 pm, Hangglider wrote:

MacOSX 10.5.9,
http://macintoshgarden.org/forum/introducing-sorbet-leopard-105-reinvigorated 


http://macintoshgarden.org/apps/sorbet-leopard


So an unofficial OS. We don't really support those...




On 27.07.22 20:55, Chris Jones wrote:


Btw. What the heck is ‘sorbet Leopard’ ??


On 27 Jul 2022, at 7:29 pm, Hangglider  wrote:

Hello,

somewhere in the dependencies for some package I have to compile
libzzip. That's less easy than it sounds:

The libzzip package seems to enforce gcc-4.2 (there's /usr/bin/gcc-4.0
and /opt/local/bin/ppc-apple-darwin9-gcc-7.5.0 == /opt/local/bin/gcc
too) and tries to use it with -Warray-bounds. gcc-4.2 doesn't have that,
but gcc7 does. Adding -DCMAKE_C_COMPILER=/opt/local/bin/gcc to the
portfile didn't do the job. so some questions arise:

Is there a well known way to enforce a given compiler?

Would/should I have to replace or remove one of the system's (Xcode's)
compiler(s) to clean things up a bit?

Should I upgrade Xcode, and to which version (PPC32, Sorbet Leopard)?

Thanks in advance for helpful responses.

HG

Re: problem compiling libzzip (PPC, Sorbet Leopard)

[Chris Jones]

> On 27 Jul 2022, at 7:54 pm, Chris Jones  wrote:
> 
> 
> 
>> On 27 Jul 2022, at 7:29 pm, Hangglider  wrote:
>> 
>> Hello,
>> 
>> somewhere in the dependencies for some package I have to compile
>> libzzip. That's less easy than it sounds:
>> 
>> The libzzip package seems to enforce gcc-4.2 (there's /usr/bin/gcc-4.0
>> and /opt/local/bin/ppc-apple-darwin9-gcc-7.5.0 == /opt/local/bin/gcc
>> too) and tries to use it with -Warray-bounds. gcc-4.2 doesn't have that,
>> but gcc7 does. Adding -DCMAKE_C_COMPILER=/opt/local/bin/gcc to the
>> portfile didn't do the job. so some questions arise:
>> 
>> Is there a well known way to enforce a given compiler?
> 
> sudo port sync
> sudo port upgrade outdated
> sudo port clean libzzip
> sudo port install libzzip configure.compiler=macports-clang-14

P.s. if v 14 is not available on your os, replace with whatever is..
> 
>> 
>> Would/should I have to replace or remove one of the system's (Xcode's)
>> compiler(s) to clean things up a bit?
>> 
>> Should I upgrade Xcode, and to which version (PPC32, Sorbet Leopard)?
>> 
>> Thanks in advance for helpful responses.
>> 
>> HG

Re: problem compiling libzzip (PPC, Sorbet Leopard)

[Chris Jones]

Btw. What the heck is ‘sorbet Leopard’ ??

> On 27 Jul 2022, at 7:29 pm, Hangglider  wrote:
> 
> Hello,
> 
> somewhere in the dependencies for some package I have to compile
> libzzip. That's less easy than it sounds:
> 
> The libzzip package seems to enforce gcc-4.2 (there's /usr/bin/gcc-4.0
> and /opt/local/bin/ppc-apple-darwin9-gcc-7.5.0 == /opt/local/bin/gcc
> too) and tries to use it with -Warray-bounds. gcc-4.2 doesn't have that,
> but gcc7 does. Adding -DCMAKE_C_COMPILER=/opt/local/bin/gcc to the
> portfile didn't do the job. so some questions arise:
> 
> Is there a well known way to enforce a given compiler?
> 
> Would/should I have to replace or remove one of the system's (Xcode's)
> compiler(s) to clean things up a bit?
> 
> Should I upgrade Xcode, and to which version (PPC32, Sorbet Leopard)?
> 
> Thanks in advance for helpful responses.
> 
> HG

Re: problem compiling libzzip (PPC, Sorbet Leopard)

[Chris Jones]

> On 27 Jul 2022, at 7:29 pm, Hangglider  wrote:
> 
> Hello,
> 
> somewhere in the dependencies for some package I have to compile
> libzzip. That's less easy than it sounds:
> 
> The libzzip package seems to enforce gcc-4.2 (there's /usr/bin/gcc-4.0
> and /opt/local/bin/ppc-apple-darwin9-gcc-7.5.0 == /opt/local/bin/gcc
> too) and tries to use it with -Warray-bounds. gcc-4.2 doesn't have that,
> but gcc7 does. Adding -DCMAKE_C_COMPILER=/opt/local/bin/gcc to the
> portfile didn't do the job. so some questions arise:
> 
> Is there a well known way to enforce a given compiler?

sudo port sync
sudo port upgrade outdated
sudo port clean libzzip
sudo port install libzzip configure.compiler=macports-clang-14

> 
> Would/should I have to replace or remove one of the system's (Xcode's)
> compiler(s) to clean things up a bit?
> 
> Should I upgrade Xcode, and to which version (PPC32, Sorbet Leopard)?
> 
> Thanks in advance for helpful responses.
> 
> HG

Re: Why so many gcc updates in the last week or so?

[Chris Jones]

Gcc12 brought a number of issues, that took time to be solved and 
required a number of updates in other gcc versions as well, and only 
became apparent as users submitted tickets etc. for those issues as they 
where found. I apologies for the number of updates, but I think now, 
touch wood, things will stabilize.


If you want to avoid having to build from source large updates, just 
hold off doing them until you see the binary tarballs are available, e.g. at


https://packages.macports.org/gcc12/

Chris

On 21/07/2022 10:12 am, Richard L. Hamilton wrote:

It seems there have been updates for one version or multiple versions of gcc or 
their libraries nearly every day lately. What’s up with that?

If one has to recompile (some are prebuilt, thankfully), that REALLY slows down 
updates. With 7 systems (4 of which are VMs at different macOS versions), 
anything that makes updates slower is not fun. Not to mention about 22 Linux, 
Solaris, or Windows systems (mostly VMs/LDOMs/zones, not physical boxes! not 
nearly as much hardware as it sounds like) getting updated too. (nostalgia for 
decades of being in IT, and that doesn’t even count emulators for Apollo 
workstation, IBM mainframe, and other exotica distantly remembered)

Re: NCEPLIB in Mac

[Chris Jones]

The build instructions at

https://github.com/NOAA-EMC/NCEPLIBS

Do not look too complex, a fairly standard looking cmake build. It might not be 
too hard for an interested party to create a portfile for it….

> On 7 Jul 2022, at 11:37 pm, Tao Zhang  wrote:
> 
> 
> Yes. I have to build it by myself if Macport does not have these package.
> Thanks
>  Tao
> 
>> On 7/7/22 4:33 PM, Chris Jones wrote:
>> 
>> Well, if those static libraries are not even built for macOS….. they are 
>> never going to work on a mac.
>> 
>> You need to either build them yourself, or download binaries for the OS you 
>> are actually using…
>> 
>>> On 7 Jul 2022, at 11:31 pm, Tao Zhang  wrote:
>>> 
>>> 
>>> Chris,
>>> 
>>>  Yes. I download those *.a from other platform, not from Mac. 
>>>  Gfortran works fine in my Mac if I do not call those *.a in a code.
>>>   
>>>  https://github.com/NOAA-EMC/NCEPLIBS does not mention which platform the 
>>> libs support.
>>>  
>>>  Thanks
>>>  Tao 
>>>  
>>> 
>>> On 7/7/22 4:22 PM, Chris Jones wrote:
>>>> 
>>>> These are really questions not for macports, but for the maintainers of 
>>>> the static libs, which I presume you downloaded in binary form from 
>>>> somewhere? The first question is what platforms do the libs support ? 64 
>>>> or 32 bit, etc…
>>>> 
>>>> Gfortran from macports works fine. This part is not your problem… it 
>>>> should work just fine with those libs as long as you use them correctly, 
>>>> which it doesn’t look like you currently are doing..
>>>> 
>>>>> On 7 Jul 2022, at 11:13 pm, Tao Zhang  wrote:
>>>>> 
>>>>> 
>>>>> Sorry for the wrong info. below is the new one.
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> When I compile the code in other machine (maybe Linux), it works fine. 
>>>>> But it does not work in Mac because of the lib. issue. see below. 
>>>>> 
>>>>> I find that there are some info. about NCEP lib., see 
>>>>> 
>>>>> https://github.com/NOAA-EMC/NCEPLIBS
>>>>> 
>>>>> I am asking if Macport can easily install some of them, especially for 
>>>>> NCEPLIBS-bacio, NCEPLIBS-ip, NCEPLIBS-sp,
>>>>>  
>>>>>  NCEPLIBS-w3emc,  and NCEPLIBS-w3nco
>>>>> 
>>>>> Also, does gfortran work with these libs.?
>>>>> 
>>>>>   
>>>>>  Thanks 
>>>>> 
>>>>>  Tao 
>>>>> 
>>>>> 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/anncli/File2> gflib 
>>>>> gribsst.daily.PSD.SST_cli.1991-2020.f 
>>>>> ld: warning: ignoring file /Users/tzhang/Disk/CPC/mkgrbsst/bin/libsp_4.a, 
>>>>> file was built for archive which is not the architecture being linked 
>>>>> (x86_64): /Users/tzhang/Disk/CPC/mkgrbsst/bin/libsp_4.a 
>>>>> ld: warning: ignoring file /Users/tzhang/Disk/CPC/mkgrbsst/bin/libip_4.a, 
>>>>> file was built for archive which is not the architecture being linked 
>>>>> (x86_64): /Users/tzhang/Disk/CPC/mkgrbsst/bin/libip_4.a 
>>>>> ld: warning: ignoring file 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3emc_4.a, file was built for 
>>>>> archive which is not the architecture being linked (x86_64): 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3emc_4.a 
>>>>> ld: warning: ignoring file 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3nco_4.a, file was built for 
>>>>> archive which is not the architecture being linked (x86_64): 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3nco_4.a 
>>>>> ld: warning: ignoring file 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libbacio_4.a, file was built for 
>>>>> archive which is not the architecture being linked (x86_64): 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libbacio_4.a 
>>>>> Undefined symbols for architecture x86_64: 
>>>>>   "_main", referenced from: 
>>>>>  implicit entry/start for main executable 
>>>>> ld: symbol(s) not found for architecture x86_64 
>>>>> collect2: error: ld returned 1 exit status 
>>>>> 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/anncli/File2> which gfnew 
>>>>> gfnew:  aliased to gfortran -m64 -ffixed-line-length-0 
>>>>> -finit-local-zero -fbounds-check 
>>>>> 
>>>>> gflib: 
>>>>> 
>>>>> - 
>>>>> 
>>>>> #set -x 
>>>>> gfnew \ 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libsp_4.a \ 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libip_4.a \ 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3emc_4.a \ 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3nco_4.a \ 
>>>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libbacio_4.a 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
> 

Re: NCEPLIB in Mac

[Chris Jones]

Well, if those static libraries are not even built for macOS….. they are never 
going to work on a mac.

You need to either build them yourself, or download binaries for the OS you are 
actually using…

> On 7 Jul 2022, at 11:31 pm, Tao Zhang  wrote:
> 
> 
> Chris,
> 
>  Yes. I download those *.a from other platform, not from Mac. 
>  Gfortran works fine in my Mac if I do not call those *.a in a code.
>   
>  https://github.com/NOAA-EMC/NCEPLIBS does not mention which platform the 
> libs support.
>  
>  Thanks
>  Tao 
>  
> 
>> On 7/7/22 4:22 PM, Chris Jones wrote:
>> 
>> These are really questions not for macports, but for the maintainers of the 
>> static libs, which I presume you downloaded in binary form from somewhere? 
>> The first question is what platforms do the libs support ? 64 or 32 bit, etc…
>> 
>> Gfortran from macports works fine. This part is not your problem… it should 
>> work just fine with those libs as long as you use them correctly, which it 
>> doesn’t look like you currently are doing..
>> 
>>> On 7 Jul 2022, at 11:13 pm, Tao Zhang  wrote:
>>> 
>>> 
>>> Sorry for the wrong info. below is the new one.
>>> 
>>> Hi,
>>> 
>>> When I compile the code in other machine (maybe Linux), it works fine. But 
>>> it does not work in Mac because of the lib. issue. see below. 
>>> 
>>> I find that there are some info. about NCEP lib., see 
>>> 
>>> https://github.com/NOAA-EMC/NCEPLIBS
>>> 
>>> I am asking if Macport can easily install some of them, especially for 
>>> NCEPLIBS-bacio, NCEPLIBS-ip, NCEPLIBS-sp,
>>>  
>>>  NCEPLIBS-w3emc,  and NCEPLIBS-w3nco
>>> 
>>> Also, does gfortran work with these libs.?
>>> 
>>>   
>>>  Thanks 
>>> 
>>>  Tao 
>>> 
>>> 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/anncli/File2> gflib 
>>> gribsst.daily.PSD.SST_cli.1991-2020.f 
>>> ld: warning: ignoring file /Users/tzhang/Disk/CPC/mkgrbsst/bin/libsp_4.a, 
>>> file was built for archive which is not the architecture being linked 
>>> (x86_64): /Users/tzhang/Disk/CPC/mkgrbsst/bin/libsp_4.a 
>>> ld: warning: ignoring file /Users/tzhang/Disk/CPC/mkgrbsst/bin/libip_4.a, 
>>> file was built for archive which is not the architecture being linked 
>>> (x86_64): /Users/tzhang/Disk/CPC/mkgrbsst/bin/libip_4.a 
>>> ld: warning: ignoring file 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3emc_4.a, file was built for 
>>> archive which is not the architecture being linked (x86_64): 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3emc_4.a 
>>> ld: warning: ignoring file 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3nco_4.a, file was built for 
>>> archive which is not the architecture being linked (x86_64): 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3nco_4.a 
>>> ld: warning: ignoring file 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libbacio_4.a, file was built for 
>>> archive which is not the architecture being linked (x86_64): 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libbacio_4.a 
>>> Undefined symbols for architecture x86_64: 
>>>   "_main", referenced from: 
>>>  implicit entry/start for main executable 
>>> ld: symbol(s) not found for architecture x86_64 
>>> collect2: error: ld returned 1 exit status 
>>> 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/anncli/File2> which gfnew 
>>> gfnew:  aliased to gfortran -m64 -ffixed-line-length-0 
>>> -finit-local-zero -fbounds-check 
>>> 
>>> gflib: 
>>> 
>>> - 
>>> 
>>> #set -x 
>>> gfnew \ 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libsp_4.a \ 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libip_4.a \ 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3emc_4.a \ 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3nco_4.a \ 
>>> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libbacio_4.a 
>>> 
>>> 
>>> 
>>> 
> 

Re: NCEPLIB in Mac

[Chris Jones]

These are really questions not for macports, but for the maintainers of the 
static libs, which I presume you downloaded in binary form from somewhere? The 
first question is what platforms do the libs support ? 64 or 32 bit, etc…

Gfortran from macports works fine. This part is not your problem… it should 
work just fine with those libs as long as you use them correctly, which it 
doesn’t look like you currently are doing..

> On 7 Jul 2022, at 11:13 pm, Tao Zhang  wrote:
> 
> 
> Sorry for the wrong info. below is the new one.
> 
> Hi,
> 
> When I compile the code in other machine (maybe Linux), it works fine. But it 
> does not work in Mac because of the lib. issue. see below. 
> 
> I find that there are some info. about NCEP lib., see 
> 
> https://github.com/NOAA-EMC/NCEPLIBS
> 
> I am asking if Macport can easily install some of them, especially for 
> NCEPLIBS-bacio, NCEPLIBS-ip, NCEPLIBS-sp,
>  
>  NCEPLIBS-w3emc,  and NCEPLIBS-w3nco
> 
> Also, does gfortran work with these libs.?
> 
>   
>  Thanks 
> 
>  Tao 
> 
> 
> /Users/tzhang/Disk/CPC/mkgrbsst/anncli/File2> gflib 
> gribsst.daily.PSD.SST_cli.1991-2020.f 
> ld: warning: ignoring file /Users/tzhang/Disk/CPC/mkgrbsst/bin/libsp_4.a, 
> file was built for archive which is not the architecture being linked 
> (x86_64): /Users/tzhang/Disk/CPC/mkgrbsst/bin/libsp_4.a 
> ld: warning: ignoring file /Users/tzhang/Disk/CPC/mkgrbsst/bin/libip_4.a, 
> file was built for archive which is not the architecture being linked 
> (x86_64): /Users/tzhang/Disk/CPC/mkgrbsst/bin/libip_4.a 
> ld: warning: ignoring file /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3emc_4.a, 
> file was built for archive which is not the architecture being linked 
> (x86_64): /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3emc_4.a 
> ld: warning: ignoring file /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3nco_4.a, 
> file was built for archive which is not the architecture being linked 
> (x86_64): /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3nco_4.a 
> ld: warning: ignoring file /Users/tzhang/Disk/CPC/mkgrbsst/bin/libbacio_4.a, 
> file was built for archive which is not the architecture being linked 
> (x86_64): /Users/tzhang/Disk/CPC/mkgrbsst/bin/libbacio_4.a 
> Undefined symbols for architecture x86_64: 
>   "_main", referenced from: 
>  implicit entry/start for main executable 
> ld: symbol(s) not found for architecture x86_64 
> collect2: error: ld returned 1 exit status 
> 
> /Users/tzhang/Disk/CPC/mkgrbsst/anncli/File2> which gfnew 
> gfnew:  aliased to gfortran -m64 -ffixed-line-length-0 -finit-local-zero 
> -fbounds-check 
> 
> gflib: 
> 
> - 
> 
> #set -x 
> gfnew \ 
> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libsp_4.a \ 
> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libip_4.a \ 
> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3emc_4.a \ 
> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libw3nco_4.a \ 
> /Users/tzhang/Disk/CPC/mkgrbsst/bin/libbacio_4.a 
> 
> 
> 
> 

Re: NCEPLIB in Mac

[Chris Jones]

The instructions given below are i think quite clear, just follow them…

> sudo port -f deactivate libunwind-headers

Then try again.

> On 7 Jul 2022, at 11:11 pm, Tao Zhang  wrote:
> 
> Hi,
> 
> 
>   When I install wgrib2 into my Macbook pro (10.14.6), I get the following 
> error.
>   Does anyone have the same issue? What causes this issue?
>   How to fix this it?
> 
>   Thanks
>   Tao
> 
> 
> --->  Attempting to fetch gcc10-10.2.0_4.darwin_18.x86_64.tbz2 from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/gcc10
> --->  Attempting to fetch gcc10-10.2.0_4.darwin_18.x86_64.tbz2 from 
> https://mse.uk.packages.macports.org/gcc10
> --->  Fetching distfiles for gcc10
> --->  Attempting to fetch gcc-10.2.0.tar.xz from 
> https://bigsearcher.com/mirrors/gcc/snapshots/10.2.0/
> --->  Attempting to fetch gcc-10.2.0.tar.xz from 
> https://distfiles.macports.org/gcc10
> --->  Attempting to fetch gcc-10.2.0.tar.xz from 
> https://mirrors.kernel.org/gnu/gcc/gcc-10.2.0/
> --->  Attempting to fetch gcc-10.2.0.tar.xz from 
> https://ywg.ca.distfiles.macports.org/mirror/macports/distfiles/gcc10
> --->  Attempting to fetch gcc-10.2.0.tar.xz from 
> http://mirrors.ibiblio.org/gnu/ftp/gnu/gcc/gcc-10.2.0
> --->  Attempting to fetch gcc-10.2.0.tar.xz from 
> https://mirror.its.dal.ca/gnu/gcc/gcc-10.2.0/
> --->  Attempting to fetch gcc-10.2.0.tar.xz from 
> ftp://gcc.gnu.org/pub/gcc/releases/gcc-10.2.0/
> --->  Verifying checksums for gcc10
> --->  Extracting gcc10
> --->  Applying patches to gcc10
> --->  Configuring gcc10
> Error: gcc10 cannot be built while libunwind-headers is active.
> Error: Please forcibly deactivate libunwind-headers, e.g. by running:
> Error:
> Error: sudo port -f deactivate libunwind-headers
> Error:
> Error: Then try again. You can reactivate libunwind-headers again later.
> Error: Failed to configure gcc10: libunwind-headers is active
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc10/gcc10/main.log
>  for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> Error: Processing of port wgrib2 failed
> 
> 

Re: not seen the 404 before

[Chris Jones]

On 05/05/2022 4:51 pm, chilli.names...@gmail.com wrote:

I can't upgrade because of 404? Is this a problem on my end?


Most probably yes. Update built just fine here.

Check your local network / firewall.




--->  Computing dependencies for curl-ca-bundle.
--->  Fetching distfiles for curl-ca-bundle
--->  curl-7.83.0.tar.xz does not exist in 
/opt/local/var/macports/distfiles/curl
--->  Attempting to fetch curl-7.83.0.tar.xz from https://curl.se/download/
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://ywg.ca.distfiles.macports.org/mirror/macports/distfiles/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from https://curl.askapache.com/
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://mse.uk.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://fra.de.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://ema.uk.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://cph.dk.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://nue.de.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://fco.it.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://kmq.jp.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://cjj.kr.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://aarnet.au.distfiles.macports.org/pub/macports/distfiles/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft 

Re: During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?

[Chris Jones]

Hi,

Speaking only for myself, I generally suggest *not* using the 
restore_ports.tcl script. When I migrate to a new OS I generate the list 
of installed ports *and* requested ones, and follow the instructions as 
far as wi[ping out my old ports prior to the update.


However, when restoring the ports I prefer to just manually do this. If 
you just open up the list of requested ports, in whatever text reader 
you prefer, its usually a quite short list (much shorter than all 
installed) and its a short job to go through and reinstall by hand 
whatever you still want. When you do this it will not try and preserve 
the same variants as before, unless you actively request them, and I 
find this a good idea as default variant sometimes get updated so just 
using the same as before is not always the best idea.


This is not to say you still will not have issues with the new Arm arch, 
as for sure some ports will have issues with that. But at least you will 
not have issues because of old settings that should no longer be preserved.


Chris

On 12/04/2022 3:10 am, Jim DeLaHunt wrote:

Hello, MacPorts folks:

I am following the MacPorts wiki "Migration"[1] instructions as I move 
from a macOS 10.14.6 Mojave machine with an intel CPU to a macOS 13.1 
Monterey machine with an arm64 CPU. I got stuck with a bug in the tiff 
port, which fails during destroot under the +universal variant. I opened 
a ticket[2] against tiff +universal on arm64, but that is not my 
question here.


I don't know why MacPorts was trying to install tiff with the +universal 
variant. I am following the Migration instructions. They have me make a 
list of installed ports using `port -qv installed`. None of these 
entries mention "requested_variants='+universal'". 91% have an empty 
string for requested variants. 9% request some other variant. However, 
two-thirds mention "archs='x86_64'", while the other one-third mention 
"archs='noarch'", and none have empty strings or some other value for 
"archs". I use the restore_ports.tcl script to install the ports on the 
new computer.


Here are four representative entries from my list of installed ports:

   aalib @1.4rc5_5 (active) requested_variants='' platform='darwin 18' 
archs='x86_64' date='2021-08-30T13:16:05-0700'
   abcde @2.9.3_1 (active) requested_variants='' platform='darwin 18' 
archs='noarch' date='2022-01-23T21:52:02-0800'
   apr-util @1.6.1_2+no_bdb (active) requested_variants='+no_bdb' 
platform='darwin 18' archs='x86_64' date='2021-08-30T13:16:21-0700'
   aspell @0.60.8_1 (active) requested_variants='-nls' platform='darwin 18' 
archs='x86_64' date='2021-08-30T13:34:34-0700'

Might the presence of "archs='x86_64'" cause the restore_ports.tcl 
script to ask for +universal variants on the new computer?


Should I perhaps null out the value "x86_64" from the archs entries in 
my installed ports list?  i.e. turn them into "archs='' "? Or should I 
replace them with the value "arm64"?


I don't see any mention in the Migration instructions about modifying 
"archs" entries when migrating from one architecture to another.


[1] 
[2] , tiff@4.3.0_0+universal: 
Failed to destroot tiff, "libtiff-4.pc differs"


--
.--Jim DeLaHunt, Vancouver, Canada

Re: libusb-devel port

[Chris Jones]

> On 5 Apr 2022, at 3:08 pm, Christoph Kukulies  wrote:
> 
> Thanks. Assumed I have downloaded a binary release from libusb’s github 
> Releases and it looks like that in the tree:
> 
> $ find macos_11.6
> macos_11.6
> macos_11.6/.DS_Store
> macos_11.6/bin
> macos_11.6/bin/dpfp
> macos_11.6/bin/listdevs
> macos_11.6/bin/sam3u_benchmark
> macos_11.6/bin/fxload
> macos_11.6/bin/xusb
> macos_11.6/bin/testlibusb
> macos_11.6/bin/hotplugtest
> macos_11.6/bin/stress
> macos_11.6/include
> macos_11.6/include/.DS_Store
> macos_11.6/include/libusb-1.0
> macos_11.6/include/libusb-1.0/libusb.h
> macos_11.6/lib
> macos_11.6/lib/pkgconfig
> macos_11.6/lib/pkgconfig/libusb-1.0.pc
> macos_11.6/lib/libusb-1.0.dylib
> macos_11.6/lib/libusb-1.0.0.dylib
> macos_11.6/lib/libusb-1.0.a
> macos_11.6/lib/libusb-1.0.la
> 
> How can I make these active in libusb-devel or otherwise available?

You cannot. Macports strongly prefers to build ports from source itself, and 
only redistributes rebuilt binaries in extreme circumstances.

You need to update the port file to fetch and then build a newer github 
revision for the devel subport. See

https://github.com/macports/macports-ports/blob/584723a8c2a65990bd0566b226f8c31b7f30fce5/devel/libusb/Portfile

See line 60 onwards.

That said, the devel port currently builds a revision that appears to be from 
the 3rd of April this year, so is pretty recent. Is this not new enough ?

Chris


> 
> Do the pkgconfig .pc files play a role in the installation mechanism?
> 
> —
> Christoph
> 
>> Am 05.04.2022 um 15:36 schrieb Chris Jones :
>> 
>> 
>>> On 05/04/2022 1:54 pm, Christoph Kukulies wrote:
>>> Thanks. Nonetheless I don‘t get how I can aim at a specific version or 
>>> 1.0.26-rc1 „HEAD“
>> 
>> you cannot. You still get whatever version libusb-devel is current set to 
>> provide. The idea of a X-devel port though is these can be updated and 
>> tested without affecting the default X port.
>> 
>> If you want a different version than libusb-devel currently provides, then 
>> you need to update the port to provide this.
>> 
>>> Btw, what is the correspondent to
>>> ldd
>>> under macOS?
>> 
>> otool -L
>> 
>>> —
>>> Christoph
>>>> Am 05.04.2022 um 12:56 schrieb Chris Jones :
>>>> 
>>>> 
>>>> 
>>>>> On 05/04/2022 11:50 am, Christoph Kukulies wrote:
>>>>> $ sudo port deactivate libusb @1.0.25_0
>>>>> Password:
>>>>> Note: It is not recommended to uninstall/deactivate a port that has 
>>>>> dependents as it breaks the dependents.
>>>>> The following ports will break:
>>>>>  libusb-compat @0.1.7_0
>>>>>  openocd @0.11.0_0
>>>>>  usbutils @007_1
>>>>>  libftdi1 @1.5_1
>>>>>  qemu @6.2.0_0
>>>>>  stlink @1.7.0_1
>>>>> Continue? [y/N]:
>>>>> 
>>>>> OK to continue?
>>>> 
>>>> yes.
>>>> 
>>>> ports that depend on libusb should use a path style dependency, to allow 
>>>> libusb or libusb-devel to satisfy it
>>>> 
>>>> path:lib/pkgconfig/libusb-1.0.pc:libusb
>>>> 
>>>> so assuming you are about to install libusb-devel its fine.
> 

Re: libusb-devel port

[Chris Jones]

On 05/04/2022 1:54 pm, Christoph Kukulies wrote:

Thanks. Nonetheless I don‘t get how I can aim at a specific version or 
1.0.26-rc1 „HEAD“


you cannot. You still get whatever version libusb-devel is current set 
to provide. The idea of a X-devel port though is these can be updated 
and tested without affecting the default X port.


If you want a different version than libusb-devel currently provides, 
then you need to update the port to provide this.




Btw, what is the correspondent to

ldd

under macOS?


otool -L



—
Christoph


Am 05.04.2022 um 12:56 schrieb Chris Jones :




On 05/04/2022 11:50 am, Christoph Kukulies wrote:
$ sudo port deactivate libusb @1.0.25_0
Password:
Note: It is not recommended to uninstall/deactivate a port that has dependents 
as it breaks the dependents.
The following ports will break:
  libusb-compat @0.1.7_0
  openocd @0.11.0_0
  usbutils @007_1
  libftdi1 @1.5_1
  qemu @6.2.0_0
  stlink @1.7.0_1
Continue? [y/N]:

OK to continue?


yes.

ports that depend on libusb should use a path style dependency, to allow libusb 
or libusb-devel to satisfy it

path:lib/pkgconfig/libusb-1.0.pc:libusb

so assuming you are about to install libusb-devel its fine.

Re: libusb-devel port

[Chris Jones]

On 05/04/2022 11:50 am, Christoph Kukulies wrote:

$ sudo port deactivate libusb @1.0.25_0
Password:
Note: It is not recommended to uninstall/deactivate a port that has 
dependents as it breaks the dependents.

The following ports will break:
  libusb-compat @0.1.7_0
  openocd @0.11.0_0
  usbutils @007_1
  libftdi1 @1.5_1
  qemu @6.2.0_0
  stlink @1.7.0_1
Continue? [y/N]:

>
> OK to continue?

yes.

ports that depend on libusb should use a path style dependency, to allow 
libusb or libusb-devel to satisfy it


path:lib/pkgconfig/libusb-1.0.pc:libusb

so assuming you are about to install libusb-devel its fine.

Re: libusb-devel port

[Chris Jones]

On 05/04/2022 11:33 am, Christoph Kukulies wrote:
I’m in the need of testing a libusb issue with an intermediate build of 
libusb (1.0.26-rc1, that is)


Since I’m always reluctant of mixing brew and macports - is that 
actually „dangerous“ or impossible at all, should that be avoided or can 
it be done -


One of the developers of libusb told me that the libusb-devel port is 
broken. I’d prefer using macports. Trying it, I got:


$ sudo port install libusb-devel
Password:

Error: Can't install libusb-devel because conflicting ports are active: 
libusb
Error: Follow https://guide.macports.org/#project.tickets 
 if you believe there is a bug.

Error: Processing of port libusb-devel failed
$

Any advice?


you need to deacivate libusb first

Re: port diagnose and xcode

[Chris Jones]

On 11/03/2022 8:02 am, Michele Venturi wrote:

What is wrong is that a simple package manager
requires an entire multigigabyte professional IDE;
I have even taken the time to talk to them about it
and file a bug about it,but they clearly don't care...
It's surely not a new issue,it's like that by design...



MacPorts is not (just) 'a simple package manager'. Yes, it performs this 
function, but first and foremost (and long before we even had binary 
tarballs to distribute as a 'package mnager') it is a system for 
building packages and their dependencies. To build something you require 
a compiler. Many ports will build fine with just the Apple CLT package, 
but some indeed require the full Xcode installation in order to be built 
(and Xcode also is not just an IDE, but is also a command line build 
system).


So yes, if you want to put it in those terms requiring Xcode/CLT is 'by 
design'.




Il ven 11 mar 2022, 01:40 James Secan > ha scritto:


In working my way through my recent “phantom ports” issue I ran the
command “port diagnose” and was more than a bit surprised by the
output line:

Error: currently installed version of Xcode, none, is not supported
by MacPorts.

followed by a list of the version supported under my version of
macOS (El Capitan, in this case).  Where is port getting this
information?  I have Xcode 8.2.0 installed, and none of my attempts
to install ports have run into any trouble related to Xcode not
being installed.  I ran "pkgutil -v
--pkg-info=com.apple.pkg.CLTools_Executables” which shows that I
have 8.2.0 installed, and the appropriate MacOSX.sdk files are in
/Library/Developer/CommandLineTools/SDKs.  I also tried this on my
test Catalina system, with the same result.

Is something wrong with my ports setup?

Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109

 > On Mar 10, 2022, at 12:34 AM, Ryan Schmidt
mailto:ryandes...@macports.org>> wrote:
 >
 > On Mar 9, 2022, at 17:13, James Secan wrote:
 >>
 >> when I run "port upgrade installed -u outdated”
 >
 > This command doesn't make a great deal of sense. You're asking
MacPorts to upgrade the "installed" ports (which includes those
those that are outdated and those that aren't) and also the
"outdated" ports (those that are outdated). It would be simpler and
more efficient to just run "sudo port -u upgrade outdated".
Single-dash/single-letter flags like "-u" go after "port" and before
the action (the action in this case being "upgrade").
 >
 > For completeness, "-u" means "uninstall inactive ports"; if you
want to keep inactive ports, for example as a safeguard so that you
could return to them in case something is wrong with the new
version, then don't use "-u". When you eventually run "sudo port
reclaim", that will get rid of the inactive versions.
 >
 > MacPorts reminds to run "sudo port reclaim" if you have not done
so in a few weeks, unless you have configured MacPorts not to remind
you.

Re: MacPorts XCode Installation

[Chris Jones]

whatever you think relevant, from the discussion here. If its not clear 
it can be added to later on so don't worry about including everything at 
first. But please lets have the discussion in trac rather than here...


On 07/03/2022 4:28 pm, Michele Venturi wrote:

What should I include in the bug report to make it clear?

Il lun 7 mar 2022, 17:25 Marius Schamschula <mailto:li...@schamschula.com>> ha scritto:


Michele,

Please submit a MacPorts ticket!

Other users may search trac if they encounter the same issue. We can
also link to any upstream tickets from there.


On Mar 7, 2022, at 10:22 AM, Michele Venturi mailto:dard...@gmail.com>> wrote:

Should I submit a bug report before we even know if it's a
MacPorts specific issue? Or how do we find that out?

Il lun 7 mar 2022, 16:47 Chris Jones mailto:jon...@hep.phy.cam.ac.uk>> ha scritto:



On 07/03/2022 3:31 pm, Michele Venturi wrote:
> I have the required libraries in /usr/lib/swift too,but MPV
is looking
> for them in /opt/local/lib,so it doesn't find them:
>
> otool -l $(which mpv)
> ...
> cmd LC_RPATH
> cmdsize 32
> path /opt/local/lib (offset 12)
>
> Should we change RPATH or add symbolic links?

No, those are not the solutions here. If there is an issue
with the
build on 10.13 we should fix that instead, rather than apply
after-the-fact bandaids.

The first thing to determine is if its a MacPorts specific
issue due to
how the build is performed, or an upstream issue. Either way
please
submit a bug report to macports trac so the discussion on this
can
continue there.

Chris

>
> Michele Venturi
> about.me/dardo82 <http://about.me/dardo82>
<http://about.me/dardo82 <http://about.me/dardo82>>
>
>

<https://about.me/dardo82?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api_content=thumb

<https://about.me/dardo82?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api_content=thumb>>

>
> Michele Venturi
> about.me/dardo82 <http://about.me/dardo82>
>

<https://about.me/dardo82?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api_content=thumb

<https://about.me/dardo82?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api_content=thumb>>

>
>
>
>
> Il giorno lun 7 mar 2022 alle ore 15:46 Ryan Schmidt
> mailto:ryandes...@macports.org>
<mailto:ryandes...@macports.org
<mailto:ryandes...@macports.org>>> ha scritto:
>
>
>
>     On Mar 7, 2022, at 08:34, Michele Venturi wrote:
>
>      > If I install MPV without Xcode I get an error when I
launch it:
>      >
>      > dyld: Library not loaded:
@rpath/libswiftAVFoundation.dylib
>      >   Referenced from: /opt/local/bin/mpv
>      >   Reason: image not found
>      >
>      > It's missing something,have you tried to execute it
on 10.13?
>
>     I have not.
>
>     I guess you're right, in relation to the Swift language
usage I
>     mentioned earlier, this port does appear to need
>     libswiftAVFoundation.dylib at runtime. And maybe it is
expecting to
>     find it within Xcode on your system. (It depends on what
@rpath
>     expands to. I forget what the command is to interrogate
a binary
>     about its rpaths.)
>
>     Swift is still a new programming language and I don't
think we have
>     many ports in MacPorts that use Swift so I'm not sure if
this should
>     be considered normal or not.
>
>     I see that I have many copies of
libswiftAVFoundation.dylib on my
>     system, within various applications' bundles, so I guess
Apple
>     expects people to include copies of the Swift dylibs
with their
>     application.
>
>     On my 10.15 system, it does not link with
>     @rpath/libswiftAVFoundation.dylib. It links with various
Swift
>     dylibs in /usr/lib/swift. Maybe the port can be made to
do so on
>     10.13 as well.
>
>     You should file a bug report about this mpv problem.
>

Re: MacPorts XCode Installation

[Chris Jones]

On 07/03/2022 3:31 pm, Michele Venturi wrote:
I have the required libraries in /usr/lib/swift too,but MPV is looking 
for them in /opt/local/lib,so it doesn't find them:


otool -l $(which mpv)
...
cmd LC_RPATH
cmdsize 32
path /opt/local/lib (offset 12)

Should we change RPATH or add symbolic links?


No, those are not the solutions here. If there is an issue with the 
build on 10.13 we should fix that instead, rather than apply 
after-the-fact bandaids.


The first thing to determine is if its a MacPorts specific issue due to 
how the build is performed, or an upstream issue. Either way please 
submit a bug report to macports trac so the discussion on this can 
continue there.


Chris



Michele Venturi
about.me/dardo82 

 
	

Michele Venturi
about.me/dardo82 
 





Il giorno lun 7 mar 2022 alle ore 15:46 Ryan Schmidt 
mailto:ryandes...@macports.org>> ha scritto:




On Mar 7, 2022, at 08:34, Michele Venturi wrote:

 > If I install MPV without Xcode I get an error when I launch it:
 >
 > dyld: Library not loaded: @rpath/libswiftAVFoundation.dylib
 >   Referenced from: /opt/local/bin/mpv
 >   Reason: image not found
 >
 > It's missing something,have you tried to execute it on 10.13?

I have not.

I guess you're right, in relation to the Swift language usage I
mentioned earlier, this port does appear to need
libswiftAVFoundation.dylib at runtime. And maybe it is expecting to
find it within Xcode on your system. (It depends on what @rpath
expands to. I forget what the command is to interrogate a binary
about its rpaths.)

Swift is still a new programming language and I don't think we have
many ports in MacPorts that use Swift so I'm not sure if this should
be considered normal or not.

I see that I have many copies of libswiftAVFoundation.dylib on my
system, within various applications' bundles, so I guess Apple
expects people to include copies of the Swift dylibs with their
application.

On my 10.15 system, it does not link with
@rpath/libswiftAVFoundation.dylib. It links with various Swift
dylibs in /usr/lib/swift. Maybe the port can be made to do so on
10.13 as well.

You should file a bug report about this mpv problem.

Re: Is this git handling of a problem on my macports-ports fork OK?

[Chris Jones]

> git pull --rebase --autostash origin master

works pretty much just fine 99.9% of the time.

cheers Chris

* Its actually what 'port sync' does under the hood, if you have 
configured macports to work directly off a git checkout of the ports 
tree, instead of the dfault rsync tarball


** the autostash option is not available in older git versions. If the 
system git on your machine does not have it, just install MacPorts git. 
Its very useful as it automatically handles unstaged changes during a 
rebase.


On 23/02/2022 2:13 pm, Kirill A. Korinsky via macports-users wrote:

Hey,

I'd like to share with two git aliases which I've made special for 
MacPorts :)


cleanup = !git branch --merged origin/HEAD | grep -v ' -> ' | grep -v 
'^\\*' | xargs -n 1 git branch -d

rebaseall = !git branch --no-merged | xargs -n 1 git rebase origin/HEAD

The first one simple removed all branches which was merged into master.

The second one rebases all branches to master.

My usual workflow after I've opened a lot of PR to cleanup everything is:
git rebaseall
git checkout master
git cleanup

--
wbr, Kirill

On 23. Feb 2022, at 15:10, Joshua Root > wrote:


Gerben Wierda wrote:


But I have been advised a pull is not enough, I should first do a fetch.


If you're referring to my private reply, what I said was that a rebase 
was not enough to bring master up to date with upstream/master, you 
have to fetch as well.


As per the git-pull man page:

  git pull runs git fetch with the given parameters and
   then depending on configuration options or command line flags, 
will call

   either git rebase or git merge to reconcile diverging branches.

Our project policy is to avoid merge commits.

- Josh

Re: certificate update for old Macs

[Chris Jones]

In my opinion the best way to keep older hardware secure and useful past the 
point the max macOS version they can run is long since obsolete, is to stop 
using those OSes and install an alternative. There are, e.g. plenty of linux 
distros out there and offer a modern, maintained, OS and run just fine in these 
machines…

> On 4 Jan 2022, at 8:12 pm, Richard L. Hamilton  wrote:
> 
> 
> 
>> On Jan 4, 2022, at 14:37, Michael  wrote:
>> 
>> 
>>> On 2022-01-03, at 4:12 PM, Richard L. Hamilton  wrote:
>>> 
>>> The only problem with that or anything similar, is that unless you go to 
>>> quite a lot of work to just download rather than install the PEM file, and 
>>> convert it into something human readable WITHOUT installing it, and 
>>> investigate every certificate in there, you're trusting that the site you 
>>> got it from is not only legit, but is secure and hasn't been hacked to 
>>> alter the file to provide some very bogus certificates that could work 
>>> together with some sort DNS spoofing to get you to feed sensitive 
>>> information (ie bank passwords, etc) via an untrusted site that would 
>>> capture it.
>> 
>> Makes sense. Now, how do you go about turning a certificate into something 
>> human readable? Serious question, I have *never* seen this discussed 
>> anywhere.
> 
> 
> The file that the script downloads is a whole bunch of PEM files concatenated 
> together. The script shows splitting that into separate files at the start 
> lines. Once that's done,
> 
> for file in *.pem
> do
>openssl -x509 -in $file -text >$file.txt 
> done
> 
> will convert them to something you can look at. But that's the easy part. 
> Looking at them and making sense of them and investigating each of the 169 
> will take you a day or two, which is why I'm not going to say much more about 
> it. Probably IF one used a more trusted set of root certificates for 
> comparison, one could decide which were definitely ok and which needed 
> further investigation, but automating all that would NOT BE FUN.
> 
> Arguably the best solution is to get ahold of the certificates bundled in the 
> latest OS version and use those, but no doubt that's often easier said than 
> done, although you can (given enough space) download the update image on your 
> old hardware that cannot run it, and (given enough knowledge) dig those 
> certificates out of the update image and get them into a form that you can 
> then import into your old system.
> 
> Realistically a lot could be fixed by just using keychain access to look for 
> expired root certificates, and then look through one of those stashes for 
> their replacements. Again manually, unless you want to do some very creative 
> automating. I'm not volunteering to kill days or more doing that!
> 
>> Everyone just says "As long as the roots are good you can trust the chain", 
>> and that's never made sense to me. The whole "trust what strangers say" 
>> system seems more like "Find a way for companies to make money" than any 
>> good security system.
>> 
> 
> Everything has to start somewhere. Usually that's with an OS or browser 
> vendor that decides which root certificates to bundle. (Do you REALLY want 
> one planetary certificate at the tip-top provided by the UN, with all 
> subordinate certificate issuers (government OR commercial) rooted to that? 
> It'd be possible, but it's probably better trusting a bunch of different 
> folks than trusting one with absolute power to break everything.) -Site or 
> personal certificates chain back to the issuer's certificate. There are FREE 
> CERTIFICATE ISSUERS, but they have their own problems, chiefly no budget, so 
> jumping all the auditing hoops (or even keeping their infrastructure 
> reliable) needed to get OS and browser vendors to included them can be a 
> problem for them. And old OSs and the older browser versions supported on 
> them for browsers other than the one that comes with the OS, are not 
> supported forever because nobody is getting paid to do that, so they don't 
> get updates for expired certificates, new certificate issuers, etc.
> 
> Programmers and such gotta eat too, have a roof over their heads, etc. Some 
> even have little kiddies to feed, which is hardly greed, not that there's any 
> shortage of actual greed.
> 
> Probably that site with the bunch to download is fine, but I don't have 
> access to a list of baddies, so I'm at best ambivalent about trusting it 
> without more digging first than I'm likely to do. At most, I'd do it to make 
> stuff that didn't matter work on an old system, but never run anything that 
> could lose me $$ or compromise accounts on there - so I'd have root 
> certificates but NOT iCloud keychain access enabled nor any account 
> passwords, personal certificates, etc on it.
> 
> 

Re: ffmpeg unexpectedly uninstalled

[Chris Jones]

> On 3 Jan 2022, at 11:54 pm, Michael Newman via macports-users 
>  wrote:
> 
> When I periodically update MacPorts I also run:
> 
> sudo port -f uninstall inactive

Why are you using the -f option here. That could force something to happen that 
might not be a good idea. Generally speaking you should not use it as a matter 
of course, and only when you really need to, for some specific reason.

> 
> This seemed to work fine until last month when ffmpeg was uninstalled. I 
> reinstalled and forgot about it.
> 
> But, it happened again yesterday:
> 
> --->  Deactivating ffmpeg @4.4.1_1+gpl2
> --->  Cleaning ffmpeg
> --->  Uninstalling ffmpeg @4.4.1_1+gpl2
> --->  Cleaning ffmpeg
> 
> So, I reinstalled and tried:
> 
> MrMuscle:~ mnewman$ sudo port -f uninstall inactive
> Password:
> Error: No ports matched the given expression
> 
> I checked the "requested" ports here from a file I created for the Big Sur 
> migration:
> 
> MrMuscle:~ mnewman$ ls -la /Users/mnewman/Desktop/requested.txt
> -rwxrwxrwx@ 1 mnewman  staff  359 Jun  8  2021 
> /Users/mnewman/Desktop/requested.txt*
> MrMuscle:~ mnewman$ grep ffmpeg /Users/mnewman/Desktop/requested.txt
> ffmpeg
> 
> So, ffmpeg is definitely a requested port.
> 
> I'm baffled. What's going on here?

Are you sure you don’t still have a version of ffmpeg installed ? The above 
only temoved inactive ports, it did not uninstall any active ports.

> 
> Mike Newman
> Korat, Thailand
> 

Re: [numpy @ bigsur: multithreading]

[Chris Jones]

> On 3 Jan 2022, at 5:18 pm, Maxim Abalenkov  wrote:
> 
> Dear all,
> 
> Thank you for all of your replies and suggestions! I have written my own 
> matrix multiplication script in order to test NumPy’s performance. Please 
> find it attached. I’m using the MKL variant of NumPy. Strangely enough the 
> `port variants py39-numpy` still returns:
> 
> port variants py39-numpy
> py39-numpy has the variants:
>   atlas: Use MacPorts ATLAS Libraries
> * conflicts with mkl openblas
>   gcc10: Build using the MacPorts gcc 10 compiler
> * conflicts with gcc11 gcc8 gcc9 gccdevel gfortran gfortran
>   gcc11: Build using the MacPorts gcc 11 compiler
> * conflicts with gcc10 gcc8 gcc9 gccdevel gfortran gfortran
>   gcc8: Build using the MacPorts gcc 8 compiler
> * conflicts with gcc10 gcc11 gcc9 gccdevel gfortran gfortran
>   gcc9: Build using the MacPorts gcc 9 compiler
> * conflicts with gcc10 gcc11 gcc8 gccdevel gfortran gfortran
>   gccdevel: Build using the MacPorts gcc devel compiler
> * conflicts with gcc10 gcc11 gcc8 gcc9 gfortran gfortran
> [+]gfortran: Build using the MacPorts gcc 11 Fortran compiler
> * conflicts with gcc10 gcc11 gcc8 gcc9 gccdevel
>   mkl: Use MacPorts MKL Libraries
> * conflicts with atlas openblas
> [+]openblas: Use MacPorts OpenBLAS Libraries
> * conflicts with atlas mkl
>   universal: Build for multiple architectures
> 
> Either I don’t understand the expected behaviour or my `port variants` 
> command returns something else. I would expect it to show [+]gfortran and 
> [+]mkl, not the [+]openblas.

No. The + sign indicates which variants are enabled by default, not what you 
happened to be using yourself. For that the command you use below correctly 
shows this.

> On the other hand, command `port installed py39-numpy` shows:
> 
> port installed py39-numpy
> The following ports are currently installed:
>  py39-numpy @1.21.5_1+gfortran+mkl
>  py39-numpy @1.22.0_0+gfortran+mkl (active)
> 
> Finally, I wasn’t able to specify 8 execution threads with `export 
> MKL_NUM_THREADS=8`. NumPy was still using 4, but the `htop` reported 350–380% 
> CPU load for the `/usr/bin/env python3 ./dgemm_numpy.py` process. I think 
> this is good news!
> 
> The `otool` command executed under 
> `/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/core`
>  shows that MKL backend is being used.
> 
> otool -L _multiarray_umath.cpy
> _multiarray_umath.cpython-39-darwin.so:
>
> /opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/libmkl_rt.2.dylib
>  (compatibility version 0.0.0, current version 0.0.0)
>/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
> 1311.0.0)
> 
> I think I still need to experiment with OpenBLAS and compare the performance 
> numbers. Thank you for your help!
> 
> —
> Best wishes,
> Maxim
> 
#!/usr/bin/env python3

import numpy as np
import time

print(np.__version__)
print(np.show_config())

m = 2
k = 2
n = 2

t0 = time.time()
alpha = np.random.rand()
beta  = np.random.rand()

A  = np.random.rand(m, k)
B  = np.random.rand(k, n)
C  = np.random.rand(m, n)
t1 = time.time()

t = t1-t0
print('Generation time: {0:f}'.format(t))
print('  alpha: {0:f},  beta: {1:f}'.format(alpha, beta))

t0 = time.time()
C  = alpha*np.matmul(A, B) + beta*C
t1 = time.time()
t  = t1-t0
print('Multiplication time: {0:f}'.format(t))

## @eof dgemm_numpy.py
> 
> 
>>> On 29 Dec 2021, at 13:33, Joshua Root  wrote:
>>> 
>>> Maxim Abalenkov wrote:
>>> 
>>> 
>>> Dear all,
>>> 
>>> I’m looking for guidance please. I would like to make sure, that I use all 
>>> eight of my CPU cores, when I run Python’s 3.9.9 NumPy on my macOS BigSur 
>>> 12.1. When I run my NumPy code, I see in ‘htop’, that only one ‘python’ 
>>> process is running and the core utilisation is 20–25%. I remember in the 
>>> past, stock MacPorts NumPy installation would use Apple’s Accelerate 
>>> library including the multithreaded BLAS and LAPACK (
>>> https://developer.apple.com/documentation/accelerate
>>> ). As I understand this is no longer the case.
>>> 
>>> I run Python code using a virtual environment located under
>>> 
>>> /opt/venv/zipfstime/lib/python3.9/site-packages/numpy/core
>>> 
>>> When I change there and issue
>>> 
>>> otool -L _multiarray_umath.cpython-39-darwin.so
>>> 
>>> _multiarray_umath.cpython-39-darwin.so:
>>>@loader_path/../.dylibs/libopenblas.0.dylib (compatibility version 
>>> 0.0.0, current version 0.0.0)
>>>/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
>>> 1281.100.1)
>>> 
>>> In other words, NumPy relies on openBLAS. Command `port variants openblas` 
>>> returns
>>> 
>>> OpenBLAS has the variants:
>>>  g95: Build using the g95 Fortran compiler
>>>* conflicts with gcc10 gcc11 gcc8 gcc9 gccdevel
>>>  gcc10: Build using the MacPorts gcc 10 compiler
>>>* conflicts with g95 g95 gcc11 gcc8 gcc9 gccdevel
>>> [+]gcc11: Build using the MacPorts gcc 11 compiler

Re: Can some ports install config files inside '/usr/local/etc'?

[Chris Jones]

Nothing in macports will be installing to /usr/local. If you have anything in 
that area it has been put there by some other means. Maybe homebrew?, but also 
a number of third party installers sometimes use this directory as well (which 
are the reasons why MacPorts specifically ignores this area).

> On 11 Dec 2021, at 5:11 am, fgyamauti2 fgyamauti2  
> wrote:
> 
> 
>   Hi,
> 
>  Apparently some ports that I've installed are making directories inside 
> '/usr/local/etc' with example configuration files. Still the installed ports 
> themselves seem to only listen to stuff inside '/opt/local/etc'.
> 
>   For instance, I have an 'unbound' folder inside both. In the former, it 
> contains 'unbound.config', while in the latter it contains 'root.key' and 
> 'unsound.config-dist' (a file with contents identical to 'unbound.config'). 
> That seems to happen to particular ports only, though. Anyone experiencing 
> that? Are these folders really unnecessary?
> 
>   Thanks in advance,
> FY
> 

Re: python ports depend on openssl not in index

[Chris Jones]

> On 10 Dec 2021, at 8:07 pm, SeaQuench  wrote:
> 
> Output of selfupdate as requested:
> 
> $ sudo port selfupdate
> --->  Updating MacPorts base sources using rsync
> Error: Error synchronizing MacPorts sources: command execution failed
> Please run `port -v selfupdate' for details.
> Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing 
> MacPorts sources: command execution failed
> 
> [To be clear, I consider my problem to be resolved, thanks.]

Yes, the above is clear, and I guess the reason behind this thread is you did 
not pay enough attention to it in the first case ;)

Chris
> 
> ‐‐‐ Original Message ‐‐‐
> 
>> On Friday, December 10th, 2021 at 2:21 PM, Chris Jones 
>>  wrote:
>> 
>> Hi,
>> 
>> Yes, the error is expected. What i am asking is if you get any indication or 
>> not that there was an issue when you run without the verbose flag. If not, 
>> then i think thats a bug we should address.
>> 
>> Chris
>> 
>>>> On 10 Dec 2021, at 7:18 pm, SeaQuench seaque...@protonmail.com wrote:
>>> 
>>> I am behind a firewall, so this is the following is predictable:
>>> 
>>> $ sudo port -v selfupdate
>>> 
>>> ---> Updating MacPorts base sources using rsync
>>> 
>>> rsync: failed to connect to rsync.macports.org: Operation timed out (60)
>>> 
>>> rsync error: error in socket IO (code 10) at 
>>> /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54.120.1/rsync/clientserver.c(106)
>>>  [receiver=2.6.9]
>>> 
>>> Command failed: /usr/bin/rsync -rtzvl --delete-after 
>>> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>>> 
>>> Exit code: 10
>>> 
>>> Error: Error synchronizing MacPorts sources: command execution failed
>>> 
>>> ‐‐‐ Original Message ‐‐‐
>>> 
>>>> On Friday, December 10th, 2021 at 10:24 AM, Christopher Jones 
>>>> jon...@hep.phy.cam.ac.uk wrote:
>>>> 
>>>> Just to be clear, are you saying running
>>>> 
>>>>> sudo port selfupdate
>>>> 
>>>> ran without warnings or error, but did not actually update ? If thats the 
>>>> case we should file a bug against base as if the rsync fails it should 
>>>> indicate this to the user ?
>>>> 
>>>> cheers Chris
>>>> 
>>>>>> On 10 Dec 2021, at 3:13 pm, SeaQuench seaque...@protonmail.com wrote:
>>>>> 
>>>>> Ryan is correct; I had been sync'ing my port index successfully, but 
>>>>> MacPorts itself grew stale due to my being unable to run selfupdate. The 
>>>>> MacPorts Migration Guide suggested a manual update (i.e. reinstall) which 
>>>>> I believe got me going again. Thanks guys! ~SeaQuench
>>>>> 
>>>>> ‐‐‐ Original Message ‐‐‐
>>>>> 
>>>>>> On Friday, December 10th, 2021 at 3:35 AM, Ryan Schmidt 
>>>>>> ryandes...@macports.org wrote:
>>>>> 
>>>>>> On Dec 10, 2021, at 02:29, Chris Jones wrote:
>>>>>> 
>>>>>>> On 9 Dec 2021, at 10:49 pm, SeaQuench wrote:
>>>>>>> 
>>>>>>>> After downloading and installing the latest MacPorts for Catalina, I 
>>>>>>>> followed the instructions to migrate MacPorts: 
>>>>>>>> https://trac.macports.org/wiki/Migration
>>>>>>>> 
>>>>>>>> Reinstalling the ports went without issue until Step 3e: `sudo 
>>>>>>>> ./restore_ports.tcl myports.txt`
>>>>>>>> 
>>>>>>>> Executing that command resulted in the error I presented initially:
>>>>>>>> 
>>>>>>>> ---> Computing dependencies for python38
>>>>>>>> 
>>>>>>>> Error: Dependency 'openssl3' not found.
>>>>>>>> 
>>>>>>>> ---> Computing dependencies for python39
>>>>>>>> 
>>>>>>>> Error: Dependency 'openssl3' not found.
>>>>>>>> 
>>>>>>>> Is that to be expected on a fresh install (before performing a sync)? 
>>>>>>>> I acknowledge that this outcome may result from the use of git versus 
>>>>>>>> rsync in 

Re: python ports depend on openssl not in index

[Chris Jones]

Hi,

Yes, the error is expected. What i am asking is if you get any indication or 
not that there was an issue when you run without the verbose flag. If not, then 
i think thats a bug we should address.

Chris

> On 10 Dec 2021, at 7:18 pm, SeaQuench  wrote:
> 
> I am behind a firewall, so this is the following is predictable:
> 
> $ sudo port -v selfupdate
> --->  Updating MacPorts base sources using rsync
> rsync: failed to connect to rsync.macports.org: Operation timed out (60)
> rsync error: error in socket IO (code 10) at 
> /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54.120.1/rsync/clientserver.c(106)
>  [receiver=2.6.9]
> Command failed: /usr/bin/rsync -rtzvl --delete-after 
> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
> Exit code: 10
> Error: Error synchronizing MacPorts sources: command execution failed
> 
> ‐‐‐ Original Message ‐‐‐
> 
>> On Friday, December 10th, 2021 at 10:24 AM, Christopher Jones 
>>  wrote:
>> 
>> Just to be clear, are you saying running
>> 
>>> sudo port selfupdate
>> 
>> ran without warnings or error, but did not actually update ? If thats the 
>> case we should file a bug against base as if the rsync fails it should 
>> indicate this to the user ?
>> 
>> cheers Chris
>> 
>>>> On 10 Dec 2021, at 3:13 pm, SeaQuench seaque...@protonmail.com wrote:
>>> 
>>> Ryan is correct; I had been sync'ing my port index successfully, but 
>>> MacPorts itself grew stale due to my being unable to run selfupdate. The 
>>> MacPorts Migration Guide suggested a manual update (i.e. reinstall) which I 
>>> believe got me going again. Thanks guys! ~SeaQuench
>>> 
>>> ‐‐‐ Original Message ‐‐‐
>>> 
>>>> On Friday, December 10th, 2021 at 3:35 AM, Ryan Schmidt 
>>>> ryandes...@macports.org wrote:
>>> 
>>>> On Dec 10, 2021, at 02:29, Chris Jones wrote:
>>>> 
>>>>> On 9 Dec 2021, at 10:49 pm, SeaQuench wrote:
>>>>> 
>>>>>> After downloading and installing the latest MacPorts for Catalina, I 
>>>>>> followed the instructions to migrate MacPorts: 
>>>>>> https://trac.macports.org/wiki/Migration
>>>>>> 
>>>>>> Reinstalling the ports went without issue until Step 3e: `sudo 
>>>>>> ./restore_ports.tcl myports.txt`
>>>>>> 
>>>>>> Executing that command resulted in the error I presented initially:
>>>>>> 
>>>>>> ---> Computing dependencies for python38
>>>>>> 
>>>>>> Error: Dependency 'openssl3' not found.
>>>>>> 
>>>>>> ---> Computing dependencies for python39
>>>>>> 
>>>>>> Error: Dependency 'openssl3' not found.
>>>>>> 
>>>>>> Is that to be expected on a fresh install (before performing a sync)? I 
>>>>>> acknowledge that this outcome may result from the use of git versus 
>>>>>> rsync in keeping MacPorts up to date. I am behind a firewall, so i must 
>>>>>> use git to sync rather than use rsync.
>>>>>> 
>>>>>> https://trac.macports.org/wiki/howto/SyncingWithGit
>>>>>> 
>>>>>> If i substitute the command `sudo port -v sync` for the command `sudo 
>>>>>> port selfupdate` - as usual - I can now install openssl without error, 
>>>>>> and all dependencies are found after re-executing: `sudo 
>>>>>> ./restore_ports.tcl myports.txt`
>>>>> 
>>>>> We need to see why you are not finding the openssl3 port, as that has 
>>>>> been available for some time.
>>>>> 
>>>>> Please run
>>>>> 
>>>>> sudo port -d sync
>>>>> 
>>>>> And post what you get back to the list
>>>> 
>>>> They already said that after running "sudo port sync", everything is 
>>>> working.
>>>> 
>>>> "sudo port selfupdate" should selfupdate (update MacPorts base) and sync 
>>>> (update ports tree). If updating base failed for some reason, then it 
>>>> might not update the ports tree either. You mentioned being behind a 
>>>> firewall that prevents you from syncing with rsync. selfupdate has no 
>>>> option but to use rsync, so that would be a likely explanation for why 
>>>> selfupdate doesn't work for you, and why you should not use selfupdate and 
>>>> should instead (i) update MacPorts base manually when a new version is 
>>>> available, using an installer from our web site and (ii) sync to update 
>>>> ports.

Re: python ports depend on openssl not in index

[Chris Jones]

Hi,

Please always remember to reply to the list.

We need to see why you are not finding the openssl3 port, as that has been 
available for some time.

Please run

sudo port -d sync

And post what you get back to the list

Chris

> On 9 Dec 2021, at 10:49 pm, SeaQuench  wrote:
> 
> 
> After downloading and installing the latest MacPorts for Catalina, I followed 
> the instructions to migrate MacPorts: https://trac.macports.org/wiki/Migration
> Reinstalling the ports went without issue until Step 3e: `sudo 
> ./restore_ports.tcl myports.txt`
> Executing that command resulted in the error I presented initially:
> --->  Computing dependencies for python38
> Error: Dependency 'openssl3' not found.
> --->  Computing dependencies for python39
> Error: Dependency 'openssl3' not found.
> 
> Is that to be expected on a fresh install (before performing a sync)? I 
> acknowledge that this outcome may result from the use of git versus rsync in 
> keeping MacPorts up to date. I am behind a firewall, so i must use git to 
> sync rather than use rsync.
> https://trac.macports.org/wiki/howto/SyncingWithGit
> If i substitute the command `sudo port -v sync` for the command `sudo port 
> selfupdate` - as usual - I can now install openssl without error, and all 
> dependencies are found after re-executing: `sudo ./restore_ports.tcl 
> myports.txt`
> 
> Any additional advice welcome. Thanks for the tip on migration, Chris!
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
>> On Thursday, December 9th, 2021 at 2:47 PM, Chris Jones 
>>  wrote:
>> 
>> 
>> 
>> Did you follow the migration guide when moving to a new major os version ?
>> 
>> https://trac.macports.org/wiki/Migration
>> 
>> If not, follow it now, to wipe out your ports and reinstall them correctly 
>> for the new os.
>> 
>> If you did, your ports tree seems to be very out of date. Then try,
>> 
>> > sudo port selfupdate
>> > sudo port sync
>> > sudo port upgrade outdated
>> 
>> Chris
>> 
>>>> On 9 Dec 2021, at 6:53 pm, SeaQuench via macports-users 
>>>>  wrote:
>>> 
>>> 
>>> 
>>> After applying an update to MacOS last August, the python ports are 
>>> reporting a dependency on either openssl11 or openssl3, neither of which 
>>> are to be found in the (local?) index for MacPorts, according to the error 
>>> I have received, copied below. While I am prompted to report a bug, I 
>>> presume I am not in a novel situation. Could someone advise me as to how to 
>>> proceed? I am running MacPorts 2.6.2 on MacOS 10.15.7 with XCode 12.4 
>>> installed.
>>> $ sudo port install python39 
>>> 
>>> 
>>> 
>>> 
>>> Warning: No port openssl3 found in the index. 
>>> ---> Computing dependencies for openssl
>>> Error: Dependency 'openssl3' not found. 
>>> Error: Unable to execute port: upgrade openssl failed 
>>> 
>>> 
>>> 
>>> 
>>> $ sudo port install openssl 
>>> 
>>> 
>>> 
>>> 
>>> ---> Computing dependencies for openssl
>>> Error: Dependency 'openssl3' not found. 
>>> Error: Follow https://guide.macports.org/#project.tickets to report a bug. 
>>> Error: Processing of port openssl failed
>>> 
>>> 
>>> $ sudo port -n upgrade --force python38
>>> --->  Computing dependencies for python38
>>> --->  Fetching archive for python38
>>> --->  Attempting to fetch 
>>> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2 from 
>>> https://packages.macports.org/python38
>>> --->  Attempting to fetch 
>>> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2.rmd160 from 
>>> https://packages.macports.org/python38
>>> --->  Installing python38 @3.8.12_4+optimizations
>>> --->  Cleaning python38
>>> --->  Computing dependencies for python38
>>> --->  Deactivating python38 @3.8.11_0
>>> --->  Cleaning python38
>>> --->  Activating python38 @3.8.12_4+optimizations
>>> --->  Cleaning python38
>>> --->  Updating database of binaries
>>> --->  Scanning binaries for linking errors
>>> --->  Found 18 broken files, matching files to ports 
>>> --->  Found 4 broken ports, determining rebuild order
>>> You can always run 'port rev-upgrade' again to fix errors.
>>> The following ports will be rebuilt:
>>>  python38 @3.8.12+optimizations
>>>  python39 @3.9.6
>>>  glib2 @2.58.3+x11
>>>  gobject-introspection @1.60.2
>>> Continue? [Y/n]: y
>>> Warning: No port openssl3 found in the index.
>>> --->  Computing dependencies for openssl
>>> Error: Dependency 'openssl3' not found.
>>> Error: rev-upgrade failed: Error rebuilding python38
>>> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
>>> 
>>> 
> 
> 

Re: python ports depend on openssl not in index

[Chris Jones]

Did you follow the migration guide when moving to a new major os version ?

https://trac.macports.org/wiki/Migration

If not, follow it now, to wipe out your ports and reinstall them correctly for 
the new os.

If you did, your ports tree seems to be very out of date. Then try,

> sudo port selfupdate
> sudo port sync
> sudo port upgrade outdated

Chris

> On 9 Dec 2021, at 6:53 pm, SeaQuench via macports-users 
>  wrote:
> 
> 
> After applying an update to MacOS last August, the python ports are reporting 
> a dependency on either openssl11 or openssl3, neither of which are to be 
> found in the (local?) index for MacPorts, according to the error I have 
> received, copied below. While I am prompted to report a bug, I presume I am 
> not in a novel situation. Could someone advise me as to how to proceed? I am 
> running MacPorts 2.6.2 on MacOS 10.15.7 with XCode 12.4 installed.
> 
> $ sudo port install python39 
> Warning: No port openssl3 found in the index. 
> ---> Computing dependencies for openssl
> Error: Dependency 'openssl3' not found. 
> Error: Unable to execute port: upgrade openssl failed 
> $ sudo port install openssl 
> ---> Computing dependencies for openssl
> Error: Dependency 'openssl3' not found. 
> Error: Follow https://guide.macports.org/#project.tickets to report a bug. 
> Error: Processing of port openssl failed
> $ sudo port -n upgrade --force python38
> --->  Computing dependencies for python38
> --->  Fetching archive for python38
> --->  Attempting to fetch 
> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2 from 
> https://packages.macports.org/python38
> --->  Attempting to fetch 
> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2.rmd160 from 
> https://packages.macports.org/python38
> --->  Installing python38 @3.8.12_4+optimizations
> --->  Cleaning python38
> --->  Computing dependencies for python38
> --->  Deactivating python38 @3.8.11_0
> --->  Cleaning python38
> --->  Activating python38 @3.8.12_4+optimizations
> --->  Cleaning python38
> --->  Updating database of binaries
> --->  Scanning binaries for linking errors
> --->  Found 18 broken files, matching files to ports 
> --->  Found 4 broken ports, determining rebuild order
> You can always run 'port rev-upgrade' again to fix errors.
> The following ports will be rebuilt:
>  python38 @3.8.12+optimizations
>  python39 @3.9.6
>  glib2 @2.58.3+x11
>  gobject-introspection @1.60.2
> Continue? [Y/n]: y
> Warning: No port openssl3 found in the index.
> --->  Computing dependencies for openssl
> Error: Dependency 'openssl3' not found.
> Error: rev-upgrade failed: Error rebuilding python38
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> 
> 

Re: is macports getting rusty?

[Chris Jones]

To first order builds are done on a first-committed-first-built basis. 
The time a build takes is not something known up front so prioritizing 
basis on this would anyway not really be feasible.


Yes, the builders must install the dependencies of a port before a given 
port can be built. If one of those deps also has an update in the queue, 
later on than the current build, but needed for the build then it will 
be done 'early'. so in a sense it is correct that commonly used 
dependencies will tend to get built a bit faster than they might 
otherwise get done.


'Normally' though the builders keep up with the pace of commits, so the 
build queue is reasonable short. It can happen that some commit might 
happen that requires a lot of ports to get built, or a big build (like 
gcc, clang or rust) comes along that causes a small backlog to build up. 
These are usually cleared quite quickly (by which I mean a few days).


Another cause of a backlog is when a new builder is added, like was done 
recently for macOS12. The builders in this case have to work their way 
through all the various deps, so a backlog can build up that takes a 
while to clear.


Chris

On 29/11/2021 2:32 pm, Richard L. Hamilton wrote:
I would expect that the buildbots also need to satisfy dependencies, and 
thus, heavily-depended on builds would tend to be done earlier, 
regardless of whether or not they were large and slow; and if they are 
large and slow, they're arguably delaying the building of even more 
smaller ports that don't depend on them, which is not necessarily a gain.


If I'm right about ports being built also by the buildbots in dependency 
order, any further tweak to build order would likely have minimal benefits.


The real improvement would be more buildbots, but that would take either 
a way of trusting volunteer buildbots (and that they were managed 
properly to produce fully correct results, and quite possibly dedicated 
to the purpose to avoid anything that would conflict or interfere), or 
an actual budget, or donated servers and server farm space, power, 
cooling, etc. Another improvement might be more people qualified, 
trusted, and authorized to babysit the buildbots, and/or automatic 
tickets on failed builds, since if a build on a buildbot fails, it's 
either a problem with the buildbot or with the port itself; and in the 
latter case, those building themselves will also have the problem.


On Nov 29, 2021, at 09:15, Bill Cole 
<mailto:macportsusers-20171...@billmail.scconsult.com>> wrote:


On 2021-11-29 at 08:32:46 UTC-0500 (Mon, 29 Nov 2021 13:32:46 +0000)
Chris Jones mailto:jon...@hep.phy.cam.ac.uk>>
is rumored to have said:

If you find yourself during an port update building rust from source, 
either just let it finish, or if you don't want your machine tied up 
building rust for some period, just cancel the build and try again 
later on, as as others have pointed out eventually the buildbots will 
provide the binary tarball for it and thus you will just pick that 
once its available.


This raises a question that I cannot find a clear answer to:

How are builds prioritized on the buildbots?

I would hope that in an ideal world, some priority is given to large, 
slow, and heavily-depended-upon builds. It's also easier to say that 
than to actually implement it, but it would help address a real pain 
point in using MacPorts.



--
Bill Cole
b...@scconsult.com <mailto:b...@scconsult.com> or billc...@apache.org 
<mailto:billc...@apache.org>

(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire



--
eMail:mailto:rlha...@smart.net <mailto:rlha...@smart.net>

Re: is macports getting rusty?

[Chris Jones]

Give the developers of rust itself a piece of your mind if you like, 
over how slow it is to compile. Good luck with that - I suspect to be 
THAT slow (although really? compiling a C compiler suite plus library 
isn't exactly fast either) they might be doing some things by brute 
force that they haven't got any other good way to do - like running a 
serious test suite, as just one example. And of course they're the ones 
that suffer most over how slow it is to compile, since they have to 
rebuild rust every time they want to test some seemingly minor change. 
So I suspect they're already doing what can to speed it up that they 
don't think sacrifices any other concern.


Actually building rust does NOT take that much longer than any other 
compiler tool kit, such as gcc or LLVM(clang) . This is in part because 
rust itself is based on LLVM and internally the build compiles its own 
LLVM instance before going on to build the rust specific parts on top of 
that. This accounts from probably something like 60-70% of the total 
build time.


If you find yourself during an port update building rust from source, 
either just let it finish, or if you don't want your machine tied up 
building rust for some period, just cancel the build and try again later 
on, as as others have pointed out eventually the buildbots will provide 
the binary tarball for it and thus you will just pick that once its 
available.


Chris

Re: Does MacPorts depend on Spotlight?

[Chris Jones]

Some users might find it useful, and the exact volume to exclude depends 
on the details of the users installation, which would be difficult to 
automate. So I think its fine to just leave it to be done by hand by 
those that wish to.


On 17/11/2021 3:09 pm, André-John Mas wrote:
Just wondering whether it would make sense for MacPorts to auto exclude 
that folder? Does spotlight even provide an API or command that would 
allow MacPorts to do that?


André-John

Sent from my phone. Envoyé depuis mon téléphone.


On 16 Nov 2021, at 21:03, Richard L. Hamilton  wrote:

Good, thanks. Perhaps I wouldn't exclude the whole /opt/local (or 
whatever install prefix) unless performance is a major issue, but 
/opt/local/var/macports, which is less likely to be interesting in 
terms of commands or configuration files or documentation, and both 
large (mine is 24GiB when the entire /opt/local is only 35GiB - and I 
frequently remove most inactive ports and run a port clean installed) 
and active in terms of changes.


On Nov 16, 2021, at 16:06, Chris Jones <mailto:jon...@hep.phy.cam.ac.uk>> wrote:



I am not aware of any use macports itself makes of spotlight, so for 
sure if you don’t plan on using it yourself to search the install 
prefix, you can disable it.


On 16 Nov 2021, at 6:26 am, Richard L. Hamilton <mailto:rlha...@smart.net>> wrote:


Seems it'd thrash Spotlight a lot less during "port selfupdate" or 
"port upgrade outdated" to exclude /opt/local, as long as that 
wouldn't break anything (obviously one couldn't then use Spotlight 
to search /opt/local, but that's ok with me).





--
eMail:mailto:rlha...@smart.net <mailto:rlha...@smart.net>

Re: Does MacPorts depend on Spotlight?

[Chris Jones]

I am not aware of any use macports itself makes of spotlight, so for sure if 
you don’t plan on using it yourself to search the install prefix, you can 
disable it.

> On 16 Nov 2021, at 6:26 am, Richard L. Hamilton  wrote:
> 
> Seems it'd thrash Spotlight a lot less during "port selfupdate" or "port 
> upgrade outdated" to exclude /opt/local, as long as that wouldn't break 
> anything (obviously one couldn't then use Spotlight to search /opt/local, but 
> that's ok with me).
> 
> 

Re: xorg-server

[Chris Jones]

> On 12 Nov 2021, at 6:59 pm, Tom  wrote:
> 
> 
>> 
>>> Hi, 
>>> 
>>> when trying to run an X11 program, I get the following error message:
>>> 
>>> (putty:8198): Gtk-WARNING **: 00:06:49.190: cannot open display: :0
>>> 
>>> How can I fix that?
>> 
>> Assuming you are running Mac OS X 10.5 or later:
>> 
>> Check your .zprofile or .profile or .bash_profile for a line like:
>> 
>> DISPLAY=:0
>> 
>> Delete it.
>> 
>> The MacPorts 2.6.4 installer for macOS 11 erroneously added this line. This 
>> problem has been fixed in newer versions of the MacPorts installer but any 
>> erroneous DISPLAY line added by the 2.6.4 installer needs to be removed 
>> manually.
> 
> Now xorg-server is starting and quiting. The app does not appear.
> What could be the problem?

Impossible to say without more data.

Do you have any crash logs in Console ? Any other messages ?

What application are you running ? Try install a simple one like xclock and see 
if that works ?

Have you tired removing then reinstalling the xorg-server port ?

Are you actually using the xorg-server X11 server or do you perhaps have 
another one installed instead ?

Have you logged out and back in again, as required by the xorg-server 
instalation ?

Chris

Re: provide latest OS root certificates via port?

[Chris Jones]

I have always favoured VMWare over parallels myself, and they now offer a free 
license for non-commerical usages.

https://customerconnect.vmware.com/web/vmware/evalcenter?p=fusion-player-personal

> On 31 Oct 2021, at 12:07 pm, Richard L. Hamilton  wrote:
> 
> Years ago, creating a (then OS X, now macOS) VM under free VirtualBox was a 
> horrid pain (which is why I'm running the relatively expensive but nicer 
> Parallels for that and VMs other than Solaris).
> 
> But apparently now it's relatively easy. You do need plenty of extra disk 
> space and I'd say 8GB more ram than you'd otherwise need. See 
> https://www.soupbowl.io/2020/04/macos-in-virtualbox/
> (I haven't tried it, but it looks believable)
> 
> 
>> On Oct 31, 2021, at 06:46, Henning Hraban Ramm  wrote:
>> 
>> I’m working on a 2013 Mac mini and can’t upgrade further than 10.14 (don’t 
>> want to loose my 32 bit software, and I seem too stupid for VMs).
> 
> 

Re: Does MacPorts need ALL of Xcode?

[Chris Jones]

> On 27 Sep 2021, at 10:36 pm, Ian Wadham  wrote:
> 
> Hello Chris,
> 
>> On 27 Sep 2021, at 8:42 am, Chris Jones  wrote:
>> The majority of ports will indeed build fine with just the CLT installed.
> 
> So what is the “recipe” to install just the CLT with no version of Xcode 
> present? And can that recipe be included in the MacPorts Guide?

I’ve no idea on the ‘best’ way as personally i want Xcode anyway, but you could 
try navigating to 

https://developer.apple.com/download/more/?=command%20line%20tools 

and install the correct version from there. If your next question is whats the 
correct version see

https://trac.macports.org/wiki/XcodeVersionInfo

> 
>> There are a number though where the build does indeed require a complete 
>> Xcode installation, which is why the baseline recommendation is to install 
>> Xcode. However if you are ok with perhaps running into the occasional port 
>> failure (the likelihood for which depends on which ports you use) you likely 
>> can get by just fine with just the CLT.
> 
> Couldn’t those ports list Xcode as a build dependency?

Not just like a regular port dep., so it gets installed as required.

There is an Xcode PG which handles this and I think errors out if Xcode is not 
installed, so its fairly obvious what is wrong.
> 
> If a dependency has to be another MacPorts package, then perhaps there could 
> be a dummy Xcode in MacPorts, maybe just a Portfile, that checks the presence 
> and version of the Xcode.app.

See above. A PG to handle this already exists.
> 
> Otherwise, new MacPorts users may be paying a 20Gb disk storage penalty 
> forever more. And the time to download and install Xcode could become a 
> disincentive for new MacPorts users in any case…
> 
> Cheers, Ian Wadham.
> 
>> Chris
>> 
>>>> On 26 Sep 2021, at 10:07 am, Mircea Trandafir  wrote:
>>> 
>>>  I’ve been using only the command line tools for more than a year with 
>>> absolutely no issues (other than the occasional “version not detected” 
>>> error, but I think that happens with Xcode too).
>>> 
>>> -- 
>>> Mircea Trandafir
>>> Associate professor
>>> Department of Economics
>>> University of Southern Denmark
>>> Campusvej 55, 5230 Odense M
>>> Denmark
>>> Email: mircea.tranda...@sam.sdu.dk
>>> Web: http://www.mirceatrandafir.com
>>> 
>>>> On Sep 26, 2021, at 5:52 AM, Ian Wadham  wrote:
>>>> 
>>>> Hi guys,
>>>> 
>>>> I have recently upgraded my MacOS from High Sierra 10.13 to Catalina 
>>>> 10.15, mainly because I would like to start playing with a package called 
>>>> Flutter, which has a dependency on Xcode 12+ in its MacBook version.
>>>> 
>>>> It appears that Xcode is following some variant of Grosch’s Law, or maybe 
>>>> Parkinson’s Law (software expands to fill the hardware space available to 
>>>> it). So I am wondering, if all a user needs are some MacPorts packages, 
>>>> whether it is necessary to install all (or even any) of Xcode just to get 
>>>> the command-line tools.
>>>> 
>>>> I have been using MacPorts to get access to FOSS for more than 10 years 
>>>> and have watched the Xcode requirement grow from around 1 Gb of disk to 
>>>> around 20 Gb in Catalina. In Xcode 9, on High Sierra, the requirement was 
>>>> around 10 Gb. So it has roughly doubled in two version steps of MacOS.
>>>> 
>>>> At first I used to regard the Xcode overhead as being like some sort of 
>>>> tax on the pleasure of using FOSS, but now it is taking up an unhealthy 
>>>> portion of the 250 Gb in my MacBook Pro’s 250 Gb internal SSD drive.
>>>> 
>>>> I have to put up with this if I wish to use Macports and Flutter, even 
>>>> though, like Dave Horsfall, I am unlikely to use Xcode as an IDE. So is it 
>>>> possible to have MacPorts depend on some minimal subset of Xcode?
>>>> 
>>>> Cheers,
>>>> Ian Wadham.
>>>> 
> 

Re: Does MacPorts need ALL of Xcode?

[Chris Jones]

The majority of ports will indeed build fine with just the CLT installed. There 
are a number though where the build does indeed require a complete Xcode 
installation, which is why the baseline recommendation is to install Xcode. 
However if you are ok with perhaps running into the occasional port failure 
(the likelihood for which depends on which ports you use) you likely can get by 
just fine with just the CLT.

Chris

> On 26 Sep 2021, at 10:07 am, Mircea Trandafir  wrote:
> 
>  I’ve been using only the command line tools for more than a year with 
> absolutely no issues (other than the occasional “version not detected” error, 
> but I think that happens with Xcode too).
> 
> -- 
> Mircea Trandafir
> Associate professor
> Department of Economics
> University of Southern Denmark
> Campusvej 55, 5230 Odense M
> Denmark
> Email: mircea.tranda...@sam.sdu.dk
> Web: http://www.mirceatrandafir.com
> 
>>> On Sep 26, 2021, at 5:52 AM, Ian Wadham  wrote:
>>> 
>> Hi guys,
>> 
>> I have recently upgraded my MacOS from High Sierra 10.13 to Catalina 10.15, 
>> mainly because I would like to start playing with a package called Flutter, 
>> which has a dependency on Xcode 12+ in its MacBook version.
>> 
>> It appears that Xcode is following some variant of Grosch’s Law, or maybe 
>> Parkinson’s Law (software expands to fill the hardware space available to 
>> it). So I am wondering, if all a user needs are some MacPorts packages, 
>> whether it is necessary to install all (or even any) of Xcode just to get 
>> the command-line tools.
>> 
>> I have been using MacPorts to get access to FOSS for more than 10 years and 
>> have watched the Xcode requirement grow from around 1 Gb of disk to around 
>> 20 Gb in Catalina. In Xcode 9, on High Sierra, the requirement was around 10 
>> Gb. So it has roughly doubled in two version steps of MacOS.
>> 
>> At first I used to regard the Xcode overhead as being like some sort of tax 
>> on the pleasure of using FOSS, but now it is taking up an unhealthy portion 
>> of the 250 Gb in my MacBook Pro’s 250 Gb internal SSD drive.
>> 
>> I have to put up with this if I wish to use Macports and Flutter, even 
>> though, like Dave Horsfall, I am unlikely to use Xcode as an IDE. So is it 
>> possible to have MacPorts depend on some minimal subset of Xcode?
>> 
>> Cheers,
>> Ian Wadham.
>> 

Re: code::blocks and X11 via MacPorts: is this as it is supposed to be?

[Chris Jones]

sudo port install xorg-server

Logout and back in again

> On 12 Sep 2021, at 11:17 am, Gerben Wierda via macports-users 
>  wrote:
> 
> I’ve been trying out code::blocks and X11 installed via MacPorts and I’m 
> under the impression something is missing.
> 
> I installed using
> 
> sudo port install org
> sudo port install codeblocks
> 
> Logging out and in again made sure the correct environment variables are set. 
>  When I then open codeblocks, I see a lot of error messages like this:
> 
> (codeblocks:75317): Gtk-CRITICAL **: 12:02:13.796: gtk_box_gadget_distribute: 
> assertion 'size >= 0' failed in GtkScrollbar
> 
> But the system does seem to launch.
> 
> Trying to launch xeyes as a test, gets me a huge entire-screen sized xeyes 
> and no way to turn that into a small window somewhere.
> 
> Is that as it is supposed to be?
> 
> Gerben Wierda (LinkedIn)
> R Enterprise Architecture (main site)
> Book: Chess and the Art of Enterprise Architecture
> Book: Mastering ArchiMate
> 

Re: cdrtools streamripper

[Chris Jones]

> On 10 Jun 2021, at 9:05 am, Giuseppe Di Matteo  
> wrote:
> 
> I opened ticket #63062.
> What about streamripper. Configure failed for libmad. (Big Sur arm64)

Same. Check for and if need be open tickets against failing ports.

> 
> Pino Di Matteo
> pinodimat...@me.com
> 
> 
> 
>> Le 9 juin 2021 à 11:04, Christopher Jones  a écrit 
>> :
>> 
>> 
>> Please check for an open trac ticket, and if one does not exist open one.
>> 
>>> On 9 Jun 2021, at 9:47 am, Giuseppe Di Matteo  
>>> wrote:
>>> 
>>> I made the change in the Portfile, but it still won’t install. It seems 
>>> that the problem is now with the arch arm64 (Mac mini M1).
>>> Giuseppe Di Matteo
>>> pinodimat...@me.com
>>> 
>>> 
>>> 
>>> 
>>> 
 Le 8 juin 2021 à 20:48, Christopher Jones  a 
 écrit :
 
 
 For the smake issue see
 
 https://github.com/macports/macports-ports/commit/9040f7195e114173a42c71ee57e74c248ef7ebb1
 
> On 7 Jun 2021, at 5:15 pm, Andrew Udvare  wrote:
> 
> 
>> On 2021-06-07, at 09:34, Giuseppe Di Matteo via macports-users 
>>  wrote:
>> 
>> I can’t install cdrtools and streamripper on macOS 11 (Big Sur).
>> 
>> Giuseppe Di Matteo
>> pinodimat...@me.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> I can reproduce the issue with cdrtools. `smake` does not accept -j.
> 
> I cannot reproduce the issue with streamripper. streamripper builds for 
> me. However, I am on x86-64.
 
>>> 
>> 
> 

Re: MacPorts 2.7.0 has been released

[Chris Jones]

See `config.log' for more details

We need to see what is in this file… (from the messages you posted below).

Chris

> On 19 May 2021, at 3:06 pm, Bjarne D Mathiesen  
> wrote:
> 
> OK -
> 
> on 10.6.8 I get :
> 
> #=> ls -l /usr/bin/cc
> lrwxr-xr-x  1 root  wheel  32  4 Jan 14:50 /usr/bin/cc ->
> ../llvm-gcc-4.2/bin/llvm-gcc-4.2
> #=> ls -l /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
> -rwxrwxr-x  1 root  admin  116992 12 Feb  2011
> /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
> 
> 
> on 10.15.7 I get :
> 
> #=> ls -l /usr/bin/cc
> lrwxr-xr-x  1 root  wheel  5  1 Mar 13:06 /usr/bin/cc -> clang
> #=> ll /usr/bin/clang
> -rwxr-xr-x  1 root  wheel  31488 21 Sep  2020 /usr/bin/clang
> 
> 
> So the (temporary) fix for me on 10.6.8 is :
> 
> #=> which clang
> /opt/local/bin/clang
> #=> mv /usr/bin/cc /usr/bin/cc.apple
> #=> ln -s $( which clang ) /usr/bin/cc
> #=> ll /usr/bin/cc
> lrwxr-xr-x  1 root  wheel  20 19 Maj 15:53 /usr/bin/cc ->
> /opt/local/bin/clang
> 
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> ---
> denne besked er skrevet i et totalt M$-frit miljø
> OpenCore + macOS 10.15.7 Catalina
> MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
> ATI Radeon RX 590 8 GB

Re: port update outdated 'Failed to archivefetch aom: version @3.1.0_0'

[Chris Jones]

Error: Follow https://guide.macports.org/#project.tickets to report a bug.

Please follow the instructions you were given above to either open a ticket or 
see if one for this issue already exists.

> On 12 May 2021, at 8:25 pm, tom eee  wrote:
> 
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.

Re: OpenMPI Users - Is Anyone Using openmpi-clang33 or openmpi-clang34?

[Chris Jones]

> On 7 May 2021, at 8:33 pm, Ken Cunningham  
> wrote:
> 
> There is one issue with that.
> 
> qt5-qtcreator needs clang-10 on arm for it’s libraries (that is actually the 
> only reason why I initially fixed clang-10 to work on arm64 in the first 
> place).
> 
> qt5-qtcreator cannot (could not) use any newer clang when I checked six 
> months ago.
> 
> So — we still need clang-10 on arm64 even if we don’t use it as a compiler 
> there.

We can at least though not bother building the openmpi versions for these 
clangs, even if we have to keep clang10 around for arm until we can migrate the 
above to clang11.

Cheers Chris
> 
> K
> 
> 
> 
>> On May 7, 2021, at 12:22 PM, Chris Jones  wrote:
>> 
>> Hi,
>> 
>> Another clean up suggestion is to remove all clangs apart from 11+ for 
>> macOS11(arm). I just noticed the buildbots building the clang-9.0 version 
>> for arm, but its worth noting that clang 9.0 and 10 are not reliable for 
>> arm, I have seen them generate bad code, fail with ICEs, so really there is 
>> little point in providing all but the clang11(and newer) version which is 
>> the first version with reliable arm support.
>> 
>> Chris
>> 
>>>> On 7 May 2021, at 8:11 pm, Ken Cunningham 
>>>>  wrote:
>>> 
>>> Yes, gcc7 works down to 10.4, both PPC and Intel and is the primary 
>>> compiler there.  I can see no need for openMPI to support any older gcc.
>>> 
>>> clang-3.3, clang-3.4, and clang-3.7 should not be used for anything other 
>>> than bootstrapping to newer clangs now.
>>> 
>>> 
>>> Ken
>>> 
>>> 
>> 
> 

Re: OpenMPI Users - Is Anyone Using openmpi-clang33 or openmpi-clang34?

[Chris Jones]

Hi,

Another clean up suggestion is to remove all clangs apart from 11+ for 
macOS11(arm). I just noticed the buildbots building the clang-9.0 version for 
arm, but its worth noting that clang 9.0 and 10 are not reliable for arm, I 
have seen them generate bad code, fail with ICEs, so really there is little 
point in providing all but the clang11(and newer) version which is the first 
version with reliable arm support.

Chris

> On 7 May 2021, at 8:11 pm, Ken Cunningham  
> wrote:
> 
> Yes, gcc7 works down to 10.4, both PPC and Intel and is the primary compiler 
> there.  I can see no need for openMPI to support any older gcc.
> 
> clang-3.3, clang-3.4, and clang-3.7 should not be used for anything other 
> than bootstrapping to newer clangs now.
> 
> 
> Ken
> 
> 

Re: OpenMPI Users - Is Anyone Using openmpi-clang33 or openmpi-clang34?

[Chris Jones]

Hi,

I would suggest maybe its worth pruning the gcc list a bit as well ? I believe 
e.g. gcc7 at least works all the way down to 10.5, perhaps even older ? Do we 
still need gcc 5, 6?

Chris

> On 7 May 2021, at 1:35 pm, Christopher Nielsen  
> wrote:
> 
> Folks,
> 
> We’re considering retirement of ports openmpi-clang33 and openmpi-clang34, to 
> reduce the number of openmpi-* ports we support. At the moment, the list is 
> quite large, and it’s becoming a challenge to thoroughly test and maintain 
> all of these:
> 
> openmpi-clang  @4.1.1  science/openmpi
> openmpi-clang10@4.1.1  science/openmpi
> openmpi-clang11@4.1.1  science/openmpi
> openmpi-clang33@4.1.1  science/openmpi
> openmpi-clang34@4.1.1  science/openmpi
> openmpi-clang37@4.1.1  science/openmpi
> openmpi-clang50@4.1.1  science/openmpi
> openmpi-clang60@4.1.1  science/openmpi
> openmpi-clang70@4.1.1  science/openmpi
> openmpi-clang80@4.1.1  science/openmpi
> openmpi-clang90@4.1.1  science/openmpi
> openmpi-default@4.1.1  science/openmpi
> openmpi-gcc5   @4.1.1  science/openmpi
> openmpi-gcc6   @4.1.1  science/openmpi
> openmpi-gcc7   @4.1.1  science/openmpi
> openmpi-gcc8   @4.1.1  science/openmpi
> openmpi-gcc9   @4.1.1  science/openmpi
> openmpi-gcc10  @4.1.1  science/openmpi
> openmpi-gcc49  @4.1.1  science/openmpi
> 
> While we hope to continue supporting as many of these as possible for the 
> foreseeable future, removing two of the oldest Clang versions would allow us 
> to provide more focus on the rest.
> 
> Please let us know if you use the clang33 or clang34 variations, or know 
> anyone who does.
> 
> Thanks,
> -Chris

Re: Is it possible to install Julia on M1 Mac?

[Chris Jones]

Hi,

Whilst the statement that the devel version of gcc was correct at the time it 
was made, gcc10 now has had support back ported. So I suggest you force 
uninstall libgcc-devel and let libgcc10 get installed in its place.

Chris

> On 7 May 2021, at 12:37 pm, Andrew Rohl  wrote:
> 
> I have installed gcc-devel as I was told that it is the only version that 
> can be compiled on the M1.
> 
> Then tried to install Julia:
> 
>> sudo port install julia  
>>   
>> 
>> --->  Computing dependencies for julia
>> Error: Can't install libgcc10 because conflicting ports are active: 
>> libgcc-devel
>> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
>> Error: Processing of port Julia failed
> 
> Is there any way to install Julia?
> 
> Many thanks
> 
>  Andrew

Re: Installing universal binaries on Apple M1 using macports

[Chris Jones]

Hi,

Llvm/clang 10 does not work reliably on apple silicon. use llvm/clang 11 
instead.

Chris

> On 30 Mar 2021, at 7:19 am, Sandeep Thakkar 
>  wrote:
> 
> 
> Hi,
> 
> I'm installing llvm-10 on Apple M1 (macOS BigSur) with these changes in 
> macports.conf:
> 
> # custom changes
> buildfromsourcealways
> macosx_deployment_target10.14
> macosx_sdk_version11.1
> 
> and the command I used is:
> % sudo port install llvm-10 +universal
> 
> But, what I see is:
> % otool -l /opt/local/libexec/llvm-10/lib/libLLVM.dylib| grep "minos\|sdk"
> minos 11.0
>   sdk 11.1
> 
> The sdk version looks fine, but why the minos is 11.0? shouldn't it be 10.14 
> as expected? What am I missing?
> 
> -- 
> Sandeep Thakkar
> 
> 

Re: gfortran for M1?

[Chris Jones]

Hi,

Gcc-devel provides gfortran for M1 machines by default.

Chris

> On 20 Mar 2021, at 1:01 pm, petr.2...@centrum.cz wrote:
> 
> Is it already possible to install gfortran on M1?
> It seems that gcc-devel does not have +gfortran variant and and other gcc 
> versions are not compatible. 
> Thank you, 
> Petr

Re: OS Platform mismatch - while installing stm32flash

[Chris Jones]

Hi,

> On 11 Mar 2021, at 6:16 pm, James Secan  wrote:
> 
> Not sure I understand this.  Do we now need to “migrate” when we update from 
> x.x.y to x.x.y+1?  Has Apple fouled things up that badly?  I thought 
> migration was only needed in a major OS upgrade, which I would consider to be 
> from macOS x to maxOS x+1.

You are correct, for a minor update it is not required.

The issue is the OP must not have followed the migration instructions correctly 
when updating from Darwin19 to Darwin20 (macOS 10.15 to 11.0), as I don’t see 
any other way he could have got those errors messages.

Chris

> 
> Jim
> 3222 NE 89th St
> Seattle, WA 98115
> (206) 430-0109
> 
>> On Mar 11, 2021, at 6:44 AM, Chris Jones  wrote:
>> 
>> Hi,
>> 
>> Looks like at some point you did not follow the migration instructions 
>> correctly. You should do so now.
>> 
>> Chris
>> 
>>>> On 11 Mar 2021, at 2:41 pm, Christoph P.U. Kukulies  
>>>> wrote:
>>> 
>>> Of course the error (OS platform mismatch) occurs on every command I'm
>>> running on port,
>>> 
>>> like
>>> 
>>> port info
>>> 
>>>> Am 11.03.2021 um 14:20 schrieb Christoph Kukulies:
>>>> Tried to do
>>>> 
>>>> 
>>>> $ sudo port install stm32flash
>>>> Password:
>>>> Error: Current platform "darwin 20" does not match expected platform 
>>>> "darwin 19"
>>>> Error: If you upgraded your OS, please follow the migration instructions: 
>>>> https://trac.macports.org/wiki/Migration
>>>> OS platform mismatch
>>>>  while executing
>>>> "mportinit ui_options global_options global_variations"
>>>> Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform 
>>>> mismatch
>>>> 
>>>> 
>>>> Did an os update from macOS 12.2.2 to 12.2.3 right before.
>>>> 
>>>> 
>>>> —
>>>> Christoph
>>>> 
>>>> 
>>> 
>> 
> 

Re: OS Platform mismatch - while installing stm32flash

[Chris Jones]

Hi,

Looks like at some point you did not follow the migration instructions 
correctly. You should do so now.

Chris

> On 11 Mar 2021, at 2:41 pm, Christoph P.U. Kukulies  wrote:
> 
> Of course the error (OS platform mismatch) occurs on every command I'm
> running on port,
> 
> like
> 
> port info
> 
>> Am 11.03.2021 um 14:20 schrieb Christoph Kukulies:
>> Tried to do
>> 
>> 
>> $ sudo port install stm32flash
>> Password:
>> Error: Current platform "darwin 20" does not match expected platform "darwin 
>> 19"
>> Error: If you upgraded your OS, please follow the migration instructions: 
>> https://trac.macports.org/wiki/Migration
>> OS platform mismatch
>>while executing
>> "mportinit ui_options global_options global_variations"
>> Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform 
>> mismatch
>> 
>> 
>> Did an os update from macOS 12.2.2 to 12.2.3 right before.
>> 
>> 
>> —
>> Christoph
>> 
>> 
> 

Re: Warning: cltversion again

[Chris Jones]

Hi,

> On 7 Mar 2021, at 6:18 pm, Fielding, Eric J (US 329A) via macports-users 
>  wrote:
> 
> 
> I am getting this warning again from running ‘port upgrade outdated’:
>  
> Warning: cltversion: The Command Line Tools are installed, but MacPorts 
> cannot determine the version.
> Warning: cltversion: For a possible fix, please see: 
> https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt
>  
> I recently opened Xcode and it said it needed to update some tools, so I 
> guess it installed a different version of the Command Line Tools (CLT) in a 
> way that MacPorts can’t determine the version. Is it worth doing the CLT 
> reinstallation described on the Hotlist page or should I just ignore it? It 
> seems that everything is building well despite the warning. I went through 
> the reinstallation procedure a month or two ago.

You should rerun the fixes. The issues sadly reappears on macOS/Xcode updates.

Chris

>  
> I am on Catalina (10.15.7), in case that makes a difference.
>  
> ++Eric

Re: stdlib.h compilation error for macports gcc9.

[Chris Jones]

per/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
>>> Thread model: posix
>>> gcc version 9.3.0 (MacPorts gcc9 9.3.0_5) 
>>> COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-c' '-o' 'E2.5.2.o' 
>>> '-mmacosx-version-min=10.15.0' '-asm_macosx_version_min=10.15' 
>>> '-shared-libgcc' '-mtune=core2'
>>>  /opt/local/libexec/gcc/x86_64-apple-darwin19/9.3.0/cc1plus -quiet -v 
>>> -D__DYNAMIC__ E2.5.2.cpp -fPIC -quiet -dumpbase E2.5.2.cpp 
>>> -mmacosx-version-min=10.15.0 -mtune=core2 -auxbase-strip E2.5.2.o 
>>> -std=c++11 -version -o 
>>> /var/folders/yh/ywbbh6_w8xl9_6006s6dywd8gr/T//cc1Ruczn.s
>>> GNU C++11 (MacPorts gcc9 9.3.0_5) version 9.3.0 (x86_64-apple-darwin19)
>>> compiled by GNU C version 9.3.0, GMP version 6.2.1, MPFR version 4.1.0, 
>>> MPC version 1.2.1, isl version isl-0.22.1-GMP
>>> 
>>> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
>>> ignoring nonexistent directory 
>>> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/opt/local/include"
>>> ignoring nonexistent directory 
>>> "/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.3.0/../../../../../x86_64-apple-darwin19/include"
>>> ignoring nonexistent directory 
>>> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include"
>>> ignoring nonexistent directory 
>>> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks"
>>> ignoring nonexistent directory 
>>> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/Library/Frameworks"
>>> #include "..." search starts here:
>>> #include <...> search starts here:
>>>  
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
>>>  /usr/local/include
>>>  /opt/local/include
>>>  /usr/local/dart-sdk/include
>>>  /Library/Frameworks/R.framework/Resources/include
>>>  /opt/local/include/gcc9/c++/
>>>  /opt/local/include/gcc9/c++//x86_64-apple-darwin19
>>>  /opt/local/include/gcc9/c++//backward
>>>  /opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.3.0/include
>>>  /opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.3.0/include-fixed
>>> End of search list.
>>> GNU C++11 (MacPorts gcc9 9.3.0_5) version 9.3.0 (x86_64-apple-darwin19)
>>> compiled by GNU C version 9.3.0, GMP version 6.2.1, MPFR version 4.1.0, 
>>> MPC version 1.2.1, isl version isl-0.22.1-GMP
>>> 
>>> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
>>> Compiler executable checksum: 45101e0fe9cd9377caa0fee122dd387a
>>> In file included from 
>>> /opt/local/include/gcc9/c++/ext/string_conversions.h:41,
>>>  from /opt/local/include/gcc9/c++/bits/basic_string.h:6493,
>>>  from /opt/local/include/gcc9/c++/string:55,
>>>  from /opt/local/include/gcc9/c++/bits/locale_classes.h:40,
>>>  from /opt/local/include/gcc9/c++/bits/ios_base.h:41,
>>>  from /opt/local/include/gcc9/c++/ios:42,
>>>  from /opt/local/include/gcc9/c++/ostream:38,
>>>  from /opt/local/include/gcc9/c++/iostream:39,
>>>  from ../../standard_includes.h:1,
>>>  from E2.5.2.cpp:1:
>>> /opt/local/include/gcc9/c++/cstdlib:75:15: fatal error: stdlib.h: No such 
>>> file or directory
>>>75 | #include_next 
>>>   |   ^~
>>> compilation terminated.
>>> make: *** [../../Makefile-Template:10: E2.5.2.o] Error 1
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>>> On 7 Feb 2021, at 10:24 pm, Carlo Tambuatco  wrote:
>>>>> 
>>>>> Well what's odd is I'm only getting this error after upgrading to the 
>>>>> latest macports gcc9. Indeed when I use the XCode provided clang version 
>>>>> of gcc, it finds all the required libraries. My CPATH environment 
>>>>> variable was sufficient to specify the locations of the libraries before 
>>>>> the upgrade, so the question is, what changed post-upgrade?
>>>>> 
>>>>> On Sun, Feb 7, 2021, 5:03 PM Chris Jones  wrote:
>>>>