Calling adding a pre-configure or pre-build block via a "pre_XXX function pointer"

[René J . V . Bertin]

Hi,

I hope the title is clear enough to attract some answers.

I currently have a some PG code

```
if {[tbool use_configure]} {
ui_debug "Doing setup_build in pre-configure"
set setup_build pre-configure
} else {
ui_debug "Doing setup_build in pre-build"
set setup_build pre-build
}   
${setup_build} {
# bla
}
```

that is executed when the PG is read. I would like to move that to a function 
that also sets the global `use_configure` so I can execute it at an appropriate 
moment in the Portfile, instead of having to set use_configure before including 
the PG. Ideally the `setup_build` variable would be namespaced.

I wrote the code that sets the variable, but it is apparently not recognised as 
a callable procedure.

Stupidly I already reverted the file so I've lost the implementation that I 
whipped up, but the actual setting of the variable was done exactly as above. I 
don't understand why it works in an inline implementation as above, but not 
when done through a function. One doesn't have to declare `pre-configure` or 
`pre-build` as globals in order to call them from functions, but maybe I should 
have declared them as such in order to be able to copy them as callable 
entities?

Thanks,
R.

rust is the new bit rot?

[René J . V . Bertin]

Hi,

A bit of a rant.

A little over a year ago I wrote a rustup PortGroup that allowed me to build 
ports with a build dependency on rust using an on-the-fly install of the 
necessary toolchain via rustup. That worked like a charm, and it fact it still 
does on Linux. Annoyingly builds that succeeded a year ago now fail on Mac 
(under 10.9) with a SEGV under fseek64 or a similar syscall, without any 
incrimination of an updated dependency in MacPorts. Several hours of effort 
yesterday to update get it to work again  were in vain. I didn't manage to 
build the current rust from source, and the binary package for darwin13  
installs a rustc compiler that crashes with pointer-not-freed aborts when I try 
to build rustup from source. The backtrace in the crash reporter is useless of 
course.
I can download the official rustup-init executable which runs after relinking 
it with the legacy-support wrapper for libSystem but it downloads a toolchain 
that's crippled too.

Comments and Portfile code suggest that rust should work on darwin13 but are 
there people who have actually tested this? I see there are binary librsvg 
packages for darwin10 even, but the build bots are not entirely representative 
for production/user systems that have a myriad of (theoretically unrelated) 
ports installed.

Maybe I need to check my legacy-support port?

R.

Re: python pep517 building: requires python.move_binaries on Linux?!

[René J . V . Bertin]

>I am interested in trying MacPorts on Linux on RISC-V by the way.

The first thing to do in that endeavour would be to go over "base" to teach it 
about the new architecture!

But I'd be really more interested in getting an answer to my original question 
in this discussion!!

R.

python pep517 building: requires python.move_binaries on Linux?!

[René J . V . Bertin]

Hi,

I've been updating a number of the python packages I have installed through my 
LinuxPorts adaptation of MacPorts.

Long story short: whatever the mechanism through which ports like pyXY-build or 
pyXY-sip install versioned symlinks into $prefix/bin and the actual executables 
under $python.prefix/bin, it doesn't work on Linux.

Is there an option I can add to the default build command? I've tried to google 
the answer but couldn't come up with a specific enough search key.

Thanks,
R.

Re: rev-upgrade and checking for +universal dependencies (and build dependencies)

[René J . V . Bertin]

On Tuesday June 18 2024 05:49:39 Saagar Jha wrote:
>If you turn SIP off, and patch MacPorts to build an arm64e slice, then you can 
>use trace mode. However your patches will build a broken trace mode for anyone 
>who has SIP enable

OK, that's also what I understood (but I don't think that's what your original 
message actually said).

>and you will also be very sad if your machine ever boots in that state.

That shouldn't happen by accident, SIP mode is determined via a firmware 
toggle, right?


R.

Re: rev-upgrade and checking for +universal dependencies (and build dependencies)

[René J . V . Bertin]

On Tuesday June 18 2024 05:04:50 Saagar Jha wrote:

>> With SIP disabled, one can add a kernel boot argument to allow user
>> space to use Apple's ABI with pointer authentication, which would allow
>> building a copy of tracelib that works on those binaries.
>> 
>> I'm not aware that anybody has successfully done that.
>
>I have. I never chose to upstream it because I figured that nobody cared for 
>that configuration, and it has the unfortunate quality that it cannot be done 
>in a way that degrades gracefully when SIP is off. On systems where SIP is 
>disabled, the loader will look for an arm64e slice or complain loudly. If you 
>include such a slice and SIP is disabled it will be preferentially selected 
>over an arm64 version by the fat binary matching algorithm, and immediately 
>terminate the process upon load. So there’s no good answer here :(

Something doesn't add up there. Do you mean those problems arise when you turn 
SIP back ON, or do you mean that you "successfully did that" with SIP turned ON?

Either way, it was to be foreseen that Apple would start turning their 
computers into iThings when they came up with their own CPU design; the fact 
that they're only barely NOT making it impossible to run Linux on them is a 
telltale sign.

R.

Re: rev-upgrade and checking for +universal dependencies (and build dependencies)

[René J . V . Bertin]

On Sunday June 09 2024 21:10:47 Clemens Lang wrote:

>With SIP disabled, one can add a kernel boot argument to allow user
>space to use Apple's ABI with pointer authentication, which would allow
>building a copy of tracelib that works on those binaries.

I have no idea what you just said, but it seems I wasn't wrong that Apple 
wouldn't stop at SIP to lock us out.

>Additionally, attempting to inject those binaries causes the program to
>be killed by the kernel, i.e., things break.

I thought that trace mode was to check that ports declare all the required 
dependencies that need to be installed (i.e. through MacPorts).

>Many Unix operating systems, including macOS, do not actually care about
>file permissions when you are root:

Yeah, I tend to forget that. 

At some point I'll probably have a closer look exactly how the rev-upgrade 
scanner handles files. If it simply builds a list of all dependencies that 
should be available it might be possible to implement a blacklist feature.

R.

Re: rev-upgrade and checking for +universal dependencies (and build dependencies)

[René J . V . Bertin]

On Saturday June 08 2024 09:46:34 Clemens Lang wrote:

>Using library preloading – which does not currently work against Apple's
>binaries on Apple Silicon Macs.

But those aren't installed through MacPorts. Does it matter here whether SIP & 
family are enabled or not, btw?

>Tracelib only works on spawned subprocesses, not the MacPorts tclsh
>process itself, so in order for that to work, rev-upgrade would have to
>spawn a separate process, which it currently does not.

For this particular case that should be a trivial detail. The rev-upgrade 
procedure does not itself spawn any helper processes at the moment, correct?

>I also don't see how this is would give you anything that
...
>would not.

The elegance and security of a single command that can be written to handle all 
possible error situations. Plus you're not crippling any functionality at all.

BTW, in terms of evaluation dependents of a shared library: would it suffice to 
remove read and/or execute permissions from the file rather than making the 
file disappear completely? If so it might already be enough to do that for just 
the file owner, provided the rev-upgrade scan is run as that user.  I suppose 
that files are normally owned by root in a normal MP installation...

R.

Re: rev-upgrade and checking for +universal dependencies (and build dependencies)

[René J . V . Bertin]

René J.V. Bertin wrote on 20150604::18:56:52 re: "Re: rev-upgrade and checking 
for +universal dependencies (and build dependencies)"

This discussion is older than I thought (or care to realise!) but I was 
reminded of it thanks to #51516 that brought Pextlib's tracelib.c to my 
attention.

As I said I'm not at all familiar with the trace mode but from what I 
understand it works by disabling access to all but a subset of installed files.

Could it be combined with the `rev-upgrade` feature to implement something like 
`port dependents [file|port]`, where `port dependents ` would disable 
access to the file in question and then run `rev-upgrade` (or optionally 
`rev-upgrade -v`) ?

R.

Building MacPorts - why not activate Tcl 64bit support?

[René J . V . Bertin]

Hi,

Looking through MacPorts configure.ac and the Tcl configure script I noticed 
that the latter requires explicit activation of 64bit support and that the 
former doesn't do that.

Is that simply to keep support for building on 32bit systems simple or is there 
another reason? I am not familiar enough with Tcl to know if there's any 
advantage to activating 64bit support ... but that's what MS once thought about 
supporting more than 640Kb or RAM ;)

R.

A question about a potential error in portconfigure::should_add_stdlib{} in the master branch

[René J . V . Bertin]

Hi,

I'm rebasing my LinuxPorts adaptation of "base" to a few days old checkout of 
the master branch, and saw something in the portconfigure::should_add_stdlib{} 
procedure:

```
# GCC also supports -stdlib starting with GCC 10 (and devel), but
# not with PPC builds
global configure.build_arch
if {[string match *g*-mp-* ${configure.cxx}]
&& ${configure.build_arch} ni {ppc ppc64}} {
# Do not pass stdlib to gcc if it is MacPorts custom macports-libstdc++ 
setting
# as gcc does not uderstand this. Instead do nothing, which means gcc 
will
# default to using its own libstdc++, which is in fact what we mean by
# configure.cxx_stdlib=macports-libstdc++
```

Besides the typo in the comment ;) I fear that `[string match *g*-mp-* 
${configure.cxx}]` will also match `${prefix}/bin/clang++-mp-XY`.
I understand the reason for the leading wildcard, but isn't the expression you 
want `[string match */g*-mp-* ${configure.cxx}]` ?


R.

Modifying the PortInfo data from a PortGroup?

[René J . V . Bertin]

Hi,

I'm experimenting with an idea for my Linux adaptation of MacPorts "base" and 
apparently need some insights on the internal implementation. No risk for this 
to taint the Mac version!

The idea is to add a global variant like +universal, ultimately via 
portutil.tcl but for the time being in a PortGroup. This variant would conflict 
with any variant individual ports might declare, so I was hoping to modify 
those variants in a callback.
Conflicts are stored in $PortInfo(vinfo)($currentVariant)(conflicts) (assuming 
that's the correct way to address an element of an array that's an element of 
an array itself also stored in a toplevel array), and I managed to modify it in 
a way that shows up via `port variants`:

