Re: New Port Request: Primesieve from https://github.com/kimwalisch/primesieve

[Ken Cunningham]

ing duplicate libraries: '-lgcc'
>> [ 44%] Built target libprimesieve
>> [ 46%] Building CXX object 
>> CMakeFiles/libprimesieve-static.dir/src/api-c.cpp.o
>> [ 48%] Building CXX object CMakeFiles/libprimesieve-static.dir/src/api.cpp.o
>> [ 51%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/CountPrintPrimes.cpp.o
>> [ 53%] Building CXX object 
>> CMakeFiles/libprimesieve-static.dir/src/CpuInfo.cpp.o
>> [ 55%] Building CXX object CMakeFiles/libprimesieve-static.dir/src/Erat.cpp.o
>> [ 57%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/EratSmall.cpp.o
>> [ 59%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/EratMedium.cpp.o
>> [ 61%] Building CXX object 
>> CMakeFiles/libprimesieve-static.dir/src/EratBig.cpp.o
>> [ 63%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/iterator-c.cpp.o
>> [ 65%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/iterator.cpp.o
>> [ 68%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/IteratorHelper.cpp.o
>> [ 70%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/LookupTables.cpp.o
>> [ 72%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/MemoryPool.cpp.o
>> [ 74%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/PrimeGenerator.cpp.o
>> [ 76%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/nthPrime.cpp.o
>> [ 78%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/ParallelSieve.cpp.o
>> [ 80%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/popcount.cpp.o
>> [ 82%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/PreSieve.cpp.o
>> [ 85%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/PrimeSieve.cpp.o
>> [ 87%] Building CXX object
>> CMakeFiles/libprimesieve-static.dir/src/SievingPrimes.cpp.o
>> [ 89%] Linking CXX static library libprimesieve.a
>> [ 89%] Built target libprimesieve-static
>> [ 91%] Building CXX object CMakeFiles/primesieve.dir/src/app/cmdoptions.cpp.o
>> [ 93%] Building CXX object CMakeFiles/primesieve.dir/src/app/help.cpp.o
>> [ 95%] Building CXX object CMakeFiles/primesieve.dir/src/app/main.cpp.o
>> [ 97%] Building CXX object CMakeFiles/primesieve.dir/src/app/test.cpp.o
>> [100%] Linking CXX executable primesieve
>> -macosx_version_min has been renamed to -macos_version_min
>> ld: warning: ignoring duplicate libraries: '-lgcc'
>> [100%] Built target primesieve
>> 
>> On Sat, Dec 16, 2023 at 7:55 PM Kenneth Wolcott
>>  wrote:
>>> 
>>> Hi Ken C.;
>>> 
>>>  Thanks, but I could not get it to compile on my machine (M1, Sonoma
>>> 14.2). I think I got a link error, don't recall right now.  Another
>>> time I got an assert failure at the link stage.
>>> 
>>> Ken W.
>>> 
>>> On Sat, Dec 16, 2023 at 7:37 PM Ken Cunningham
>>>  wrote:
>>>> 
>>>> Someone can make a port for this, but here you are for a quickie, to show 
>>>> you how this is done:
>>>> 
>>>> 
>>>> % sudo port install cmake
>>>> 
>>>> 
>>>> % git clone --depth=1 https://github.com/kimwalisch/primesieve
>>>> % cd primesieve
>>>> % mkdir build
>>>> % cd build
>>>> % cmake ..
>>>> % make
>>>> 
>>>> % ./primesieve 100 --count --print
>>>> 2
>>>> 3
>>>> 5
>>>> 7
>>>> 11
>>>> 13
>>>> 17
>>>> 19
>>>> 23
>>>> 29
>>>> 31
>>>> 37
>>>> 41
>>>> 43
>>>> 47
>>>> 53
>>>> 59
>>>> 61
>>>> 67
>>>> 71
>>>> 73
>>>> 79
>>>> 83
>>>> 89
>>>> 97
>>>> 25
>>>> 

Re: New Port Request: Primesieve from https://github.com/kimwalisch/primesieve

[Ken Cunningham]

Someone can make a port for this, but here you are for a quickie, to show you 
how this is done:


% sudo port install cmake


% git clone --depth=1 https://github.com/kimwalisch/primesieve
% cd primesieve
% mkdir build
% cd build
% cmake ..
% make

% ./primesieve 100 --count --print
2
3
5
7
11
13
17
19
23
29
31
37
41
43
47
53
59
61
67
71
73
79
83
89
97
25

Re: perl5 variants (was: #68635: meld port depends on a nonexistent p5.36-xml-parser port)

[Ken Cunningham]

> On Nov 4, 2023, at 4:51 PM, Ken Cunningham  
> wrote:
> 
> So to clean that up:
> 
> sudo port -f uninstall perl5 perl5.36
> 
> and then:
> 
> sudo port -f install perl5

That last line should have been:

sudo port -v install perl5

K

Re: perl5 variants (was: #68635: meld port depends on a nonexistent p5.36-xml-parser port)

[Ken Cunningham]

MacPorts current "default" perl is perl5.34.

I tooks like you have manually installed perl5.36 and there is no need for perl 
5.36, so you could uninstall that if you care to. Everything else is pegged to 
perl 5.34 currently, except your "perl5" port which must have manually been 
installed with the +perl5.36 variant to get that variant installed.

So to clean that up:

sudo port -f uninstall perl5 perl5.36

and then:

sudo port -f install perl5

and that should pick up the defaults, which you want, so you don't have to 
build everything all the time..




Once a year MacPorts updates it's default perl and python versions, in January 
if I recall the routine.

There is (AFAIK) no current method to say "just use the current latest perl all 
the time"... you get pegged to the one that is designated the current default 
when you install perl or a perl port, and thereafter you are stuck on that perl 
version forevermore for those ports...

So if you want to be really neat and tidy, you would keep a list (port echo 
requested) of what you actually wanted installed, and approximately every 
February or March, after the dust has settled, do a:

sudo port -f uninstall installed

and then a

sudo port reclaim

and then reinstall the things on your "requested list" -- manually, I would 
suggest, so you can look them over -- one by one.

If you see any gcc or llvm ports on your "requested" list probably best not to 
reinstall those, as the new defaults will call in the current needed versions.

Ken

Re: Help with legacysupport PortGroup for building GIMP for older MacOS's

[Ken Cunningham]

Building and using legacysupport on a newer system to target an older system is 
tricky to design and implement properly.

I think it is possible to do it, but issues will probably arise that only show 
up at deployment time.

If I wanted to deploy gimp to 10.13, I would set up a 10.13 VM in Parallels on 
an Intel system, and build the final package there. That would be fully 
supported by macports, and require nothing special to work properly.

I’m not sure if you would need a special prefix for your package, but if not, 
if you build a self-contained application bundle, then you could even use 
premade binaries.

Ken

Re: Help me understand dependents of libgcc-devel vs gcc13?

[Ken Cunningham]

There was a time when the only version of gcc that built on arm64 was 
gcc-devel/libgcc-devel. So ports put a specific dependency on that on arm. This 
was a long time ago now.  It got things built.

Then various gcc versions came out, gcc-12, gcc-13 that would build on arm64 
(with extra patches, but would build). So the dependency on 
gcc-devel/libgcc-devel was removed. 

But there are situations where if you had already installed some ports, you 
were stuck in the gcc-devel loop due to recorded variant history. Or if you had 
gcc-devel installed / libgcc-devel, it just kept on getting updated.

None of this is ideal... It was just "expedient" as a Way To Get Things Done 
when things are imperfect.

Same thing happens with perl and python and other supporting ports.

MacPorts has been trying to purge all this kind of stuff out of the ports tree 
-- but it's hard, and complicated, and there is still lots and lots of it in 
there. Josh has made specific changes to try to reduce this recorded clutter.


What I do is keep track of the ports I actually want installed by using 
"requested".

Then every so often I delete all my ports, and reinstall them all freshly (not 
using the restore script, as that records the old variants I'm trying to get 
rid of) to pick up all the new defaults that have crept in over the period of 
time since I did it last.

By doing that, you get all the new perl versions, python versions, gcc 
versions, etc.

Ken

Re: Can gcc13 create fat binaries for Intel+ARM in one-liner?

[Ken Cunningham]

The necessary parts Apple added (driverdriver.c) to enable that have not been 
updated since gcc-4.2, so one-pass universal is not available since then.

People occassionaly talk about updating driverdriver.c, and there are a few 
shell scripts floating around that do some of it, but that’s as far as it goes.

K

> On Jun 21, 2023, at 01:41, Ces VLC  wrote:
> 
> 
> Hi!
> 
> Last time I used gcc for creating fat binaries was in the days of Snow 
> Leopard, using the Apple-bundled version of gcc, which, if I recall correctly 
> had this behaviour of letting you specify several archs in the same 
> invocation because of a patch written by Apple. I also seem to recall that 
> years later I tried a genuine (non-Apple) gcc, and creation of fat binaries 
> as a one liner was no longer available.
> 
> I know that gcc support for Apple Silicon comes as a patch, and it's not 
> upstreamed yet AFAIK, but I was wondering if that patch lets you build 
> Intel+ARM universal fat binaries in a single invocation as well, or if that's 
> not supported.
> 
> Kind regards and thanks a lot!

Re: best Xcode version for Mojave?

[Ken Cunningham]

On 2023-06-12, at 7:25 PM, Richard L. Hamilton wrote:

> "On macOS 10.14, iTerm2 @3.4.19 requires Xcode 11.0 or later but you have 
> Xcode 10.3."
> 
> 11.3.1 is the newest Xcode for Mojave.
> 
> Is there any known downside to Xcode 11.3.1 on Mojave rather than the 10.3 I 
> have on there now? Space is tight, so I'm not sure I want both.
> 
> And will I need 11.3.1 command line tools too?
> 


MacPorts builds software most reliably when the MacOSX SDK exactly matches the 
OS version you are building on.

This is because the vast amount of open source software out there does not 
usually take sufficient efforts to account for the different system 
capabilities of MacOS versions in the same way that software written 
specifically for MacOS might.

MacPorts will therefore usually recommend the last version of Xcode that comes 
with a MacOSX SDK that matches the system version. This is what the buildbots 
have installed.

You can, however, save the system-matching SDK from that version of Xcode 
somewhere, update Xcode to the latest version (that usually has the next 
system's MacOS SDK in it), and then copy back the system-matching SDK into the 
proper place in both the CommandLineTools installation and the Xcode 
installation.

Then you have the best of both worlds.

Because this involves extra steps, and is still hard to automate at present, 
MacPorts is not currently recommending that.

But that is what I do.

There are plans underway to allow a system-matching SDK (or any SDK) with any 
version of Xcode, but these have not yet reached the point where this is all 
automated.

Ken

Re: Exa port dependencies

[Ken Cunningham]

I have long thought the doc variants should never be the default.

Lots of bloat and extra deps and build errors.

But I know others feel differently.

I know I can set -doc in variants.conf, but then you’re building everything.


K

> On Jun 9, 2023, at 04:01, Joshua Root  wrote:
> 
> 
>> 
>> The list below is the current list of build dependencies when I do a
>> port install of "exa +doc+git". The list seems pretty ridiculous though.
>> I just cloned the exa repository and did a cargo build outside macports.
>> None of these dependencies are required.
> The vast majority of those are dependencies of pandoc, which is used by the 
> exa port's doc variant. They won't be installed when installing exa from a 
> binary archive. If you need to build locally and don't want all these deps, 
> you can use -doc.
> 
> - Josh
> 

Re: Portfile question for 10.6.8

[Ken Cunningham]

> On Jun 6, 2023, at 6:28 PM, raf via macports-users 
>  wrote:
> 
> On Wed, Jun 07, 2023 at 11:09:13AM +1000, raf via macports-users 
>  wrote:
> 
>> Yay! It worked. Many thanks. I'll fix my Makefile for the upcoming version
>> of rawhide and create the Portfile for that.
> 
> I spoke too soon. The compilation worked, but when I ran the
> program to list everything in my home directory, there were
> many many "Bad file descriptor" errors for fstatat(). It's
> happening for everything immediately below the current
> directory. Any ideas?
> 
> cheers,
> raf
> 

is  -I/opt/local/include/LegacySupport making it into your CFLAGS and CXXFLAGS 
during the build?

Re: Portfile question for 10.6.8

[Ken Cunningham]

> On Jun 6, 2023, at 6:16 PM, raf via macports-users 
>  wrote:
> 
> On Wed, Jun 07, 2023 at 11:09:13AM +1000, raf via macports-users 
>  wrote:
> 
>> So if I use different macro names (e.g. ALL_CFLAGS and ALL_LDFLAGS), and just
>> add $(CFLAGS) and $(LDFLAGS) from the environment to it, then it should work.
>> I'll try that.
>> 
>> Yay! It worked. Many thanks. I'll fix my Makefile for the upcoming version
>> of rawhide and create the Portfile for that.
> 
> That still leaves the question of how 10.6.8 hosts can download distfiles
> from a non-https site (when https sites won't support TLS 1.0). Do distfiles
> magically end up on http://distfiles.macports.org?
> 
> cheers,
> raf
> 

Newer systems download them to distfiles.macports.org 
, and that site supports older TLS so older 
systems can get them from there.

Re: Portfile question for 10.6.8

[Ken Cunningham]

it looks like the legacy support library is not being included in the link.

This is common when only scripts are used, as there are many flags that might 
not be considered.

If you run the build on 10.6 using some extra verbosity flags like "-d" it will 
show you all the ENVVARs and LDFLAGS etc that macports sets. You should see the 
ones your script needs to account for in that list to get the proper 
legacysupport library on the link line.

K



> On Jun 6, 2023, at 7:44 AM, raf via macports-users 
>  wrote:
> 
> On Tue, Jun 06, 2023 at 11:52:26PM +1000, raf  wrote:
> 
>> Hi, I'm writing a Portfile, and I have two macOS
>> systems to test it on: 10.6.8 and 10.14.6. Both have
>> macports-2.8.1.
>> 
>> I'm having trouble getting it working on macos-10.6.8.
>> It doesn't know where to download the tarball from.
>> 
>> This is the Portfile (minus blank lines):
>> 
>>  # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>>  PortSystem  1.0
>>  PortGroup   legacysupport 1.0
>>  #PortGroup   github 1.0
>>  PortGroup   makefile 1.0
>>  # Need openat(), unlinkat(), fdopendir()
>>  legacysupport.newest_darwin_requires_legacy 13
>>  namerawhide
>>  version 3.1
>>  #github.setup raforg rawhide 3.1 v
>>  #github.tarball_from releases
>>  revision0
>>  categories  sysutils
>>  platforms   darwin
>>  license GPL-3+
>>  maintainers raf.org:raf
>>  description (rh) find files using pretty C expressions
>>  long_description(rh) An alternative to find(1) that is more fun to use
>>  homepagehttps://raf.org/rawhide/
>>  master_sites${homepage}download/
>>  checksums   rmd160 230300b186a02dc5f2406b15f26a2d3e640b3a51 \
>>  sha256 
>> f495311262b44d3b55ba301f8367c65fbfc075f09d6fce4018a5e5e0588cc6fa \
>>  size 272193
>>  depends_lib port:pcre2 port:libmagic
>>  # Only a script, not a real configure.
>>  use_configure   yes
>>  destroot.destdirPREFIX=${destroot}${prefix}
>>  configure.args  --macports
>>  build.targetrh
>>  livecheck.type  regex
>>  livecheck.url   ${master_sites}
>>  livecheck.regex ${name}-(\\d+(?:\\.\\d+)*)${extract.suffix}
>> 
>> It works on 10.14.6, but on 10.6.8, it guesses a bunch of download locations:
>> 
>>> sudo port install rawhide
>>  Portfile changed since last build; discarding previous state.
>>  --->  Computing dependencies for rawhide
>>  --->  Fetching distfiles for rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://distfiles.macports.org/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> https://raf.org/rawhide/download/
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://aarnet.au.distfiles.macports.org/pub/macports/distfiles/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://jog.id.distfiles.macports.org/macports/distfiles/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://kmq.jp.distfiles.macports.org/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://mirror.fcix.net/macports/distfiles/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://cjj.kr.distfiles.macports.org/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://ywg.ca.distfiles.macports.org/mirror/macports/distfiles/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://pek.cn.distfiles.macports.org/macports/distfiles/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://fra.de.distfiles.macports.org/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://ema.uk.distfiles.macports.org/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://cph.dk.distfiles.macports.org/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://fco.it.distfiles.macports.org/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://mse.uk.distfiles.macports.org/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://nue.de.distfiles.macports.org/rawhide
>>  --->  Attempting to fetch rawhide-3.1.tar.gz from 
>> http://atl.us.distfiles.macports.org/rawhide
>>  Error: Failed to fetch rawhide: The requested URL returned error: 404
>>  Error: See 
>> /opt/local/var/macports/logs/_Users_raf_macports_ports_sysutils_rawhide/rawhide/main.log
>>  for details.
>>  Error: Follow https://guide.macports.org/#project.tickets if you believe 
>> there is a bug.
>>  Error: Processing of port rawhide failed
>> 
>> I don't know why it tried distfiles.macports.org/rawhide first,
>> or why it didn't find https://raf.org/rawhide/download/rawhide-3.1.tar.gz
>> 
>> I then tried 

Re: gcc12 fault?

[Ken Cunningham]

> On Jun 1, 2023, at 6:18 PM, Joshua Root  wrote:
> 
> Ken Cunningham wrote:
> 
>> what you see is difficult to explain, unless the PATH changed between the 
>> two tests.
>> 
>> if
>> 
>> 'which gcc' gives /opt/local/bin/gcc
>> 
>> then
>> 
>> gcc --version
>> 
>> should give exactly the same as
>> 
>> /opt/local/bin/gcc --version
> 
> Not necessarily. Shells cache command locations, so if 'gcc' was run prior to 
> the creation of /opt/local/bin/gcc, subsequently invocations will continue to 
> run the previously found gcc. Running 'hash -r' or starting a new shell will 
> give you an empty cache and thus set things right.
> 
> The 'which' command doesn't know about the shell's cache state; it only looks 
> at the current PATH. This is why 'type' often helps to understand what's 
> going on in these situations, as Richard hinted.
> 
> - Josh
> 

You have probably already noted that which and type are both built in to the 
default zsh on Ventura and as far as I can tell from my testing here give 
identical results in every case. Both correctly predict the binary that will be 
executed in every case I tried.

What will happen when you add and remove binaries from an upstream PATH folder 
is a bit difficult to predict accurately. I won't try to summarize the findings 
only to have someone point out their idea of an exception, but it's fair to say 
that it's best to open a new shell to get predictable results.

K

Re: gcc12 fault?

[Ken Cunningham]

what you see is difficult to explain, unless the PATH changed between the two 
tests.

if

'which gcc' gives /opt/local/bin/gcc

then

gcc --version

should give exactly the same as

/opt/local/bin/gcc --version


Now you know that /opt/local/bin/gcc will not actually exist, unless you have 
"selected" a gcc in macports to be your default gcc.  You probably want to 
unselect that if you did select one, as having it always set can cause problems 
that can be hard to debug. I do set a selected gcc sometimes, but unset it 
right after.

Ken




On 2023-06-01, at 8:17 AM, David Nicholls via macports-users wrote:

> I upgraded OSX to the latest Ventura, installed the latest Xcode, and Xcode 
> tools, accepted the license, then reinstalled Macports as per the 
> instructions.  Versions of gcc older than gcc12 failed (as advised in the 
> resintall), so I installed gcc12, ran port select to activate gcc12 and 
> gfortran12. All ok so far.
> 
> 'which gcc' gives /opt/local/bin/gcc
> 
> But:
> 
> :~ username$ gcc --version
> Apple clang version 14.0.3 (clang-1403.0.22.14.1)
> Target: x86_64-apple-darwin22.5.0
> Thread model: posix
> InstalledDir: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> 
> and
> 
> :~ username$ /opt/local/bin/gcc --version
> gcc (MacPorts gcc12 12.3.0_0+stdlib_flag) 12.3.0
> Copyright (C) 2022 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> Why does the command 'gcc --version' not give that same result as 
> '/opt/local/bin/gcc --version' ?
> 
> 'gfortan --version' works as expected
> 
> DN

Re: Wine

[Ken Cunningham]

Yes, the one in MacPorts is aging now.

FYI, Dean just released wine-8.7 an hour ago:

https://github.com/Gcenx/macOS_Wine_builds/releases/tag/8.7

It is a fully-encapsulated build, all the libraries inside the app bundle.

I just installed it and it runs nicely on my arm64 Mac

Ken


> On May 1, 2023, at 9:30 AM, André-John Mas  wrote:
> 
> I am a little confused here, since the latest Wine release on MacPorts 
> indicates it os 4.0.4:
> 
> https://ports.macports.org/port/wine/
> 
> Latest CrossOver Wine is 7.7 and official WineHQ is 8.5.
> 
> is the latest version on MacPorts really that old, or am I misunderstanding 
> something?
> 
> Thanks
> 
> Andre
> 
>> On Apr 30, 2023, at 14:39, Ken Cunningham  
>> wrote:
>> 
>> You probably won't want to build it, though.
>> 
>> Dean uses MacPorts to build wine, and then makes the binaries available here:
>> 
>> https://github.com/Gcenx/macOS_Wine_builds/releases/
>> 
>> Homebrew just downloads and installs the premade binaries that are made by 
>> Dean's MacPorts overlay.
>> 
>> These are considered the official Wine builds for MacOS.
>> 
>> Perhaps one day Dean will be able to integrate his updates into MacPorts 
>> main repo, but Ryan has been building and maintaining Wine on MacPorts for 
>> many years and has a parallel update in the works.
>> 
>> Unfortunately Ryan is also extremely busy with all his other MacPorts 
>> efforts, and has not been able to finish his update to wine for some years 
>> now, so may have to pass the gavel to Dean in the end.
>> 
>> Best,
>> 
>> ken
>> 
>> 
>> 
>>> On Apr 30, 2023, at 11:27 AM, contextnerror ​  
>>> wrote:
>>> 
>>> Yes and no. You’ll want to use the version by Gcenx.
>>> https://github.com/Gcenx/macports-wine
>>> 
>>>> On Apr 30, 2023, at 1:46 AM, Christoph Kukulies  wrote:
>>>> 
>>>> Data  point: 
>>>> 
>>>> $ sudo port install wine
>>>> Password:
>>>> wine is known to fail. Try to install anyway? [y/N]: y
>>>> Error: wine cannot be installed for the configured build_arch 'x86_64' 
>>>> because it only supports the arch(s) 'i386'.
>>>> Error: Follow https://guide.macports.org/#project.tickets if you believe 
>>>> there is a bug.
>>>> Error: Processing of port wine failed
>>>> $ 
>>>> 
>>>> 
>>>> 
>>>>> Am 30.04.2023 um 10:45 schrieb Christoph Kukulies :
>>>>> 
>>>>> Does macports support Wine ?
>>>>> 
>>>>> —
>>>>> Christoph
>>>>> 
>>>> 
>> 
> 

Re: Wine

[Ken Cunningham]

You probably won't want to build it, though.

Dean uses MacPorts to build wine, and then makes the binaries available here:

https://github.com/Gcenx/macOS_Wine_builds/releases/

Homebrew just downloads and installs the premade binaries that are made by 
Dean's MacPorts overlay.

These are considered the official Wine builds for MacOS.

Perhaps one day Dean will be able to integrate his updates into MacPorts main 
repo, but Ryan has been building and maintaining Wine on MacPorts for many 
years and has a parallel update in the works.

Unfortunately Ryan is also extremely busy with all his other MacPorts efforts, 
and has not been able to finish his update to wine for some years now, so may 
have to pass the gavel to Dean in the end.

Best,

ken



> On Apr 30, 2023, at 11:27 AM, contextnerror ​  
> wrote:
> 
> Yes and no. You’ll want to use the version by Gcenx.
> https://github.com/Gcenx/macports-wine
> 
>> On Apr 30, 2023, at 1:46 AM, Christoph Kukulies  wrote:
>> 
>> Data  point: 
>> 
>> $ sudo port install wine
>> Password:
>> wine is known to fail. Try to install anyway? [y/N]: y
>> Error: wine cannot be installed for the configured build_arch 'x86_64' 
>> because it only supports the arch(s) 'i386'.
>> Error: Follow https://guide.macports.org/#project.tickets if you believe 
>> there is a bug.
>> Error: Processing of port wine failed
>> $ 
>> 
>> 
>> 
>>> Am 30.04.2023 um 10:45 schrieb Christoph Kukulies :
>>> 
>>> Does macports support Wine ?
>>> 
>>> —
>>> Christoph
>>> 
>> 

Re: Cannot build glib2

[Ken Cunningham]

FYI I have had good luck with opencore legacy patcher on several machines.

A macbookpro 9,2 can run the current Ventura, for example, very nicely 
(upgraded to 16GB Ram).

Some machines don't fare as well -- a macbookpro 9,1 I  tried to upgrade 
struggles.

K



On 2023-04-18, at 11:17 AM, Eldrid Rensburg wrote:

> Some "modern" builds can't build on older MBP arch. I have a similar MBP with 
> HS - where e.g. homebrew requires a newer XCode that in turn requires a newer 
> macOS (with newer hardware - Apple's money-making tactics will continue with 
> the newer MBPs). My work client projects required a newer setup - but I still 
> keep the old MBP HS as a workhorse for other stuff.
> 
> On Sun, 16 Apr 2023, 22:59 Dave Horsfall,  wrote:
> Early MacBook Pro (13", mid 2010), High Sierra 10.13.6 (as far as it will 
> go).
> 
> When doing my weekly port upgrade, it bombs out with:
> 
> --->  Building glib2 
> Error: Failed to build glib2: command execution failed   
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/main.log
>  for details.
> 
> I see a lot of warnings in main.log such as:
> 
> :info:build ld: warning: The i386 architecture is deprecated for macOS 
> (remove from the Xcode build setting: ARCHS)
> 
> Is this some insidious attempt by Cupertino to force me to buy an M series?
> 
> Compressed main.log attached.
> 
> -- Dave

Re: meson and NM

[Ken Cunningham]

> On Apr 17, 2023, at 4:43 PM, Riccardo Mottola  
> wrote:
> 
> Hi Ken!
> 
> hmm... somehow your email got garbled? It is without subject and I cannot 
> relate.. but I think I got it.
> 
> 
> Ken Cunningham wrote:
>> meson is now more picky about unrecognized arguments.
>> 
>> This will have to be removed, and then making sure it uses the right NM 
>> might have to be done another way:
>> 
>> lt_cv_path_NM=/opt/local/bin/nm
>> 
>> 
> 
> Are you suggesting that the "classic" way I used for years:
> 
> if {${os.platform} eq "darwin" && ${os.major} < 10} {
> depends_build-append port:cctools
> configure.env-append NM=${prefix}/bin/nm
> configure.args-append lt_cv_path_NM=${prefix}/bin/nm
> }
> 
> is not correct, since it adds extra arguments?

exactly. meson doesn't recognize  lt_cv_path_NM=${prefix}/bin/nm and stops the 
configuration.

> Indeed I was using an old Portfile, the one I "saved".
> 
> The current portfile has:
> 
> if {${os.platform} eq "darwin" && ${os.major} < 10} {
> depends_build-append \
> port:cctools
> configure.env-append \
> NM=${prefix}/bin/nm
> }
> 
> 

that probably works, and if so, then should be all that is needed

> I wonder if this different way needs to be propagated to many other ports or 
> just if meson is used.

there will be an error only if meson is used. Not many ports have this addition 
at present, however:

% ag -G Portfile  -l lt_cv_path_NM
devel/gmp/Portfile
devel/gnutls/Portfile
net/curl/Portfile
python/py-pygtk/Portfile
python/py-pygtk-devel/Portfile
mail/libidn2/Portfile
audio/pulseaudio/Portfile
graphics/gimp2/Portfile
graphics/gimp2-devel/Portfile


> 
> pango built now, so resuming build of other stuff!
> 
> I will not file a bug, since it is already corrected. This is me trying to 
> determine pango versions which worked. I am very confused, I have not found a 
> specific verison pattern - as I noted in the trac ticket.
> 
> Thanks!
> 
> Riccardo

Re: Cannot build glib2

[Ken Cunningham]

if glib2 now links against dbus (and it seems at least one test does) then dbus 
will need to be added to the build deps of glib2 so that macports can work out 
the architecture matching needed to prevent this.

I can't see any indication that any of the installed glib2 files link against 
dbus, so it doesn't need to be a library dependency for glib2.

K

(PS - or alternatively tests can be disabled by default, and dbus added to the 
test deps, if someone wants that instead for purity. Makes things more 
complicated somewhat, but also more precise and pure in arch management).



> On Apr 16, 2023, at 4:26 PM, Richard L. Hamilton  wrote:
> 
>> 
>> Early MacBook Pro (13", mid 2010), High Sierra 10.13.6 (as far as it will 
>> go).
>> 
>> When doing my weekly port upgrade, it bombs out with:
>> 
>>--->  Building glib2 
>>Error: Failed to build glib2: command execution failed   
>>Error: See 
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/main.log
>>  for details.
>> 
>> I see a lot of warnings in main.log such as:
>> 
>>:info:build ld: warning: The i386 architecture is deprecated for macOS 
>> (remove from the Xcode build setting: ARCHS)
>> 
>> Is this some insidious attempt by Cupertino to force me to buy an M series?
> 
> Not insidious, Apple doesn't even know about it, and warnings are not errors 
> (although they may be treated as errors if the creator of the build procedure 
> - not necessarily the port maintainer - chooses to).
> 
> A library, almost certainly libdbus-1 (provided by the dbus port) does not 
> support i386 (32-bit) but only x86_64 (64-bit). I verified that with
> 
> sh-3.2$ nm /opt/local/lib/libdbus-1.dylib|grep _dbus_message_set_path
> 0001483c T _dbus_message_set_path
> 
> (hex may vary, but " T " should be there indicating the symbol is a defined 
> text (function name, usually)  symbol)
> 
> That may mean you tried to install glib2 with +universal but did not 
> previously install dbus with +universal. Or something like that which has 
> similar results.
> 
> Pretty sure that dbus CAN be installed universal, because I have it that way 
> on my Snow Leopard VM. Apparently I gave up on installing ports with 
> +universal as too much bother on Mojave even though it's the last OS that 
> supports i386, and of course I don't have i386 or universal builds on later 
> OSs that don't support that. (I don't have anything running High Sierra, so 
> that's as close as I can get to your situation)
> 
> Building dbus +universal will likely require that every port it depends on 
> (at least at runtime) is also built +universal, and it depends on quite a few 
> ports. No guarantee that one of them won't be a show-stopper for some reason 
> or other (although since I had it built on that Snow Leopard VM, it should 
> likely be possible, if very slow).
> 
> You really have to look more closely at the log, look for the first line 
> (other than the fetching of the downloads, which can fail on some locations 
> before succeeding on one of them, i.e. http 404 errors don't count) that has 
> the word "error" (case insensitive and followed by a colon to exclude 
> mentions of error handing routines and limit it to error messages). And then 
> look back a bit from there to see what failed.
> 
> In your case (with the "error:" in question and the prior reference to 
> -ldbus-1 highlighted in red):
> 
> :info:build [827/1188] /usr/bin/clang  -o gio/tests/gdbus-serialization 
> gio/tests/gdbus-serialization.p/gdbus-serialization.c.o 
> gio/tests/gdbus-serialization.p/gdbus-tests.c.o -L/opt/local/lib 
> -I/opt/local/include -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names 
> -Wl,-undefined,error -Wl,-headerpad_max_install_names -lresolv -bind_at_load 
> -arch i386 -pipe -Os -Wno-deprecated-declarations -arch i386 
> -Wl,-rpath,@loader_path/../../glib -Wl,-rpath,@loader_path/../../gmodule 
> -Wl,-rpath,@loader_path/../../gobject -Wl,-rpath,@loader_path/.. 
> -Wl,-rpath,/opt/local/lib glib/libglib-2.0.0.dylib 
> gmodule/libgmodule-2.0.0.dylib gobject/libgobject-2.0.0.dylib 
> gio/libgio-2.0.0.dylib -lintl -L/opt/local/lib -ldbus-1
> :info:build FAILED: gio/tests/gdbus-serialization 
> :info:build /usr/bin/clang  -o gio/tests/gdbus-serialization 
> gio/tests/gdbus-serialization.p/gdbus-serialization.c.o 
> gio/tests/gdbus-serialization.p/gdbus-tests.c.o -L/opt/local/lib 
> -I/opt/local/include -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names 
> -Wl,-undefined,error -Wl,-headerpad_max_install_names -lresolv -bind_at_load 
> -arch i386 -pipe -Os -Wno-deprecated-declarations -arch i386 
> -Wl,-rpath,@loader_path/../../glib -Wl,-rpath,@loader_path/../../gmodule 
> -Wl,-rpath,@loader_path/../../gobject -Wl,-rpath,@loader_path/.. 
> -Wl,-rpath,/opt/local/lib glib/libglib-2.0.0.dylib 
> gmodule/libgmodule-2.0.0.dylib gobject/libgobject-2.0.0.dylib 
> 

Re: compiling ArcticFox on 10.11 - atomic not found, cxx11

[Ken Cunningham]

$ cat atomic.cxx
#include 
int main(void) {
return (0);
}

$ clang++-mp-9.0 -stdlib=libstdc++ atomic.cxx
atomic.cxx:1:10: fatal error: 'atomic' file not found
#include 
^~~~
1 error generated.


$ clang++-mp-9.0 -stdlib=macports-libstdc++ atomic.cxx


h$ clang++-mp-9.0 -stdlib=libc++  atomic.cxx

[no subject]

[Ken Cunningham]

meson is now more picky about unrecognized arguments.

This will have to be removed, and then making sure it uses the right NM
might have to be done another way:

lt_cv_path_NM=/opt/local/bin/nm





> *info:configure meson: error: unrecognized arguments:
> */opt/local/var/macports/build/_Users_multix_code_LeopardPorts_x11_pango/pango/work/build
> :*info:configure Command failed:  cd
> *"/opt/local/var/macports/build/_Users_multix_code_LeopardPorts_x11_pango/pango/work/pango-1.48.9"
> && /opt/local/bin/meson setup --prefix=/opt/local -Dxft=disabled
> -Dintrospection=enabled lt_cv_path_NM=/opt/local/bin/nm
> /opt/local/var/macports/build/_Users_multix_code_LeopardPorts_x11_pango/pango/work/pango-1.48.9
> /opt/local/var/macports/build/_Users_multix_code_LeopardPorts_x11_pango/pango/work/build
>
>
> is 10.5 meson too old? can I somehow use a macports one? Maybe it is
> similar to the typical nm issue.
>
>

Re: MacBook broken GPU workarounds

[Ken Cunningham]

I disassembled my MacBookPro 2,1 and baked the motherboard in the oven for 8 
minutes at 350F (IIRC), supported on some pyramids of tinfoil.

It worked for another 1.5 years after that, but then died again and that was 
enough for me.

I removed all the useful parts from it and moved on, giving it an honourable 
grave. 

It worked from 2007 to 2021, so I had nothing much to complain about I felt.

If I was going to send it somewhere, I would have sent it to "dosdude" who 
seems to be the one who know the most about this at this point in time. For 
you, from Italy to the USA and back -- not very cost effective.

Ken

Re: Setting environment and support of older OS/arch

[Ken Cunningham]

You can also look into how to use pkgconfig and cmake to find needed libraries.

They can suffice for simpler header and library path additions, and often that 
might be all you need for a simpler project with just one or two things needed.

K

Re: Setting environment and support of older OS/arch

[Ken Cunningham]

If you are doing your own compilation using the compilers and libraries from 
MacPorts, you need to direct your build to use the specified tools, headers, 
and libraries.

You can look at what MacPorts sets up itself for each build for a clue, for 
example this is setup for a generic build of something on an arm64 system 
running Ventura. 

You'd tweak this for a system running some other system like Leopard or Tiger, 
of course -- you can't just use this one.

you need to export all these environment variables in the shell before you 
start running your configure or make steps, so perhaps you might preface each 
one with "export " and make a shell script of this, to make it easier.

--
CC='/usr/bin/clang'
CFLAGS='-pipe -Os 
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch arm64'
CPATH='/opt/local/include'
CPPFLAGS='-I/opt/local/include 
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk'
CXX='/usr/bin/clang++'
CXXFLAGS='-pipe -Os -stdlib=libc++ 
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch arm64'
DEVELOPER_DIR='/Library/Developer/CommandLineTools'
F90FLAGS='-pipe -Os -m64'
FCFLAGS='-pipe -Os -m64'
FFLAGS='-pipe -Os -m64'
INSTALL='/usr/bin/install -c'
LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names 
-Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch 
arm64'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='13.0'
OBJC='/usr/bin/clang'
OBJCFLAGS='-pipe -Os 
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch arm64'
OBJCXX='/usr/bin/clang++'
OBJCXXFLAGS='-pipe -Os -stdlib=libc++ 
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch arm64'
SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk'
--



Now you might rightly say this is harder than putting everything in /usr/local, 
and why did MacPorts put everything in /opt/local and make it so hard to use?

And there you would see the primary reason that homebrew came to exist, 10 or 
15 years ago.

But putting everything in /opt/local is actually defendable better in a number 
of ways, although does require a deeper level of understanding about what is 
doing on to make it work.

And don't even get me started about how to make MacPorts work with Xcode -- :>

Good luck, ask questions when you get stuck.

Ken

Re: libgcc11 failed build failed on macOS 13.0.1

[Ken Cunningham]

On Ventura arm64, libgcc11 is not part of the youtube-dl dependency tree. You 
can use:

port rdeps youtube-dl

so see what is on the tree.

I can install youtube-dl without any trouble.

% port -v installed youtube-dl
The following ports are currently installed:
  youtube-dl @2021.12.17_1+ffmpeg+python311 (active) requested_variants='' 
platform='darwin 22' archs='noarch' date='2023-02-12T08:36:26-0800'

and nothing related to gcc is installed in the process.

% port -v installed | grep active | grep gcc


Could you run:

port rdeps youtube-dl

and help us see what is calling in libgcc11 on your system?

Thanks,

Ken

Re: GIMP Quartz broken on 10.7, perhaps gtk

[Ken Cunningham]

I saw your bisecting in the relevant ticket.

https://trac.macports.org/ticket/65897 
<https://trac.macports.org/ticket/65897#comment:13>

Let’s keep all the discussion there — rather than here and there.

K

> On Jan 21, 2023, at 3:20 PM, Riccardo Mottola  
> wrote:
> 
> Hi,
> 
> On 2023-01-12 14:12:38 +0100 Ken Cunningham  
> wrote:
> 
>> My guess would be to look at harfbuzz…make sure our patches there still 
>> make sense, run the test suite. It can be touchy, different compilers can 
>> change test results, etc.
>> 
>> To disable one port in an overlay with minimal fuss, rename to Portfile to 
>> something else (I use Portfile.disabled), and portindex ignores it.
> 
> harfbuzz looks fine. I think the problem is pango, although librsvg is a pain 
> because it needs to be rebuilt, current versions check for pango and some 
> combinations did not work for me.
> I tried going back in time using old port files from git.
> 
> Then, I wne further brewing portfiles for intermediate versions, since we 
> jump directly from 1.42 to 1.48
> 
> 1) pango @1.42.4_3+quartz+x11 (active)
> 2) pango @1.43.0_0+quartz+x11
> 3) pango @1.46.0_0+quartz+x11
> 4) pango @1.48.9_0+quartz+x11
> 5) pango @1.48.10_0+quartz+x11
> 6) pango @1.50.3_0+quartz+x11
> 7) pango @1.50.7_0+quartz+x11
> 
> 1.42.4 works, 1.43 is already broken
> 
> GIMP should still use gtk2, so that's easier.
> 
> -- 
> Sent with GNUMail running on MacOS 10.7
> 

Re: GIMP Quartz broken on 10.7, perhaps gtk

[Ken Cunningham]

So here’s a very simple reproducer:

https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/examples/hello-world.c 
<https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/examples/hello-world.c>

I’m sure you know, but you build it on 10.7, for example, like this:

clang -g -O0  -o test `pkg-config --cflags --libs gtk+-3.0` hello-world.c

then you can run it, or load it into lldb (even on 10.7, works OK) and start 
debugging it.

If you want to also add debugging to gtk3, you would rebuild gtk3 with some 
modifications to the portfile to make debugging better, and “keep” the source 
code for tracing. Something like this in the gtk3 portfile would do it:

==
$ diff -u gnome/gtk3/Portfile `port file gtk3`
--- gnome/gtk3/Portfile 2022-09-10 15:42:40.0 -0700
+++ 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/gnome/gtk3/Portfile
  2023-01-16 21:36:02.0 -0800
@@ -63,6 +63,10 @@
 use_autoreconf  yes
 autoreconf.args -fvi
 
+
+configure.optflags-delete -Os -O0 -O1 -O2 -O3
+configure.optflags-append -g -O0
+
 # gtk3 +quartz uses instancetype which is not available
 # before approximately Xcode 4.6 (#49391)
 # if building +x11 blacklist comilers that do not support C11
@@ -111,6 +115,8 @@
 --disable-schemas-compile \
 gio_can_sniff=yes
 
+configure.args-append --enable-debug=yes
+
 build.args-append   V=1 \
 CPP_FOR_BUILD="${configure.cpp}"
 


and then to rebuild gtk3 with all the debugging and source left behind, you 
would do this, perhaps:

sudo port -f uninstall gtk3

(select the quartz variant to uninstall)

sudo port -v -s -k install gtk3 +quartz

and you’d then have a heavily debug-enabled gtk3 with all the source left 
behind, so you could step through the code with lldb and view the frame 
variables and hopefully steer you in the right direction.

My guess is the error is occurring somewhere in the pango/cairo/harfbuzz trio , 
so you might want to rebuild all those ports with full debugging enabled and 
with the source code left behind too, so you can trace those through as well.

Of course, upstream would be helpful. However, to ask them for help, we’d have 
to first upgrade/update our gtk3 port and make sure the error still happens 
(likely will). Also, have to survey all the patches macports adds to 
gtk3/glib2/pango/cairo/harfbuzz and make sure they are all defendable to 
upstream.

It’s not easy. I did some of this tonight, and I stepped through the code to 
see where the out of memory errors were originating, at least. They are 
originating, it seems to me, in the widget redraw code of gtk3, in the part 
that pertains to cairo I thought. But that is as far as I got.

As mentioned, the x11 version works nicely still, so the error is somewhere in 
the quartz backend, NS* code, etc, and to be honest, that stuff is hard to 
debug. The gtk3 interactive debugger unfortunately won’t open when gtk3 is 
built with the quartz backend (on 10.7 at least), so that is unfortunate.

Ken




> On Jan 12, 2023, at 5:12 AM, Ken Cunningham  
> wrote:
> 
> My guess would be to look at harfbuzz…make sure our patches there still make 
> sense, run the test suite. It can be touchy, different compilers can change 
> test results, etc.
> 
> To disable one port in an overlay with minimal fuss, rename to Portfile to 
> something else (I use Portfile.disabled), and portindex ignores it.
> 
> K
> 
>> On Jan 12, 2023, at 01:42, Riccardo Mottola  
>> wrote:
>> 
>> Hi!
>> 
>> I did further tests here.
>> In my local repository I pinned also a previous version of pango and 
>> pang-devel, but had difficulties "upgarding" to a previous version, how can 
>> it be done cleanly?
>> 
>> Then I thought of just activating some previous versions… I had a bit mess 
>> here and there when rev-upgrade , so I also set back librsvg.
>> 
>> The following ports are currently installed:
>> pango @1.42.4_3+quartz+x11 (active)
>> pango @1.50.7_0+quartz+x11
>> 
>> The following ports are currently installed:
>> harfbuzz @2.8.2_0
>> harfbuzz @3.4.0_0 (active)
>> harfbuzz @5.2.0_0
>> harfbuzz @5.3.1_0
>> 
>> The following ports are currently installed:
>> librsvg @2.40.20_4+quartz (active)
>> librsvg @2.54.5_0
>> 
>> 
>> I don't remember if I had to touch other stuff… how can I now? Is port 
>> installed enough?
>> 
>> port list outdated
>> Warning: The 'list' action only shows the currently available version of 
>> each port. To see installed versions, use the 'installed' action.
>> emacs-app  @28.2   editors/emacs
>> librsvg@2.54.5 graphics/librsvg
>> pango   

Re: GIMP Quartz broken on 10.7, perhaps gtk

[Ken Cunningham]

My guess would be to look at harfbuzz…make sure our patches there still make 
sense, run the test suite. It can be touchy, different compilers can change 
test results, etc.

To disable one port in an overlay with minimal fuss, rename to Portfile to 
something else (I use Portfile.disabled), and portindex ignores it.

K

> On Jan 12, 2023, at 01:42, Riccardo Mottola  
> wrote:
> 
> Hi!
> 
> I did further tests here.
> In my local repository I pinned also a previous version of pango and 
> pang-devel, but had difficulties "upgarding" to a previous version, how can 
> it be done cleanly?
> 
> Then I thought of just activating some previous versions… I had a bit mess 
> here and there when rev-upgrade , so I also set back librsvg.
> 
> The following ports are currently installed:
>  pango @1.42.4_3+quartz+x11 (active)
>  pango @1.50.7_0+quartz+x11
> 
> The following ports are currently installed:
>  harfbuzz @2.8.2_0
>  harfbuzz @3.4.0_0 (active)
>  harfbuzz @5.2.0_0
>  harfbuzz @5.3.1_0
> 
> The following ports are currently installed:
>  librsvg @2.40.20_4+quartz (active)
>  librsvg @2.54.5_0
> 
> 
> I don't remember if I had to touch other stuff… how can I now? Is port 
> installed enough?
> 
> port list outdated
> Warning: The 'list' action only shows the currently available version of each 
> port. To see installed versions, use the 'installed' action.
> emacs-app  @28.2   editors/emacs
> librsvg@2.54.5 graphics/librsvg
> pango  @1.50.3 x11/pango
> pango  @1.50.7 x11/pango
> 
> 
> emacs-app cannot be upgraded. harfbuzz here is not shown… So I don't think it 
> is perfect.
> 
> Anyway… I would think that the issue is between pango, harfbuzz and librsvg! 
> Since then recompiling current gimp… has a perfectly working gimp! yay! 
> 
> Riccardo
> 
> PS: suppose if I have pango and harfbuzz in my local port tree. I want to 
> test with current harfbuzz. How can I "hide" it, but keeping the rest of the 
> local port? Rename the directory? put a command in the portfile… or move the 
> port directory away to be in case put in back.
> 
> 
> 
> -- 
> Sent with GNUMail running on MacOS 10.7
> 

Re: GIMP Quartz broken on 10.7, perhaps gtk

[Ken Cunningham]

The default x11 installation of gimp works perfectly.

I know that is not the version you want, you want the +quartz version.

But there’s a data point, at least, and a likely clue as to where to look for 
the issue with font rendering.

Ken





> On Jan 8, 2023, at 2:24 PM, Ken Cunningham  
> wrote:
> 
> I see the same thing on a fresh gimp2 install +quartz on 10.7 (one very tiny 
> patch needed to gimp2 to change NULL -> 0 to keep clang-15 happy, otherwise a 
> no-touch build).
> 
> However, there is no text drawn on any gimp2 windows or dialog boxes, as you 
> noted.
> 
> Installing pan2 +quartz +gtk3, I see the same thing, no text anywhere, and 
> many messages about “drawing failure for widget XYZ: out of memory”.
> 
> So there is clearly something to fix. Perhaps every quartz gtk3 application 
> is broken on 10.7 (and some other systems? — not sure yet).
> 
> Reinstalling pan2 to build as +quartz against the default +gtk2 also shows no 
> text anywhere (but no out of memory errors are revealed in the terminal 
> window, which is probably just inferior default debugging).
> 
> I haven’t tested (as yet) the non-quartz versions of these ports.
> 
> I would write up the simplest possible gtk3 application that displays text, a 
> real “hello world” thing, and then start debugging from there.
> 
> Best,
> 
> Ken
> 

Re: GIMP Quartz broken on 10.7, perhaps gtk

[Ken Cunningham]

I see the same thing on a fresh gimp2 install +quartz on 10.7 (one very tiny 
patch needed to gimp2 to change NULL -> 0 to keep clang-15 happy, otherwise a 
no-touch build).

However, there is no text drawn on any gimp2 windows or dialog boxes, as you 
noted.

Installing pan2 +quartz +gtk3, I see the same thing, no text anywhere, and many 
messages about “drawing failure for widget XYZ: out of memory”.

So there is clearly something to fix. Perhaps every quartz gtk3 application is 
broken on 10.7 (and some other systems? — not sure yet).

Reinstalling pan2 to build as +quartz against the default +gtk2 also shows no 
text anywhere (but no out of memory errors are revealed in the terminal window, 
which is probably just inferior default debugging).

I haven’t tested (as yet) the non-quartz versions of these ports.

I would write up the simplest possible gtk3 application that displays text, a 
real “hello world” thing, and then start debugging from there.

Best,

Ken

Re: a2ps fails to install (compressed log attached)

[Ken Cunningham]

> On Dec 20, 2022, at 8:12 AM, Ken Cunningham  
> wrote:
> 
> , or we generate another port that provides Apple’s older makeinfo version 
> from Ventura.

Monterey I meant

Re: a2ps fails to install (compressed log attached)

[Ken Cunningham]

% uname -a
Darwin MacBookPro-2012 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:08:47 
PST 2022; root:xnu-8792.61.2~4/RELEASE_X86_64 x86_64

% ls -la /usr/bin/makeinfo
ls: /usr/bin/makeinfo: No such file or directory


The makeinfo in the makeinfo port was too new to build this, so once you change 
it to use that makeinfo again, it will likely still be broken.

Someone will need to fix it to work with the new makeinfo, or we generate 
another port that provides Apple’s older makeinfo version from Ventura.

> On Dec 20, 2022, at 7:11 AM, Richard L. Hamilton  wrote:
> 
> I have a Ventura VM (with Xcode and command line tools installed), and it’s 
> not there, although there’s a man page in the Monterey SDK for the command 
> line tools.
> 
>> On Dec 20, 2022, at 9:30 AM, Marc Wilson  wrote:
>> 
>> I don’t have a Ventura machine to check, but /usr/bin/makeinfo is certainly 
>> present in Monterey.
>> 
>> $ ll /usr/bin/makeinfo 
>> -rwxr-xr-x  1 root  wheel  611936 Dec  2 00:43 /usr/bin/makeinfo*
>> 
>> -- 
>> Marc Wilson
>> posgu...@gmail.com
> 
> 

Re: iInstall denemo failed due to failure to configure qt5-qtbase

[Ken Cunningham]

Oh, I’m sorry, you already did that. 

My apologies, I didn’t read that closely enough.

I don’t know for sure what is happening to you now then.

K



> On Oct 29, 2022, at 7:24 PM, Ken Cunningham  
> wrote:
> 
> Probably you need to go to the developer.apple.com 
> <http://developer.apple.com/> website and download Xcode 14.1 RC2 and the 
> latest command line tools, and install those.
> 
> Apple noted a last minute hiccup in Xcode that made them delay the final 
> Xcode 14.1 a bit, which is why Ventura is out but you can’t get the right 
> Xcode yet from the App Store.
> 
> Everyone is in the same boat, homebrew too — shouldn’t be long.
> 
> Ken
> 
> 
>> On Oct 29, 2022, at 4:56 PM, Kenneth Wolcott  
>> wrote:
>> 
>> So I downloaded and installed the XCode RC 2 and CL Tools R2..
>> 
>> Then
>> 
>> port diagnose
>> Error: The installed version of Xcode, none, is not supported by
>> MacPorts. For your currently installed system, the following versions
>> of Xcode are supported: 14.1
>> LaTeX: xcode-select --install
>> xcode-select: error: command line tools are already installed, use
>> "Software Update" in System Settings to install updates
>> 
>> What does this mean?
>> 
>> Ken Wolcott
>> 
>> On Sat, Oct 29, 2022 at 4:45 PM Kenneth Wolcott
>>  wrote:
>>> 
>>> Hi;
>>> 
>>>  Interesting note:
>>> 
>>> port diagnose
>>> Error: The installed version of Xcode, none, is not supported by
>>> MacPorts. For your currently installed system, the following versions
>>> of Xcode are supported: 14.1
>>> 
>>> So I'm installing XCode and CLI tools again..
>>> 
>>> Thanks,
>>> Ken Wolcott
>>> 
>>> On Sat, Oct 29, 2022 at 1:57 PM Kenneth Wolcott
>>>  wrote:
>>>> 
>>>> Thanks for the help; but still not working.
>>>> 
>>>> sudo port clean qt5-qtbase
>>>> sudo port -v -t install qt5-qtbase
>>>> 
>>>> failed.
>>>> 
>>>> sudo port -v -t clean denemo
>>>> sudo port -v -t install denemo
>>>> 
>>>> failed as above.
>>>> 
>>>> sudo port selfupdate
>>>> sudo port upgrade outdated
>>>> 
>>>> sudo port clean qt5-qtbase
>>>> sudo port clean denemo
>>>> sudo port -v -t install qt5-qtbase
>>>> 
>>>> failed as above.
>>>> 
>>>> Attached is the most recent log.
>>>> 
>>>> Thanks,
>>>> Ken Wolcott
>>>> 
>>>> On Sat, Oct 29, 2022 at 10:04 AM Ken Cunningham
>>>>  wrote:
>>>>> 
>>>>> should be fixed now, after you update
>>>>> 
>>>>> thx K
> 

Re: iInstall denemo failed due to failure to configure qt5-qtbase

[Ken Cunningham]

Probably you need to go to the developer.apple.com 
<http://developer.apple.com/> website and download Xcode 14.1 RC2 and the 
latest command line tools, and install those.

Apple noted a last minute hiccup in Xcode that made them delay the final Xcode 
14.1 a bit, which is why Ventura is out but you can’t get the right Xcode yet 
from the App Store.

Everyone is in the same boat, homebrew too — shouldn’t be long.

Ken


> On Oct 29, 2022, at 4:56 PM, Kenneth Wolcott  wrote:
> 
> So I downloaded and installed the XCode RC 2 and CL Tools R2..
> 
> Then
> 
> port diagnose
> Error: The installed version of Xcode, none, is not supported by
> MacPorts. For your currently installed system, the following versions
> of Xcode are supported: 14.1
> LaTeX: xcode-select --install
> xcode-select: error: command line tools are already installed, use
> "Software Update" in System Settings to install updates
> 
> What does this mean?
> 
> Ken Wolcott
> 
> On Sat, Oct 29, 2022 at 4:45 PM Kenneth Wolcott
>  wrote:
>> 
>> Hi;
>> 
>>  Interesting note:
>> 
>> port diagnose
>> Error: The installed version of Xcode, none, is not supported by
>> MacPorts. For your currently installed system, the following versions
>> of Xcode are supported: 14.1
>> 
>> So I'm installing XCode and CLI tools again..
>> 
>> Thanks,
>> Ken Wolcott
>> 
>> On Sat, Oct 29, 2022 at 1:57 PM Kenneth Wolcott
>>  wrote:
>>> 
>>> Thanks for the help; but still not working.
>>> 
>>> sudo port clean qt5-qtbase
>>> sudo port -v -t install qt5-qtbase
>>> 
>>> failed.
>>> 
>>> sudo port -v -t clean denemo
>>> sudo port -v -t install denemo
>>> 
>>> failed as above.
>>> 
>>> sudo port selfupdate
>>> sudo port upgrade outdated
>>> 
>>> sudo port clean qt5-qtbase
>>> sudo port clean denemo
>>> sudo port -v -t install qt5-qtbase
>>> 
>>> failed as above.
>>> 
>>> Attached is the most recent log.
>>> 
>>> Thanks,
>>> Ken Wolcott
>>> 
>>> On Sat, Oct 29, 2022 at 10:04 AM Ken Cunningham
>>>  wrote:
>>>> 
>>>> should be fixed now, after you update
>>>> 
>>>> thx K

Re: macports-users Digest, Vol 194, Issue 22 ==> py-jupyter won't install

[Ken Cunningham]

I just tried to install py-jupyter on a clean machine, and got the same error:

g-info/dependency_links.txt
Error: Failed to activate py310-jupyter: Image error: 
/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/__pycache__/jupyter.cpython-310.pyc
 is being used by the active py310-jupyter_core port.  Please deactivate this 
port first, or use 'port -f activate py310-jupyter' to force the activation.


so there is some kind of a problem with py-jupyter that needs fixing.

there doesn’t seem to be an open ticket for this, so that would be the thing to 
do, if you like.

K

Re: iInstall denemo failed due to failure to configure qt5-qtbase

[Ken Cunningham]

should be fixed now, after you update

thx K

Re: problems recompiling ports for Ventura

[Ken Cunningham]

> On Oct 28, 2022, at 8:16 PM, Andreas Skarlatoudis  wrote:
> 
> :notice:patch --->  Applying patches to aquaterm
> :info:patch --->  Applying no-NSMailDelivery.patch
> :debug:patch Environment:
> :debug:patch CC_PRINT_OPTIONS='YES'
> :debug:patch 
> CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqu


The new patch that fixes the build is this one:

project-copyfiles.patch

and I don’t see it being applied in your log, so your ports must be not updated 
fully.

So:

sudo port clean aquaterm
sudo port -v selfupdate
sudo port -v install aquaterm

Best,

Ken

Re: iInstall denemo failed due to failure to configure qt5-qtbase

[Ken Cunningham]

The qt5 issue is a pain, something as yet unexplained to do with xcrun not 
recognizing an SDK that is sitting right there.

please see the relevant ticket:

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

Re: problems recompiling ports for Ventura

[Ken Cunningham]

Aquaterm was fixed yesterday:

https://github.com/macports/macports-ports/commit/32c5c1e4a77f9a7437e74be6fb25551fd2e17e6e




k

Re: Cannot build graphene (fwd)

[Ken Cunningham]

somehow, you *are* compiling it +universal, clearly, or it wouldn’t be showing 
this isdue.

So clean it, then look through all your installed ports to see what is forcing 
it universal and get rid of that, assuming you don’t want it universal. It 
might be some port that only builds 32 bit that is forcing it universal on you.

to fix the universal build, the pc files have to be made to match. Either 
configure the conflicting differences off to match, or strip them predestroot 
if you can’t figure out how to configure them off.

K

Re: Cannot build DOSBOX

[Ken Cunningham]

use dosbox-x instead.

I added it to MP largely because it is 64bit and maintained actively. It’s been 
updated a number of times lately I see.

K

K

Re: What happens when a port fails to compile (+universal) and there is no maintainer?

[Ken Cunningham]

it builds OK universal on Monterey Intel:

% port -v installed jemalloc
The following ports are currently installed:
  jemalloc @5.3.0_2+universal (active) requested_variants='+universal' 
platform='darwin 21' archs='arm64 x86_64' date='2022-08-22T17:31:05-0700’


There are many combinations and permutations that can make strange things 
happen.

If someone else reproduces your universal build failure on an arm Mac, perhaps 
we can sort it out. Usually we do.

I don’t have an arm Mac, though, so will defer to someone who does.

Re: problem compiling libzzip (PPC, Sorbet Leopard)

[Ken Cunningham]

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

MacPorts method of doing this is to first build a list of all known compilers 
that a system can support, and put them in preferred order. This is done 
through the interaction of several bits of tcl code that can be described later 
if you are interested.

Then the Portfile will “blacklist” compilers or groups of compilers that are 
known not to work to build a given port.

MacPorts base then chooses the first compiler on the list of possible system 
compilers that is not blacklisted.

So — if libzzip will not build with gcc-4.2, then that compiler would be added 
to the port’s blacklisted compilers, with a statement like this in the Portfile:


compiler.blacklist-append gcc-4.2


or if all the 4-series gcc’s won’t work, this:

compiler.blacklist-append gcc-4.*

etc.

There are some other tricks that can be used, but for the purposes of how this 
is done, this is a reasonable way to start out. Chris mentioned a way to force 
a specific compiler, eg:

sudo port -v install libzzip configure.compiler=macports-gcc-7

a list of all the known compiler names is here

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

although not all of those are available on 10.5.x PPC of course (eg none of the 
clang compilers is available there).


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

In general, to keep things sane, MacPorts assumes that you have installed the 
last possible version of Xcode that the system can support.

There are a few exceptions to this rule just to keep you on your toes, of 
course, but none of the exceptions apply to Leopard.


> 
> Thanks in advance for helpful responses.
> 
> HG

As “Sorbet Leopard” is a non-standard release of MacOSX 10.5 Leopard for 
PowerPC with various modifications from the base system, MacPorts will not be 
able to support it. It is just too insane to try to keep these variant PPC 
systems sorted out, none of our common maintainers would use them, nobody would 
have ever thoroughly tested the tools out (gcc, cctools, ld64, etc) agains 
these systems, and so on.

So use them if you want, but please be fair and only open tickets against the 
official released versions of MacOSX system software. If we sense there is a 
variant system in play, we won’t be able to help you.

Of course, you are free to fork MacPorts and/or use your own overlay of 
Portfile fixes that work on your variant OS version! It is a free country 
(still, more or less) and you can do anything you danged well want to do!

Thx, K

Re: port:audacity up for grabs

[Ken Cunningham]

Rene, our loss.

Thanks so much for all that you have contributed over the years!

Ken

Re: Should I expect a +quartz variant to propagate to dependencies, and overrule existing variants?

[Ken Cunningham]

> Should I expect a +quartz variant to propagate to dependencies, and 
> overrule existing variants?

propagate to dependencies?

Yes. You demonstrated that already when you tried to install gimp +quartz and 
it passed that down to deps.

overrule existing variants?

No. 

If you already have a port installed with a certain variant, and then you try 
to install that port again with a conflicting variant (especially 
automatically), MacPorts doesn’t know what you really want to do exactly. So it 
asks you to deactivate or uninstall the one you have installed first, rather 
than doing it automatically for you.

Design choice, most would support, not everyone.

You can find the ports you have installed as x11 pretty easily (port -v 
installed | grep x11) and deactivate them, or just deactivate all your ports if 
you prefer and then install gimp +quartz and away you go.


You can add +quartz to “variants.conf” to make that a global default even if 
you forget setting if you like.

HTH,

K

Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?

[Ken Cunningham]

You can (for yourself) just change the github commit to HEAD and you’ll get the 
latest commit. Disable the checksum phase if you do that.

I often do that in some of my local portfile overlay repos for my own uses, but 
you can’t do that for macports in general as Ryan points out as the builds are 
not reproducible.

K

Re: A simple request (MkHexGrid) turned into ...

[Ken Cunningham]

> On May 14, 2022, at 1:21 PM, Mojca Miklavec  wrote:
> 

> See:
>
> https://github.com/macports/macports-ports/blob/master/multimedia/dav1d/Portfile#L47-L50
> suggesting that this looks like a workaround for a bug in the meson
> build system that has been ignored for more than a year:
>https://github.com/mesonbuild/meson/issues/8307
> and it looks as if this was only relevant for macOS <= 10.9.
> 

I fixed this about a year and a half ago here:

https://github.com/macports/macports-ports/commit/229bb3be0e72cdbc0fd2f97fc74350a50fa5538f
 



so dav1d no longer needs to add in a workaround. I think I mentioned that at 
the time, but the dav1d workaround had just been added so it was kept anyway, 
for no good reason.

Of course, I haven’t tried to build the port with the old compilers on 10.7 and 
10.8 since. It may still fail, for other reasons, as far as I know.

Best,

Ken

Re: A simple request (MkHexGrid) turned into ...

[Ken Cunningham]

It was a couple of years ago I fixed up ICU — so I don’t recall just now a 
specific python 2.7 reason.

Bootstrapping maybe. Sorry,

Ken



> On May 14, 2022, at 9:27 AM, Mojca Miklavec  wrote:
> 
> On Sat, 14 May 2022 at 16:20, Michael wrote:
>> 
>> So I thought I'd install a simple little hex map generator. Mkhexgrid.
>> 
>> Hasn't been updated in years, should be simple, right?
>> 
>> Three versions of Python (37, 38, and 39)
>> A full reinstall of X
>> 
>> I mean, I can sort-of understand perl, one python, and ssl -- maybe it 
>> needed to rebuild something, and needed updated ssh fetching and rebuilding 
>> the compilation environment.
>> 
>> But everything else? And three versions of python? And not just python 2 vs 
>> python 3.
> 
> For me python 2.7 sneaks in as a build dependency of ICU (that only
> affects users of the latest macOS).
> I see neither python 3.7 nor python 3.8 on the dependency list. Those
> could be side-effects of something that you have installed earlier
> which keeps depending on an older version of python. Or maybe you are
> using a different OS version that has slightly different dependencies.
> 
> The following patch for ICU that replaces python 2.7 with 3.10 seems
> to work for me:
> 
> --- a/devel/icu/Portfile
> +++ b/devel/icu/Portfile
> @@ -113,9 +113,9 @@ if {${subport} eq ${name} || ${subport} eq "${name}-lx"} {
> test.args VERBOSE=1
> 
> if {${os.platform} eq "darwin" && (${os.major} < 11 || ${os.major} > 20)} {
> - depends_build-append port:python27
> - license_noconflict python27
> - configure.python ${prefix}/bin/python2.7
> + depends_build-append port:python310
> + license_noconflict python310
> + configure.python ${prefix}/bin/python3.10
> }
> 
> if {${build_arch} eq "ppc" || ${build_arch} eq "ppc64"} {
> 
> This patch should probably be applied anyway.
> 
> (Ken: is there some Tiger-like reason to keep python 2.7 as a build
> dependency of ICU?)
> 
> You can check why you are getting weird dependency by running the
> following command:
>port rdeps mkhexgrid
> 
> Say, the reason why you need python 3.9 is because meson currently
> declares a dependency on python 3.9 and that should definitely be
> changed as well.
> There's an open pull request for meson from 2 days ago.
> 
>> I'm assuming that somewhere, some graphical library was being used that 
>> could output to X as well as to ascii/curses. I just have no idea what.
> 
> Yes, mkhexgrid depends on gd2 which depends on X11 by default. Try to
> run "port info gd2" or check
>https://ports.macports.org/port/gd2/details/
> 
> You can avoid the need to install x11 by installing "sudo port install
> gd2 -x11" before installing mkhexgrid.
> 
> All I can say is that the situation with multiple versions of
> python/perl/etc. could and should be improved.
> Whether or not the default variant to install gd2 with X11 support is
> something that I'm not competent to judge.
> 
> "port rdeps " will usually provide you enough information to
> figure out why some dependency is there.
> Sometimes it makes sense, sometimes it's something that could be improved.
> 
> Btw: you should usually update all your ports before installing a new port.
> It could happen that by installing a new port, one of the libraries (a
> dependency) will be upgraded, while another port that depends on that
> same library won't be updated and may stop working.
> 
> Mojca

Re: Replacement Options for Discontinued macOS Server

[Ken Cunningham]

I took an old, useless-for-macOS Intel system and installed Ubuntu 20.04 on it. 
A Core2 Duo with 2GB ram is fine for this.

letsencrypt manages all the certificate renewals automatically for all my ssl 
domains every 90 days or so. I installed it a few years ago and never thought 
about it again.

The web server, print server, file server, fax server using hylafax, media 
server, and mail server all work very easily. webmin is a fine GUI front end 
for most needs.

updates itself every few hours from ubuntu.

There are hundreds of walkthrus on the web for any problem you might have, and 
thousands of users doing the same thing.

haven’t bothered to look at configuring apple devices yet.

k

Re: What is up with perl5.26 on Snow Leo?

[Ken Cunningham]

> On Nov 27, 2021, at 8:09 PM, Ryan Schmidt  wrote:
> 
> On Nov 27, 2021, at 19:58, Ken Cunningham wrote:
> 
>>> Ok... the significance of this is...??
>> Well in your case, the significance of appears overwhelming — in that it is 
>> an excellent clue as to the cause of your problem, I believe.
>> 
>> ie - there is nothing wrong on your system, it is nothing you did, it is not 
>> your fault, indeed something has changed — all that kind of stuff.
>> 
>> So it is the starting point of sorting out a solution maybe, whatever the 
>> solution might be.
>> 
>> I think - on systems of a certain age, we leave the build compiler for perl 
>> as the build compiler, and just add a run dep on that compiler for perl.
> 
> The reasons for making the change were sound. I would not revert it or change 
> it. As I said in my previous message, the problem seems to be that the perl 
> build system is trying to compile something in the destroot phase. It should 
> compile everything in the build phase instead.
> 

Maybe - see the next commit after the one referenced — perhaps the answer lies 
within.

Re: What is up with perl5.26 on Snow Leo?

[Ken Cunningham]

> Ok... the significance of this is...??
Well in your case, the significance of appears overwhelming — in that it is an 
excellent clue as to the cause of your problem, I believe.

ie - there is nothing wrong on your system, it is nothing you did, it is not 
your fault, indeed something has changed — all that kind of stuff.

So it is the starting point of sorting out a solution maybe, whatever the 
solution might be.

I think - on systems of a certain age, we leave the build compiler for perl as 
the build compiler, and just add a run dep on that compiler for perl.

Maybe. I gave it literally just 60 seconds worth of thought, so perhaps (no 
doubt) you will come up with something better for us.

Ken

Re: What is up with perl5.26 on Snow Leo?

[Ken Cunningham]

all the perl ports were specifically changed to use /usr/bin/cc in the
commit below, but something in this plan seems to be not working out:

https://github.com/macports/macports-ports/commit/f35a2c53331234cc730b090b1b866d4b1702a747#diff-01ad5d115e4eb4db83effd528c2194cac034c159e11b68078f468daa1f282a7f

Re: multi-ask

[Ken Cunningham]

Yeah, I guess that website name is a little bit too close to "emasculation" for 
my memory to bring it forward :>

K

> On Nov 21, 2021, at 9:40 AM, chilli.names...@gmail.com wrote:
> 
> I think you meant
> 
> https://www.emaculation.com/forum/viewtopic.php?t=7361 
> 

Re: multi-ask

[Ken Cunningham]

When I last updated the basiliskii and sheepshaver ports I was still 
fairly new to macports and took them on as a challenge. They had some 
interesting wrinkles I was looking to understand.



At that time, both of them did not run well when built as 64-bit 
versions; the JIT code, that really makes them run quickly, did not work 
when built 64 bit, and the networking stack had not been fixed to build 
and run 64 bit. Of course, at that time, macOS supported i386, and we 
were (most of us) unaware that 32bit Intel support was about to disappear.



So the ports were set up to force both of them to build as 32bit 
versions, which worked. I allowed a +SixtyFour variant for people who 
were explorers to try out the 64bit build.



Because the GUI required the whole x11 infrastructure to run, and it was 
pointed out that most people would not want to have to build that all 
universal, I came up with a way to build the GUI separately. That way, 
it could be 64bit only, and save the x11 stack from endless universal 
building.



Things have changed; both basiliskii and sheepshaver have had their 64 
bit warts removed, and they do now work properly when built 64 (current 
versions). There are several forks, and one of the forks now is better 
than the upstream I used in 2017 I believe.



Both basiliskii and sheepshaver continue to work very well. I still use 
MacPort's 32 bit version all the time on my older 10.6 system, to run 
some older MacOS9 software I like to use. It works just great, and I 
don't think it ever needs to be updated, to be honest, although I have 
not rebuilt it in a while to see if anything has changed in the build 
supporting ports.



I recently downloaded a prebuilt version of both basiliskii and 
sheepshaver from the 'macemulation' website that is 64bit and runs on 
BigSur, and that works well too.



I have not tried to update the basiliskii and sheepshaver ports in 
MacPorts in recent years, although no doubt it could be done without too 
much trouble. Newer versions I note are using xcode to build, and that 
adds a layer of complexity, and makes builds on older systems harder.



Perhaps the two ports might be retired, and people sent to upstream 
sources to download prebuilt binaries instead. There are upstream 
versions available that run as far back as 10.6.8 I believe.

Re: mango linking question

[Ken Cunningham]

Nothing important, we think.

When we first started building ports with the buildbot using BigSur, we built 
with the system of the time which was BigSur 11.2, so some of the builds were 
marked with that system as a floor.

We later decided hat it would be better to build against the lowest BigSur, so 
changed the builds to be against 11.0, so as to be compatible with all BigSur 
versions.

Not everything has been rebuilt, so there is still some 11.2 labelled code in 
there.

Ken

(it is possible, actually, that someone might install some of that 11.2 code on 
a BigSur 11.0 or 11.1 system and something might not work right. That has not 
yet been reported, and not many are likely hanging back on < 11.2 any more, so 
we haven't gone through rebuilding it all. In due course, everything will get 
rebuilt and then this error should no longer appear. 

It is also possible that something good might happen if the port was built 
against - say - 11.6 that can't happen if the build is forced to be 11.0 
compatible. That also has not happened yet as far as we know, so we are 
watching for that at the moment).

K

> On Sep 30, 2021, at 11:27 AM, Langer, Stephen A. (Fed) via macports-users 
>  wrote:
> 
> Hi --
> 
> What do these messages mean, and do I need to worry about them?  They occur 
> when linking a program with clang++.
> 
> % /usr/bin/clang++ -L/opt/local/lib ... something.o ... -lpangocairo-1.0 
> -lpango-1.0 ... -o something.so
> 
> ld: warning: dylib (/opt/local/lib/libpangocairo-1.0.dylib) was built for 
> newer macOS version (11.2) than being linked (11.0)
> ld: warning: dylib (/opt/local/lib/libpango-1.0.dylib) was built for newer 
> macOS version (11.2) than being linked (11.0)
> 
> I'm using Big Sur 11.6 with Xcode 13.0.  Macports is up to date, and so is 
> pango.
> 
> % port installed pango
> The following ports are currently installed:
>  pango @1.42.4_3+quartz+x11 (active)
> 
> Thanks.
> -- Steve
> 

Re: What version of Xcode for which macOS ?

[Ken Cunningham]

One thing that may not be clear from our table is that in several cases the
buildbot (and therefore our recommended) Xcode has been held back from the
latest available version.

This was done to have an SDK version that matches the OS version.

This is somewhat problematic as the App store prompts to update it all the
time, so I suspect most users actually use the latest Xcode anyway.

K

On Monday, September 27, 2021, Christopher Jones 
wrote:

>
>
> > On 27 Sep 2021, at 8:49 am, Bjarne D Mathiesen 
> wrote:
> >
> > This thread led me to search for the relationships between
> > * Xcode version
> > * macOS / OS X version
> > and I couldn't find a table with these
> >
> > So far, I've come up with
> >
> > Mac OS X / mac OS  | Xcode
> > |
> > 10.4Tiger   | 2.4.1
> > 10.5Leopard | 3.0
> > 10.6Snow Leopard| 3.2.2
> > 10.7Lion| 4.3.3
> > 10.8Mountain Lion   | 5.1.1
> > 10.9Maverics| 6.2
> > 10.10   Yosemite| 7
> > 10.11   El Capitan  | 8.2
> > 10.12   Sierra  | 9.2
> > 10.13   High Sierra | 10.1
> > 10.14   Mojave  | 10.3
> > 10.15   Catalina| 12.4
> > 11  Big Sur | 13
> > 12  Montery |
> >
> > Supplements / correction etc are more than welcome
> >
> > I do think we really need to have this listed explicitly somewhere
>
>
> we already do
>
> https://trac.macports.org/wiki/XcodeVersionInfo
>
> >
> > --
> > Bjarne D Mathiesen
> > Korsør ; Danmark ; Europa
> > ---
> > denne besked er skrevet i et totalt M$-frit miljø
> > MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina
> > 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM
> > ATI Radeon RX 590 8 GB
>
>

Re: MacPorts for High Sierra?

[Ken Cunningham]

> On Aug 15, 2021, at 6:43 PM, Dave Horsfall  wrote:

> https://everymac.com/mac-answers/macos-11-big-sur-faq/macos-big-sur-macos-11-compatbility-list-system-requirements.html
> 
>System Requirements
> 
>In marketing and technical documentation and elsewhere, Apple
>specifies that macOS Big Sur runs on these Macs:
> 
>   MacBook (2015 and later)
>   MacBook Air (2013 and later)
>   MacBook Pro (Late 2013 and later)  <=
>   iMac Pro (2017 and later)
>   iMac (2014 and later)
>   Mac mini (2014 and later)
>   Mac Pro (2013 and later)
> 
>   Compared to the previous version of the macOS -- macOS
>   Catalina (10.15) -- macOS Big Sur (macOS 11) drops support
>   for the Mid-2012 MacBook Air; Mid-2012, Late 2012, and Early
>   2013 MacBook Pro; Late 2012, Early 2013, and Late 2013 iMac;
>   and Late 2012 Mac mini models.

Yes, that looks like a nice list of the hardware that runs BigSur, indeed.

For the systems that can run MacPorts, see this page:

https://www.macports.org/install.php#installing 


Best,

K

Re: MacPorts for High Sierra?

[Ken Cunningham]

> On Aug 15, 2021, at 6:25 PM, Dave Horsfall  wrote:
> 
> I had to upgrade this old MacBook Pro (mid 2010) from Sierra to High Sierra 
> to run some software that I needed, and now I find that MacPorts wants Big 
> Sur which this thing won't run (and I can't afford a new one).
> 
> So, is there an old version of MacPorts somewhere that runs on HS?
> 
> Thanks.
> 
> -- Dave

No — but there is a brand spanking new version of MacPorts that runs on High 
Sierra. I am in fact using it right at this second, and it works just great.

MacPorts doesn’t require BigSur; it runs on everything from Tiger PPC up.

Perhaps you didn’t find the right HS installer? Try this one:

https://github.com/macports/macports-base/releases/download/v2.7.1/MacPorts-2.7.1-10.13-HighSierra.pkg

K

Re: Building icu port on macos x tiger

[Ken Cunningham]

I'm going to start by saying that I have great respect for your willingness
to explore, and you clearly have some skills. Your contributions to
supporting the older systems on Tiger will be much appreciated over time.

I'm not 100% sure how changing this information in that library has solved
your issue, however.

The dyld in Tiger is usually able to handle jumps of up to 16MB in code --
I am not an expert, by any means, but you will see a patch in our ld64-97
port that fixed an issue where branch islands were not working properly.
One of the Apple engineers was involved in looking that over. It was a
simple typo.

I used the current libgcc7 / gcc7 / ld64-97 / dyld to build TenFourFox on
PPC and Intel on Tiger, and it has huge libraries with large offsets. In
that case, if you try to disable optimizations with a -O0, the branches can
be too far apart and the code won't link.

I'm saying all this to point out that I am certain that (in the general
sense) the dyld in Tiger can handle a 4K & 2K jump without trouble.

The library you changed the code on has been more or less the same for
years, and passes the bulk of the libgcc test suite correctly.

You do seem to have been able to load libxml2 using python3 once you made
that change in libgcc_s.1.dylib, I won't argue about that point.

Why that might have allowed the library to load, what it did to the
function of libgcc_s.1.dylib in general, whether libgcc_s.1.dylib even
works at all any longer, is an open question. Before we could make such a
change in the build of libgcc7, we'd clearly need to dive way deeper here
to see what is going on.

Once again, whatever is causing libxml2 to not be loadable in python3, I
suspect it will be something else in the end. Perhaps we might get an
independent verification from someone else on TIger PPC that they see the
same issue.

Glad to have you around, please keep contributing.

Ken


On Wed, Jun 30, 2021 at 12:21 AM brian  wrote:

> In case someone else runs into this and whatever, another way that I found
> to fix this issue was to hexedit /opt/lib/libgcc/libgcc_s.1.dylib as per:
>
> barf@tiger:~/lib/foo$ otool -f /opt/local/lib/libgcc/libgcc_s.1.dylib
> Fat headers
> fat_magic 0xcafebabe
> nfat_arch 1
> architecture 0
> cputype 7
> cpusubtype 3
> capabilities 0x0
> offset 4096
> size 99832
> align 2^12 (4096)
> barf@tiger:~/lib/foo$ otool -f /opt/local/lib/libgcc/libgcc_s.1.dylib.bak
> Fat headers
> fat_magic 0xcafebabe
> nfat_arch 1
> architecture 0
> cputype 7
> cpusubtype 3
> capabilities 0x0
> offset 2048
> size 99832
> align 2^11 (2048)
>
> and now the problem is solved
>
> barf@tiger:~/Documents$ python3
> Python 3.9.5 (default, Jun 13 2021, 23:36:56)
> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42
> 5666.3_16+boot on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import libxml2
> >>>
>
> without removing optimizations from icu. It appears that dyld in tiger
> doesn't like the offset and/or align value of 2048 (in the fat header) used
> when building libgcc_s.1.dylib from gcc7 port. 4096 makes it happier. So
> change the values and pad with zeros appropriately.
>
> On Mon, Jun 28, 2021 at 9:16 AM brian  wrote:
>
>> > So it is not likely going to be that the root problem is that icu is
>> built with incorrect optimization settings. I'm actually quite surprised
>> changing those fixed things for you, and have no idea why that
>> would happen.
>>
>> The idea was to adjust things so that for symbol lookup purposes it
>> didn't matter if the application/system was looking
>> /usr/lib/libgcc_s.1.dylib or  /opt/local/lib/libgcc/libgcc_s.1.dylib since
>> the symbols used would be in both (by explicitly not using ___divmoddi4
>> optimization during compilation).
>>
>> I'll see about sorting out where Trac is and recreating the issue as time
>> permits.
>>
>> Thanks.
>>
>> On Sun, Jun 27, 2021 at 12:46 PM Ken Cunningham <
>> ken.cunningham.web...@gmail.com> wrote:
>>
>>> Now here we have to make sure we are asking the right question.
>>>
>>> If your build of icu doesn't work at all, and every time you try to use
>>> something that is built against icu it fails with this error, then the
>>> problem must be with icu and we have to look there.
>>>
>>> If icu seems to work whenever you use it, passes the icu test suite
>>> (there is one), and it is only the build of whatever it is that you are
>>> trying to use it with that generates that python-related error, then you
>>> have to look at the python thing and see what

Re: Building icu port on macos x tiger

[Ken Cunningham]

Now here we have to make sure we are asking the right question.

If your build of icu doesn't work at all, and every time you try to use
something that is built against icu it fails with this error, then the
problem must be with icu and we have to look there.

If icu seems to work whenever you use it, passes the icu test suite (there
is one), and it is only the build of whatever it is that you are trying to
use it with that generates that python-related error, then you have to look
at the python thing and see what is going on. The error could be with that,
or with the build of python, or elsewhere.

Certain things set DYLD_LIBRARY_PATH and can totally hose you without you
having any idea what is going on.

So it is not likely going to be that the root problem is that icu is built
with incorrect optimization settings. I'm actually quite surprised changing
those fixed things for you, and have no idea why that would happen.

It is much more likely that something else is at play.

At the moment, I don't know if you are on PPC or Intel, and what it was you
were trying to build/run/install when the thing you were after failed.

So probably this is the point where you open a ticket in Trac about what
you were actually doing when the error occurred, and post up the full log.

There are many smart people here who can at least try to sort you out.
Almost none of them use Tiger, but that doesn't matter much, as they can
spot errors and issues when they see them.

On Sat, Jun 26, 2021 at 7:05 PM brian  wrote:

> You assume correctly regarding the build but I'm not sure I grok your
> suggested alternative for making it run properly. I have:
>
> barf@tiger:/opt/local/var/macports/sources/
> rsync.macports.org/macports/release/tarballs/ports$ otool -L
> /opt/local/lib/libicui18n.67.1.dylib
> /opt/local/lib/libicui18n.67.1.dylib:
> /opt/local/lib/libicui18n.67.dylib (compatibility version 67.0.0,
> current version 67.1.0)
> /opt/local/lib/libicuuc.67.dylib (compatibility version 67.0.0,
> current version 67.1.0)
> /opt/local/lib/libicudata.67.dylib (compatibility version 67.0.0,
> current version 67.1.0)
> /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version
> 7.0.0, current version 7.24.0)
> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
> version 1.0.0)
> /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version
> 1.0.0, current version 1.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 88.3.9)
> barf@tiger:/opt/local/var/macports/sources/
> rsync.macports.org/macports/release/tarballs/ports$ nm
> /usr/lib/libgcc_s.1.dylib | grep divmoddi
> /usr/lib/libgcc_s.1.dylib(_udivmoddi4_s.o):
> 90bd5b6d T ___udivmoddi4
> braf@tiger:/opt/local/var/macports/sources/
> rsync.macports.org/macports/release/tarballs/ports$ nm
> /opt/local/lib/libgcc/libgcc_s.1.dylib | grep divmoddi
> 4480 T ___divmoddi4
> 48b0 T ___udivmoddi4
> barf@tiger:/opt/local/var/macports/sources/
> rsync.macports.org/macports/release/tarballs/ports$ port installed
> ...
> gcc7 @7.5.0_2 (active)
> ...
> icu @67.1_4 (active)
> ...
>
> OS X Tiger seems to be looking in the wrong libgcc_s for this particular
> symbol. How would I force the OS to look in the right place instead of just
> adjusting the compiler to not use this optimization?
>
> Thanks.
>
> On Sat, Jun 26, 2021 at 7:12 PM Ken Cunningham <
> ken.cunningham.web...@gmail.com> wrote:
>
>> >
>> dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libxml2mod.so,
>>
>> > 2): Symbol not found: ___divmoddi4
>>   Referenced from: /opt/local/lib/libicui18n.67.dylib
>>
>> > resulting from the default build configuration of macports icu on Tiger?
>>
>>
>>
>> Assuming you built icu with gcc7 on Tiger, I suppose it is now expecting to 
>> find that symbol in libgcc:
>>
>>
>> https://github.com/atgreen/gcc/blob/master/libgcc/config/spu/divmodti4.c
>>
>>
>> You would have built icu with a newer gcc compiler to get c++11 support for 
>> icu, but you are probably now using an older version of the gcc compiler 
>> like apple-gcc42, and that doesn't have that symbol in libgcc.
>>
>>
>> So you have to force a newer gcc (specifically to get a newer libgcc), and 
>> it should be there.
>>
>>
>>

Re: Building icu port on macos x tiger

[Ken Cunningham]

>
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libxml2mod.so,

> 2): Symbol not found: ___divmoddi4
  Referenced from: /opt/local/lib/libicui18n.67.dylib

> resulting from the default build configuration of macports icu on Tiger?



Assuming you built icu with gcc7 on Tiger, I suppose it is now
expecting to find that symbol in libgcc:


https://github.com/atgreen/gcc/blob/master/libgcc/config/spu/divmodti4.c


You would have built icu with a newer gcc compiler to get c++11
support for icu, but you are probably now using an older version of
the gcc compiler like apple-gcc42, and that doesn't have that symbol
in libgcc.


So you have to force a newer gcc (specifically to get a newer libgcc),
and it should be there.

Re: unexpected warning from dylib

[Ken Cunningham]

> My MacOS version is fully up to date 11.4, and my Xcode is fully up to date 
> (12.5) and I’m seeing these warnings:
> 
> ld: warning: dylib (/opt/local/lib/libidn2.dylib) was built for newer macOS 
> version (11.3) than being linked (11.0)
> ld: warning: dylib (/opt/local/lib/libzstd.dylib) was built for newer macOS 
> version (11.3) than being linked (11.0)
> ld: warning: dylib (/opt/local/lib/libssl.dylib) was built for newer macOS 
> version (11.2) than being linked (11.0)
> ld: warning: dylib (/opt/local/lib/libcrypto.dylib) was built for newer macOS 
> version (11.2) than being linked (11.0)
> 
> 2 Questions:
> 1 - Why?
> 2 - How can I make them go away?

For a while the buildbot was building software with a deployment target of 
11.2, and sometimes 11.3.

Now the deployment target is 11.0. We think that is probably right, to cover 
all 11.x systems with one buildbot.

Some software from the buildbot that has a newer deployment target of 11.2 or 
11.3 will have to be rebuilt with a dep target of 11.0.

That means rev-bumping the software to make a new build on the buildbot, or 
rebuilding the software yourself on your machine.

In this case, you would run

“port provides /path/to/troubled/lib.dylib” with your libs above, and rebuild 
from source what needs rebuilding by running:

sudo port -v -s install my_troubled_port

and if you want to be really helpful, PR some revbumps too for everyone else.

Best,

Ken

Re: Why don't p5-* ports mark their dependencies?

[Ken Cunningham]

I think Bill perhaps then you really want to open a thread with the title:

“I would like to suggest we move MacPorts default perl to 5.30 now”.

And then let the conversation happen, and if the outcome is “Yes” then that 
will happen.

Or 5.32. Whatever you care to suggest.

But trying to fight against the current default recommended perl, whatever it 
is, is kind of a waste of precious time and effort.

Ken

Re: Why don't p5-* ports mark their dependencies?

[Ken Cunningham]

macports recommended perl is still 5.28

$ port info perl5
perl5 @5.28.3 (lang)
Sub-ports:perl5.16, perl5.18, perl5.20, perl5.22, perl5.24, 
perl5.26, perl5.28, perl5.30, perl5.32
Variants: perl5_26, [+]perl5_28, perl5_30


so that is supposed to be the default perl for everything, until such time as 
that is changed to perl 5.30.

So if you want perl 5.30 for everything, you will be fighting upstream at every 
turn.

Ken

Re: Error building "gq"

[Ken Cunningham]

> error: incomplete definition of type 'struct x509_st'

would most likely mean the software needs to either use the older openssl 1.0 
(via PG perhaps) or be updated to use the newer openssl 1.1 (look upstream or 
elsewhere for patches).

These build issues are best managed via tickets, of course.

k

Re: MacPorts 2.7.0 has been released

[Ken Cunningham]

my SnowLeopard macports-base built and installed just fine.

As Chris says, post up your config log and we might see the error.

Or — simpler perhaps -- just try to build any “hello_world.c” program at all 
with your llvm-gcc-4.2 compiler and you might find out how it is broken.

I seem to remember something about a bunch of symlinks you made from cctools 
things into macports cctools in the past (perhaps I recall wrong).

K

Re: Reclaim was not 'safe'

[Ken Cunningham]

> Isn't that just sudo port setrequested installed 

That’s what I’ve always done to avoid this, also having been burned by it once 
years ago:

sudo port setrequested installed
sudo port -v reclaim

K

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

[Ken Cunningham]

There is one issue with that.

qt5-qtcreator needs clang-10 on arm for it’s libraries (that is actually the 
only reason why I initially fixed clang-10 to work on arm64 in the first place).

qt5-qtcreator cannot (could not) use any newer clang when I checked six months 
ago.

So — we still need clang-10 on arm64 even if we don’t use it as a compiler 
there.

K



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

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

[Ken Cunningham]

Yes, gcc7 works down to 10.4, both PPC and Intel and is the primary compiler 
there.  I can see no need for openMPI to support any older gcc.

clang-3.3, clang-3.4, and clang-3.7 should not be used for anything other than 
bootstrapping to newer clangs now.


Ken

Re: Using macports-libcxx to build a non-MacPorts cmake project

[Ken Cunningham]

I you show me exactly what you’re trying to build and where the WIP sits, I 
would be happy to take a look for you if you like.

Ken



> On May 6, 2021, at 8:08 AM, wowfunha...@gmail.com  
> wrote:
> 
> Thanks Ken! Those cause the build to fail in the same way as before—which I'm 
> going to take to mean I was doing it right all along, and Dolphin just isn't 
> going to be amenable to building this way. My shared_mutex-free build mostly 
> works anyway.
> 
> 
> On May 3, 2021, at 5:46 PM, Ken Cunningham  <mailto:ken.cunningham.web...@gmail.com>> wrote:
> 
>> what you did actually might have worked, I think, ideally… too bad it didn’t.
>> 
>> Can you do this perhaps?
>> 
>> export CXXFLAGS="-nostdinc++ -I/opt/local/include/libcxx/v1” 
>> export LDFLAGS="-L/opt/local/lib/libcxx"
>> 
>> 
>> or maybe this: 
>> 
>> CXX=/path/to/clang-9.0 CXXFLAGS="-nostdinc++ -I/opt/local/include/libcxx/v1” 
>>  LDFLAGS="-L/opt/local/lib/libcxx” cmake ../path/to/source
>> 
>> 
>> or maybe:
>> 
>> CXX="/path/to/clang-9.0 -nostdinc++ -I/opt/local/include/libcxx/v1”  
>> LDFLAGS="-L/opt/local/lib/libcxx” cmake ../path/to/source
>> 
>> I really need to finish that simple shell script that is supposed to set up 
>> the environment like MacPorts does for you, but I will probably never get 
>> around to that…
>> 
>> Ken
>> 
> 

Re: Error: Failed to build source-highlight: command execution failed

[Ken Cunningham]

> That log shows that you are back at the original problem, whose proposed 
> solution was to force the use of a newer version of the clang compiler 
> by running these:

At least we can get source-highlight off this table, and then if there is some 
other problem with clang-9.0, fix that.

clang-9.0 was just revbumped, so perhaps that will lead to a rebuild for him of 
a new working version.

perhaps.

K

Re: Error: Failed to build source-highlight: command execution failed

[Ken Cunningham]

I believe this should be fixed now (fix works for me on 10.7).

please wait a bit for the commits to propagate through (couple of hours) and 
then try your build again and I hope this brings you success.

best,

K

Re: Issue compiling simple code with clang++-mp-11

[Ken Cunningham]

this should be fixed now, for clang-11 at least, courtesy of @landonf finding 
the relevant upstream commit in the llvm tree and backporting it to clang-11.

Ken

Re: Using macports-libcxx to build a non-MacPorts cmake project

[Ken Cunningham]

what you did actually might have worked, I think, ideally… too bad it didn’t.

Can you do this perhaps?

export CXXFLAGS="-nostdinc++ -I/opt/local/include/libcxx/v1” 
export LDFLAGS="-L/opt/local/lib/libcxx"


or maybe this: 

CXX=/path/to/clang-9.0 CXXFLAGS="-nostdinc++ -I/opt/local/include/libcxx/v1”  
LDFLAGS="-L/opt/local/lib/libcxx” cmake ../path/to/source


or maybe:

CXX="/path/to/clang-9.0 -nostdinc++ -I/opt/local/include/libcxx/v1”  
LDFLAGS="-L/opt/local/lib/libcxx” cmake ../path/to/source

I really need to finish that simple shell script that is supposed to set up the 
environment like MacPorts does for you, but I will probably never get around to 
that…

Ken

Re: Error: Failed to build source-highlight: command execution failed

[Ken Cunningham]

To hopefully solve your browser spinning-beachball problem at
developer.apple.com, the browsers-for-older-systems market has had a lot of
activity lately.

For 10.7 (and probably 10.7 to 10.9) the nicest, most capable one I have
seen lately is a legacy version of Chromium that seems to work really well
-- supports async/wait and all the needed protocols. Github works normally,
as do all the other websites. There is a minor window-resizing graphics
glitch that is not a problem for me -- just a brief flash.

Jonathan made a downloader/installer available that is nice:

https://jonathanalland.com/downloads/chromium-legacy-downloader.zip

I use it every day on 10.7.

Ken

Re: Installing universal binaries on Apple M1 using macports

[Ken Cunningham]

Thanks for that. Learned something new, that is really old.

otool has -arch support in it.

so you can examine different parts of your universal binary like this:


otool -l -arch arm64

otool -l arch x86_64


which is totally obvious in retrospect, but I just never thought of 
doing it before



Ken




On 2021-03-31 6:10 a.m., Sandeep Thakkar wrote:

Hi,

I installed postgresql13 the same way. I then copied the files to 
macOS Catalina and here is the output:


*on macOS Big Sur arm64:*
% sw_vers | grep ProductVersion
ProductVersion: 11.0.1

% otool -l /opt/local/lib/postgresql13/libpq.dylib| grep minos
    minos 11.0

% md5 /opt/local/lib/postgresql13/libpq.dylib
MD5 (/opt/local/lib/postgresql13/libpq.dylib) = 
b0bae706c59a99ddbb40bb6fe3e3ea66


*on macOS Catalina x86_64:*
$ sw_vers | grep ProductVersion
ProductVersion: 10.15.7

$ md5 /tmp/opt/local/lib/postgresql13/libpq.dylib
MD5 (/tmp/opt/local/lib/postgresql13/libpq.dylib) = 
b0bae706c59a99ddbb40bb6fe3e3ea66


$ otool -l /tmp/opt/local/lib/postgresql13/libpq.dylib | grep minos
     minos 10.14

So, it seems the build is fine. The otool is correctly returning the 
macosx-version-min for that Arch which seems fine.


Thank you for your responses and sorry for the noise.

On Wed, Mar 31, 2021 at 12:30 AM Ken Cunningham 
<mailto:ken.cunningham.web...@gmail.com>> wrote:



and the command I used is:
*% sudo port install llvm-10 +universal*

But, what I see is:
*% otool -l /opt/local/libexec/llvm-10/lib/libLLVM.dylib| grep "minos\|sdk"*
 minos 11.0
   sdk 11.1

The sdk version looks fine, but why the minos is 11.0? shouldn't it be
10.14 as expected? What am I missing?


Well, you’re the first person I know of who has tried this, but I get what 
you’re up to — here are my thoughts:

When you try to build things universal, it happens in one of two ways. 
Either MacOS can build it as universal “in one go” with multiple arch flags, or 
MacOS cannot build it like that and you need to build it twice, once with each 
arch, and lipo them together.

MacPorts does the automatic lipoing together using a mechanism set up in 
the “muniversal” PortGroup.

When you build llvm-10, it’s a “one go” multiarch build.

I don’t think that the compiler would know exactly what to do with a build 
line like this:

clang++ -arch arm64 -arch x86_64 -macosx-version-min=10.14 …

There is no way you can hope to build arm64 for a macosx-version-min of 
10.14 (arm64 requires a version min of 11.0 I imagine). So, it is quite 
possible that to be helpful, it ignores your macosx-version-min=10.14 as being 
a likely “mistake” and bumps your macosx-version-min to something reasonable, 
like minos 11.0.

If, however, you built it separately and lipo’d them together yourself (or 
using the muniversal PG) something might be built that has one 
macosx-version-min for arm64 and a different macosx-version-min for x86_64.

I would say — Yuk.

Are you sure you want to build this exactly? If you did want to build a 
univeral binary that runs on x86_64 from 10.14 up, and on arm64, you might well 
have to build them separately and lipo them together, either manually or using 
the muniversal PG to do it for you.

Best,

Ken



--
Sandeep Thakkar

Re: Installing universal binaries on Apple M1 using macports

[Ken Cunningham]

> and the command I used is:
> *% sudo port install llvm-10 +universal*
> 
> But, what I see is:
> *% otool -l /opt/local/libexec/llvm-10/lib/libLLVM.dylib| grep "minos\|sdk"*
> minos 11.0
>   sdk 11.1
> 
> The sdk version looks fine, but why the minos is 11.0? shouldn't it be
> 10.14 as expected? What am I missing?

Well, you’re the first person I know of who has tried this, but I get what 
you’re up to — here are my thoughts:

When you try to build things universal, it happens in one of two ways. Either 
MacOS can build it as universal “in one go” with multiple arch flags, or MacOS 
cannot build it like that and you need to build it twice, once with each arch, 
and lipo them together.

MacPorts does the automatic lipoing together using a mechanism set up in the 
“muniversal” PortGroup.

When you build llvm-10, it’s a “one go” multiarch build.

I don’t think that the compiler would know exactly what to do with a build line 
like this:

clang++ -arch arm64 -arch x86_64 -macosx-version-min=10.14 … 

There is no way you can hope to build arm64 for a macosx-version-min of 10.14 
(arm64 requires a version min of 11.0 I imagine). So, it is quite possible that 
to be helpful, it ignores your macosx-version-min=10.14 as being a likely 
“mistake” and bumps your macosx-version-min to something reasonable, like minos 
11.0.

If, however, you built it separately and lipo’d them together yourself (or 
using the muniversal PG) something might be built that has one 
macosx-version-min for arm64 and a different macosx-version-min for x86_64.

I would say — Yuk. 

Are you sure you want to build this exactly? If you did want to build a 
univeral binary that runs on x86_64 from 10.14 up, and on arm64, you might well 
have to build them separately and lipo them together, either manually or using 
the muniversal PG to do it for you.

Best,

Ken

Re: Class wxDisclosureNSButton is implemented in both … One of the two will be used. Which one is undefined.

[Ken Cunningham]

wxWidgets-3.0 on the buildbot was built back in January 
 when install_name_tool had a bug 
in it. That bug has since been fixed.


sudo port -f uninstall wxWidgets-3.0
sudo port -v -s install wxWidgets-3.0

should get you fixed up.

Someone might consider revbumping wxWidgets-3.0 at some point when they feel 
it’s a good time to do that.

Best,

Ken

Re: cMP w/ 256 GB RAM

[Ken Cunningham]

My own pair of classic MacPros are set up in a similar way. I find it a very 
impressive and flexible setup indeed.

I have the MacPros running the current BigSur, and they can multi-boot to 
10.15, 10.14, 10.6, and 10.5. The more powerful system also boots into 
Windows10, where the new FlightSim 2020 rules.

I run Parallels in one of the installations, and have all the systems 10.5 to 
11.3 installed that way, (and WIndows 95, 98, 2000, and Ubuntu 2020.04).

VirtualBox runs Tiger Intel and i386 Snow Leopard.

I’m sure Apple must look at my App Store profile and wonder what the heck is 
going on...

Ken

Re: Writing a Portfile for the Zig language / lld

[Ken Cunningham]

if you check out that PR and install that PR's clang-11, you'll get lld
with it.

Hope your zigging goes smoothly.

BTW, several other people are working on zig just today (free book come out
or something??). There is already a Portfile, and some are trying to update
it to the current release right now...

Best,

K

On Thursday, March 25, 2021,  wrote:

> 2021. 3. 26. 오전 6:07, Ken Cunningham  작성:
> >
> > People are invited to kick the tires on this PR.
> >
> > I put this lld addition to the clang-11 port together for some early
> testers <https://github.com/macports/macports-ports/pull/10404>
>
> Thanks for the quick addition! From gleaming the code I guess I can
> install clang to get lld together?
>
> I’ll be trying to write a Zig portfile as soon as I have time today :-)
>
> > feedback appreciated.
>
>

Re: Writing a Portfile for the Zig language / lld

[Ken Cunningham]

People are invited to kick the tires on this PR.

I put this lld addition to the clang-11 port together for some early testers 


feedback appreciated.

Writing a Portfile for the Zig language / lld

[Ken Cunningham]

lld would best be an addition to our existing llvm tree build, when added.
(libomp builds separately for historical reasons going back many years, but
that should be folded in too at some point.)

It's not particularly difficult to add to our llvm build, as I mentioned
yesterday. But it's not a good choice for a first Portfile attempt either.

Up to now we had no reason for lld as MacOS uses ld64. I don't know if
llvm's lld has had any significant use at all so far on MacOS, or what
warts or changed functionality it might bring to the table, and issues it
might raise. I assume someday it was meant to replace ld64, but no idea
when.

But Zig does seem to actually use the headers and libs of lld, so as of
your ticket yesterday there is a reason to add it.

I'll add it over the next few days...there's a process to go through given
our broad system support.

K

clang++ and libc++

[Ken Cunningham]

I undertook some further refinements and put together a port for this.

The "macports-libcxx" port will install the needed libc++ libraries and the
matching headers, with the needed minor tweak to disable the availability
test you ran across. The port notes explain how to use it, and there is
more info here about how it works, possible issues you might see, and such:

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

Can't make any promises, but I know it does work in at least some cases
(actually all I tried so far) to allow newer libc++ features on older
systems, for example running the most recent mkvtoolnix (which uses many
new c++ features) back as far as 10.11 at least.

MacPorts offers quite robust "best-effort" older systems support, and large
part of that is toolchain support, which is an interest of mine; you may
this helps with that.

K

Re: Forcing python39 on M1

[Ken Cunningham]

> Having heard that python39 is the only one (so far) to compile natively on 
> M1, I’m trying to force the python ports I use to python39

Hello Peter,

FYI, an arm64 version of python38 appears to be available:

http://packages.macports.org/python38/python38-3.8.8_0.darwin_20.arm64.tbz2

and is “green” on the ports review page:

https://ports.macports.org/port/python38/summary


The ports.macports.org page can be misleading at times, unfortunately, as it 
will show “green” if the port has been blocked from building even if it can’t 
be built, which is no doubt confusing to people at times and there is (I 
believe) a ticket about that somewhere.

The packages.macports.org site is pretty reliable, although to be 100% certain, 
you do need to actually install the port and examine it with “file” or “arch” 
or similar.

And the fact that the arm64 python38 exists doesn’t necessarily mean a 
universal python38 exists for x86_64/arm64 or can be built. It might or might 
not.

So there are some caveats to the presence of the python38 file there on 
packages, but it is there.

Best,

Ken

Re: Apple notarisation process - LC_VERSION_MIN_MACOSX

[Ken Cunningham]

Both versions of the load command are still in use.

The cutoff for which load command gets used appears to be based on the 
deployment target that has been set. The clang driver (and ld64) then uses the 
right one, depending on that.

A deployment target of 10.14+ will set LC_BUILD_VERSION.
A deployment target of 10.13 or less will set LC_VERSION_MIN_MACOSX.

I would imagine that the App store might use the same criteria for examining 
your submission, and enforce those rules.

So (inference) if you are building something using MacPorts on a newer system 
to have a deployment target that is older (for this issue, 10.13 or less) you 
need to set that deployment target for everything you would use.

MacPorts does allow you to do that, setting an older deployment target, in 
macports.conf. And then yes, you would have to build everything from source to 
have that set correctly. Probably best to have a separate macports installation 
in a different prefix for that.

Please ask further if you have any other questions about this.

Best,

Ken





Evidence:

% cat libweakfunc.c
#include 

void
weakfunc(void)
{
puts("I am a weak function. ");
}


11.2:
% clang -mmacosx-version-min=11.2 -dynamiclib libweakfunc.c -o libweakfunc.dylib
% otool -l libweakfunc.dylib | grep -A 4 -B 3 LC_BUILD_VERSION
 cmdsize 24
uuid 9B13A902-DABE-3376-B6F0-CF3049B0A66C
Load command 9
  cmd LC_BUILD_VERSION
  cmdsize 32
 platform 1
minos 11.2
  sdk 10.15.6
% otool -l libweakfunc.dylib | grep -A 4 -B 3 LC_VERSION_MIN_MACOSX


10.14:
% clang -mmacosx-version-min=10.14 -dynamiclib libweakfunc.c -o 
libweakfunc.dylib
% otool -l libweakfunc.dylib | grep -A 4 -B 3 LC_BUILD_VERSION  
 
 cmdsize 24
uuid 46E2E497-E5CC-3254-8B2F-56A355EE8BBD
Load command 8
  cmd LC_BUILD_VERSION
  cmdsize 32
 platform 1
minos 10.14
  sdk 10.15.6
% otool -l libweakfunc.dylib | grep -A 4 -B 3 LC_VERSION_MIN_MACOSX  


10.13:
% clang -mmacosx-version-min=10.13 -dynamiclib libweakfunc.c -o 
libweakfunc.dylib
% otool -l libweakfunc.dylib | grep -A 4 -B 3 LC_BUILD_VERSION  
 
% otool -l libweakfunc.dylib | grep -A 4 -B 3 LC_VERSION_MIN_MACOSX 
 
 cmdsize 24
uuid 070BAEA2-4139-31F8-8A56-762F0E6122E2
Load command 8
  cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.13
  sdk 10.15.6
Load command 9


10.6:
% clang -mmacosx-version-min=10.6 -dynamiclib libweakfunc.c -o libweakfunc.dylib
% otool -l libweakfunc.dylib | grep -A 4 -B 3 LC_BUILD_VERSION  
% otool -l libweakfunc.dylib | grep -A 4 -B 3 LC_VERSION_MIN_MACOSX 
 cmdsize 24
uuid 9FB0F27C-55C3-3E76-87B4-FBDABDDFA38E
Load command 8
  cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.6
  sdk 10.15.6
Load command 9


and testing just MACOSX_DEPLOYMENT_TARGET without setting the command line 
parameter:

% export MACOSX_DEPLOYMENT_TARGET=10.13
% clang -dynamiclib libweakfunc.c -o libweakfunc.dylib 
% otool -l libweakfunc.dylib | grep -A 4 -B 3 LC_BUILD_VERSION 
% otool -l libweakfunc.dylib | grep -A 4 -B 3 LC_VERSION_MIN_MACOSX
 cmdsize 24
uuid 070BAEA2-4139-31F8-8A56-762F0E6122E2
Load command 8
  cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.13
  sdk 10.15.6
Load command 9

Re: Apple notarisation process - LC_VERSION_MIN_MACOSX

[Ken Cunningham]

Back to the OP, he reports his submissions of MacPorts-built libraries were
rejected due to lack of the titular define, which we see no longer exists.

So sorting that out is for Apple, it would seem.

Nothing I can fix in ld64 or suggest in compile args, anyway, so nothing it
would seem we can do here.

K



On Friday, March 5, 2021, Rainer Müller  wrote:

> On 05/03/2021 04.43, Ken Cunningham wrote:
> > Apple is not using LC_VERSION_MIN_MACOSX any longer, as at least one
> helpful
> > person pointed out. So — we will never “fix” the problem of this not
> being
> > added, as it is — gone, it appears.
> >
> > See https://developer.apple.com/forums/thread/127450
> > <https://developer.apple.com/forums/thread/127450> and other links.
>
> There was a separate load command for the minimum version of each platform:
>  - LC_VERSION_MIN_MACOSX
>  - LC_VERSION_MIN_IPHONEOS
>  - LC_VERSION_MIN_WATCHOS
>  - LC_VERSION_MIN_TVOS
> They have been replaced with LC_BUILD_VERSION, which encodes both the
> platform
> and the minimum required version.
>
> If your binary does not have LC_VERSION_MIN_MACOSX, it will have
> LC_BUILD_VERSION instead. This is the same information, just encoded
> differently. You should be able to decode this with `otool -l`.
>
> Rainer
>

Re: Apple notarisation process - LC_VERSION_MIN_MACOSX

[Ken Cunningham]

> On Mar 3, 2021, at 11:50 AM, Ken Cunningham  
> wrote:
> The LC_VERSION_MIN_MACOSX issue is interesting.
> 
> There is lots of code in ld64 that appears designed to add this, and to fall 
> back on the DEPLOYMENT_TARGET to set it if it's not on the command line, and 
> to handle mismatches between the DEP target and the command line.
> 
> And yet I too can't see that chunk being added to dylibs either using xcode 
> ld64 or ld64-latest, whether building from source or downloaded from the 
> buildbot.
> 
> Something is amiss -- not sure it is a MacPorts issue, exactly, at this 
> moment. I await inspiration or insight...
> 
> K



Apple is not using LC_VERSION_MIN_MACOSX any longer, as at least one helpful 
person pointed out. So — we will never “fix” the problem of this not being 
added, as it is — gone, it appears.

See https://developer.apple.com/forums/thread/127450 
<https://developer.apple.com/forums/thread/127450> and other links.

What we should do, or not do, to have the libraries in MacPorts acceptable to 
the App Store, if there is anything that can or should be done in fact, is not 
clear to me from that link.

Best,

Ken

Fwd: Apple notarisation process - LC_VERSION_MIN_MACOSX

[Ken Cunningham]

sent this to the dev list due to finger slip on ipad buttons...

-- Forwarded message --
From: *Ken Cunningham* 
Date: Wednesday, March 3, 2021
Subject: Apple notarisation process - LC_VERSION_MIN_MACOSX
To: macports-dev 


We really should have MacPorts libs be utilizable by projects that want to
put them on the App Store or use them any way they want to use them, if at
all possible.

The LC_VERSION_MIN_MACOSX issue is interesting.

There is lots of code in ld64 that appears designed to add this, and to
fall back on the DEPLOYMENT_TARGET to set it if it's not on the command
line, and to handle mismatches between the DEP target and the command line.

And yet I too can't see that chunk being added to dylibs either using xcode
ld64 or ld64-latest, whether building from source or downloaded from the
buildbot.

Something is amiss -- not sure it is a MacPorts issue, exactly, at this
moment. I await inspiration or insight...

K

re: clang++ and libc++

[Ken Cunningham]

As of clang-11, the most current libc++ is installed tucked away in the
llvm-11 libs dir.

There is both a dylib (rpathed) and a static libc++ there.

I set this up for now for people like you to use for exactly this. You will
have to force it (DYLD_LIBRARY_PATH, possibly static link it, or some other
way).

It's new. Please feel free to let me know how it works for you.

Ken
 (maintainer of toolchains - clang and libc++, cctools, ld64, tapi - on
MacPorts)

Re: Building Clang 8/9 in El Capitan

[Ken Cunningham]

typo, of course. I meant

compiler.cxx_standard 2017
compiler.thread_local_storage yes

I'm typing this in TenFourFox right now on Tiger ;>

K



On Sat, Feb 13, 2021 at 3:25 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> To try to make bootstrapping clang and llvm as workable as possible, the
> compilers that can build them are carefully tested and the portfile tweaked
> to manage each one. Sometimes the compilers seem to build them, but the
> products don't work properly. Sometimes they don't build at all.
>
> MacPorts base has some "broad strokes" compiler settings for thread_local,
> c++11, c++17, etc -- but these are designed to make it as easy as possible
> for Portfile authors to select compilers that are sure to work with their
> software. For example, there is an array of compilers that support varying
> amounts of c++17 between clang 5 and clang 9, and the matching Xcode system
> clangs. If we just used the "broad stroke" compiler selection in MacPorts
> base, we would indeed exclude a whole bunch of clang compilers that might
> well (and do) work to build a given version of clang. In so doing, that
> would make bootstrapping more complicated in many ways.
>
> So, in the clang-8.0 Portfile for example we have a selection of
> hand-tuned blacklisting, started by Jeremy way-back-when, and then
> extensively tweaked by me afterwards. We (I) tried to cover every
> situation, but using non-default (or non-common) Xcode installs on the
> midrange macOS systems between 10.8 and 10.12 is really complicated. I'm
> usually happy to test each and every default compiler setup on those
> systems, and I just don't have VMs set up for non-default situations.
>
> When a user comes along with a new report of a combination that doesn't
> work, I'm happy to tweak the blacklisting, if it is a reliable report on a
> well-set-up system where the Xcode matchest the CLTs and the SDK is right
> and the log is clear. I have done that before, and I"m happy to do that
> again.
>
> The current blacklisting in clang-8.0 looks like this:
> {{{
> # llvm-3.5 and later requires a C++11 runtime
> # Xcode 4.3's clang (318.x) fails per
> https://trac.macports.org/ticket/44161
> # Xcode 4.5's clang (421.11.66) fails due to
> http://llvm.org/bugs/show_bug.cgi?id=20184
> # Xcode 4.6.3's clang (425.0.28) fails due to
> http://trac.macports.org/ticket/46897
> # Xcode 4.6.3's clang (425.0.28) fails due to
> https://llvm.org/bugs/show_bug.cgi?id=30384
> # Xcode 5.1's clang (clang-503.0.40) has codegen issues (resulting
> compiler crashes)
> # Xcode 6.2's clang (600.0.57) fails due to
> https://llvm.org/bugs/show_bug.cgi?id=25753
> compiler.blacklist *gcc* {clang < 602}
>
> # clang older than 3.5 fail due to
> https://llvm.org/bugs/show_bug.cgi?id=25753
> # new llvms build with clang-3.4 but have codegen issues resulting
> compiler crashes
> compiler.blacklist-append macports-clang-3.3 macports-clang-3.4
>
> # Override the normal compiler fallback list entirely since we have
> # such specific requirements.
> compiler.fallback   clang
>
> # 3.7 is already needed to bootstrap cmake, so is a good last resort
> # when the system clang is too old.
> if {${os.platform} eq "darwin" && ${os.major} < 18} {
> compiler.fallback-append macports-clang-3.7
> }
>
> if {${subport} eq "lldb-${llvm_version}"} {
> # Xcode 6.4's clang (602.0.53) fails to build lldb with 'thread-local
> storage is not supported for the current target'
> compiler.blacklist-append {clang < 700}
> }
> }}}
>
> So you can see, we are really trying to allow the maximum number of
> working compilers and taking aggressive steps to do so.
>
> I could easily just say
> {{{
> compiler.cxx_standard 2018
> compielr.thread_local_storage yes
> }}}
> and delete all that and forget about it.
>
> I have _no idea_ what kind of wreckage that would throw into our already
> delicate hand-tuned compiler selection and to be honest I'm not overly
> interested to spend three weeks figuring that all out for each clang
> version, when what we have now (except for occasional user setups) has
> worked exceedingly well, I would think.
>
> So work with me here, and please don't try to make this even harder than
> it already is by upending what amounts to many hours of work first by
> Jeremy and then by me to make this work properly.
>
> Ken
>
> On Sat, Feb 13, 2021 at 2:35 AM Ryan Schmidt 
> wrote:
>
>>
>>
>> On Feb 13, 2021, at 03:42, Ken Cunningham wrote:
>>
>> > Thread local includes __thread, Thread_local, and thread_local.
>> >
>> > The compilers that support them are all differe

Re: Building Clang 8/9 in El Capitan

[Ken Cunningham]

To try to make bootstrapping clang and llvm as workable as possible, the
compilers that can build them are carefully tested and the portfile tweaked
to manage each one. Sometimes the compilers seem to build them, but the
products don't work properly. Sometimes they don't build at all.

MacPorts base has some "broad strokes" compiler settings for thread_local,
c++11, c++17, etc -- but these are designed to make it as easy as possible
for Portfile authors to select compilers that are sure to work with their
software. For example, there is an array of compilers that support varying
amounts of c++17 between clang 5 and clang 9, and the matching Xcode system
clangs. If we just used the "broad stroke" compiler selection in MacPorts
base, we would indeed exclude a whole bunch of clang compilers that might
well (and do) work to build a given version of clang. In so doing, that
would make bootstrapping more complicated in many ways.

So, in the clang-8.0 Portfile for example we have a selection of hand-tuned
blacklisting, started by Jeremy way-back-when, and then extensively tweaked
by me afterwards. We (I) tried to cover every situation, but using
non-default (or non-common) Xcode installs on the midrange macOS systems
between 10.8 and 10.12 is really complicated. I'm usually happy to test
each and every default compiler setup on those systems, and I just don't
have VMs set up for non-default situations.

When a user comes along with a new report of a combination that doesn't
work, I'm happy to tweak the blacklisting, if it is a reliable report on a
well-set-up system where the Xcode matchest the CLTs and the SDK is right
and the log is clear. I have done that before, and I"m happy to do that
again.

The current blacklisting in clang-8.0 looks like this:
{{{
# llvm-3.5 and later requires a C++11 runtime
# Xcode 4.3's clang (318.x) fails per https://trac.macports.org/ticket/44161
# Xcode 4.5's clang (421.11.66) fails due to
http://llvm.org/bugs/show_bug.cgi?id=20184
# Xcode 4.6.3's clang (425.0.28) fails due to
http://trac.macports.org/ticket/46897
# Xcode 4.6.3's clang (425.0.28) fails due to
https://llvm.org/bugs/show_bug.cgi?id=30384
# Xcode 5.1's clang (clang-503.0.40) has codegen issues (resulting compiler
crashes)
# Xcode 6.2's clang (600.0.57) fails due to
https://llvm.org/bugs/show_bug.cgi?id=25753
compiler.blacklist *gcc* {clang < 602}

# clang older than 3.5 fail due to
https://llvm.org/bugs/show_bug.cgi?id=25753
# new llvms build with clang-3.4 but have codegen issues resulting compiler
crashes
compiler.blacklist-append macports-clang-3.3 macports-clang-3.4

# Override the normal compiler fallback list entirely since we have
# such specific requirements.
compiler.fallback   clang

# 3.7 is already needed to bootstrap cmake, so is a good last resort
# when the system clang is too old.
if {${os.platform} eq "darwin" && ${os.major} < 18} {
compiler.fallback-append macports-clang-3.7
}

if {${subport} eq "lldb-${llvm_version}"} {
# Xcode 6.4's clang (602.0.53) fails to build lldb with 'thread-local
storage is not supported for the current target'
compiler.blacklist-append {clang < 700}
}
}}}

So you can see, we are really trying to allow the maximum number of working
compilers and taking aggressive steps to do so.

I could easily just say
{{{
compiler.cxx_standard 2018
compielr.thread_local_storage yes
}}}
and delete all that and forget about it.

I have _no idea_ what kind of wreckage that would throw into our already
delicate hand-tuned compiler selection and to be honest I'm not overly
interested to spend three weeks figuring that all out for each clang
version, when what we have now (except for occasional user setups) has
worked exceedingly well, I would think.

So work with me here, and please don't try to make this even harder than it
already is by upending what amounts to many hours of work first by Jeremy
and then by me to make this work properly.

Ken

On Sat, Feb 13, 2021 at 2:35 AM Ryan Schmidt 
wrote:

>
>
> On Feb 13, 2021, at 03:42, Ken Cunningham wrote:
>
> > Thread local includes __thread, Thread_local, and thread_local.
> >
> > The compilers that support them are all different.
> >
> > To make it easy for people to not think about it much, especially when
> you’re not talking about bootstrapping compiler, etc, MacPorts base just
> treats them all the same.
> >
> > The system clang on 10.7 supports thread_local storage.
> >
> > But base excludes it because it doesn’t support the “thread_local”
> keyword.
> >
> > And 100 more complicated examples I could explain further to you if you
> are interested in learning more about it.
>
> Ok, so it sounds like "compiler.thread_local_storage yes" might in some
> circumstances exclude a compiler that would have been able to build the
> code. I guess when this 

Re: Building Clang 8/9 in El Capitan

[Ken Cunningham]

> On Feb 13, 2021, at 1:27 AM, Ryan Schmidt  wrote:
> 
> 
> I would consider it unreasonable to ask users to be aware of the existence of 
> our buildbot infrastructure or what versions of Xcode we have installed on 
> the buildbot workers and to ask them to duplicate it.
> 
> I didn't mention that I have Xcode 8.2.1 on the 10.11 buildbot worker in 
> order to suggest that the user should duplicate it. Rather I mentioned it as 
> a way to explain why we could build it and he currently cannot.
> 
> Users should feel free to install any version of Xcode that is compatible 
> with their OS version. Most users will probably choose the latest compatible 
> version.


> 
> It is fine if not all ports can be built with all Xcode versions, though 
> where possible we should accommodate any compatible Xcode version, such as by 
> using the compiler_blacklist_versions portgroup to blacklist incompatible 
> Xcode clang versions or helpers like compiler.thread_local_storage that 
> abstract away the knowledge of which clang versions support which features. 
> As a last resort, a port could print an error if it cannot build with the 
> currently installed Xcode and could advise the user on which version would be 
> acceptable. I created the xcodeversion portgroup to help you emit such an 
> error message.
> 


> I'm not sure what you mean by "compiler.thread_local_storage yes" being 
> "unpredictable". It should very predictably restrict the list of acceptable 
> compilers to those that support thread-local storage, with the exception of 
> the bug that currently exists when compiler.cxx_standard is set greater than 
> 2011 which will be fixed in the next version of MacPorts. If you do not 
> require thread-local storage on 10.6, then you can enclose the directive in a 
> conditional that excludes 10.6.


Thread local includes __thread, Thread_local, and thread_local.

The compilers that support them are all different.

To make it easy for people to not think about it much, especially when you’re 
not talking about bootstrapping compiler, etc, MacPorts base just treats them 
all the same.

The system clang on 10.7 supports thread_local storage.

But base excludes it because it doesn’t support the “thread_local” keyword.

And 100 more complicated examples I could explain further to you if you are 
interested in learning more about it.

K

Re: Building Clang 8/9 in El Capitan

[Ken Cunningham]

I would suggest you install Xcode 8.2.1 to match the buildbots.


Don’t forget that in almost all cases, MacPorts will use the SDK installed in 
“/“ when building software. That SDK is the 10.11 SDK, so it is the one that 
matches your system, and is the one you want. Virtually all standard “open 
source software” will use that SDK in “/“ on that system.

The only time that the SDK in Xcode (or the CLTs) is used is if certain 
software, usually building with Xcode, forces that SDK to be used over the 
objections of MacPorts (eg qt5, clang’s compiler_rt, etc).

But - I submit - in those cases, you are likely to be OK, because that software 
more than likely “knows what to do”.


So - for maximum happiness, and maximum compatibility, I suggest you duplicate 
the BuildBot setup we use as a reference platform, and install Xcode 8.2.1 like 
Ryan did.


I can’t see that I am going to change the already very complicated Portfiles 
that we set up to build clang-11 all the way back to 10.6 (and some clangs 
earlier) for what are non-reference systems.

It sounds simple to add: 

compiler.thread_local_storage yes

but it is just not true that that compiler is always needed. That line in 
MacPorts forces a whole chain of events that we don’t want to rehash, with very 
unpredictable results. For example, clang-8.0 builds perfectly well on MacOSX 
10.6 using a compiler that does not support thread_local storage, because we 
have worked around that to match the buildbot reference platform.

So — we already go to great lengths to support older systems, but I don’t think 
it’s too much to ask that users set up their older systems in a consistent way 
to the buildbots we have.

Best,

Ken

Re: Building Clang 8/9 in El Capitan

[Ken Cunningham]

Both clang-8.0 and clang-9.0 having been building properly for us on the 
buildbots and (when I last did it) locally for me, on ElCap.

See  and the one for 
clang-8.0.

But your logic is flawed about why you want it, as no clang version provides a 
macOS SDK, those come with either XCode or the Command Line Tools which you 
install separately from Apple.

If you have a build error with clang 8 or 9, open a ticket and include your 
log, and we'll what might be wrong.

Bes;t

Ken

Re: stdlib.h compilation error for macports gcc9.

[Ken Cunningham]

Our fix changed the baked-in gcc SDK reference from using the 
MacOSX11.x  and above  to MacOSX.sdk. that fixes a number of broken 
systems, but not all it appears.



Perhaps we should find a way to broaden that down to including 
MacOSX10.15+ as well, if Catalina is going to be using the MacOSX11.x SDK.



Luckily it appears our previous fix was not responsible for this -- just 
not broad enough to fix even more issues people have.



And -- baking the SDK into gcc at all is just a pain. It should just use 
SDKROOT and it was supposed to do that after Iain's fixes.



Ken

Re: how to use MacPorts libraries in an Xcode project using the Xcode GUI -- anyone?

[Ken Cunningham]

Thanks for taking the time to explain that.

I will try it out on a few Xcode versions.

We might do well to put this into a wki page or a short screen-capture video.

People seem highly likely to me to need to know how to do this soon if not 
already now, building things with Xcode using universal libraries arm64/Intel 
that MacPorts can provide.

If we get this working as smoothly as it hopefully will, we should link to it 
prominently from the very front page of MacPorts.org <http://macports.org/>.



Ken




> On Jan 29, 2021, at 1:17 PM, Andrew Udvare  wrote:
> 
> 
> 
>> On 2021-01-29, at 12:40, Ken Cunningham  
>> wrote:
>> 
>> I was working on an Xcode project in the Xcode GUI the other day (Apple's 
>> ld64-530) and needed various parts  that I know MacPorts supplies.
>> 
>> 
>> But it is not simple or intuitive to know how to add headers and libraries 
>> from MacPorts to an Xcode project, I found.
>> 
>> 
>> I did see how to add header search paths (that was not trivially easy to 
>> find, but could be found), but I had to add "/opt/local/include" which 
>> brought in everything from MacPorts, rather than just the bit I wanted. And 
>> then there are the libraries, and then the install_names will be all wrong.
>> 
> You should have /opt/local/include as one of the header search paths if you 
> intend to link with a dylib that is in /opt/local/lib. But then you must also 
> have the correct rpath in the binary too.
>> 
>> So, as I was working through this I thought -- in 20 years, this must have 
>> come up many times -- where is the wiki page on how to do this? And -- there 
>> must be many people out there who use Xcode all day long who know how to 
>> make this work smoothly much better than I do.
>> 
>> 
>> Does anyone have the recipe for happy use of MacPorts headers and libraries 
>> in an Xcode GUI project?
> 
> You can add /opt/local/Library/Frameworks as one of the Framework search 
> paths.
> 
> Not required but you should have /opt/local/lib as a library lookup path.
> 
> These last two are not required if you link only in the following way:
> 
> When you go to the project settings, you can click on 'Build Phases' and then 
> under 'Link Binary With Libraries', click the + button and add frameworks 
> from /opt/local/Library/Frameworks and dylibs from /opt/local/lib. In the 
> dialog, on the bottom left, choose Add Other then Add Files. Then hit 
> Command+Shift+G and type /opt/local. Browse to find the library 
> (dylib)/framework you want to add.
> 
> The resulting binary should have commands similar to (otool -l):
> 
> Load command 36
>  cmd LC_RPATH
>  cmdsize 48
> path /opt/local/Library/Frameworks (offset 12)
> 
> For any directly linked framework:
> 
> Load command 33
>  cmd LC_LOAD_DYLIB
>  cmdsize 64
> name @rpath/Commandant.framework/Commandant (offset 24)
>   time stamp 2 Wed Dec 31 19:00:02 1969
>  current version 1.0.0
> compatibility version 1.0.0
> 
> And possibly:
> 
> Load command 77
>  cmd LC_RPATH
>  cmdsize 32
> path /opt/local/lib (offset 12)
> 
> I've patched many projects to use frameworks from MacPorts, most recently 
> mas: https://github.com/Tatsh/ports/tree/master/sysutils/mas
> 
> Andrew

how to use MacPorts libraries in an Xcode project using the Xcode GUI -- anyone?

[Ken Cunningham]

I was working on an Xcode project in the Xcode GUI the other day 
(Apple's ld64-530) and needed various parts  that I know MacPorts supplies.



But it is not simple or intuitive to know how to add headers and 
libraries from MacPorts to an Xcode project, I found.



I did see how to add header search paths (that was not trivially easy to 
find, but could be found), but I had to add "/opt/local/include" which 
brought in everything from MacPorts, rather than just the bit I wanted. 
And then there are the libraries, and then the install_names will be all 
wrong.



So, as I was working through this I thought -- in 20 years, this must 
have come up many times -- where is the wiki page on how to do this? And 
-- there must be many people out there who use Xcode all day long who 
know how to make this work smoothly much better than I do.



Does anyone have the recipe for happy use of MacPorts headers and 
libraries in an Xcode GUI project?



With +universal here again, and MacPorts the only game in town for it, 
it would be great if people knew how to make it work easily.



Best,


Ken

Re: [workaround] 10.6.8 & mysql57

[Ken Cunningham]

ah, I just noticed that I fixed mysql56, but not mysql57 it appears.

hopefully the fix is as simple as mysql56 was.

K

Re: [workaround] 10.6.8 & mysql57

[Ken Cunningham]

looks like they moved that /usr/bin/libtool command from the previous file it 
was in, to here:

cmake/merge_archives.cmake.in
109:COMMAND /usr/bin/libtool -static -o ${TARGET_LOC} ${LIB_LOCATIONS}


most likely, just have to change the target of the reinplace in the Portfile.


Look, sure — you can symlink all of the cctools from /opt/local/bin/ into 
/usr/bin and into the SDKs in /Developer/usr/bin

From time to time, I admit I have done that to get out of a tight jam, but it 
is fragile, and you will find that things break and don’t build as expected 
that way, and then it might be hard to debug because you won’t know what’s 
going on exactly.

To manage one build, then revert, on your own system, is one thing. To set your 
system up that way and leave it like that, and recommend it to others as a 
general principle — well, that’s another.


I’ll fix it. Thanks for the heads up that it had broken.

Ken

Re: [workaround] 10.6.8 & mysql57

[Ken Cunningham]

Hey, I fixed that properly here 


if it doesn’t work for you, let me know.

no need to overwrite all your /usr/bin stuff and cause who-knows-what damage…

Ken