{{{
platform linux {
variant testIdea description {Some fancy new experiment.} {}
set newVariantName testIdea
}

proc LTO::callback {} {
# this callback could really also handle the disable and allow switches!
global supported_archs LTO.must_be_disabled
global PortInfo newVariantName
platform linux {
if {[variant_exists ${newVariantName}] && [info exist 
PortInfo(variants)] && [info exists PortInfo(vinfo)]} {
array unset vinfo
array set vinfo $PortInfo(vinfo)
foreach v $PortInfo(variants) {
array unset variant
array set variant $vinfo(${v})
if {[info exists variant(conflicts)]} {
ui_debug "${v}: conflicts with $variant(conflicts), adding 
+${newVariantName}"
set conflicts [join [lsort "$variant(conflicts) 
${newVariantName}"]]
} else {
ui_debug "${v}: adding conflict with +${newVariantName}"
set conflicts "${newVariantName}"
}
array set variant [list conflicts ${conflicts}]
array set vinfo [list ${v} [array get variant]]
array set PortInfo [list vinfo [array get vinfo]]
}
}
}
#snip
}}}

{{{
> port -v variants openssl
openssl has the variants:
   LTO: build with link-time optimisation
 * conflicts with testIdea
   builtwith: Label the install with the compiler used
 * conflicts with testIdea
   cpucompat: Build using some commonly supported SIMD settings for optimal 
cross-CPU tuning
 * conflicts with cputuned testIdea
   cputuned: Build using -march=native for optimal tuning to your CPU
 * conflicts with cpucompat testIdea
   docs: install (html) documentation
 * conflicts with testIdea
   testIdea: Some fancy new experiment.
 * conflicts with testIdea
   use_lld: use the LLD linker
 * conflicts with testIdea
}}}

However, while this doesn't break existing conflict situations it does not 
actually add a functional new conflict:

{{{
> port -v variants openssl +cputuned+cpucompat
Error: openssl: Variant cputuned conflicts with cpucompat
Error: Unable to open port: Error evaluating variants
}}}

{{{
> port -v variants openssl +cputuned+testIdea
openssl has the variants:
   LTO: build with link-time optimisation
 * conflicts with testIdea
   builtwith: Label the install with the compiler used
 * conflicts with testIdea
   cpucompat: Build using some commonly supported SIMD settings for optimal 
cross-CPU tuning
 * conflicts with cputuned testIdea
  +cputuned: Build using -march=native for optimal tuning to your CPU
 * conflicts with cpucompat testIdea
   docs: install (html) documentation
 * conflicts with testIdea
  +testIdea: Some fancy new experiment.
 * conflicts with testIdea
   use_lld: use the LLD linker
 * conflicts with testIdea
}}}

My initial idea was that `PortInfo` might be a copy so modifying it would be 
pointless, but that seems unlikely since the modifications show up via `port 
variants`.

Am I overlooking something, or should I simply do the conflict detection 
myself? I realise that might be needed anyway since IIRC the `default_variants` 
feature also doesn't play nice with declared variant conflicts.

Thanks in advance,
R.

Re: CMake | IPO: -f[no-]fat-lto-objects are not cross-platform GCC options (#25931)

[René J . V . Bertin]

You're welcome ...

On Thursday April 25 2024 15:41:59 Sergey Fedorov wrote:
>Wonder when this annoying bug is fixed:

As you saw, it can help to provide a patch that fixes the issue. I have been 
dealing with CMake devs for quite a while and know they can be very convinced 
about their approaches and implementations, and often seem to understand code 
better than descriptions. Plus, a proper patch makes it easier for them to 
assess side-effects on the "normal" production systems that they're mostly 
concerned with.

Fwd: CMake | IPO: -f[no-]fat-lto-objects are not cross-platform GCC options (#25931)

[René J . V . Bertin]

FYI: https://gitlab.kitware.com/cmake/cmake/-/issues/25931

(fix should land in the next release.)

R.

Re: livecheck and curl 8.7.1

[René J . V . Bertin]

On Friday April 19 2024 22:10:40 Kirill A.  Korinsky wrote:

>Because MacPorts download distfiles and packages from HTTP, not HTTPS
>because it contains checksums for that it downloads :)

Nope. Maybe for distfiles that are hosted on the own servers, but the past few 
years more and more ports have had their `master_sites` converted to https URLs.

(With good reason: pure http sites are disappearing little by little.)

A random bit of proof:

DEBUG: fetch phase started at Fri Apr 19 23:04:39 CEST 2024
--->  Fetching distfiles for pulseaudio
DEBUG: Executing org.macports.fetch (pulseaudio)
--->  pulseaudio-17.0.tar.xz does not exist in 
/opt/local/var/macports/distfiles/pulseaudio
--->  Attempting to fetch pulseaudio-17.0.tar.xz from 
https://www.freedesktop.org/software/pulseaudio/releases/
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 1529k  100 1529k0 0   977k  0  0:00:01  0:00:01 --:--:--  977k

R.

Re: livecheck and curl 8.7.1

[René J . V . Bertin]

On Friday April 19 2024 20:51:20 Kirill A.  Korinsky wrote:

>"cleaner" approach is running dedicated instance of MacPorts which installs
>only curl. Someone calls that "bootstrap" MacPorts.

Maybe the cleaner approach to get the desired libcurl, but the end result is 
exactly the same. (One could build Pextlib.dylib such that it uses one of the 
dynamic rpath flavours to find libcurl.)

>bootstrap MacPorts, that fixes all issues.

I strongly doubt it would fix the issue I've encountered. I realise it only 
happens with livecheck'ing; downloading works just fine for some weird reason.

R.

livecheck and curl 8.7.1

[René J . V . Bertin]

Hi,

For a few years now I've copied libcurl.4.dylib and dependencies into 
$prefix/libexec/lib/pextlib1.0 and then use install_name_tool magic to ensure 
Pextlib.so uses this copy. This solves the problems with livechecks or even 
downloads failing because of unsupported SSL certificates on my older OS.

I just tried this with libcurl from curl 8.7.1 and get the error below, both on 
Mac and on Linux:

DEBUG: Fetching https://www.openssl.org/source
DEBUG: Using CURL options --append-http-header {Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8} 
--enable-compression
Error: cannot check if openssl3 was updated (curl_multi_info_read() returned 
{.msg = CURLMSG_DONE, .data.result = 23 (!= CURLE_OK)}, but the error buffer is 
not set. curl_easy_strerror(.data.result): Failed writing received data to 
disk/application)

The error suggests that the output couldn't be saved but doing `system "cat 
$tempfile"` in the error catching code suggests that the download worked just 
fine.

Any idea what's happening here? I'd check the curl utility to see if it gives a 
similar error but using that tool correctly is higher rocket science apparently 
:-/

Thanks,
R.

Re: inserting -stdlib=libstdc++ into cxxflags

[René J . V . Bertin]

BTW, did you ever run into trouble with libstdc++'s "new ABI" 
(https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html) ?

R.

Re: inserting -stdlib=libstdc++ into cxxflags

[René J . V . Bertin]

On Sunday March 17 2024 03:44:00 Sergey Fedorov wrote:

>> but if libc++ 5 was maybe still a bit faster overall than libstc++ the
>situation is now rather reversed though differences remain small

I take that back, the differences aren't always small!

I realised that the so-called "native" benchmark from the libcxx source tree 
could be used with the libstdc++ from (currently) port:libgcc13. It took some 
time to figure out how to inject the `-stdlib=macports-libstdc++` argument 
properly but once I got that working on Linux it transferred without further 
ado to Mac.

These results just in. Libc++ and all benchmarking code built with 
`clang++-mp-12 -O3 -march=native -flto`.

libstdc++ is indeed consistently faster. Usually by not much (though the 
differences in kernel time spent can be relatively important):

```
> build/libcxx/benchmarks/algorithms.partition_point.libcxx.out
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.13, 1.27, 1.34

89.198 user_cpu 0.907 kernel_cpu 1:30.11 total_time 99.9%CPU {93360128M 0F 
226542R 0I 0O 0k 0w 445c}
> /build/libcxx/benchmarks/algorithms.partition_point.native.out
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.42, 1.35, 1.34

75.612 user_cpu 0.911 kernel_cpu 1:16.53 total_time 99.9%CPU {102424576M 0F 
229228R 0I 0O 0k 0w 504c}
```

```
> build/libcxx/benchmarks/algorithms.libcxx.out --benchmark_repetitions=1 
> --benchmark_filter='_262144$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.63, 1.75, 1.70

220.386 user_cpu 2.961 kernel_cpu 3:43.50 total_time 99.9%CPU {79626240M 0F 
542726R 0I 9O 0k 154w 3502c}
> build/libcxx/benchmarks/algorithms.native.out --benchmark_repetitions=1 
> --benchmark_filter='_262144$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.66, 1.79, 1.67

 
190.844 user_cpu 2.615 kernel_cpu 3:13.50 total_time 99.9%CPU {89800704M 0F 
504812R 0I 9O 0k 149w 1942c}
```

But observe this, as far as I understand a "small" version of the above 
benchmark that seems to highlight a huge overhead in libc++:

```
> build/libcxx/benchmarks/algorithms.libcxx.out --benchmark_repetitions=1 
> --benchmark_filter='_1$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.61, 1.37, 1.36

1947.681 user_cpu 221.754 kernel_cpu 36:10.22 total_time 99.9%CPU {78262272M 0F 
1503675R 0I 9O 0k 152w 22829c}
> build/libcxx/benchmarks/algorithms.native.out --benchmark_repetitions=1 
> --benchmark_filter='_1$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.63, 1.42, 1.36

1056.593 user_cpu 8.435 kernel_cpu 17:45.51 total_time 99.9%CPU {78917632M 0F 
1458187R 0I 9O 0k 154w 12805c}
```

Here the library from the "bloated" GCC is twice as fast overall, and uses 
almost 30x less kernel CPU time!

I see the same on Linux.

This makes me wonder if shouldn't try building llvm+clang against 
macports-libstdc++ . I have already managed to do so with lld-17 (only depends 
on libc++ via libxml2, and turns out to be "safe to mingle"). Newer clang 
versions build against their own libc++ even on Linux (when building with 
clang) so that suggests the code has been designed to separate the possibly 2 
C++ runtime versions that get linked. It would probably be impossible to use 
the resulting libLLVM or libclang in dependent ports but maybe the performance 
increase might be worth it.

R

Re: external build progress reporting cli utility?

[René J . V . Bertin]

>You can run the build under screen / tmux.

Sure, but that only works if you think about it before launching it. And I only 
know `screen` as a utility to run multiple commands/sessions from a single 
shell, a more advanced for of the Ctrl-Z, bg and fg shell commands. What I'm 
thinking about is phoning in from anywhere and peek at the logfile through a 
filter that detects the `:info:[^ ]* [X/Y] .*` from the possibly interminable 
compiler commands in that file and presents them in an easy to digest fashion.

My initial idea was to roll my own, and then I realised the code to do this 
exists and that it might be possible to write a Tcl script that reuses that 
code. Heck, maybe it's even an idea to implement something like a `port state 
foo` command that prints the currently executing phase for port:foo and the 
current progress if that information is available.

R.

external build progress reporting cli utility?

[René J . V . Bertin]

Hi,

Does anyone else ever launch a substantial build on the "local console" and 
then leaves the Mac, but would like to monitor progress remotely sometimes from 
a simple SSH remote connection?

I do, and wonder how difficult it would be to be able to do something like 
`tail -f `port logfile foo` | port_progress` and get the same kind of progress 
report shown on the terminal where you launched the build command.

I know the progress bar is built from information that's also sent to the log 
file but not how straightforward it would be to write a Tcl script that loads 
the appropriate package(s) and applies the progress reporting routines on input 
read from stdin.

Implementing `tail -f` in Tcl would be a next-level exercise ;)

Thanks,
R.

Re: inserting -stdlib=libstdc++ into cxxflags

[René J . V . Bertin]

On Wednesday March 13 2024 03:44:17 Sergio Had wrote:
>Which OS are we talking about?

10.9.5 but that what matters here is that it's a libc++-based OS version.

>Building against libstdc++ is broken for Intel

Not from what I can tell; I test built an OLD libxmlxx copy against libstdc++ 
from GCC13 and that works. Of course it's easy to break the application if you 
end up mixing libstdc++ with libc++. 

In fact, if libstdc++ were broken GCC itself wouldn't work: it can only be 
built against that C++ runtime. (You can imagine how complex my bootstrap flags 
are to build a gcc that uses libc++ by default ;) )

Yes, gcc 13 isn't yet compatible with libc++, but the current -stdlib=libc++ 
implementation also fails (for me) on Qt5 (5.9) projects because libc++ has its 
own version of (IIRC) cstddef and raises an error if the one from GCC has 
already been included. To avoid that the c++/v1 directory must be before the 
GCC C header dirs in the search list, and not after as GCC currently does it. 
I've signalled that, and you can achieve the same thing with the traditional 
recipe to use libc++ with GCC: `-nostdinc++ -isystem/path/to/c++/v1`.

FWIW, I patched GCC 6 and 7 back in the day to add a `-stdlib=` argument. I 
don't really know why I didn't use it, probably because the concurrent clang 
versions were still faster. That's no longer the case; GCC 12 is about as slow 
as clang 12 (but a lot more modern, with full, non-buggy C++20 support, and 
apparently less resource hungry).

I've caved and activated gcc12+stdlib_flag (i.e. the stock MP build) which will 
do what I want ATM without need for additional flags. I'm now rebuilding lld-17 
with its minimal libLLVM & family. That build failed with -stdlib=libc++ (so 
gcc12 isn't perfectly compatible with any of our libc++ implementations I 
tested either) but the initial estimate is that the build would have completed 
in about 2/3 of the time as it would take with clang 16. Lld looks to depend on 
libc++ only through port:icu via libxml2 which is pure C afaik so the C++ 
runtimes should remain separated in this case. We'll see... anyway the only 
reason I'd keep the build is if it's a lot faster or a lot more compact than 
the one with clang 16. I mostly just want to compare build times on a hefty 
project.

R.

inserting -stdlib=libstdc++ into cxxflags

[René J . V . Bertin]

Hi,

I've been tinkering a bit with a personal GCC12 build patched to use libc++ by 
default, and now find myself unable to build against libstdc++.

`configure.cxxflags-append -stdlib=libstdc++` appears to be filtered out 
somewhere in the "base" bowels, and `configure.cxx_stdlib libstdc++` appears 
not to have any effect either. I'm not seeing any warnings in the logfile, 
which is surprising (and rather bad practise IMHO).

What am I missing here, and what backdoor(s) could I use? I notice that 
CXXFLAGS (aka Env(CXXFLAGS)) isn't yet set in `pre-configure`; I haven't yet 
checked if "base" preserves its settings when initialising it (have been 
assuming it won't). With autoconf-based projects one can set `configure.cxx 
${configure.cxx} -stdlib=libstdc++` but that doesn't fly for cmake-based 
projects...

Thanks,
R.

Fwd: Re: [MacPorts] #69411: ld64-latest upgrade time?

[René J . V . Bertin]

A quick heads-up to anyone with an interest in the linker (and who wasn't aware 
of the ticket yet).

R.

---
Forwarded message:
Date: Monday March 11 2024
Subject: Re: [MacPorts] #69411: ld64-latest upgrade time?


#69411: ld64-latest upgrade time?
--+
  Reporter:  RJVB |  Owner:  (none)
  Type:  request  | Status:  new
  Priority:  Normal   |  Milestone:
 Component:  ports|Version:
Resolution:   |   Keywords:
  Port:  ld64 |
--+

Comment (by RJVB):

 So, I've been tinkering with lld and subsequently going down a rabbit hole
 with LLVM-17... Here's a rough overview about using lld before the details
 escape me completely...

 - lld won't generate 32bit code, at least not for Intel. Not the biggest
 problem probably, but a bummer since a (much) faster linker would be more
 beneficial for older systems that need to do (lots of) universal builds.
 - lld isn't a perfect drop-in replacement for ld64 (see below for the list
 of as-yet-unsupported arguments). I haven't found any adverse effects
 though. In this aspect lld-17 isn't better than lld-16.
 - somewhere between LLVM-12 and LLVM-15 a new `-platform_version` argument
 was introduced that apparently deprecates `-macosx_version_min` which is
 still accepted but apparently ignored at least to the extent that it
 doesn't provide the info expected via `-platform_version`. A wrapper
 script is thus required which must live at the place of the actual
 ld64.lld *hardlink*, and invoke lld as `ld64.lld` (so I moved the link to
 `${llvm_prefix}/bin/wrapped/ld64.lld`).
 - `-fuse-ld=/path/to/l*d` is deprecated (because it doesn't allow to
 determine the linker variant ... easily); there is a new argument to
 specify /path/to/linker (which is incompatible with gcc). With the
 deprecated form the linker is apparently assumed to be compatible with
 ld64 (which is true via the aforementioned wrapper).
 - lld can be built as a standalone project, so against the already
 installed port:llvm-xy . I had hoped to build it as a monolithic
 standalone *port* with a minimal build of the required llvm bits ''linked
 statically''. Sadly it does not appear to be possible to build libLLVM as
 a static library, so ultimately I opted to write a subport that installs
 to its own subprefix `${prefix}/libexec/lld-17`, with only the libLLVM
 dylib (and currently libLTO which is probably NOT needed).
 - GCC's `-fuse-ld=lld` appears not to have any effect on Darwin and if you
 force it an error is raised:
 {{{
 ld64.lld: error: No LC_DYLD_INFO_ONLY or LC_DYLD_EXPORTS_TRIE found in
 /opt/local/bin/../lib/gcc13/gcc/x86_64-apple-
 darwin13/13.2.0/../../../libgcc_s.1.1.dylib
 }}}


 Missing:
 {{{
 ld64.lld: warning: Option `-reexported_symbols_list' is not yet
 implemented. Stay tuned...
 ld64.lld: warning: Option `-force_symbols_not_weak_list' is undocumented.
 Should lld implement it?
 ld64.lld: warning: Option `-force_symbols_weak_list' is undocumented.
 Should lld implement it?
 ld64.lld: warning: Option `-reexported_symbols_list' is not yet
 implemented. Stay tuned...
 ld64.lld: warning: Option `-no_compact_unwind' is undocumented. Should lld
 implement it?
 }}}

 "Standalone build":
 My goal was to have access to the most recent/capable lld without
 necessarily having to have at least the full corresponding llvm port
 active. Given what a resource hog LLVM has become there is a good reason
 not to waste possibly precious disk space to versions that you're not
 going to be using regularly. Plus, clang++-17 has proven to fail to link a
 lot of code (including `port:llvm-17` itself) because of symbols like
 (IIRC) `std::verbose_abort` missing from libc++ (and I have libc++ 13 in
 my personal $prefix!).

 Here's my current implementation:
 https://github.com/RJVB/macstrop/blob/master/lang/llvm-17/Portfile#L415
 configured to install to `$prefix/libexec/lld-17`.
 Note that I fixed a number of other "issues" with the port, in particular
 - re-allow building with the MacPorts CMAKE_BUILD_TYPE (the build system
 no longer rejects unknown types)
 - use Ninja (or in my case, the lighter Samurai). All I needed to do was
 figure out the install targets that the cumbersome way of invoking `make
 install` from subdirectories evidently also use. FWIW, CMake makes this
 relatively easy because it generates a `help` target that will list all
 known targets (in the current dir, which means for the entire project when
 using Ninja).
 - fix the use of ccache (a complete rebuild after a clean or changing only
 a single C++ file takes about 35min instead of over 6 hours on my
 machine).

-- 
Ticket URL: 

gatekeeper overhead during builds and libtool

[René J . V . Bertin]

Hi,

Does anyone else notice significant overhead from the gatekeeper daemon (or 
however it's called on more modern versions of the OS) during builds? This 
seems to be linked to intensive use of the libtool script. One of the ports 
where this overhead is very clearly visible is Mesa; I suspect that it will be 
more noticeable with project consisting of numerous tiny source files.

For a few years now I've been following a project call slibtool 
(https://dev.midipix.org/cross/slibtool) that aims to replace the libtool 
script by compiled C code, and has drop-in replacement capabilities. In some 
testing where I managed to get that drop-in mode to work, a complete Mesa 
rebuild with slibtool and primed ccache took `1072.870 user_cpu 118.142 
kernel_cpu 5:59.47 total_time 331.3%CPU`. A normal build with the libtool 
script and the same primed ccache took `2688.511 user_cpu 1621.190 kernel_cpu 
33:14.06 total_time 216.1%CPU` . Note the discrepancy between the accounted CPU 
time (user+kernel) and the total time; I think the differences between the 2 
builds cannot be due to the different CPU loads alone but instead must be an 
effect of the gatekeeper daemon burning CPU.

Sadly slibtool still hasn't advanced much on Mac and in general doesn't look 
ready for prime-time use as a libtool replacement in random projects.

The goal of this message is to see if anyone is interested in helping that 
project advance but also to see if there's another way to keep that daemon in 
its cage that I haven't discovered (I already have configured things such that 
anything is allowed to run so it beats me why the daemon still burns so much 
CPU).

Thanks,
R.

Really strange permissions errors

[René J . V . Bertin]

Hello!

I'm trying to understand a weird permissions related error that a user of one 
of my custom ports is getting and I cannot yet reproduce.

In a nutshell: this port uses an automatically generated subport (a "devport") 
for which I create the destroot as part of the main port's post-destroot. 
That's essentially a file move operation but of course the devport workdir has 
to exist. I haven't yet figured out how to create that directory manually so I 
use `system "port -n -vd fetch $devport"` to take care of that. I have tested 
about all possible scenarios I could think of on my end, but this user is 
getting the error below that cannot explain.

`sudo port destroot acl` means that the post-destroot stage is executed as 
root; indeed I already fixed a previous error in that same github ticket by 
deleting the "offending" file preventively in the post-destroot. If the fetch 
phase is de-escalated to and executed as $macports_user then this should apply 
to both the main and the devport, which means that (in this case) 
/opt/local/var/macports/build/_opt_local_site-ports_sysutils_acl should be 
owned by $macports_user too.

I'm aware that I'm not running the latest "base" version yet but I haven't seen 
any changes to the code that could explain these symptoms ... are we maybe 
dealing with some of the magic Apple sandboxing on their more recent OS 
versions, here? It's either that or I'm overlooking something really (too) 
obvious ...

Maybe just deconstruct the main port's ${workdir} to build my the devport's 
workdir with my own code?

Thanks,
R.

---
Forwarded message:
Date: Friday January 19 2024
From: Hamid 
To: RJVB/macstrop 
Cc: René Bertin , State change 

Subject: Re: [RJVB/macstrop] acl: destroot fails (Issue #96)


ran these after the commit appeared:
`sudo port clean acl acl-dev
sudo port -n destroot acl`

and now it fails with:
`:info:destroot DEBUG: can't create directory 
"/opt/local/var/macports/build/_opt_local_site-ports_sysutils_acl/acl-dev": not 
owner
:info:destroot while executing
:info:destroot "file mkdir $workpath/.home"
:info:destroot (procedure "open_statefile" line 7)
:info:destroot invoked from within
:info:destroot "open_statefile"
:info:destroot (procedure "check_variants" line 28)
:info:destroot invoked from within
:info:destroot "check_variants fetch"
:info:destroot invoked from within
:info:destroot "$workername eval "check_variants $target"" 
:info:destroot (procedure "mportexec" line 7) 
:info:destroot invoked from within
:info:destroot "mportexec $workername $target"
:info:destroot Error: Unable to execute port: can't create directory 
"/opt/local/var/macports/build/_opt_local_site-ports_sysutils_acl/acl-dev": not 
owner
:info:destroot Command failed: port -nok -vd fetch acl-dev 
:info:destroot Exit code: 1`


-- 
Reply to this email directly or view it on GitHub:
https://github.com/RJVB/macstrop/issues/96#issuecomment-1899459109
You are receiving this because you modified the open/close state.

Message ID: 

Re: `port archive` ?

[René J . V . Bertin]

On Wednesday October 25 2023 06:05:45 Eric Gallager wrote:

>Yes, conflicts registered in the Portfile. For example:

>--->  Computing dependencies for arm-elf-gcc3
>Error: Can't install arm-elf-gcc3 because conflicting ports are
>active: arm-elf-gcc
>Error: Follow https://guide.macports.org/#project.tickets if you
>believe there is a bug.

Heh, at least it's telling you what to do ;)

Allowing `port archive --force foo` to override/ignore such conditions should 
be an acceptable workaround I suppose?
Compare to dpkg's --force-X options.

R.

hack'a'day :accessing macports:: variables from a PortGroup

[René J . V . Bertin]

Hi,

This is probably seen as a forbidden hack, but is there a way to access 
variables from the macports namespace in a PortGroup (or Portfile)?

I know that "user" code like this is executed under/through `mportopen` which 
is in that namespace, but when I invoke `namespace children` I only see (all?) 
other namespaces.

Use case: I'd like to set `revupgrade_autorun` to false under very specific 
circumstances.

R.

Re: `port archive` ?

[René J . V . Bertin]

FWIW, I'm now using `port archive` in my "devport" PortGroup, so that updating 
the main port and the companion devport with developer content doesn't 
re-activate that content if the user deactivated it. (It still gets installed 
normally otherwise.)

R.

Re: `port archive` ?

[René J . V . Bertin]

On Monday October 23 2023 01:34:03 Eric Gallager wrote:

>I sometimes try using the `port archive` command, and one thing I'm
>wondering about it is, why does it bother calculating conflicts if it
>doesn't actually install the port?

That's strange, in my experience conflicts are detected when moving files into 
place during the activation stage. So I presume you are talking about conflicts 
registered in the PortFile?

It's true that for those you could argue that `port install` could fall back to 
`port archive` and post a note for the user. Might be too subtle for the Joe & 
Jane users though, and it might not be worth the effort to implement a switch 
in macports.conf for this?

In fact, isn't there already logic in place that prevents you from activating a 
port that conflicts with another? If so, implementing that switch should be 
trivial...

R.

Re: "devports"

[René J . V . Bertin]

On Saturday October 21 2023 14:27:26 René J.V. Bertin wrote:

>Anyone feel like kicking these tyres with me? :)

Too late, but there's code to kick to see what errors I've grown!

It was an interesting little exercise, relatively easy to implement by letting 
the archive unpack take place in a subport's destroot dir.

FWIW: one port where I also use this mechanism on Mac is my `port:acl` 
(https://github.com/RJVB/macstrop/blob/master/sysutils/acl/Portfile) because 
rsync should not detect and link against it.

R.

Re: `port archive` ?

[René J . V . Bertin]

On Sunday October 22 2023 19:38:46 Rainer Müller wrote:
>Yes, 'port archive' would do what you are looking for. You are correct
>this is actually missing in port(1), but please see the separate man
>page port-archive(1).

Thanks, and strange. That's exactly what I did, or thought I did (came up 
empty, may have made a typo...).

R

"devports"

[René J . V . Bertin]

Hi,

I know this comes up once in a while, and how it's non-trivial to integrate 
with MacPorts's way of doing things: "dev ports" that contain the 
developer/ment resources corresponding to (usually) a library. These can be 
very useful to prevent blocking or at least awkward situations in case of build 
conflicts, where you would prefer not to (or can't) deactivate the runtime 
components of a conflicting library.

To my knowledge gettext is the only port for which something similar has been 
implemented; I think it was also for this port that I first implemented my own 
solution a few years ago when I started porting MacPorts to Linux.

I just added an automatic install/upgrade of the devport after installing or 
upgrading the mainport, and that seemed like a good time to bring up my 
implementation :

https://github.com/RJVB/macstrop/blob/master/_resources/port1.0/group/devport-1.0.tcl

I'm not really looking to propose it for inclusion, more for some constructive 
feedback on how I might improve it.

This PortGroup-based solution introduces a subport called `${name}-dev` and 
defines some funtions to populate it with standard content (the headerfiles, 
static libraries and "link-libraries" (libfoo.dylib on Darwin or libfoo.so 
elsewhere)) and/or user-defined port-specific content. This is all moved into a 
tar archive in the main port's post-destroot phase.
The devport itself has only a destroot phase, in which that archive is unpacked 
into `$destroot` and a pre-activate phase that replaces that archive with an 
empty file because it is no longer required. For this reason the devport's 
destroot also has a `restore_devport_tarball` feature, in case one wants to 
reinstall the devport for some reason.

This has been working flawlessly for years, though I almost only use it on 
Linux, but it has always irked me a little bit that the devport content is 
installed twice. Writing this I realise that I could probably rewrite the "move 
into a tar archive" approach with something even naughtier but also more 
elegant: move it directly into `port work ${name}-dev`/destroot . It was always 
a question how I'd continue from there, actually installing the port, but I 
seem to have figured that bit out now:

https://github.com/RJVB/macstrop/blob/6e61d3c444bbd49cf4bed2f886c0a6432b8a643f/_resources/port1.0/group/devport-1.0.tcl#L238

The remaining question is then how to do the "move into the devport's destroot" 
step in a way that doesn't make it completely impossible to install the devport 
manually, or else how to handle that fact.

Anyone feel like kicking these tyres with me? :)

R

`port archive` ?

[René J . V . Bertin]

Hi,

It happens that I'd like to "install" a variant of a self-built port without 
actually activating it (e.g. when libraries are in use and I have no immediate 
need to activate that different variant).

Looking through the code I saw there must exist a `port archive` command that 
isn't documented in the manpage. Does that do what I'm looking for or does it 
just make the tar bundle under $prefix/var/macports/software ?

Thanks,
R.

Re: [MacPorts] #68136: cross-platform portfiles and shlib extension

[René J . V . Bertin]

> Why would a port need that? It would be up to the build system to know how
> to build libraries for each platform.

Who said anything about the build systems? Have a look at the path-style 
depspecs used in many ports!

accessing $argv0 from Portfile?

[René J . V . Bertin]

Hi,

Is there a way to get the path to MacPort's tclsh interpreter from within a 
Portfile, other than by using a `glob` to find it in 
$prefix/libexec/macports/bin ?

(not to do anything naughty, just to run a Tcl test/benchmark.)

libc++ with ParallelSTL (pstl)?

[René J . V . Bertin]

Hi,

Working on my own port:libcxx to upgrade it to 13.0.1 I noticed that there's an 
intriguing possibility to build it to use ParallelSTL - and that happens to be 
a "runtime" that's included in the source tree.

Does anyone have experience with this feature?

It does require an extra dependency on port:tbb in order to be of any interest, 
but that doesn't seem to be problematic.

Thanks,
R.

self-building libobjc?

[René J . V . Bertin]

Hi,

I've been tinkering a bit with DYLD_INSERT_LIBRARIES, DYLD_FORCE_FLAT_NAMESPACE 
 and the MacPorts libc++, on OS X 10.9.5 . Some applications crash at startup.

While that may be because of simply forcing a flat namespace the crash reporter 
does mention that libobjc.A.dylib is being loaded at the time of the crash.

Which led to the question if we can build that library ourselves and install it 
like port:macports-libcxx, even if just the platform version. Has anyone tried 
and succeeded? I'm getting build failures because of missing header files like 
`mach-o/dyld_priv.h` or `os/lock_private.h`.

R

Re: path:-style depspec to libc++.dylib?

[René J . V . Bertin]

On Monday May 08 2023 12:41:08 Kirill A. Korinsky wrote:

>and it works as expected.

FWIW, my attempt also worked for things like `port info` and IIRC even `port 
fetch`; I got the error when I tried `port configure`, when "base" actually 
tries to use the depspec data.

Re: path:-style depspec to libc++.dylib?

[René J . V . Bertin]

On Monday May 08 2023 12:41:08 Kirill A. Korinsky wrote:


>I just tried
>
>depends_lib path:lib/libc++.dylib:libcxx
>
>and it works as expected.

Interesting. I am not at the right machine right now but I was tinkering with 
the legacy-support 1.1 PortGroup, where it adds a dependency on 
port:macports-libcxx. That does go through an extra indirection/function. I 
must have tried this:

legacysupport::add_once depends_lib append 
path:lib/libcxx/libc++.1.dylib:macports-libcxx

Instead, I'm now doing `legacysupport::add_once depends_lib append 
path:include/libcxx/v1/version:macports-libcxx` which works too but is less 
ideal because I always like to refer to a file that is needed at runtime (for 
depends_lib).

path:-style depspec to libc++.dylib?

[René J . V . Bertin]

Hi,

I tried to write a path:-style depspec to libc++.dylib, but that gives me a 
regexp compilation error. Can that be avoided by escaping those pluses in the 
filename and if so, how? A simple backslash didn't do it for me.

Thanks,
R.

Re: reinplacing -Wl,-foo,bar to "-foo bar"?

[René J . V . Bertin]

On Wednesday April 26 2023 17:13:22 René J.V. Bertin wrote:

>I'll probably get there, but in anyone has the magic formula handy I'd 
>appreciate it.

NM, figured it out.

BTW, this was part of developing a PortGroup that provides an alternative for 
ports which need rust and cargo in order to be built, initially because it was 
clearly going to be more trouble than I cared for to port port:rust and 
port:cargo to my LinuxPorts project. (And because I didn't expect there to be a 
binary build of those ports for OS X 10.9 ...)
I now have a working "rustup" PortGroup (tested against port:clamav and 
port:sccache) which will still use port:rust+cargo if they are installed (or 
when forced to), but will otherwise do a minimal rustup install inside `port 
work` and let the build system do its thing more or less freely, including 
fetching whatever packages (crates?) are required.

Personally I prefer this kind of overhead if you need rust only to build a 
handful of ports (the minimal rustup install has a much smaller footprint than 
the MacPorts equivalent).



R.

reinplacing -Wl,-foo,bar to "-foo bar"?

[René J . V . Bertin]

Hi,

This is a little problem I'm grappling with on Linux, but it could be of 
interest for others. I need the set `configure.ld` to the actual linker (say 
$prefix/bin/ld) because that's what the build system in question expects (here: 
rustc) because it passes flags that aren't understood by gcc or clang.

So in this case, the compiler_wrapper PG cannot pass on ${configure.ldflags} in 
the script, not "as is" in any case.

The best approach I see at this point is an option to rewrite the linker 
wrapper in that PG, unwrapping the -Wl,-foo,bar[,...] options. I know what 
regexp to use for that in vi (some sequence of versions of 
`s/-Wl,\([^,]*\),\([^,]*\)/\1 \2/g`) , but apparently sed has a slightly 
different syntax.
I'll probably get there, but in anyone has the magic formula handy I'd 
appreciate it.

Thanks
R.

dbus: legacy vs. current plist locations

[René J . V . Bertin]

Hi,

I've been running a customised port:dbus for years now, that I've never updated 
(because 1.10.12 ain't broke...). Looking at where things are being installed 
currently I see some significant differences in the install location of the 
launchd plists.

Has there been an automatic transition when those chances were implemented, or 
did users have to take manual action to ensure the dbus daemon would be 
launched again?

R.

configure step downloading resources - supported on buildbots?

[René J . V . Bertin]

Hi,

Exploring Audacity's latest code I notice it requires the conan package manager 
nowadays, for building "vendored" libraries. A number of those aren't in 
MacPorts.

>From what I've seen this downloaded stuff goes into `build.dir` but I seem to 
>recall that the build bots don't support downloading things during the build. 
>Is that correct and still the case?

Thanks,
R.

trac preview annoyance

[René J . V . Bertin]

Hi,

I've started noticing (a euphemism...) browser page scrolling when the trac 
preview updates, not systematically but sufficiently frequently to be very 
annoying e.g. when it happens when you're just about to reposition the cursor.

I don't know if this is due to an update to trac or to my browser (Waterfox G4) 
but I'd like it to stop. Is there a way to disable the automatic preview (I 
suppose if so it would have to be one of the "Default handler" settings under 
Preferences/User Interface)?

Thanks,
R.

Re: what's with the C++ extension?

[René J . V . Bertin]

On Monday September 19 2022 18:41:54 Chris Jones wrote:

>Note though the expose of that feature, on newer systems at least, is very 
>much limited at the moment and I stand by my statement that mixing multiple 
>c++ runtimes, unless done very very carefully, is a recipe for problems. So 
>expanding the usage of that option to many more ports should be done carefully.

I see that with that port, executables link to 
$prefix/lib/libcxx/libc++.1.0.dylib instead of libc++.1.dylib but even with my 
current approach f using DYLD_INSERT_LIBRARIES to inject 
/opt/local/lib/libc++.1.dylib I notice that the dyld still also loads 
/usr/lib/libc++.1.dylib (in that order). However, to stick with my earlier 
comparison, I also see /opt/local/lib/libz.1.dylib and /usr/lib/libz.1.dylib 
being loaded (in that order) in zlib dependents.

I used DYLD_PRINT_LIBRARIES to see what's being "loaded", of course I cannot 
tell if the 2nd library will actually get used (not if nothing in the program 
uses symbols only available in the older library?). I may have to use the 
Activity Monitor for that.

Of course libz is a C library but in my experience it's even trickier to 
prevent issues when loading multiple versions of those.

I'm going to update my own port:libcxx to 9.0.1 (easier than to 12 because that 
apparently doesn't build the same way), install the link interface library and 
then see what happens (and report back here if I run into issues).

R.

Re: what's with the C++ extension?

[René J . V . Bertin]

never mind, I discovered port:macports-libcxx and the trac ticket that led to 
its creation (which mentions the filesystem extension...)

The port does exactly what I think should be done, but at a port-specific level.

R.

Re: what's with the C++ extension?

[René J . V . Bertin]

On Monday September 19 2022 13:56:01 Chris Jones wrote:

>But anyway, I m sure you will think you are right, so please feel free to 
>experiment on your own system, as you get to own the pieces there once it 
>breaks.

What do you think happens when you upgrade an OS but not ALL your other 
software?

Libc++ isn't something that is magically different from other libraries.

Check the libcxx sources. There's an option to build it against the v1 or the 
v2 ABI. As long as the v1 ABI is available you can at least run applications 
built against an older libc++ version using a later version of the v1 ABI. Just 
like with any other library. If you read my initial post attentively you will 
realise that this is exactly what I have been doing for years now (and in case 
it wasn't clear, I do mean I install the libs under $prefix/lib!).
I do not currently install a libc++.dylib, but I will start experimenting with 
this: it should just mean that any new code I build will find the 
implementation for functions that are declared by the headerfiles (and not 
marked as unavailable). Any catastrophic failure will be limited to those 
ports, not to my system

In fact: the libc++ headerfiles for libc++ vX are installed with port:clang-X 
so anything built with that compiler will assume to find the implementation of 
functions declared in those headers, but will also use the ABI of that version! 
We can use the system libc++ with a much newer clang version for 2 reasons:
- the LLVM devs take care not to modify the ABI except possibly in 
backwards-compatible ways (like Qt also guarantee) allowing you to use newer 
libc++ headers (and thus structures/classes) with an older libc++ binary
- Apple marks newer functions as available from a certain OS version only. 
Sooner or later they will miss a function because I doubt they test every 
feature in every new clang/llvm version on ever previous version of the OS 
where it can be built.

Now, if someone knows off the top of their heads which libc++ version was 
shipped with OS 10.15.0 I'd appreciate not having to hunt down that information 
myself - thanks!

R.

PS: I've updated my port:libcxx from v5 to v6.0 to v6.0.1 to v8.0.0 without 
rebuilding a single port. And FYI, on Linux I do install libc++.so (= the 
linker interface library, in /usr/lib because there's no conflict there) and I 
have been building a certain number of my ports with a +libcxx variant that 
does what I hope must be evident. Those too did not require a rebuild after 
upgrading libc++.

Re: what's with the C++ extension?

[René J . V . Bertin]

On Sunday September 18 2022 23:57:53 Chris Jones wrote:

>Follow the above at your own risk.

As I said, there is no need to update the system libc++ on systems that already 
have it; `port:libcxx` can (could) provide a set of libraries under ${prefix} 
that override the system ones for dependent ports, just like any other port 
that provides newer versions of what's also provided by Apple.
This carries the same amount of risk as comes with those other ports 
(port:zlib, for instance...)

>
>The much better solution, imho, is if you needed newer c++ support, just 
>migrate to a more recent os that supports it…

Yeah, sure. Let's see before I download the 10.15 installer, oh, wait, my 
hardware will only upgrade to 10.13 (officially).

Guess why I'm migrating away from Macs ...

R.

Re: what's with the C++ extension?

[René J . V . Bertin]

On Sunday September 18 2022 14:29:07 René J.V. Bertin wrote:

>On more recent systems that have a stock libc++ one can install `port:libcxx` 
>with the binaries under $prefix . I have been doing that for years so all 
>MacPorts executables use it, and that has never caused any ABI issues with 
>system libraries that were built against the stock libc++ version.

Let me amend that: I only have the runtimes of the libraries installed 
(libc++.1.dylib and libc++qabi.1.dylib, version 8.0.0 to be exact), so all my 
builds are still linked against the system version.

R

Re: Disabled key in launchd plists

[René J . V . Bertin]

On Sunday September 18 2022 00:55:59 Ryan Schmidt wrote:

>I don't think I have anything further I want to add to this conversation. I've 
>explained to the best of my knowledge how launchd/launchctl work and what 
>MacPorts does with its launchd support and why. I'm sure you can perform any 
>further investigations that interest you on your own.

Sure, appreciated ... and we're not the only ones left on this list (right?!) ;)

R.

what's with the C++ extension?

[René J . V . Bertin]

Hi,

Building C++ code that does

#include 

I get either a file-not-found error or a bunch of errors that the functions are 
10.15+ only. What's with that?

If the implementation is provided by libc++, isn't this something that could be 
patched? Shouldn't require any external dependencies on systems that already 
underwent the libc++ conversion.

On more recent systems that have a stock libc++ one can install `port:libcxx` 
with the binaries under $prefix . I have been doing that for years so all 
MacPorts executables use it, and that has never caused any ABI issues with 
system libraries that were built against the stock libc++ version.
In fact, I often use my own build for other applications as well, assuming 
they'll benefit from newer=better and the maximum optimisation I used in the 
build.

R.

Re: Disabled key in launchd plists

[René J . V . Bertin]

Ryan Schmidt wrote on 20220916::21:30:28 re: "Re: Disabled key in launchd 
plists"

>My reading of the documentation is that the system will start any launchd 
>plists at system startup time that are in the standard LaunchDaemons 
>directories and that are not disabled.

That's possible, but it could be that it's done via launchctl. Academic 
difference, probably.

>As I said, we don't want things the user installed with MacPorts to start 
>unexpectedly at system startup time.

That would depend a bit on what kind of service, no, and to what extent the 
unexpected load isn't that because documented? BTW, launch *agents* would only 
be started when a user logs in. That, in a sense, is a trickier situation. A 
MacPorts user is an admin, in principle, so in a situation to decide on 
installing ports that contain a system daemon (which could perform a crucial 
but strictly MacPorts-specific function). Deciding whether or not other users 
on that system should run the same agents as him/her is another thing.

I'm not familiar with `port load`; I presume (hope...) that it's unambiguous as 
to the difference between agents and daemons, that the former have to be 
started as the user, the latter "sudo" etc.

>I don't know if you can specify a directory to launchctl to have it load all 
>plists in a directory.

I only noticed that yesterday too, first from looking through the sources and 
then confirmed it in the manpage. It makes sense.

> If the plist is not in a standard LaunchDaemons directory, I assume that 
> would load the plist immediately, but not at future system startups. Since 
> that would be an undesirable situation I haven't ever tested it.

Why is that undesirable? As far as I see, the whole system is designed this 
way. It works for agents (at least the ones symlinked in /Library/LaunchAgents 
get started again after logging in, AFAIHS) but it would make even more sense 
for daemons. You start (load) them once and they keep running to perform the 
background service you (sometimes) want. You just have to be aware of it.
It's true that Apple could have foreseen a way to load either type temporarily.

Or I could be wrong, the documentation isn't exactly without ambiguities (it 
says "Note that per-user configuration files (LaunchAgents) must be owned by 
the user loading them." which is clearly not true if they did not forget to 
specify that this applies only to the ones in ~/Library/LaunchAgents).

I could reboot my system to test a few of these assumptions but somehow that 
annoys me :)

R.

Re: Disabled key in launchd plists

[René J . V . Bertin]

On Thursday September 15 2022 10:07:24 Ryan Schmidt wrote:
>Apple's default value of Disabled is false, which means (according to the 
>documentation I read) that the service will be started automatically the next 
>time the system starts up

Or the user logs in, for agents. That's what I thought too until recently, but 
the manpage also says 

"This document details the parameters that can be given to an XML property list 
that can be loaded into launchd with launchctl."

The launchd manpage confirms this by stating that
"The primary and preferred interface to launchd is via the launchctl(1) tool 
which (among other options) allows the user or administrator to load and unload 
jobs."

But it also says 

"Where possible, it is preferable for jobs to launch on demand based on 
criteria specified in their respective configuration files."

which could imply that jobs can get loaded by simply being in the proper 
directory.

It is true for instance that I moved the XOrg plists out of its directory as 
part of getting a "normal" DISPLAY variable, but it's perfectly possible that 
simply having unloaded the plist was enough.


I have the launchd sources so I suppose I could dive in there and try to answer 
this once and for all...

>, but we want the plists our ports install to be disabled until the user 
>enables them.

But would launchd even look where MacPorts installs these plists? I suppose it 
doesn't...

BTW, all this is in the context of "rebooting" a launchd rewrite (relaunchd) 
for Linux, so my "LinuxPorts" ports can also install directory watchers etc.

R.

Disabled key in launchd plists

[René J . V . Bertin]

Hi,

I've noticed that most of the launchd plists installed by ports have `Disabled: 
true`. There are a select few that don't, among which the mariadb server. I 
have that port installed, and yet no mariadb launchd job loaded which suggests 
that launchd does not auto-load plists, at least not from an "unsupported" 
location like /opt/local/Library/Launch{Agents,Daemons}.

What's the actual function of this key? Just a convenience feature so you can 
do `launchctl [un]load /path/to/*.plist` and only load the enabled jobs?

Thanks,
R.

Re: "LinuxPorts and machista

[René J . V . Bertin]

René J.V. Bertin wrote on 20220715::00:04:04 re: ""LinuxPorts and machista"

>I seem to recall that I am less alone nowadays in actually using an adapted 
>version of MacPorts on Linux (or *BSD)?

During a spell of hilarious mood I decided to refer to those in (Portfile & 
patch) code as "Lamarck". As in "Lamarck is not Darwin" (hah. hah. hah)

R.

"LinuxPorts and machista

[René J . V . Bertin]

Hi,

I seem to recall that I am less alone nowadays in actually using an adapted 
version of MacPorts on Linux (or *BSD)?

One of the things I miss on Linux is the rev-upgrade feature, if not only 
because it is also very useful to figure out who depends on a given shared 
library.

Anyway, has anyone also dabbling in this cross-platform use looked into 
alternatives to machista ("elfista" ...) or patching machista itself so the 
crucial functions also support ELF binaries (this would be easier for the build 
system I presume)?

Machista itself builds on Linux and could presumably be used for MACH objects; 
I've just had to patch _wrap_macho_loadcmd_mlt_install_name_get() to avoid 
dereferencing a NULL pointer (which must have happened to me, on Linux or when 
I tested basic functionality on FreeBSD).

Thanks,
R.

PS: I've made a fileIsBinary patch for Linux myself that detects the ELF magic 
opcode but continues to return False until I've figured out what to do with 
detected binaries.

How about a MacPorts "system" (generic) python port?

[René J . V . Bertin]

---
Forwarded message:
Date: Thursday July 14 2022
Subject: Re: [MacPorts] #65478: glib2, glib2-devel, glib2-upstream: only has a 
build dependency on python?!

Ticket URL: 
Comment (by ryandesign):

> The ticket is closed and any remaining discussions [...] should probably be 
> held in a more-visible location, such as on the macports-dev mailing list.

Willco & didco.

> Some users have objected to being made to install multiple versions of 
> python, especially python27 which is EOL, so when possible we usually choose 
> to use a recommended version of python3x (as specified in the python 
> portgroup) rather than python27.

I'd be among those users (save for the v2.7 tidbit). However as I pointed out 
in the ticket, using a moving recommended version currently leads to an 
increasing number of different python versions. Many ports also require add-on 
packages in order to be built or run, and those too stick around when the 
recommended version is updated. Try to clean that up afterwards, especially if 
you use Python yourself too and aren't too regarding of the version you're 
using (maybe because you use `port select`).

I don't like complaining without offering potential solutions. So in the ticket 
I suggested that the Python PG could provide some optional logic for ports that 
need Python as a build and/or runtime dependency, adding variants so users can 
decide which version(s) they want to maintain.
There's an alternative that's probably better: provide a `port:python3` 
or(/and) maybe even a `port:python` which becomes the designated replacement of 
/usr/bin/python{,3}. Have that install in its own location that doesn't clash 
with any of the existing python ports. Addons then become `py3-foo`
subports, or the `py-foo` main ports that are now stubs (any of them which 
aren't?). Now you can update this generic port as you deem fit.

I think this will also be a lot clearer for users who want "just a Python" port 
without specific reasons to pick a specific version.

R.

gobject_introspection and meson

[René J . V . Bertin]

Hi,

Please bear with this question concerning an install that doesn't use the 
latest build of everything...

I see that the gobject_introspection PG has support for disabling the feature 
when the meson build system is used, supposes the option is provided 
universally and needs to be activated.

This breaks building port:gjs locally for me, with the message that the 
`introspection` option doesn't exist. I do see that there is a binary build on 
the build bots so I have to conclude that some port (not new enough on my 
install) provides this option somehow.

Does anyone happen to know what port that might be?

I've been googling the issue and from the results I get the impression that the 
consensus is that introspection is too crucial a feature to disable, so there 
is no central option to disable it.

FWIW, port:gjs also generates an identical error about the `python` option to 
select the Python binary...

Thanks,
R.

Re: +universal for x864+arm64 on Macintel

[René J . V . Bertin]

On Wednesday June 15 2022 17:10:01 Christopher Jones wrote:

>what about configure.universal_archs though, have you set that to have > 1 
>entry ? thats what base cares about, hence the "due to < 2 supported 
>universal_archs

A! That works, indeed. It seems that this variable is empty when the 
portfile is parsed but initialised with the OS-supported archs from 
`supported_archs`, is that correct? That's not exactly what 
`guide.macports.org` states - for `universal_archs`, it doesn't discuss 
`configure.universal_archs`. IMHO it's a bit unexpected that there are 2 
settings to control what architectures a port supports!

R.

Re: +universal for x864+arm64 on Macintel

[René J . V . Bertin]

>Base is exactly smart enough. When supported_archs contains only 1 arch, it 
>does make sense to offer a universal variant, therefore base prevents it.

As I said before, supported_archs contains x86_64 and arm64.

If ports should be able to create a universal variant in case that variant 
isn't created automatically, "base" should be polite enough to assume that the 
port maintainers know and have a reason for what they're doing.

Re: +universal for x864+arm64 on Macintel

[René J . V . Bertin]

On Monday June 13 2022 04:34:46 Ryan Schmidt wrote:

>The standard universal variant has no content. (Universal support is 
>implemented by adding the return value of procedures like 
>[get_canonical_archflags cc] to CFLAGS.) Many ports implement their own 
>universal variant by manually creating this empty universal variant ("variant 
>universal {}") and using get_canonical_archflags where needed.

Bummer, looks like "base" is trying to be too smart: the manually created 
variant is removed after the Portfile has been parsed, "due to < 2 supported 
universal_archs".

R

Re: +universal for x864+arm64 on Macintel

[René J . V . Bertin]

On Monday June 13 2022 17:54:06 Ryan Schmidt wrote:

>There is no support in MacPorts base (or via a portgroup) yet for using such 
>an SDK; it would have to be programmed into the port manually. I had submitted 
>a PR to add such support to base, but it proved to be incomplete and I did not 
>pursue completing it yet.

/methinks that's a good reason to use a PortGroup at least at first. The 
functionality is highly specific so maybe not the most urgent to complexify 
"base" with - you could commit your incomplete work as is now and probably get 
a hand from the maintainer(s) who actually stand to gain from the functionality.

Re: +universal for x864+arm64 on Macintel

[René J . V . Bertin]

On Monday June 13 2022 21:40:19 Chris Jones wrote:

I did indeed misread; I should have realised that 10.11 predates ARM Macs by 
too much.

>Macports only supports buidling against  the sdk you would ‘naturally’ get 
>installing the Xcode/CLT version supported on a given OS. Whilst it might be 
>possible in a hacking way to install a newer SDK on alder OS, this is not 
>something macports can realistically support.

Ryan has a recent port that installs (I think) any of the available SDKs and I 
got the impression it was possible to build ports against these SDKs.

However, I wasn't thinking about building within MacPorts. I first installed 
MacPorts as an easy way to obtain libraries that I needed for my own software 
(and Qt binaries for Mac were long if not still built against dependencies 
installed through MacPorts). That's the context I had in mind - there is very 
little point to (locally) building ports for an architecture you can't run.

Anyway, I've got an answer to my original question.

R.

Re: +universal for x864+arm64 on Macintel

[René J . V . Bertin]

Ryan Schmidt wrote on 20220613::04:34:46 re: "Re: +universal for x864+arm64 on 
Macintel"

>As far as I know, the SDK would also need to support arm64, which SDKs prior 
>to macOS 11 don't. Therefore MacPorts doesn't support compiling for macOS for 
>arm64 prior to macOS 11.

What Apple call the SDK is essentially the combination of standard headerfiles 
(incl. the system-specific ones) plus the standard libraries (including the 
ones for system functions). Is there any reason to suspect that one cannot use 
the 10.11+ SDKs on earlier OS X versions?

R.

Re: +universal for x864+arm64 on Macintel

[René J . V . Bertin]

On Monday June 13 2022 02:48:06 Ryan Schmidt wrote:
> (and if MacPorts does not create a universal variant automatically in this 
> case then the port should do so itself)

Doh, I should have thought about that. Still, it would be more elegant to 
handle that situation with something like `universal_variant force` (admitting 
that the logic isn't perfect).

I suppose pre-10.11 installs should still be able to cross-compile for arm64, 
with the right compiler and libraries installed, no?
(Link step included btw, as all normally built clang compilers are 
cross-compilers so a new-enough clang should be able to generate the correct 
object code for Apple silicon.)

+universal for x864+arm64 on Macintel

[René J . V . Bertin]

Hi,

Just an observation:

When I tried to test the new +universal variant of a x864_64 + arm64 port 
(port:VLC) installing from official DMGs on my 10.9.5 Mac I discovered that the 
variant wasn't added because the port only supported the current build 
architecture. Whaaat? It took me a while to realise that maybe "base" knew I 
can't build arm64 binaries (supposedly; never tried) and thus ignored the arm64 
entry in the port's supported_archs list. The variant did appear when I added 
i386 support (bogus in this case as the universal DMG doesn't contain i386 
binaries).

Such intelligence from "base" is probably a good thing but somewhere I feel 
that it's inappropriate in this port's kind of situation. The universal DMG 
exists after all, and my port installs from there, not by building anything. Is 
there a way to override the logic and force the +universal variant?

The problem isn't necessarily entirely moot; port:VLC installs a library that 
can be used by 3rd party (non-MacPorts) applications, and it doesn't strike as 
impossible to build arm64 binaries on a system where MacPorts considers that to 
be impossible.

Thanks,
R.

typo in the cargo_fetch PG?

[René J . V . Bertin]

Hi,

In cargo_fetch.1.0.tcl::cargo._old_macos_compatibility, shouldn't the bail-out 
test be for `${os.platform} ne "darwin" || ${os.major} >= 12` instead of the 
current combined condition?

R.

Re: OWL - wayland for mac

[René J . V . Bertin]

On Tuesday November 30 2021 11:30:26 Robert Tillyard wrote:
>It would be nice if this was an option as we currently rely on the ability to 
>run over TCP/IP and serve X11 out from the server to the client devices.

You'd need xwayland for that if I understand correctly, but that should become 
accessible too once the underlying technology is available on Mac.

R.

>
>Regards, Rob.
>
>> On 30 Nov 2021, at 11:10, René J.V. Bertin via X11-users 
>>  wrote:
>> 
>> FYI,
>> 
>> Someone has been making progress in getting a functional Wayland on Mac.
>> 
>> HTH
>> R.
>> 
>> ---
>> Forwarded message:
>> Date: Tuesday November 30 2021
>> From: Mastodon 
>> To: rjvber...@gmail.com
>> Cc: 
>> Subject: 1 new notification since your last visit 
>> 
>> 
>> RJVB,
>> 
>> Here is a brief summary of the messages you missed since your last visit on 
>> Aug 25, 2021, 18:37
>> 
>> * ajitsinghmalra mentioned you in:
>> 
>>  @bugaevc @RJVB  I'm trying to use wayland for mac and cloned 
>> https://github.com/owl-compositor/wayland.  Any help would be higely 
>> appreciated because I'm stuck at meson.build:83:3: ERROR: Problem 
>> encountered: SFD_CLOEXEC is needed to compile Wayland libraries**
>> 
>>  View: https://mastodon.technology/web/statuses/107288330557594849
>> 
>> ---
>> 
>> Mastodon hosted on mastodon.technology
>> Change e-mail preferences: https://mastodon.technology/settings/preferences
>

port:libcxx - why so old

[René J . V . Bertin]

Hi,

Judging from the version number, port:libcxx ships a version that's long 
outdated. Is there a reason for that, like it's the latest version that builds 
on all OS X versions that require the libc++ conversion?

I have a local version that is currently at v8.0.0 on my 10.9.5 system and have 
had that install the runtime shared libraries (= not the ones used by the 
linker) in $prefix/lib via an additional +runtime variant which also installs a 
launch wrapper that adds $prefix/lib to DYLD_INSERT_LIBRARIES 
(DYLD_LIBRARY_PATH typically isn't enough on Mac). It's a lot newer than my 
system versions even (than v5.0.1) and yet I can't recall having had any issues 
with it. On the contrary, it fixed a number of strange C++ runtime warnings in 
certain KDE software and must give me that bit more performance because built 
with a more recent clang, full CPU-specific optimisation and LTO.

R.

Re: python PortGroup and destroot.pre_args

[René J . V . Bertin]

On Friday July 02 2021 04:31:50 Ryan Schmidt wrote:

>If I create a dummy portfile that includes the python portgroup then then 
>immediately tries to print destroot.pre_args, it shows why it failed:

Yes, I followed that much.

>The real question is why do you need to access destroot.pre_args right after 
>including the python portgroup and before setting name?

No, the real question is in reading the one I asked a little bit less literally:

>> Why would `name` have to be defined in order to be able to evaluate 
>> destroot.pre_args ?

i.e. why would you do anything in a Portgroup that introduces this side-effect. 
For instance, can't whatever it does be done in a pre-destroot block, or via a 
callback (using a function that ? 

To answer your question: this came up because of a `destroot.pre_args-prepend 
-v` statement I added to another Portgroup (local copy of the meson PG I've 
been trying to improve). It seems perfectly reasonable to ensure (via its 
dedicated PG) that a build system uses verbose mode in a build phase.

I've worked around the issue by doing the prepend only when the Python PG 
hasn't been included (I could have added "and `name` isn't set yet) but it'd be 
really nice if PGs tried their best to interfere least with others...

R.

python PortGroup and destroot.pre_args

[René J . V . Bertin]

Hi,

There's a strange side effect of the Python PG on `destroot.pre_args` (and 
maybe other, related variables). Accessing the variable after including the PG 
leads to

{{{
DEBUG: Sourced PortGroup python 1.0 from 
/path/to//_resources/port1.0/group/python-1.0.tcl
DEBUG: can't read "name": no such variable
while executing
"set $option"
(procedure "option" line 10)
invoked from within
"option name"
(procedure "python_get_version" line 2)
invoked from within
"python_get_version"
invoked from within
"subst {[python_get_version]}"
invoked from within
"set python.version [subst {[python_get_version]}]"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list set $optionName] [subst -nocommands {[subst 
{$option_defaults($optionName)}]}]"
(procedure "default_check" line 10)
invoked from within
"default_check python.version {} read"
(read trace on "python.version")
invoked from within
"string range ${python.version} 0 end-1"
invoked from within
"subst {[string range ${python.version} 0 end-1].[string index 
${python.version} end]}"
invoked from within
"set python.branch [subst {[string range ${python.version} 0 end-1].[string 
index ${python.version} end]}]"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list set $optionName] [subst -nocommands {[subst 
{$option_defaults($optionName)}]}]"
(procedure "default_check" line 10)
invoked from within
"default_check python.branch {} read"
(read trace on "python.branch")
invoked from within
"subst {${frameworks_dir}/Python.framework/Versions/${python.branch}}"
invoked from within
"set python.prefix [subst 
{${frameworks_dir}/Python.framework/Versions/${python.branch}}]"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list set $optionName] [subst -nocommands {[subst 
{$option_defaults($optionName)}]}]"
(procedure "default_check" line 10)
invoked from within
"default_check python.prefix {} read"
(read trace on "python.prefix")
invoked from within
"subst {${python.prefix}/bin/python${python.branch}}"
invoked from within
"set python.bin [subst {${python.prefix}/bin/python${python.branch}}]"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list set $optionName] [subst -nocommands {[subst 
{$option_defaults($optionName)}]}]"
(procedure "default_check" line 10)
invoked from within
"default_check python.bin {} read"
(read trace on "python.bin")
invoked from within
"subst {${python.bin} setup.py --no-user-cfg}"
invoked from within
"set destroot.cmd [subst {${python.bin} setup.py --no-user-cfg}]"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list set $optionName] [subst -nocommands {[subst 
{$option_defaults($optionName)}]}]"
(procedure "default_check" line 10)
invoked from within
"default_check destroot.cmd {} read"
(read trace on "destroot.cmd")
invoked from within
"set $option"
(procedure "option" line 10)
invoked from within
"option destroot.cmd"
(procedure "portdestroot::destroot_getargs" line 2)
invoked from within
"portdestroot::destroot_getargs"
invoked from within
"subst {[portdestroot::destroot_getargs]}"
invoked from within
"set destroot.pre_args [subst {[portdestroot::destroot_getargs]}]"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list set $optionName] [subst -nocommands {[subst 
{$option_defaults($optionName)}]}]"
(procedure "default_check" line 10)
invoked from within
"default_check destroot.pre_args {} read"
(read trace on "destroot.pre_args")
invoked from within
"ui_msg ${destroot.pre_args}"
(file "Portfile" line 5)
invoked from within
"source Portfile"
invoked from within
"$workername eval {source Portfile}"
(procedure "mportopen" line 50)
invoked from within
"mportopen $url"
}}}

Why would `name` have to be defined in order to be able to evaluate 
destroot.pre_args ?

R

Re: depends_run and activation

[René J . V . Bertin]

On Wednesday March 17 2021 06:53:53 Ryan Schmidt wrote:

>I think your proposal would result in a lot of unnecessary activations of 
>older dependencies which could have consequences for other ports.

Without versioned dependencies would be helpful t avoid that (e.g. in Debian 
you can indicate a dependency on versions older or newer than some reference, 
but also when a package breaks others older or newer than some given version.

This is why is talked about "at least proposing to", and that could be an 
optional feature. I really cannot predict how complex this could become to 
grasp, but users savvy enough to attempt this sort of thing would have to sort 
that kind of complexity out anyway. I do know that Debian's versioned 
dependencies aren't without issues: it can be hell to figure out why certain 
upgrades refuse to apply (and if you happen to do the full upgrade when your 
mirror is still in the process of fetching all new packages, well, let's just 
say I almost lost my desktop environment once because a crucial common 
dependency would be broken by an update elsewhere).

It just occurs to me that with APFS you could take snapshots of the entire 
$prefix and *maybe* use those to roll back temporarily the entire $prefix tree 
when you really need to go back to an old version with crucial features without 
breaking functionality in other ports. 

I just tried running portindex on the tree that had the port with the newly 
added depends_run . It didn't make a difference ...

R.

Re: depends_run and activation

[René J . V . Bertin]

On Wednesday March 17 2021 05:28:29 Ryan Schmidt wrote:

>I don't believe we can do that because I don't believe that information is 
>stored in the registry.

Probably not, given that MacPort doesn't do versioned dependencies. In itself 
that doesn't mean that it couldn't store the versions of all dependencies that 
were active (or current) when a port was installed, of course. (And with the 
registry being a database I presume such changes can be made anytime?)

>And it could break other ports to reactivate old versions of dependencies, so 
>we don't want to make it too easy or automatic to do so.

But wouldn't it be easier to undo such damage if this were all automatic, 
rather than having to fix your mess-up by hand?

>> That's just an observation btw (which one can extend to variants - wouldn't 
>> it be great if you could activate the +quartz instead of the +x11 version of 
>> a GTk port and have all dependencies be adjusted as required?)
>
>Not really. All ports in a MacPorts installation must use x11 or quartz. You 
>can't decide to change which you use after you already have ports installed.

I wouldn't mind having "dangling" GTk dependent ports; the feature as I 
described would undoubtedly be able to correct those without having to hunt 
down all "wrong" dependencies. But you could also imagine the opposite 
approach, kind of like the port select mechanism where you'd activate either 
the x11 or the quartz variant of the common dependency (here, GTk) and have all 
ports flipped That would require a decision about how to handle ports that 
exist (are installed) only in one variant.

>It was really a mistake for us to have implemented the choice as variants. 
>Implementing it as subports would have been better, but that was 
>understandably not done since the subport feature did not exist at the time.

No, I think that would actually have been worse, unless you mean with the added 
help of a PortGroup, and GTk-x11 and GTk-quartz installed in separate 
sub-prefixes. There are similar scenarios possible with Qt that I have been 
giving quite some thought over the past few years, though there the urgency is 
much less since Qt has good guarantees that binaries built against 5.x will run 
against 5.x+i .There's also a possible +quartz vs +x11 scenario, but that's 
extremely simple ... figure out how to build a qt5-x11 port (that installs just 
the X11 "backend") and suddenly most-if-not-all Qt5 applications can be started 
in X11 mode at runtime (from a terminal, at least) :)

> Activating old versions of ports for long-term use is not an intended use of 
> MacPorts.

I wasn't considering the use duration at all in my reasoning. In fact, my 
arguments are strongest (for me at least) for occasional use of that older 
version. If you're going to be using that older version for a long time then 
the overhead of having to figure out what  other ports to re-activate is less 
important. (And in fact, I think this was one of the reasons for which I 
started  my own ports tree - cutting down on the overhead of keeping things 
up-to-date).

R

Re: depends_run and activation

[René J . V . Bertin]

On Tuesday March 16 2021 23:12:12 Ryan Schmidt wrote:

>There is no such thing as a "too-new version". There is only one version of a 
>port available in the ports tree -- the current version.

Sure, but anything that's in the current port tree should not be authoritative 
over what is currently installed. It it were, you'd have a hard time keeping 
retired ports alive, for instance.

>If you install a port, MacPorts will first install or upgrade any of that 
>port's dependencies.

For upgrading that makes sense. It does not for activating a non-current 
version. The MacPorts devs who designed the de/activation feature must have had 
good reasons for introducing it, and users can have very good reasons to keep 
older versions of a port around. Audacity is among my own official ports (the 
upcoming version will use a new project file format that older versions can't 
read).
For activating an older version it would make sense to offer to activate the 
versions of the dependency ports that were installed when the target port was 
installed. That's just an observation btw (which one can extend to variants - 
wouldn't it be great if you could activate the +quartz instead of the +x11 
version of a GTk port and have all dependencies be adjusted as required?)

>I assume that MacPorts handles re-activation of a port the same way that it 
>handles installation of a port with regard to upgrading dependencies.

As said above, it shouldn't and should actually do the opposite. Imagine that 
you're reactivating the last (older) version of a port to support 32bit, or 
more fashionable, the last to support Intel architecture. You wouldn't want 
that to cause its dependencies to be upgraded/activated to a version that 
dropped support for that particular architecture. 

>Have you run portindex in the root of that ports tree, such that the 
>newly-added dependency is in the index? If not, that might explain it.

Seems I still haven't so I suppose I can still check if this indeed makes a 
difference.

R.

Re: depends_run and activation

[René J . V . Bertin]

On Monday March 15 2021 08:00:10 Ryan Schmidt wrote:
>On Mar 14, 2021, at 07:51, René J.V. Bertin wrote:
>
>> Supposing runtime dependencies are stored in the registry,
>
>Yes of course.
>
>> wouldn't it be possible and a good idea to give at least a warning if any 
>> are missing when you (re)activate a port?
>
>It shouldn't warn; it should install or activate any deps that are missing. It 
>looks like MacPorts is trying to do that already, but there appears to be a 
>bug:


Hmmm, then I don't understand why yesterday this didn't work for me. Trying now 
with (an older version of) paracode as in your example gives a similar result. 
In my case however:

{{{
>  sudo port activate paracode
--->  Computing dependencies for paracode
The following dependencies will be installed:  python38
Continue? [Y/n]: y
Error: Requested variants "+readline" do not match those the build was started 
with: "+optimizations+readline".
Error: Please use the same variants again, or run 'port clean python38' first 
to remove the existing partially completed build.
Error: See 
/opt/local/var/lnxports/logs/_opt_local_linux-ports_lang_python38/python38/main.log
 for details.
Warning: Failed to execute portfile from registry for paracode @2.7_0
}}}

I'm guessing an attempt would have been made to install python38+readline if I 
had not left the workdir around.

Is it possible that no attempt is made to activate the port if it is already 
installed? I think you could argue that `port activate` should only do an 
actual install if the dependency is not installed at all. Otherwise you could 
end up installing a too-new version.

PS: the port I tried this with yesterday is one of my own, a subport to which I 
added a runtime dependency on the main port and then reinstalled with `upgrade 
--force`. Maybe that somehow explains why it seems to ignore that new runtime 
dep?

R.

depends_run and activation

[René J . V . Bertin]

Hi,

Supposing runtime dependencies are stored in the registry, wouldn't it be 
possible and a good idea to give at least a warning if any are missing when you 
(re)activate a port? I presume you would already have gotten a warning when 
DEactivating the dependency, but that can have been long enough ago that you 
forgot about it (think ports for development that you only require 
sporadically).

R.

Re: [MacPorts] #54752: cmake 1.1 PG : ccache support

[René J . V . Bertin]

> In the cmake-1.1 PortGroup, where this is all handled, I don't see that
> the appropriate configure args are ever actually added to the
> configure.pre_args list.

That's done via the `cmake::ccaching` procedure.

I can confirm that `CMAKE__LAUNCHER` works with the make and ninja 
generators.

> For our Python ports - and specifically, those that are using Ninja - the 
> CCache variables must be set via the environment to have an effect.

Which ports are that (i.e. where does cmake come in with those)?

Re: [MacPorts] #58729: legacy-support missing futimens() (and utimensat)

[René J . V . Bertin]

> That actually leads to an interesting observation: no file system I know
> of that is writable on OS X actually supports sub-second time precision
> (other, than, MAYBE... NFS and SMB?)

Have you tried ZFS?

Re: [MacPorts] #58729: legacy-support missing futimens() (and utimensat)

[René J . V . Bertin]

> You can test back as far as 10.9, right?

I can too, just let me know if and when.

default_variants and variant conflicts

[René J . V . Bertin]

Hi,

I still have some recurrent problems with variants and causality/serialness.

I'm now developing a set of Python variants (mutually exclusive) for a port, 
declared and defined programmatically and with the latest python version as the 
default variant.

 I don't really understand but can live with the fact that I need 1 first loop 
to declare the variants (with an inner loop to generate the appropriate 
conflicts list), then set the default variant and only then do another loop to 
check variant_isset and do the actual work.

But why doesn't `default_variant` notice that it's setting a variant that 
conflicts with a variant set by the user? That means I have to check 
variant_isset in my first loop too, just to determine whether or not the user 
set a variant...

R.

Re: "publishing" Tcl support functions used in Portfiles?

[René J . V . Bertin]

On Monday September 07 2020 22:39:50 Joshua Root wrote:

Hi,

>You do it like this:
>
>
>In that proc, $mport is an identifier that was returned from mportopen,
>and the code being executed in the port's interpreter is 'set $key',
>which could of course be replaced with any other code you want.

I think that function is actually designed to return the value of `key`. It 
took me a while to figure that out, and thus why I couldn't replace `key` with 
arbitrary code.

The resulting script I came up with: 
https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde/files/update-qthelp-collection-mp.tcl

It calls a function from one of my PortGroup files that dependent ports would 
normally (and still do) evoke in the post-activate. At first I thought that 
having to specify a port to obtain a port-specific interpreter was going to be 
a stumbling block but I think that in the end it made things easier for this 
particular application. I don't have anything to set up beyond getting that 
interpreter.

R.

Re: "publishing" Tcl support functions used in Portfiles?

[René J . V . Bertin]

On Monday September 07 2020 22:39:50 Joshua Root wrote:

Thanks, will have a look.

>You do it like this:
>
>
>In that proc, $mport is an identifier that was returned from mportopen,
>and the code being executed in the port's interpreter is 'set $key',
>which could of course be replaced with any other code you want.

Sounds like maybe one can put a wrapper script in the hashbang that sets $key 
to the contents of the file it gets called with (and with which you could turn 
Portfiles into executables if you really wanted). Playtime! :)

>Activating an installed port will execute the pre/post-activate code
>that was in the Portfile when it was installed, not necessarily what's
>in the Portfile now.

Well of course, but that's not the reason as far as I can tell.

R.

"publishing" Tcl support functions used in Portfiles?

[René J . V . Bertin]

Hi,

This may be considered a "not-done" but please bear with me and give me some 
pointers on how it might be done locally...

Suppose you have developed a Tcl function in a Portfile (or a PortGroup) that 
performs a necessary job which you might sometimes want to be able to perform 
outside of a `port build/destroot/install/activate` step. Exporting the Tcl to 
a script that invokes the MacPorts interpreter via its hashbang isn't hard, but 
the function will likely use extensions normally available only in Portfiles. 
In particular, it might use resources defined in a PortGroup (say, the Qt5 PG). 

I have already figured out in the past how to write scripts that execute in the 
same kind of context as the `port` driver script (so I can "roll my own" `port 
provides` or `port content`; the most useful of these scripts allows me to 
detect activation conflicts, new files and missing ones before actually 
upgrading to a new version).
I haven't yet figured out how to write standalone scripts that run in "Portfile 
context". If there's a skeleton example that shows how to do that I'd love to 
see it.

Possible real-world usage: code handled in post-activate blocks seems to be 
executed only (or reliably so) when an install preceded the activation. Just 
testing right now with one of my ports that should be doing some significant 
work in that phase I can confirm that it appears to be skipped entirely when 
just activating a different installed version. Of course that's probably a bug 
that should be fixed but the actual job performed is one I'd like to make 
independent of the activation phase without having to reimplement it.

Thanks,
R.

Re: admin user (and ditto group member) no longer has the corresponding permissions?!

[René J . V . Bertin]

On Tuesday July 28 2020 00:15:22 Clemens Lang wrote:

>Don't do that, that completely breaks the privilege separation. You
>might as well use a non-root install then.

Not at all. It who the macportsuser is changes nothing for the usual case of 
installing binary packages nor for the normal case of properly written 
Portfiles and the usual monolithic `sudo port install foo` command. Sure, if I 
`port destroot foo` without sudo, I will be the owner of the installed files,b 
but that's still not the same thing as doing a non-root install.

>This configuration is also unsupported. This means that you should not
>expect support on this mailing list for such a configuration.

I'm not.

>macOS has been doing capability management on top of traditional unix
>permissions for a while now, for example associated to your aqua login
>session.

Well, it hasn't in my case, beyond the annoyances associated with signing 
(again, this is on 10.9, pre-SIP, one of the reasons I've been sticking to it), 
and Mac-specific ACLs/xattrs aren't at play here either.

>This list isn't the place to ask about those details, Apple
>documentation, and Apple forums are.

You know as well as I do that the Apple forums are useless in cases like this, 
which require at least low-level knowledge of Unix intricacies. Experience from 
the past has shown that this is a perfect place to find such knowledge.

But you're right. This issue affects access to any file/directory in both 
port:xterm and port:mrxt, so I'll just file an issue on trac.

R.

admin user (and ditto group member) no longer has the corresponding permissions?!

[René J . V . Bertin]

Hi,

(Cross-post - apologies - explanation below)

To streamline things as a port dev/maintainer I've set `macportsuser` to 
myself, which means that as a member of the admin group I get to do a lot of 
things without needing to sudo all the time. I know the risks, and always 
managed to avoid them.

And now something has changed, not just for the MacPorts-related directories 
(the build dir, in particular), but system-wide, and even after a reboot.

I'm still an admin user, and AFAICT I can still do everything I could through 
the GUI. I can still "sudo". But I can no longer access files that are not mine 
and don't have the required permissions for "other" users. I have another admin 
user account ("adplus"), and when I su or FUS as/to that account I can still do 
anything I expect to be able to do. The group memberships are almost strictly 
identical: my usual account just is a member of the access_bpf (wireshark) and 
procmod groups.

For instance:
```
%> mkdir /tmp/kk
%> sudo chown root:admin /tmp/kk ; sudo chmod 770 /tmp/kk ; \ls -ldO /tmp/kk ; 
\ls -lO /tmp/kk
drwxrwx---  2 root  admin  - 68 Jul 27 20:14 /tmp/kk
%> date > /tmp/kk/kkk
/tmp/kk/kkk: Permission denied.
Exit 1
%> \ls -lO /tmp/kk
ls: kk: Permission denied
Exit 1

%> su -l adplus
%> date > /tmp/kk/kkk
%> \ls -lO /tmp/kk
total 8
-rw-r--r--  1 adplus  admin  - 30 Jul 27 20:29 kkk
```
Now, to make this more interesting: the above applies to a shell running in a 
terminal emulator that gets started when I launch my X11 environment (from the 
X11 icon in the Dock). Shells running in Terminal.app (also launched from the 
Dock) give me all the permissions I expect, and if I start my X terminal 
emulator from such a shell it inherits those permissions. Launching X11 from a 
shell in Terminal.app doesn't help.

In short, it looks like somehow my regular user account gets partly crippled 
when I start my X11 environment the way I used to, or at least in shells 
launched through xterm. Specifically, I can launch a Terminal.app or iTerm.app 
from my xinitrc script, and I'll have the expected permissions in there. But 
when I launch an xterm through that test shell, I will not have all permissions.
I seem to have read reports of something like this on the XQuartz ML (which is 
why I'm cross-posting) but I'm running OS X 10.9.5 which hasn't seen any 
system/policy updates for quite some time (and certainly not during the 
previous 19-day uptime, not that I recall at least). I'm using an X11 server 
built from version of the MacPorts port:x11 (and haven't touched anything in 
there either).

Any idea what on earth is happening here, what could have changed?

Thanks!
René Bertin

Re: [MacPorts] #51083: update: port:qgit

[René J . V . Bertin]

I guess I'll have to take a look...

When starting via the cli, did you use a full path to the bundle exec?

If I had to guess at this point I'd wager that "they" tried to build a nice, 
standalone app bundle and either failed, or else there was something in my port 
that interferes (though I should add that most misses I've observed in this 
process yield an executable that doesn't run at all).

`port edit` and ^Z in remote shells

[René J . V . Bertin]

Hi,

I've been noticing a weird and rather annoying anomaly I thought I'd share here 
to see if anyone has an idea why it happens. NB: I don't think it's a bug in 
MacPorts.

I often work remotely on my Mac, sometimes ssh'in in from my Linux rig, more 
often launching a terminal emulator from my Mac login session, with $DISPLAY 
set appropriately, so that my remote shell share the environment variables and 
really behaves like if I were working locally or over VNC. That's usually 
xfce4-terminal.

I also have a habit of pushing foreground terminal applications like vi[m] to 
the background with ^Z if I want to do something like checking the effect of an 
edit to a script (or Portfile).

When I do that in such a remote terminal emulator, more often than not the 
application is suspended but doesn't get send to the background. Instead, I do 
see the expected interactive session screen, usually with the ^Z echoed but the 
prompt doesn't appear. I need to open another tab or ssh in to send the editor 
process a SIGCONT to unblock it.

I don't think I've ever seen this over a simple ssh login, nor do I think I've 
seen the equivalent when I open a remote terminal emulator from Linux under 
XQuartz. Other than that, I get this with all terminal emulators including 
xterm and all shells I tried.

Any ideas? I don't see how this could  be a bug in something like ncurses 
because then it should happen also when I run these emulators locally (and 
fortunately that isn't the case).

Thanks,
R.

Re: control verbose mode in Portfile?

[René J . V . Bertin]

Christopher Jones wrote:

> If you want pass a message on to the user, you should not use verbose output
> to do that. Instead just use a regular ‘ui_msg'

Except that this is not what I'm after; `port -v` generates additional output 
to 
what's printed via `ui_msg`, just like `set -x` shows more than just the `echo` 
commands. I probably shouldn't have implied that I wanted to use this to give 
more feedback to the user, although it could be useful if the post-activate 
calls a command (say a scan) that generates informative output (say progress 
info).

A similar argument (irrelevant here) goes for `notes` vs. `ui_msg`: they're 
complementary. 

R

upgrading self-built MacPorts and version management

[René J . V . Bertin]

Hi,

I've just upgraded my Linux adaptation of MacPorts's master branch, where I was 
helped greatly by the fact I use the system package manager (after doing a 
-reinstated- `port dpkg MacPorts-devel`) because it allowed me to revert to the 
previous version when I ran into a glitch I had introduced myself.
Yes, I use port:MacPorts-devel as a tool to benefit from reproducible builds 
and easy patch management. Works great despite someone once telling me that 
"base" isn't meant for that :)

1) This led me to wonder how many files I have left over from previous `make 
install` type upgrades on Mac, and if using packages created by `port pkg 
MacPorts-devel` is an answer to that question (as well as to being able to 
revert to the previous version in case you mess something up).

2) I seem to remember that we discussed port:MacPorts and/or 
port:MacPorts-devel years ago and that there were plans to make it possible to 
let MacPorts control its own. I don't know if I just dreamt it or if such plans 
were abandoned ... but exactly what is/was the problem with actually installing 
port:MacPorts? The fact that you can uninstall the port and be left with a 
broken install (which you can simply avoid doing) or the fact that this will 
also happen "behind the scenes" when you do an upgrade (or de/activate) because 
all required files aren't read into memory before doing the upgrade (or 
de/activate)?

In case answers to both 1) and 2) are negative: it should be possible for 
someone to roll their own package/version management by installing port:dpkg, 
port:rpm or whatever other simpler alternatives exist. If any of those actually 
work reliably on Mac?

FWIW, I have a custom port for `porg` (http://porg.sourceforge.net/) but I have 
never actually checked if it is clever enough to uninstall stale files from a 
previous package version.

Thanks,
R.

PS: all this is provoked by my recent tweaks to the buildsystem making it 
possible to build "base" with link-time optimisation, which was an interesting 
exercise in itself, exposing a few more false-positive design flaws in autoconf 
:)

control verbose mode in Portfile?

[René J . V . Bertin]

Hi,

Out of curiosity: is it possible to control verbose mode in a Portfile, like 
with `set +x` / `set -x` in shell scripts?

I'd be interested to use that in the post-activate block of a number of my 
ports, as an easy way to give a little more feedback to the user.

Thanks,
R.

Re: invalid certificate chain during port-fetch

[René J . V . Bertin]

Thanks Mojca.

Looking at the quoted ticket I see that I did propose the idea there back in 
2016, so maybe I did write the patch after all. Doesn't really matter.

What does matter is that it should be possible to pull a similar trick with 
libcurl itself provided it is conservative enough in the evolution of its ABI. 
Load libcurl dynamically, preferably from $prefix/lib but falling back to the 
system one, and fetch the required functions. Qt does something similar with 
OpenSSL (which probably involves a much larger number of imports).

FWIW, I'm aware that I'm running an OS that is out of date. One can debate 
whether or not something like libcurl is supposed to be part of the system, but 
the argument is moot for those users who are limited to an even older OS 
version because their hardware doesn't permit upgrading. Of course you can 
argue that those users can fetch their stuff from the MacPorts mirrors, but 
isn't finding a software solution for this issue cheaper than having to mirror 
an ever-increasing amount of copies of stuff readily available elsewhere?

R.

Re: invalid certificate chain during port-fetch

[René J . V . Bertin]

On Saturday December 28 2019 21:51:07 Ryan Schmidt wrote:

>If I understood the patch correctly, it adds a fallback so that if fetching 
>via the curl library fails, then it tries fetching via the curl command line 
>program. To my knowledge MacPorts has never had code for using the curl 
>command line program, only the curl library.

It does, and if it didn't then I guess this snippet must have been proposed 
during a discussion on a mailing list, or maybe it had already been contributed.

Either way, the idea makes sense even if the implementation leaves to be 
desired, no?

R.

Re: invalid certificate chain during port-fetch

[René J . V . Bertin]

On Saturday December 28 2019 14:10:29 Ryan Schmidt wrote:

>> but don't understand why the fallback doesn't work on Mac. Maybe a different 
>> exception is raised there?
>> 
>> Anyway, I think the fallback makes sense in this kind of situation, and it 
>> should handle bootstrap errors gracefully. That is, if port:curl isn't yet 
>> installed the system curl will be found.
>
>I don't want to debug any custom changes you've made to MacPorts base.

I'm not asking you to but I'm quite certain this is a reintroduction of code 
that was removed for some reason. It doesn't look like how I'd have written it 
(I wouldn't have bothered with an exception filter).

R.

Re: invalid certificate chain during port-fetch

[René J . V . Bertin]

On Friday December 27 2019 21:32:26 Ryan Schmidt wrote:

Hi,

Thanks for looking into this!

>You didn't mention what instructions you're referring to

Only because there are several threads about this issue on S-E and I was on a 
different machine when I wrote to the ML.. And you must have seen that this is 
about a "KDE 5" port, i.e. one from my macstrop tree. I didn't draw attention 
to *that* because the problem has nothing to do with any specific port in 
particular ;)

>You can use a different method to fetch the file (for example MacPorts curl or 
>Safari or another web browser) and put it in the right place on your system

That's what I did. The curious thing is that my Mac and Linux MacPorts installs 
both have this patch to portfetch.tcl :

{{{
@@ -567,7 +568,19 @@ proc portfetch::fetchfiles {args} {
 set fetched 1
 break
 } catch {{*} eCode eMessage} {
-ui_debug [msgcat::mc "Fetching distfile failed: %s" 
$eMessage]
+ui_warn [msgcat::mc "Fetching distfile failed: %s" 
$eMessage]
+ui_debug "complete command:"
+ui_debug "curl fetch {*}$fetch_options $file_url 
\"${distpath}/${distfile}.TMP\""
+if {${eMessage} eq "gnutls_handshake() failed: Handshake 
failed"} {
+if {![catch {system "curl -L $file_url -o 
\"${distpath}/${distfile}.TMP\""} err]} {
+ui_debug [msgcat::mc "Fetching distfile succeeded 
via curl"]
+file rename -force "${distpath}/${distfile}.TMP" 
"${distpath}/${distfile}"
+set fetched 1
+break
+} else {
+ui_warn [msgcat::mc "Fetching distfile failed also 
via curl: %s" $err]
+}
+}
 set lastError $eMessage
 } finally {
 file delete -force "${distpath}/${distfile}.TMP"
}}}

IIRC this is a a snippet I restored back in 2016 for reasons long forgotten.

As a result I see this on Linux:

{{{
--->  Fetching distfiles for kf5-libkcontacts
DEBUG: Executing proc-pre-org.macports.fetch-fetch-0
DEBUG: Executing org.macports.fetch (kf5-libkcontacts)
--->  kcontacts-19.08.3.tar.xz does not exist in 
/opt/local/var/lnxports/distfiles/kf5-libkcontacts
--->  Attempting to fetch kcontacts-19.08.3.tar.xz from 
https://download.kde.org/stable/applications/19.08.3/src
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
Warning: Fetching distfile failed: gnutls_handshake() failed: Handshake failed
DEBUG: complete command:
DEBUG: curl fetch {*}--progress builtin 
https://download.kde.org/stable/applications/19.08.3/src/kcontacts-19.08.3.tar.xz
 
"/opt/local/var/lnxports/distfiles/kf5-libkcontacts/kcontacts-19.08.3.tar.xz.TMP"
DEBUG: system: curl -L 
https://download.kde.org/stable/applications/19.08.3/src/kcontacts-19.08.3.tar.xz
 -o 
"/opt/local/var/lnxports/distfiles/kf5-libkcontacts/kcontacts-19.08.3.tar.xz.TMP"
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   356  100   3560 0   1186  0 --:--:-- --:--:-- --:--:--  1186
100  535k  100  535k0 0   743k  0 --:--:-- --:--:-- --:--:--  743k
DEBUG: Fetching distfile succeeded via curl
DEBUG: Executing proc-post-org.macports.fetch-fetch-0
}}}

but don't understand why the fallback doesn't work on Mac. Maybe a different 
exception is raised there?

Anyway, I think the fallback makes sense in this kind of situation, and it 
should handle bootstrap errors gracefully. That is, if port:curl isn't yet 
installed the system curl will be found.

> We should do our mirroring on a newer version of macOS, but making that 
> change to our server infrastructure is nontrivial.

Heh, is that your way of saying that upgrading the OS isn't as trivial as Apple 
would like us to believe? :)
I presume SIP is involved here?


>You might want to bring this problem to the attention of whoever runs that 
>server. They may not realize that the restrictions they've put in place impact 
>OS versions as recent as OS X 10.11. They may be willing to relax their 
>restrictions somewhat so that older systems can still connect.

I can try to do that, I have an idea whom I might contact about that. I don't 
know if they'll care though: the KF5 Frameworks now require Qt 5.12 which no 
longer supports OS X 10.11 . The last frameworks release that can be made to 
build on 10.9 (with older versions for the QML-related ones) is 5.60.0 so it's 
been quiet on that front for me the last 5 months or so :-/

R.

Re: suggestion: samurai

[René J . V . Bertin]

A QtWebEngine rebuild in the same build.dir (without preceding `make clean`) 
completed just fine using ninja symlinked `samu` (a part of the tree was 
rebuild).

Samu is also able to build ninja itself (if you skip the ninja bootstrap 
procedure and copy samu to ${worksrcpath}/ninja).

Here's an implementation of the port in case

 anyone wants to test:

https://github.com/RJVB/macstrop/blob/master/devel/samurai/Portfile

R

Re: suggestion: samurai

[René J . V . Bertin]

PS: an alternative solution for the ninja issue outlined in my OP would be a 
wrapper script like this

{{{
#!/bin/sh

if [ "${NINJA_JOBS}" != "" ] ;then
exec ninja.bin -j "${NINJA_JOBS}" "$@"
else
exec ninja.bin "$@"
fi
}}}

suggestion: samurai

[René J . V . Bertin]

Hi,

I just discovered a potentially interesting alternative to the ninja build 
tool: https://github.com/michaelforney/samurai:

samurai is a ninja-compatible build tool written in C99 with a focus on 
simplicity, speed, and portability.

I have yet to investigate and compare it, but the main difference where the 
interest is clear is "The environment variable SAMUFLAGS can now be used to 
specify default -j or -v options."

Why? If you've ever built something like QtWebEngine from source you must have 
noticed that that is almost a local DOS attack. Qmake will generate a Makefile 
through why a python-based build system is launched which in turn calls ninja, 
all without heeding $build.jobs which gets thrown out in the first (g)make 
level. I don't have definitive proof but I'm pretty certain that some of the 
ninja files spawn other ninja jobs, meaning you end up with multiple copies 
running that all think they can launch way more jobs than they should. And 
those jobs aren't small bites either: clang++ can get very memory hungry on 
larger C++ files (not to mention ObjC++!).
In practice, you end up with a build that may actually complete quicker and 
allow the system to be used for (light) other tasks in the meantime if you 
force a hard limit of say half the available CPU cores on the number of jobs 
ninja can use.

The typical "port:samurai scenario" would be to make it conflict with ninja, 
and make $prefix/bin/ninja a symlink to idem/samurai.

I'm planning to try this and build QtWebEngine on a machine I'm not using much 
these days, just to check if the build completes. If it does then 
port:qt5-qtwebengine could use `depends_build path:bin/ninja:samurai` .

R.

invalid certificate chain during port-fetch

[René J . V . Bertin]

Hi,

Any suggestions how I can work around this kind of error (on OSX 10.9.8)?

{{{
--->  Attempting to fetch kcontacts-19.08.3.tar.xz from 
https://download.kde.org/stable/applications/19.08.3/src
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
Warning: Fetching distfile failed: SSL certificate problem: Invalid certificate 
chain
}}}

The instructions I found on stackexchange didn't work for me.

Thanks,
R.