Re: OpenJDK: need little help with ObjC

[Ken Cunningham]

For reference, I threw some extra pool management into glib2 to stop messages 
exactly like that here:

https://github.com/macports/macports-ports/blob/master/devel/glib2/files/patch-glib2-findfolders-before-Lion.diff


perhaps adding some into openjdk would help. A bit of trial and error might be 
required.

K


> On Jul 16, 2024, at 7:44 AM, Ken Cunningham  
> wrote:
> 
> The usual equivalent older construct is this:
> 
> 
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> {
> 
> }
> [pool drain];
> 
> 
> which (AFAIK) does exactly the same thing as:
> 
> @autoreleasepool
> {
> 
> }
> 
> but just a little less beautifully.
> 
> Now the commit you referenced has this older construct still in place. But I 
> didn't look at the current source code that you are compiling to see what it 
> has.
> 
> Ken
> 
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> { } [pool drain];
>> On Jul 16, 2024, at 7:17 AM, Sergey Fedorov  wrote:
>> 
>> On Tue, Jul 16, 2024 at 6:19 PM Saagar Jha  wrote:
>> I’m guessing that since the block runs elsewhere there isn’t an 
>> autoreleasepool for it anymore. You can probably fix this by wrapping the 
>> call to JavaMain in @autoreleasepool {}?
>> Saagar Jha
>> 
>> This syntax is not supported by GCC, we need to use a standard ObjC somehow.
>> 
>>> 
>>> On Jul 10, 2024, at 02:47, Riccardo Mottola via macports-dev 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> Sergio Had wrote:
>>>> I have finally built the thing and it works, from looks of things, but I 
>>>> get a message on startup:
>>>> 36-25% 
>>>> /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_java_openjdk8/openjdk8/work/jdk8u-jdk8u372-ga/build/openjdk8/images/j2sdk-image/bin/java
>>>>  -version
>>>> 2024-07-09 18:34:10.587 java[13785:1903] *** __NSAutoreleaseNoPool(): 
>>>> Object 0x5d12e50 of class NSCFDictionary autoreleased with no pool in 
>>>> place - just leaking
>>>> 2024-07-09 18:34:10.590 java[13785:1903] *** __NSAutoreleaseNoPool(): 
>>>> Object 0x5d13310 of class NSCFData autoreleased with no pool in place - 
>>>> just leaking
>>>> openjdk version "1.8.0_372"
>>>> OpenJDK Runtime Environment (build 1.8.0_372-root_2024_07_09_15_56-b00)
>>>> OpenJDK Zero VM (build 25.372-b00, interpreted mode)
>>>> 
>>>> This seems to be related to the code, which upstream has switched to block 
>>>> syntax (it does not build with GCC), so I had to use its earlier version.
>>>> From commit message it seems upstream also had this startup issue:
>>>> https://github.com/openjdk/jdk8u/commit/c29d997ca180ba5d812df7745c668cfc906be20b
>>> 
>>> the message tells you that you are using NS* objects without an Autorelease 
>>> Pool. It will cause issues, but "should work", so your app should run.
>>> I notice what they appear to be CoreFoundation bridge object. You should 
>>> try to track where they come from, maybe put a breakpoint and stacktrace.
>>> 
>>> The snipped seen in the commit looks trivial, no nsblocks needed and has an 
>>> fresh ARP allocated, so I think the issue is elsewhere.
>>> 
>>> Riccardo
>> 
> 

Re: OpenJDK: need little help with ObjC

[Ken Cunningham]

The usual equivalent older construct is this:


NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
{

}
[pool drain];


which (AFAIK) does exactly the same thing as:

@autoreleasepool
{

}

but just a little less beautifully.

Now the commit you referenced has this older construct still in place. But I 
didn't look at the current source code that you are compiling to see what it 
has.

Ken

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
{ } [pool drain];
> On Jul 16, 2024, at 7:17 AM, Sergey Fedorov  wrote:
> 
> On Tue, Jul 16, 2024 at 6:19 PM Saagar Jha  wrote:
> I’m guessing that since the block runs elsewhere there isn’t an 
> autoreleasepool for it anymore. You can probably fix this by wrapping the 
> call to JavaMain in @autoreleasepool {}?
> Saagar Jha
> 
> This syntax is not supported by GCC, we need to use a standard ObjC somehow.
>  
>> 
>> On Jul 10, 2024, at 02:47, Riccardo Mottola via macports-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> Sergio Had wrote:
>>> I have finally built the thing and it works, from looks of things, but I 
>>> get a message on startup:
>>> 36-25% 
>>> /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_java_openjdk8/openjdk8/work/jdk8u-jdk8u372-ga/build/openjdk8/images/j2sdk-image/bin/java
>>>  -version
>>> 2024-07-09 18:34:10.587 java[13785:1903] *** __NSAutoreleaseNoPool(): 
>>> Object 0x5d12e50 of class NSCFDictionary autoreleased with no pool in place 
>>> - just leaking
>>> 2024-07-09 18:34:10.590 java[13785:1903] *** __NSAutoreleaseNoPool(): 
>>> Object 0x5d13310 of class NSCFData autoreleased with no pool in place - 
>>> just leaking
>>> openjdk version "1.8.0_372"
>>> OpenJDK Runtime Environment (build 1.8.0_372-root_2024_07_09_15_56-b00)
>>> OpenJDK Zero VM (build 25.372-b00, interpreted mode)
>>> 
>>> This seems to be related to the code, which upstream has switched to block 
>>> syntax (it does not build with GCC), so I had to use its earlier version.
>>> From commit message it seems upstream also had this startup issue:
>>> https://github.com/openjdk/jdk8u/commit/c29d997ca180ba5d812df7745c668cfc906be20b
>> 
>> the message tells you that you are using NS* objects without an Autorelease 
>> Pool. It will cause issues, but "should work", so your app should run.
>> I notice what they appear to be CoreFoundation bridge object. You should try 
>> to track where they come from, maybe put a breakpoint and stacktrace.
>> 
>> The snipped seen in the commit looks trivial, no nsblocks needed and has an 
>> fresh ARP allocated, so I think the issue is elsewhere.
>> 
>> Riccardo
> 

Re: paging the macports devs about NSObject between Lion and Mountain Lion

[Ken Cunningham]

Well -- I can take your word for it, and be of no help ...  or you can show us 
the exact link line, with -Wl,-lobjc added to it, and the failure.



Ken


> On Jun 10, 2024, at 9:19 AM, Gagan Sidhu  wrote:
> 
> the output is no different with the -lobjc, which is why i said with or 
> without lobjc
> 
> it’s the exact same as below.
> 
> Thanks,
> Gagan
> 
>> On Jun 10, 2024, at 10:17 AM, Ken Cunningham 
>> mailto:ken.cunningham.web...@gmail.com>> 
>> wrote:
>> 
>> Yes but I still don't see -lobjc on your link line...
>> 
>> K
>> 
>> 
>> 
>>> On Jun 10, 2024, at 9:15 AM, Gagan Sidhu via macports-dev 
>>> mailto:macports-dev@lists.macports.org>> 
>>> wrote:
>>> 
>>> oh does the list parse out indented comments? if so my apologies!
>>> 
>>> the original error is this:
>>> 
>>> GagansMacPro:updater Gagan$ /opt/local/bin/ccache /opt/local/bin/clang++ 
>>> -isysroot /Users/Gagan/.mozbuild/MacOSX14.4.sdk -objc 
>>> -mmacosx-version-min=10.7 -stdlib=libc++ -o 
>>> ../../../../dist/bin/org.mozilla.updater -fstack-protector-strong 
>>> -fno-sized-deallocation -fno-aligned-new -fno-exceptions -fPIC -fno-rtti 
>>> -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno 
>>> -pthread -gdwarf-4 -fno-omit-frame-pointer -funwind-tables 
>>> -Wl,@/Users/Gagan/Downloads/mozilla-unified/obj-x86_64-apple-darwin18.7.0/toolkit/mozapps/update/updater/org_mozilla_updater.list
>>> -fuse-ld=lld -fstack-protector-strong 
>>> -Wl,-rpath,@executable_path/../Frameworks/UpdateSettings.framework 
>>> -sectcreate __TEXT __info_plist 
>>> /Users/Gagan/Downloads/mozilla-unified/obj-x86_64-apple-darwin18.7.0/dist/bin/Info.plist
>>>  -sectcreate __TEXT __launchd_plist 
>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/Launchd.plist
>>>   ../../../../build/pure_virtual/libpure_virtual.a 
>>> -Wl,-rpath,@executable_path ../../../../dist/bin/UpdateSettings -framework 
>>> Security -framework Cocoa -framework SystemConfiguration
>>> ld64.lld: error: undefined symbol: OBJC_CLASS_$_NSObject
>>>>>> referenced by 
>>>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>>>>>> launchchild_osx.o:(symbol 
>>>>>> OBJC_CLASS_$_ElevatedUpdateServer+0x8)
>>>>>> referenced by 
>>>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/progressui_osx.mm
>>>>>> progressui_osx.o:(symbol OBJC_CLASS_$_UpdaterUI+0x8)
>>> 
>>> ld64.lld: error: undefined symbol: OBJC_METACLASS_$_NSObject
>>>>>> referenced by 
>>>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>>>>>> launchchild_osx.o:(symbol 
>>>>>> OBJC_METACLASS_$_ElevatedUpdateServer+0x8)
>>>>>> referenced by 
>>>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>>>>>> launchchild_osx.o:(symbol 
>>>>>> OBJC_METACLASS_$_ElevatedUpdateServer+0x0)
>>>>>> referenced by 
>>>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/progressui_osx.mm
>>>>>> progressui_osx.o:(symbol OBJC_METACLASS_$_UpdaterUI+0x8)
>>>>>> referenced 1 more times
>>> 
>>> 
>>> with or without -lobjc
>>> 
>>> Thanks,
>>> Gagan
>>> 
>>>> On Jun 10, 2024, at 10:14 AM, Ken Cunningham 
>>>> mailto:ken.cunningham.web...@gmail.com>> 
>>>> wrote:
>>>> 
>>>> I can't see lobjc on the link line.
>>>> 
>>>> Could you show us a failed link with it there?
>>>> 
>>>> Thx
>>>> 
>>>> 
>>>> 
>>>>> On Jun 10, 2024, at 8:51 AM, Gagan Sidhu via macports-dev 
>>>>> >>>> <mailto:macports-dev@lists.macports.org>> wrote:
>>>>> 
>>>>> 
>>>>>> GagansMacPro:updater Gagan$ /opt/local/bin/ccache /opt/local/bin/clang++ 
>>>>>> -isysroot /Users/Gagan/.mozbuild/MacOSX14.4.sdk 
>>>>>> -mmacosx-version-min=10.7 -stdlib=libc++ -o 
>>>>>> ../../../../dist/bin/org.mozilla.updater -fstack-protector-strong 
>>>>>> -fno-sized-deallocation -fno-aligned-new 

Re: paging the macports devs about NSObject between Lion and Mountain Lion

[Ken Cunningham]

Yes but I still don't see -lobjc on your link line...

K



> On Jun 10, 2024, at 9:15 AM, Gagan Sidhu via macports-dev 
>  wrote:
> 
> oh does the list parse out indented comments? if so my apologies!
> 
> the original error is this:
> 
> GagansMacPro:updater Gagan$ /opt/local/bin/ccache /opt/local/bin/clang++ 
> -isysroot /Users/Gagan/.mozbuild/MacOSX14.4.sdk -objc 
> -mmacosx-version-min=10.7 -stdlib=libc++ -o 
> ../../../../dist/bin/org.mozilla.updater -fstack-protector-strong 
> -fno-sized-deallocation -fno-aligned-new -fno-exceptions -fPIC -fno-rtti 
> -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread 
> -gdwarf-4 -fno-omit-frame-pointer -funwind-tables 
> -Wl,@/Users/Gagan/Downloads/mozilla-unified/obj-x86_64-apple-darwin18.7.0/toolkit/mozapps/update/updater/org_mozilla_updater.list
> -fuse-ld=lld -fstack-protector-strong 
> -Wl,-rpath,@executable_path/../Frameworks/UpdateSettings.framework 
> -sectcreate __TEXT __info_plist 
> /Users/Gagan/Downloads/mozilla-unified/obj-x86_64-apple-darwin18.7.0/dist/bin/Info.plist
>  -sectcreate __TEXT __launchd_plist 
> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/Launchd.plist
>   ../../../../build/pure_virtual/libpure_virtual.a 
> -Wl,-rpath,@executable_path ../../../../dist/bin/UpdateSettings -framework 
> Security -framework Cocoa -framework SystemConfiguration
> ld64.lld: error: undefined symbol: OBJC_CLASS_$_NSObject
>>>> referenced by 
>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>>>>  launchchild_osx.o:(symbol 
>>>> OBJC_CLASS_$_ElevatedUpdateServer+0x8)
>>>> referenced by 
>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/progressui_osx.mm
>>>>  progressui_osx.o:(symbol OBJC_CLASS_$_UpdaterUI+0x8)
> 
> ld64.lld: error: undefined symbol: OBJC_METACLASS_$_NSObject
>>>> referenced by 
>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>>>>  launchchild_osx.o:(symbol 
>>>> OBJC_METACLASS_$_ElevatedUpdateServer+0x8)
>>>> referenced by 
>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>>>>  launchchild_osx.o:(symbol 
>>>> OBJC_METACLASS_$_ElevatedUpdateServer+0x0)
>>>> referenced by 
>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/progressui_osx.mm
>>>>  progressui_osx.o:(symbol OBJC_METACLASS_$_UpdaterUI+0x8)
>>>> referenced 1 more times
> 
> 
> with or without -lobjc
> 
> Thanks,
> Gagan
> 
>> On Jun 10, 2024, at 10:14 AM, Ken Cunningham 
>>  wrote:
>> 
>> I can't see lobjc on the link line.
>> 
>> Could you show us a failed link with it there?
>> 
>> Thx
>> 
>> 
>> 
>>> On Jun 10, 2024, at 8:51 AM, Gagan Sidhu via macports-dev 
>>>  wrote:
>>> 
>>> 
>>>> GagansMacPro:updater Gagan$ /opt/local/bin/ccache /opt/local/bin/clang++ 
>>>> -isysroot /Users/Gagan/.mozbuild/MacOSX14.4.sdk -mmacosx-version-min=10.7 
>>>> -stdlib=libc++ -o ../../../../dist/bin/org.mozilla.updater 
>>>> -fstack-protector-strong -fno-sized-deallocation -fno-aligned-new 
>>>> -fno-exceptions -fPIC -fno-rtti -ffunction-sections -fdata-sections 
>>>> -fno-exceptions -fno-math-errno -pthread -gdwarf-4 -fno-omit-frame-pointer 
>>>> -funwind-tables 
>>>> -Wl,@/Users/Gagan/Downloads/mozilla-unified/obj-x86_64-apple-darwin18.7.0/toolkit/mozapps/update/updater/org_mozilla_updater.list
>>>> -fuse-ld=lld -fstack-protector-strong 
>>>> -Wl,-rpath,@executable_path/../Frameworks/UpdateSettings.framework 
>>>> -sectcreate __TEXT __info_plist 
>>>> /Users/Gagan/Downloads/mozilla-unified/obj-x86_64-apple-darwin18.7.0/dist/bin/Info.plist
>>>>  -sectcreate __TEXT __launchd_plist 
>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/Launchd.plist
>>>>   ../../../../build/pure_virtual/libpure_virtual.a 
>>>> -Wl,-rpath,@executable_path ../../../../dist/bin/UpdateSettings -framework 
>>>> Security -framework Cocoa -framework SystemConfiguration
>>> 
>>> with or without -lobjc still produces the same undefined symbol error.
>>> 
>>> sorry for the duplicate message ken. forgot to send it ot the mailer.
>>> 
>>>> 
>>>>> On Jun 10, 2024, at 9:45 AM, Ken Cunningham 
>>>

Re: paging the macports devs about NSObject between Lion and Mountain Lion

[Ken Cunningham]

I can't see lobjc on the link line.

Could you show us a failed link with it there?

Thx



> On Jun 10, 2024, at 8:51 AM, Gagan Sidhu via macports-dev 
>  wrote:
> 
> 
>> GagansMacPro:updater Gagan$ /opt/local/bin/ccache /opt/local/bin/clang++ 
>> -isysroot /Users/Gagan/.mozbuild/MacOSX14.4.sdk -mmacosx-version-min=10.7 
>> -stdlib=libc++ -o ../../../../dist/bin/org.mozilla.updater 
>> -fstack-protector-strong -fno-sized-deallocation -fno-aligned-new 
>> -fno-exceptions -fPIC -fno-rtti -ffunction-sections -fdata-sections 
>> -fno-exceptions -fno-math-errno -pthread -gdwarf-4 -fno-omit-frame-pointer 
>> -funwind-tables 
>> -Wl,@/Users/Gagan/Downloads/mozilla-unified/obj-x86_64-apple-darwin18.7.0/toolkit/mozapps/update/updater/org_mozilla_updater.list
>> -fuse-ld=lld -fstack-protector-strong 
>> -Wl,-rpath,@executable_path/../Frameworks/UpdateSettings.framework 
>> -sectcreate __TEXT __info_plist 
>> /Users/Gagan/Downloads/mozilla-unified/obj-x86_64-apple-darwin18.7.0/dist/bin/Info.plist
>>  -sectcreate __TEXT __launchd_plist 
>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/Launchd.plist
>>   ../../../../build/pure_virtual/libpure_virtual.a 
>> -Wl,-rpath,@executable_path ../../../../dist/bin/UpdateSettings -framework 
>> Security -framework Cocoa -framework SystemConfiguration
> 
> 
> with or without -lobjc still produces the same undefined symbol error.
> 
> sorry for the duplicate message ken. forgot to send it ot the mailer.
> 
>> 
>>> On Jun 10, 2024, at 9:45 AM, Ken Cunningham 
>>> mailto:ken.cunningham.web...@gmail.com>> 
>>> wrote:
>>> 
>>> It's easier to help if we can see the link line you're using, but in short 
>>> you need to make sure that lobjc is in the link libs, sometimes by 
>>> explicitly adding it:
>>> 
>>> LDFLAGS="$LDFLAGS -framework Cocoa -lobjc"
>>> 
>>> K
>>> 
>>>> On Jun 10, 2024, at 8:08 AM, Gagan Sidhu via macports-dev 
>>>> mailto:macports-dev@lists.macports.org>> 
>>>> wrote:
>>>> 
>>>> hi team,
>>>> 
>>>> first of all, i just built the clang-18 properly and wow am i amazed. here 
>>>> i was asking about wasm and stuff, i should have been a little more 
>>>> thorough, my bad.
>>>>-really this thing is a work of art. great yob
>>>> 
>>>> now to my question, which i also posted to 
>>>> stackexchange(https://stackoverflow.com/questions/78602533/using-nsobject-with-modern-os-x-sdk-14-4-and-10-7-macosx-deployment-target)
>>>> 
>>>> briefly: the NSObject class moved from the runtime to Foundation from Lion 
>>>> to Mountain Lion.
>>>> 
>>>> so there is a little bit of a “hole” in trying to compile for a 10.7 
>>>> target using an SDK that is >=10.8:
>>>> 
>>>>> ld64.lld: error: undefined symbol: OBJC_CLASS_$_NSObject
>>>>>>>> referenced by 
>>>>>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>>>>>>>> launchchild_osx.o:(symbol 
>>>>>>>> OBJC_CLASS_$_ElevatedUpdateServer+0x8)
>>>>>>>> referenced by 
>>>>>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/progressui_osx.mm
>>>>>>>> progressui_osx.o:(symbol OBJC_CLASS_$_UpdaterUI+0x8)
>>>>> 
>>>>> ld64.lld: error: undefined symbol: OBJC_METACLASS_$_NSObject
>>>>>>>> referenced by 
>>>>>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>>>>>>>> launchchild_osx.o:(symbol 
>>>>>>>> OBJC_METACLASS_$_ElevatedUpdateServer+0x8)
>>>>>>>> referenced by 
>>>>>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>>>>>>>> launchchild_osx.o:(symbol 
>>>>>>>> OBJC_METACLASS_$_ElevatedUpdateServer+0x0)
>>>>>>>> referenced by 
>>>>>>>> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/progressui_osx.mm
>>>>>>>> progressui_osx.o:(symbol OBJC_METACLASS_$_UpdaterUI+0x8)
>>>>>>>> referenced 1 more times
>>>>> clang++: error: linker command failed with exit code 1 (use -v to see 
>>>>> invocation)
>>>> 
>>>> 
>>>> usually it will say something like this because, as is obvious to this 
>>>> educated and sharp crowd, the >=10.8 objc runtime will not have NSObject 
>>>> like 10.7, and thus there is no framework we can link for a 10.7 target to 
>>>> get NSObject.
>>>> 
>>>> have any of you vets dealt this issew? is there a simple way? i haven’t 
>>>> thought too hard about trying to use an OSObject but i’m open to 
>>>> alternatives.
>>>> 
>>>> maybe duplicating the class and renaming any usage with a macro? i was 
>>>> hoping for sokmething cleaner tho.
>>>> 
>>>> Thanks,
>>>> Gagan
>>>> 
>>> 
>> 
> 

Re: paging the macports devs about NSObject between Lion and Mountain Lion

[Ken Cunningham]

It's easier to help if we can see the link line you're using, but in short you 
need to make sure that lobjc is in the link libs, sometimes by explicitly 
adding it:

LDFLAGS="$LDFLAGS -framework Cocoa -lobjc"

K

> On Jun 10, 2024, at 8:08 AM, Gagan Sidhu via macports-dev 
>  wrote:
> 
> hi team,
> 
> first of all, i just built the clang-18 properly and wow am i amazed. here i 
> was asking about wasm and stuff, i should have been a little more thorough, 
> my bad.
>   -really this thing is a work of art. great yob
> 
> now to my question, which i also posted to 
> stackexchange(https://stackoverflow.com/questions/78602533/using-nsobject-with-modern-os-x-sdk-14-4-and-10-7-macosx-deployment-target)
> 
> briefly: the NSObject class moved from the runtime to Foundation from Lion to 
> Mountain Lion.
> 
> so there is a little bit of a “hole” in trying to compile for a 10.7 target 
> using an SDK that is >=10.8:
> 
>> ld64.lld: error: undefined symbol: OBJC_CLASS_$_NSObject
> referenced by 
> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>  launchchild_osx.o:(symbol 
> OBJC_CLASS_$_ElevatedUpdateServer+0x8)
> referenced by 
> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/progressui_osx.mm
>  progressui_osx.o:(symbol OBJC_CLASS_$_UpdaterUI+0x8)
>> 
>> ld64.lld: error: undefined symbol: OBJC_METACLASS_$_NSObject
> referenced by 
> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>  launchchild_osx.o:(symbol 
> OBJC_METACLASS_$_ElevatedUpdateServer+0x8)
> referenced by 
> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/launchchild_osx.mm
>  launchchild_osx.o:(symbol 
> OBJC_METACLASS_$_ElevatedUpdateServer+0x0)
> referenced by 
> /Users/Gagan/Downloads/mozilla-unified/toolkit/mozapps/update/updater/progressui_osx.mm
>  progressui_osx.o:(symbol OBJC_METACLASS_$_UpdaterUI+0x8)
> referenced 1 more times
>> clang++: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
> 
> 
> usually it will say something like this because, as is obvious to this 
> educated and sharp crowd, the >=10.8 objc runtime will not have NSObject like 
> 10.7, and thus there is no framework we can link for a 10.7 target to get 
> NSObject.
> 
> have any of you vets dealt this issew? is there a simple way? i haven’t 
> thought too hard about trying to use an OSObject but i’m open to alternatives.
> 
> maybe duplicating the class and renaming any usage with a macro? i was hoping 
> for sokmething cleaner tho.
> 
> Thanks,
> Gagan
> 

Re: [MacPorts] #69892: python312 reportedly fails to build on G3: Python: incompatible cpu-subtype

[Ken Cunningham]

and

 file
 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_python312/python312/work/Python-3.12.3/Python.framework/Versions/3.12/Python

?

On Thu, May 2, 2024 at 9:23 AM MacPorts  wrote:

> #69892: python312 reportedly fails to build on G3: Python: incompatible
> cpu-subtype
> ---+--
>   Reporter:  barracuda156  |  Owner:  jmroot
>   Type:  defect| Status:  assigned
>   Priority:  Normal|  Milestone:
>  Component:  ports |Version:  2.9.3
> Resolution:|   Keywords:  tiger
>   Port:  python312 |
> ---+--
>
> Comment (by yumikonoua):
>
>  the file "file
>  /opt/local/Library/Frameworks/Python.framework/Versions/3.12/Python" does
>  not exist
>
> --
> Ticket URL: 
> MacPorts 
> Ports system for macOS
>

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

[Ken Cunningham]

> On Apr 7, 2024, at 11:24 PM, Riccardo Mottola  
> wrote:
> 
> Hi,
> 
> Ken Cunningham wrote:
>> Up to now, though, older systems have used gcc7, and in a few cases gcc5 or 
>> gcc48 are used for specific issues. So those gcc versions may still be 
>> needed ... time will tell.
> 
> for me it is gcc48 (or apple 4.2 on tiger or such) for old software. gcc6 
> covers most needs and gcc7 is "current". Who knows, maybe gcc13 replaces gcc7 
> in all its uses. Or maybe later we can add gcc8 or whatever.
> 
> Let's switch? I hope gcc's can be added later, maybe even with libgcc stupped?
> 
> If we do it today or tomorrow, I can leave my G4 building :-P
> 
> Riccardo

Just yesterday I fixed gcc10-bootstrap to build on Tiger PPC and pushed that to 
master, which required YA new bootstrap compiler. So the parts are now in place 
for the attempt.

If everyone wants all the gcc versions supported, we can do that. I don't care 
-- it's just a lot of building (and also fixing that will need to be done, but 
I presume you'll pitch in on the fixing of the broken gcc versions).

K

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

[Ken Cunningham]

Once gcc13 is the default gcc used on older systems, it would be hoped that it 
would cover off most needs.

Up to now, though, older systems have used gcc7, and in a few cases gcc5 or 
gcc48 are used for specific issues. So those gcc versions may still be needed 
... time will tell.

If the whole gory mess of gccs are left enabled, then to get gcc48, gcc5, or 
gcc7, you will need to build a large bunch of needless libgccs to get them. 
With no buildbot, that would pretty much suck.

The "better solution"  is pretty clearly don't enable the needless gccs on 
ancient systems -- problem solved.

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

[Ken Cunningham]

Two of the libgccs are stubs, the rest are not.

so it is pretty much as bad as it looks.

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

[Ken Cunningham]

It’s important you understand how the libgcc ports work now, to see how this 
libgcc chain is set up and the problems it might cause on slower older systems 
that have no buildbot.

Go to an Intel system like 10.7, uninstall all ports.

Disable the buildbot by clearing archive_sites in sources.conf.

Then try to install gcc7. gcc7 of course requires libgcc7.

But because libgcc7 depends on libgcc8, libgcc8 will have to be built first.

But because libgcc8 depends on libgcc9, libgcc9 will have to be built first.

But because libgcc9 depends on libgcc10, libgcc10 will have to be built first.

But because libgcc10 depends on libgcc11, libgcc11 will have to be built first.

But because libgcc11 depends on libgcc12, libgcc12 will have to be built first.

But because libgcc12 depends on libgcc13,:libgcc13 will have to be built first.

And libgcc13 is the end of the chain currently…until libgcc14 comes along.

So that is the chain.

It is pretty easy to have libgcc7 depend on libgcc13 instead of libgcc8 on 
older systems, and skip a bunch of this chain. And in base, it’s pretty easy to 
make gcc7 and gcc13 available compilers on these systems, and not the in 
between gcc versions.

It would be messy in both libgccN dependencies and base to skip odd versions of 
gcc and support even versions. Doable, but messy and confusing for coding and 
blacklisting. And little point to it.

And finally, if we are going to update libgcc, we might as well use the current 
libgcc, rather than the obsolete libgcc8.

[Barracuda has been suggesting to start up a completely new, separate gcc-ppc 
port at gcc13 that he would control…but I see no point to that, as it would 
just be our current gcc13 port anyway with a couple more patches, would break 
the ”one libstdc++ rule” for all the other gccs in so doing, and make a 
shambles of gcc compiler selection in base and blacklisting in portfiles.]

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

[Ken Cunningham]

In general, the more a given system deviates from the main herd of ports, the 
more likely there are to be problems and the less likely they are to be fixed. 
To be honest, I don’t see why a new gcc port to be used only for powerpc is 
needed.

My only question is whether to skip over gcc8-12, or include them.

If we skip over gcc8-12, we can probably have a new release that uses gcc13 as 
the primary gcc on all systems in macports done by Monday. Less maybe. Last 
time I jumped the version, it took me an hour.

And then — no more worries. Existing macports base infrastructure will just 
work as it is. Some fairly minor tweaking of what compilers are available on 
which systems will be done.

If we have to fix all the gcc versions between gcc8 and 12 — well that will 
take a bit more time to fix and to build.

For Riccardo’s bug, we always knew the gcc JIT was fragile on 32 bit systems. 
It probably needs to be disabled there by tweaking this block in the gcc8 
Portfile:

if {${subport} eq "gcc8"} {

# the jit is not building on i386 systems
# see https://trac.macports.org/ticket/61130
if {${build_arch} ne "i386"} {
lappend gcc_configure_langs jit
}

}

Maybe that’s all it needs.




Ken




> On Mar 29, 2024, at 4:50 AM, Sergio Had  wrote:
> 
> Well, the PR is either merged or not merged :)
> 

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

[Ken Cunningham]

I am not a MacPorts admin, however I believe they were pretty clear that 
10.6-ppc-specific fixes belong in an overlay repo, not in macports code.

If you want that changed, take it up with them.

I personally agree with that decision, so I abide by it, until such time as it 
changes.

K



> On Mar 29, 2024, at 04:00, Sergio Had  wrote:
> 
> 
> Ken, the last time you objected to having gcc10-bootstrap building for ppc on 
> 10.6 in gcc13 port.
> Because that was extra 10 characters of code in the macro, which was too ugly 
> to tolerate, apparently.
> (It was needed for 10.6.8 Rosetta just as much, of course: we cannot use 
> clangs on any powerpc, be it released macOS or pre-released.)
> 
> Anyway, what I suggest is the following:
> 
> 1. Keep Rosetta and 10.6 ppc stuff out of existing gcc ports. Those will be 
> only for 10.4–10.5 on PowerPC, which is what you want, AFAIU. No “spaghetti 
> code”, which you dislike.
> 2. I make a separate gcc-powerpc port, analogous to gcc-devel, where I can 
> add tweaks I want, and restrict that port to PowerPC. Throw away everything 
> unneeded from there, make it easy to maintain.
> 
> To that separate port I can add support for libc++ on PowerPC, fix IEEE 
> arithmetic in Fortran, support 10.6 ppc and Rosetta, and whats not. Which 
> will not land into any other gcc ports, unless someone else – not me – 
> decides to pick that.
> 
> As I bonus I (and whomever decides to use it) can avoid unnecessary revbumps, 
> wasting many hours of compilation time for nothing, and on the other hand 
> revbump powerpc port without causing pain to anyone else.
> 
> I honestly hope this can keep everyone satisfied.
> 
> I also hope you can cooperate with me then to move 10.4–10.5 to libgcc13, 
> since we should not have a disagreement anymore.
> 
> 
>> On Mar 29, 2024, at 5:34 AM, Ken Cunningham 
>>  wrote:
>> 
>> I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had 
>> anything to do with why nobody had gotten around to updating the gcc version 
>> used on older systems.
>> 
>> At least, it was not anywhere on my radar.
>> 
>> Just -- nobody did the legwork.
>> 
>> Ken
>> 
>> 
>>> On 2024-03-28, at 11:47 AM, Sergio Had wrote:
>>> 
>>> Let me make another, final attempt to sort this out once for all and for 
>>> everyone on old systems.
>>> 
>>> I got an idea how to satisfy Ken’s preference of not supporting ppc builds 
>>> on 10.6 in gcc ports and my need to support those.
>>> 
>>> That was the stopper so far, not allowing an agreement to merge.
>>> 
>>> I may do this today itself: I have everything working for months, just need 
>>> to sort commits to make it readable and implement a solution for what I 
>>> want.
>>> 
>>> As a bonus, you will get IEEE intrinsics in Fortran – something that never 
>>> existed on ppc.
>>>> On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote:
>>>> You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). 
>>>> I have seen people using gcc13 on 10.5 ppc following my instructions from 
>>>> the PR.
>>>> 
>>>> What is the point of gcc8?
>>>> 
>>>> You build gcc10-bootstrap and then use it to build gcc13. Nothing else 
>>>> needed in between.
>>>>> On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev 
>>>>> , wrote:
>>>>> Hi,
>>>>> 
>>>>> after all the talk about gcc versions, I tried to build gcc 8 here.
>>>>> Officially it says "gcc8 is known to fail".
>>>>> 
>>>>> I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit
>>>>> later, I fear my MacBook has fan issues.
>>>>> 
>>>>> Intel 64bit finished build! Took several hours. I thus tried to install
>>>>> it... and it says again
>>>>> "libgcc8 is known to fail. Try to install anyway?" and yes, it just built!
>>>>> 
>>>>> However then it asks about libgcc9 but I want to stay on libgcc8,
>>>>> that was the point... am Inheriting that it will go up to gcc13?
>>>>> 
>>>>> 
>>>>> On PowerPC instead build fails (and ultimate goal is to enable newer
>>>>> gccs on PPC too, where it is needed)
>>>>> 
>>>>> :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic',
>>>>> '-fPIC', '-fpie' or '-fPIE'
>>>>> :info:build
>>>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:
>>>>> In member function 'gcc::jit::result*
>>>>> gcc::jit::playback::context::dlopen_built_dso()':
>>>>> :info:build
>>>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3:
>>>>> error: 'dlerror' was not declared in this scope
>>>>> :info:build dlerror ();
>>>>> :info:build ^~~
>>>>> 
>>>>> 
>>>>> Already seen this? Full build log is 6.7MB
>>>>> Should I open a ticket on this or is there already one for gcc8 efforts?
>>>>> didn't find it.
>>>>> 
>>>>> Riccardo
>> 
> 

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

[Ken Cunningham]

supporting all the gcc versions between gcc 8 and 12 on older systems will be 
quite a bit of work and require a lot of build time for poor users of these 
systems.

To have libgcc7, the way it is now, you need to build libgcc13, 12, 11, 10, 9, 
8, and then 7.

That is -- a lot of gcc building for a questionable benefit.

If we could agree to use what we have (up to gcc7) and then skip to gcc13 it 
would be much easier.

That would likely take no more than a few hours of work for some one to do, 
once there was consensus on it.


Ken


On 2024-03-28, at 8:57 AM, Riccardo Mottola wrote:

> Hi,
> 
> after all the talk about gcc versions, I tried to build gcc 8 here.
> Officially it says "gcc8 is known to fail".
> 
> I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit
> later, I fear my MacBook has fan issues.
> 
> Intel 64bit finished build! Took several hours. I thus tried to install
> it... and it says again
> "libgcc8 is known to fail. Try to install anyway?" and yes, it just built!
> 
> However then it asks about libgcc9 but I want to stay on libgcc8,
> that was the point... am Inheriting that it will go up to gcc13?
> 
> 
> On PowerPC instead build fails (and ultimate goal is to enable newer
> gccs on PPC too, where it is needed)
> 
> :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic',
> '-fPIC', '-fpie' or '-fPIE'
> :info:build
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:
> In member function 'gcc::jit::result*
> gcc::jit::playback::context::dlopen_built_dso()':
> :info:build
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3:
> error: 'dlerror' was not declared in this scope
> :info:builddlerror ();
> :info:build^~~
> 
> 
> Already seen this? Full build log is 6.7MB
> Should I open a ticket on this or is there already one for gcc8 efforts?
> didn't find it.
> 
> Riccardo

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

[Ken Cunningham]

I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had 
anything to do with why nobody had gotten around to updating the gcc version 
used on older systems.

At least, it was not anywhere on my radar.

Just -- nobody did the legwork.

Ken


On 2024-03-28, at 11:47 AM, Sergio Had wrote:

> Let me make another, final attempt to sort this out once for all and for 
> everyone on old systems.
> 
> I got an idea how to satisfy Ken’s preference of not supporting ppc builds on 
> 10.6 in gcc ports and my need to support those.
> 
> That was the stopper so far, not allowing an agreement to merge.
> 
> I may do this today itself: I have everything working for months, just need 
> to sort commits to make it readable and implement a solution for what I want.
> 
> As a bonus, you will get IEEE intrinsics in Fortran – something that never 
> existed on ppc.
> On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote:
>> You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). I 
>> have seen people using gcc13 on 10.5 ppc following my instructions from the 
>> PR.
>> 
>> What is the point of gcc8?
>> 
>> You build gcc10-bootstrap and then use it to build gcc13. Nothing else 
>> needed in between.
>> On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev 
>> , wrote:
>>> Hi,
>>> 
>>> after all the talk about gcc versions, I tried to build gcc 8 here.
>>> Officially it says "gcc8 is known to fail".
>>> 
>>> I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit
>>> later, I fear my MacBook has fan issues.
>>> 
>>> Intel 64bit finished build! Took several hours. I thus tried to install
>>> it... and it says again
>>> "libgcc8 is known to fail. Try to install anyway?" and yes, it just built!
>>> 
>>> However then it asks about libgcc9 but I want to stay on libgcc8,
>>> that was the point... am Inheriting that it will go up to gcc13?
>>> 
>>> 
>>> On PowerPC instead build fails (and ultimate goal is to enable newer
>>> gccs on PPC too, where it is needed)
>>> 
>>> :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic',
>>> '-fPIC', '-fpie' or '-fPIE'
>>> :info:build
>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:
>>> In member function 'gcc::jit::result*
>>> gcc::jit::playback::context::dlopen_built_dso()':
>>> :info:build
>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3:
>>> error: 'dlerror' was not declared in this scope
>>> :info:build dlerror ();
>>> :info:build ^~~
>>> 
>>> 
>>> Already seen this? Full build log is 6.7MB
>>> Should I open a ticket on this or is there already one for gcc8 efforts?
>>> didn't find it.
>>> 
>>> Riccardo

Re: cmake-devel --> cmake coming .... please test if you care to

[Ken Cunningham]

We sorted out a workaround for the failing systems that was incorporated 
upstream, and after some further testing, updated the cmake port to the current 
version on all systems.

Both cmake and cmake-devel are about the same now, so feel free to go back to 
the main cmake port.

Tiger needs verification.

K

> On Mar 27, 2024, at 02:29, Riccardo Mottola  
> wrote:
> 
> Hi Ken,
> 
> Ken Cunningham wrote:
>> the cmake port is very very far behind.
>> 
>> cmake-devel has been updated to the newest version currently available
>> (3.29.0) for most systems, and then newest supportable (3.28.4) for 10.7
>> and < 10.6.
>> 
> 
> I deactivated cmake and installed cmake-devel as test on 10.5 intel
> 64bit, 10.7, 10.11
> 
> Build when file on all systems. I think the best test is using it during
> more upgrades... I don't remember off-hand which ports use to test.
> I hope that w e don't get red-herrings of failures on other packages due
> to that.
> 
>> 
>> https://trac.macports.org/ticket/67540
>> 
>> If you are a keener with debugging on 10.7, and can sort out a proper
>> fix for 3.29.0 on 10.7, upstream will love you. Most likely eventually
>> we/they will use the commits they added to the 3.28.N branch to fix it
>> for those systems, although those commits are more involved that we
>> usually like to carry.
> 
> At a first glance I don't understand the issue, it looks like
> compiler/linker gets confused. If you want... we can try to tinker on it.
> 
> Riccardo

cmake-devel --> cmake coming .... please test if you care to

[Ken Cunningham]

the cmake port is very very far behind.

cmake-devel has been updated to the newest version currently available (3.29.0) 
for most systems, and then newest supportable (3.28.4) for 10.7 and < 10.6.

Please try out if you care to, as cmake-devel should become cmake soon.

If you are interested in the issues regarding v3.29.0 on 10.7 (kernel panic) or 
< 10.6, there are details here:

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

If you are a keener with debugging on 10.7, and can sort out a proper fix for 
3.29.0 on 10.7, upstream will love you. Most likely eventually we/they will use 
the commits they added to the 3.28.N branch to fix it for those systems, 
although those commits are more involved that we usually like to carry.

K

Re: inserting -stdlib=libstdc++ into cxxflags

[Ken Cunningham]

sorry, clang-11-bootstrap

> On Mar 23, 2024, at 00:01, Ken Cunningham  
> wrote:
> 
> the clang-10-bootstrap port builds against libstdc++ now.
> 
> K

Re: inserting -stdlib=libstdc++ into cxxflags

[Ken Cunningham]

the clang-10-bootstrap port builds against libstdc++ now.

K

Re: GTK on PowerPC: does anyone have it actually working?

[Ken Cunningham]

> On Mar 15, 2024, at 6:05 PM, Ken Cunningham  
> wrote:
> 
> 
> 
>> On Mar 14, 2024, at 4:07 AM, Sergio Had  wrote:
>> 
>> I guess you ask Ken, but anyway, does anyone have X11 GUI working for 
>> `transmission-x11` 
> 
> transmission-x11 works on 10.6 PPC.
> 
> (I had to do a little minor surgery on the transmission source code to make 
> it build with gcc7.)
> 
> Ken

Freudian slip :>

Works on 10.5 PPC.

Re: GTK on PowerPC: does anyone have it actually working?

[Ken Cunningham]

> On Mar 14, 2024, at 4:07 AM, Sergio Had  wrote:
> 
> I guess you ask Ken, but anyway, does anyone have X11 GUI working for 
> `transmission-x11` 

transmission-x11 works on 10.6 PPC.

(I had to do a little minor surgery on the transmission source code to make it 
build with gcc7.)

Ken

Re: GTK on PowerPC: does anyone have it actually working?

[Ken Cunningham]

If you’re having an issue of some kind, it’s probably best to open a ticket 
where it can be worked through. The exact specifics usually matter.

One quick test however is to install xterm and lauch xterm via the menu in 
macport’s XQuartz. Then try to run your gtk software from that xterm window. 

The issues usually seen are when trying to launch gtk/X11 apps from the Apple 
Terminal.app. This can get muddled up in the X11.app installed by the Apple 
installer and the XQuartz.app installed separately from the XQuartz website. 

Hygiene is important. Clearing out unneeded launch items (some of which may 
live in /System/Library as well as /Library), getting rid of other X11 servers, 
and getting rid of redundant duplicates (which may exist in /usr/X11 or 
/opt/X11) may be needed.

K

> On Mar 14, 2024, at 04:07, Sergio Had  wrote:
> 
> 
>>> On Mar 14, 2024, at 5:33 PM, Riccardo Mottola via macports-dev 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> Ken Cunningham wrote:
>>> gtk3 (x11 variant) is working fine for me on PowerPC Leopard, for one.
>> 
>> I'm hacking on GTK2 and GTK3 quartz support for Leopard... intel first, they 
>> were working well enough to get gimp starting up (gtk2...)
> 
> I think I could not get it to start, though it builds fine.
> 
>> The only other GTK3 app I use is meld, which is now unusable (doesn't even 
>> show a window) on 10.6 and 10.7, so I didn't even attempt on 10.5. on 
>> 10.11-10.13 it has heavy redraw issues (has since about a year). But it is 
>> really a maze of dependencies, so I don't know if the bug is in GTK or one 
>> of the many dependent libraries.
> 
> I did have problems with GTK and X11 ports on 10.6 ppc, but however:
> 
> 1. 10.6 ppc is not an officially supported system in Macports, so some stuff 
> may need extra fix-ups (usually trivial – fix some macros).
> 2. It is not impossible that I have a messed-up X11, since macOS 
> implementation may conflict with MacPorts one, and there is also XQuartz. 
> Unfortunately, there is no clear instruction how to go about that, and I have 
> seen related complaints re 10.5 and 10.4.
> 
> Once I rebuild gcc13 on Leopard, I will try again there.
> 
>> I will try to build on 10.5 PPC tomorrow and see how things fare
>> 
>> What app(s) do you use?
> 
> 
> I guess you ask Ken, but anyway, does anyone have X11 GUI working for 
> `transmission-x11` and `gtk-gnutella`?
> 
> P. S. On a side note, wxWidgets 3.1 also does not work for me, at least on 
> PowerPC. At the same time almost everything Qt4-based works beautifully. 
> Cocoa-based apps work, as long as the code does not rely on incompatible ObjC 
> syntax and new SDKs.
> 

Re: GTK on PowerPC: does anyone have it actually working?

[Ken Cunningham]

nothing special.

if it’s not working for you, we can probably work through it in a ticket…



> On Mar 11, 2024, at 00:45, Sergio Had  wrote:
> 
> Thank you, Ken, this is helpful.
> 
> Could you say whether you did any specific manual setup for X11?
> 
> 
> 
>>> On Mar 11, 2024, at 3:36 AM, Ken Cunningham 
>>>  wrote:
>>> 
>>> 
>>> 
>>> Sergey said:
>> 
>>> It looks like while even gtk4 builds fine with no hacks (and of course gtk2 
>>> and gtk3 do), none of the apps built against then actually work. Everything 
>>> crashes on start.
>>> 
>>> Could anyone confirm if any GTK version is known to work on a PPC system, 
>>> and point at a specific app to test?
>>> 
>> 
>> gtk3 (x11 variant) is working fine for me on PowerPC Leopard, for one.
>> 
>> Just installed pan2 and a few other ports and no issues noted.
>> 
>> 
> 

Re: GTK on PowerPC: does anyone have it actually working?

[Ken Cunningham]

> Sergey said:

> It looks like while even gtk4 builds fine with no hacks (and of course gtk2 
> and gtk3 do), none of the apps built against then actually work. Everything 
> crashes on start.
> 
> Could anyone confirm if any GTK version is known to work on a PPC system, and 
> point at a specific app to test?
> 

gtk3 (x11 variant) is working fine for me on PowerPC Leopard, for one.

Just installed pan2 and a few other ports and no issues noted.

Re: How to force run tests as non-root?

[Ken Cunningham]

You are completely right, and I was wrong about this.

I am now not certain how it came to be that macports was installed under the 
root user for the 10.6-ppc installation in the mentioned ticket (assuming I got 
the part right).

K

> On Feb 24, 2024, at 13:07, Joshua Root  wrote:
> 
> On 25/2/2024 03:07, Ken Cunningham wrote:
>> Some of your macports installations are installed as the root user, instead 
>> of the macports user.
>> This happened because there is no installer for 10.6-ppc to automatically 
>> create the macports user. You have an open ticket about this too, where I 
>> pointed to the commands to be run to generate the macports user.
>> Sooner or later you will probably have to fix this.
> 
> It shouldn't make any difference to this whether you use the pkg installer or 
> install from source, since the Makefile also creates the run user. Unless of 
> course you specifically tell configure --with-macports-user=root (very not 
> recommended).
> 
> - Josh

Re: How to force run tests as non-root?

[Ken Cunningham]

Oh, OK…. That’s different then, for sure.Let me see if I get the same result.KOn Feb 24, 2024, at 08:32, Sergey Fedorov  wrote:Ken, you are right about 10.6-ppc, of course, but in this particular case I am having an issue with Sonoma.Specifically, I cannot get Vidalia tests run with sudo port test. At the same time, they run fine if I launch the test binary manually without sudo.What fails:1. sudo port test vidalia2. sudo /opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_security_Vidalia/Vidalia/work/vidalia-8240540188062a168a66b25ca61b852cc89140ad/src/tests/VidaliaTestSuite3. sudo -u macports /opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_security_Vidalia/Vidalia/work/vidalia-8240540188062a168a66b25ca61b852cc89140ad/src/tests/VidaliaTestSuiteWhat works fine:1. /opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_security_Vidalia/Vidalia/work/vidalia-8240540188062a168a66b25ca61b852cc89140ad/src/tests/VidaliaTestSuite2. sudo -u svacchanda /opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_security_Vidalia/Vidalia/work/vidalia-8240540188062a168a66b25ca61b852cc89140ad/src/tests/VidaliaTestSuite (that is, from a current non-root user).(Portfile in the master has no support for tests, as of now, so running it gonna fail anyway.)On Sat, Feb 24, 2024 at 11:24 PM Ken Cunningham <ken.cunningham.web...@gmail.com> wrote:Some of your macports installations are installed as the root user, instead of the macports user.

This happened because there is no installer for 10.6-ppc to automatically create the macports user. You have an open ticket about this too, where I pointed to the commands to be run to generate the macports user.

Sooner or later you will probably have to fix this.

Re: How to force run tests as non-root?

[Ken Cunningham]

Some of your macports installations are installed as the root user, instead of 
the macports user.

This happened because there is no installer for 10.6-ppc to automatically 
create the macports user. You have an open ticket about this too, where I 
pointed to the commands to be run to generate the macports user.

Sooner or later you will probably have to fix this.

thank you for the arm64 sonoma buildbot, Ryan

[Ken Cunningham]

I installed fresh copy of the 2.9 base beta and then all new ports -- and it is 
just ripping along now that many of them are already built.

Appreciate all your efforts keeping that going ... must be a ton of work.

Ken

Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)

[Ken Cunningham]

I think you just don't realize the wreckage you've done.

Here is one of hundreds of your typical commits, although this is a simpler one 
than most, to be honest.

The commit below has no purpose other than to allow the port to build as PPC on 
10.6. And as that is really only of interest on 10.6-for-PPC, it is 
specifically for that. You say you want to support "Rosetta" but nobody builds 
for PPC on 10.6.

Here, you've reordered a few instructions, and blocked out some code from 
running on PPC (presumably because the instructions don't exist on 10.6-for-PPC 
so it wouldn't compile). 

However, this changes the code. And it's not simple code, it is complicated 
code. Does this change the function of the code? Would it still work properly 
on 10.6 Intel? Does it work at all on 10.6 for PPC? Who can tell? I certainly 
don't think you have the experience to know. I can't eyeball it as being fine.

It used to say:

tcmalloc_zone.version = 6;
tcmalloc_zone.free_definite_size = _free_definite_size;
tcmalloc_zone.memalign = _memalign;
tcmalloc_introspection.zone_locked = _zone_locked;

and now it says (I think) on Intel:

tcmalloc_zone.version = 6;
tcmalloc_zone.memalign = _memalign;
tcmalloc_zone.free_definite_size = _free_definite_size;
tcmalloc_introspection.zone_locked = _zone_locked;

and on 10.6-PPC you just get this:

tcmalloc_zone.version = 6;
tcmalloc_zone.memalign = _memalign;

Does reordering those statements change the function? Does it work at all with 
the two statements removed? It would take me considerable reading to find out. 
It took me 10 minutes just to figure out what your patch did.

And now there it sits in the ports tree, a useless MacPorts-only patch, just 
waiting to break something. Some poor sot might bring an issue to upstream 
about this, having no idea that this is not even upstream's code any more.

And there are HUNDREDS of these all throughout the codebase that need to be all 
stripped out.

This is unfortunately a huge mess now.

K




https://github.com/macports/macports-ports/commit/418232ebb3d0e68579364c6246de4464f8f494c9

==
--- src/libc_override_osx.h.orig 2021-12-13 14:28:06.0 +0800
+++ src/libc_override_osx.h 2023-01-19 20:14:36.0 +0800
@@ -276,9 +276,11 @@
MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6
// Switch to version 6 on OSX 10.6 to support memalign.
tcmalloc_zone.version = 6;
- tcmalloc_zone.free_definite_size = _free_definite_size;
tcmalloc_zone.memalign = _memalign;
+#ifndef __POWERPC__
+ tcmalloc_zone.free_definite_size = _free_definite_size;
tcmalloc_introspection.zone_locked = _zone_locked;
+#endif

// Request the default purgable zone to force its creation. The
// current default zone is registered with the purgable zone for
=



> On Jan 8, 2024, at 9:50 AM, Sergey Fedorov  wrote:
> 
> Here we go again.
> 
> 1. To begin with, nobody is submitting 10A190-specific fixes to Macports. 
> They are sitting in my local repo. Please, do not mislead people who are 
> unaware of the matter.
> 
> 2. Standard 10.6.8 release from Apple does support building and running ppc 
> binaries via Rosetta. Nothing unreleased or, as you [mis]frame, “stolen”.
> While I think your opposition is completely unjustified, there has been no 
> demands or even active discussion about supporting pre-released builds on 
> 10.6. The point is supporting officially released 10.6.8.
> 
> 3. If anyone did wonder, the whole issue with 10A190 is literally ~20 ports 
> altogether, and those fixes amount to a few lines of code to adjust a few 
> assumptions re SDK. Despite it being portrayed as something like half of the 
> Macports tree is broken and needs tailored hacks which gonna break 
> everything. This is nowhere the case.
> However, as I said above, nobody demanded 10A190 being supported in the 
> master. Nobody commits 10A190-specific fixups.
> 
> 4. > “The problem was that there were many fragile and sharply increasing 
> *specific* workarounds added into the ports tree solely to support running 
> this PowerPC beta on MacPorts”.
> 
> This accusation keeps being repeated, but it is simply not true. You will not 
> be able to show multiple specific workarounds for 10A190 in Macports master. 
> They are not there.
> There were a few specific fixes for standard 10.6.8 Rosetta, largely because 
> the makefile build system misdetects the arch. They are not numerous either, 
> and verily not sharply increasing.
> 
> It will be great not to keep repeating false statements targeting those who 
> are unaware of the facts.
> 

Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)

[Ken Cunningham]

There is no hiccup in MacPorts support for PowerPC systems, despite the 
dramatic title of the PR.

Also there is no hiccup in support for older released Apple operating systems. 
10.4 and 10.5 remain fully supported by MacPorts (although 10.4 might be on 
last legs).

There is also no need (IMHO) for a fork of MacPorts to support older Apple 
operating systems.

What there was a difference of opinion about was whether MacPorts should 
provide *specific* and rather extensive support for an unreleased early PowerPC 
beta of an Apple operating system that was a stepping stone to what became 
MacOSX 10.6 that had been found in an old developer's drawer and released into 
the wild through various websites.

The problem was that there were many fragile and sharply increasing *specific* 
workarounds added into the ports tree solely to support running this PowerPC 
beta on MacPorts. 

These were kludgy and hard to eyeball debug. Nobody could test them very well, 
as the number of users of this unreleased beta PowerPC SnowLeopard OS were 
extremely few. They were scattered throughout the ports tree and patches in 
ways that made them very difficult, and time consuming, to properly vet.

MacPorts has always considered 10.6 as supporting i386 and x86_64, and a great 
many ports and portgroups were written with this in mind. That fits very nicely 
into the support MacPorts provides up to 10.13, that also support i386 and 
x86_64, so that whole block of systems can be managed often one unit. Once 
legacysupport came out, the number of changes in Portfiles that were needed to 
support 10.6 was actually very minimal, and that was the whole idea. 

However, to support a 10.6 PPC beta meant redoing a large number of these 
assumptions to accommodate cross-compiling PowerPC code. Different compilers, 
different universal options -- an entire redo. In addition, the 10.6 beta is 
missing a number functions and capabilities that 10.6.8 Intel has, and to 
10.5.8 PowerPC has further fixups and enhancements added to it by Apple that 
never made it into the unreleased 10.6 beta.

There is no reason anyone needs to use 10.6-for-PowerPC. Of course, you can if 
you want, and go ahead and make some changes in ports to support that if you 
care to. That is a reason for someone to fork MacPorts ports tree, but there is 
certainly no reason those changes need to be distributed to every MacPorts user.


To be honest, I can't really believe we're even having the conversation about 
whether we support a specific unreleased stolen Apple OS from a developer's 
drawer that doesn't fit into the existing structure and requires hundreds or 
more additions to the ports tree. It was just nuts from the beginning to allow 
this into MacPorts.

Ken

Key universal build failures

[Ken Cunningham]

One of MacPorts' most significant differences from the other available package 
mangers is it's preserved support for universal building. It is perhaps the 
most impressive feature that MacPorts offers that the other package managers do 
not (AFAIK).

However, at present, there are several core key ports that cannot be built as 
universal for arm64/x86_64 that may benefit from attention.

1. openblas

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

2. graphene

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

the issue with graphene to decide as a whole how MacPorts might handle 
pkgconfig files that are different between the different universal arches. Some 
initial thoughts on that are here:

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

3. gtk3

a few different tickets about different aspects of the failures to build 
universal:

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

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

4. libgcc

a fully universal-supporting gcc with an up-to-date driverdriver.c that works 
would be nice, but even in the absence of that (or as a step towards that, 
perhaps) an actual universal build (arm64/x86_64) of libgcc would be nice to 
have.

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


If these ports were fixed, then I believe a cascade of other ports would build 
universal, and people are looking for that.

Re: Sonoma Apple Silicon build machine

[Ken Cunningham]

no Sonoma arm64 builder yet:build.macports.org

Re: Xcode PortGroup: Xcode compiles code twice?

[Ken Cunningham]

the xcode portgroup has always done this.

it builds everything in the build phase, and then builds everything again in 
the destroot phase.

we have discussed this over the years and the previous conclusion was that this 
was completely unavoidable, and we’d just have to live with it.

sometimes I just disable the build phase

build {}

to save time when I’m working on a big port.

K

Re: VLC for PowerPC: make a separate port or modify existing?

[Ken Cunningham]

vlc is built against a cocoa interface, not qt, on macos. It has many HAVE_OSX defines scattered thoroughout the code, that all assume macos technologies for the pathways. It is currently written to support a floor sdk of 10.11. Changing all that code to support old systems again is… unrealistic, shall we say.So you’re not getting any current version to build, but as I said, you might get some old version to build. I have an old version that works now on older systems, of course :) It just can’t play much.But Mplayer is much more functional, which was my point. And older systems are lucky to have that, as vlc and mpv have left them all behind, given their full GUIs needing more current SDK features.A recent update to the mplayer-devel code broke <10.7 , but that looks like an easy fix to me.On Aug 4, 2023, at 23:03, Sergey Fedorov  wrote:> even if you find some old version that still builds on the ancient systems ... pointlessly out of date.2.2.8 builds, I think the latest should (either with restored Qt4 or without Qt). The question is which works.So far it seems that X11 video output works but has broken colors due to never fixed upstream bugs in OpenGL or alike.For example, this was reported in 2016 and apparently still broken: https://bugreports.qt.io/browse/QTBUG-56975P. S. It is useful to have several players. From experience even on modern Intel, none is perfectly reliable and some will be preferred to another conditionally.On Sat, Aug 5, 2023 at 8:50 AM Ken Cunningham <ken.cunningham.web...@gmail.com> wrote:even if you find some old version that still builds on the ancient systems ... pointlessly out of date.yet MPlayer is right up to the minute, and worked very well even on Tiger PPC last I tried it.Anyway, play with VLC as you wish, of course.On Aug 4, 2023, at 5:26 PM, Sergey Fedorov <vital@gmail.com> wrote:Don’t worry, I will not submit a PR for VLC unless it actually works with video. There is no point otherwise.If it does not, I just leave it. But for now it still makes sense to have an idea what to do with the port IF it works.On Sat, Aug 5, 2023 at 7:02 AM Ken Cunningham <ken.cunningham.web...@gmail.com> wrote:For playing videos on older systems, I think MPlayer is the way to go.Give that a try if you haven't.KenOn 2023-08-04, at 3:57 PM, Sergey Fedorov wrote:I need an advice.We got VLC2 port (which is totally broken for all systems) and VLC port, which installs pre-built binary. Neither supports PPC, obviously, and even i386.Leaving the main VLC aside, VLC2 is already a mess and in the present state is unusable for practical purposes. Rewriting the logic is doable (I have done it locally, kind of), however I have few concerns here:1. Given the complexity of the port, it may not be obvious for anyone who might wish to update it in the future or fix something for Intel systems, what has to be left untouched for PPC (assuming that testing for PPC cannot be done due to lack of hardware). It is very easy to break the build, I just now tried to enable a feature which looked harmless, and that broke the build immediately. And we cannot really write passages of explanations for every change or choice.2. On the other hand, even though the port is currently broken for Intel, my fixes might introduce some undesirable effects for it, unless of course literally everything is put inside the guarding condition. But then we have x2 more code in the port, which is already barely readable.For these reasons, it seems easier and safer to have a separate VLC-ppc port: then I can work on it without bothering to match versions or to break anything for someone, and at the same time be reasonably sure no one accidentally breaks PPC build.However, we seldom make arch-specific ports, so I assume, it may not be considered desirable.Which way should I go here? Ultimately I am fine with either option, but it will save time to decide first rather than having to rewrite later something completely.P. S. Re status of the thing itself:Given that FreeBSD seems to build the current VLC 3.x for 32-bit archs, including PPC (may be untested, but still), chances are it can be fixed. However, support for Qt4 has to be restored or otherwise Qt should be foregone completely.Building of VLC2 I have fixed for PPC tonight. It works in some aspects (GUI is acceptably okay, audio output seems perfect), but video either does not or works partly (I cannot tests all output modes right now for technical reasons).So it is not a matter of tomorrow’s PR yet, but if it works, it may work rather soon.

Re: VLC for PowerPC: make a separate port or modify existing?

[Ken Cunningham]

even if you find some old version that still builds on the ancient systems ... 
pointlessly out of date.

yet MPlayer is right up to the minute, and worked very well even on Tiger PPC 
last I tried it.

Anyway, play with VLC as you wish, of course.



> On Aug 4, 2023, at 5:26 PM, Sergey Fedorov  wrote:
> 
> Don’t worry, I will not submit a PR for VLC unless it actually works with 
> video. There is no point otherwise.
> 
> If it does not, I just leave it. But for now it still makes sense to have an 
> idea what to do with the port IF it works.
> 
> On Sat, Aug 5, 2023 at 7:02 AM Ken Cunningham 
> mailto:ken.cunningham.web...@gmail.com>> 
> wrote:
>> For playing videos on older systems, I think MPlayer is the way to go.
>> 
>> Give that a try if you haven't.
>> 
>> Ken
>> 
>> 
>> On 2023-08-04, at 3:57 PM, Sergey Fedorov wrote:
>> 
>>> I need an advice.
>>> 
>>> We got VLC2 port (which is totally broken for all systems) and VLC port, 
>>> which installs pre-built binary. Neither supports PPC, obviously, and even 
>>> i386.
>>> 
>>> Leaving the main VLC aside, VLC2 is already a mess and in the present state 
>>> is unusable for practical purposes. Rewriting the logic is doable (I have 
>>> done it locally, kind of), however I have few concerns here:
>>> 
>>> 1. Given the complexity of the port, it may not be obvious for anyone who 
>>> might wish to update it in the future or fix something for Intel systems, 
>>> what has to be left untouched for PPC (assuming that testing for PPC cannot 
>>> be done due to lack of hardware). It is very easy to break the build, I 
>>> just now tried to enable a feature which looked harmless, and that broke 
>>> the build immediately. And we cannot really write passages of explanations 
>>> for every change or choice.
>>> 
>>> 2. On the other hand, even though the port is currently broken for Intel, 
>>> my fixes might introduce some undesirable effects for it, unless of course 
>>> literally everything is put inside the guarding condition. But then we have 
>>> x2 more code in the port, which is already barely readable.
>>> 
>>> For these reasons, it seems easier and safer to have a separate VLC-ppc 
>>> port: then I can work on it without bothering to match versions or to break 
>>> anything for someone, and at the same time be reasonably sure no one 
>>> accidentally breaks PPC build.
>>> 
>>> However, we seldom make arch-specific ports, so I assume, it may not be 
>>> considered desirable.
>>> 
>>> Which way should I go here? Ultimately I am fine with either option, but it 
>>> will save time to decide first rather than having to rewrite later 
>>> something completely.
>>> 
>>> 
>>> P. S. Re status of the thing itself:
>>> 
>>> Given that FreeBSD seems to build the current VLC 3.x for 32-bit archs, 
>>> including PPC (may be untested, but still), chances are it can be fixed. 
>>> However, support for Qt4 has to be restored or otherwise Qt should be 
>>> foregone completely.
>>> 
>>> Building of VLC2 I have fixed for PPC tonight. It works in some aspects 
>>> (GUI is acceptably okay, audio output seems perfect), but video either does 
>>> not or works partly (I cannot tests all output modes right now for 
>>> technical reasons).
>>> So it is not a matter of tomorrow’s PR yet, but if it works, it may work 
>>> rather soon.
>>> 
>>> 
>> 

Re: VLC for PowerPC: make a separate port or modify existing?

[Ken Cunningham]

For playing videos on older systems, I think MPlayer is the way to go.

Give that a try if you haven't.

Ken


On 2023-08-04, at 3:57 PM, Sergey Fedorov wrote:

> I need an advice.
> 
> We got VLC2 port (which is totally broken for all systems) and VLC port, 
> which installs pre-built binary. Neither supports PPC, obviously, and even 
> i386.
> 
> Leaving the main VLC aside, VLC2 is already a mess and in the present state 
> is unusable for practical purposes. Rewriting the logic is doable (I have 
> done it locally, kind of), however I have few concerns here:
> 
> 1. Given the complexity of the port, it may not be obvious for anyone who 
> might wish to update it in the future or fix something for Intel systems, 
> what has to be left untouched for PPC (assuming that testing for PPC cannot 
> be done due to lack of hardware). It is very easy to break the build, I just 
> now tried to enable a feature which looked harmless, and that broke the build 
> immediately. And we cannot really write passages of explanations for every 
> change or choice.
> 
> 2. On the other hand, even though the port is currently broken for Intel, my 
> fixes might introduce some undesirable effects for it, unless of course 
> literally everything is put inside the guarding condition. But then we have 
> x2 more code in the port, which is already barely readable.
> 
> For these reasons, it seems easier and safer to have a separate VLC-ppc port: 
> then I can work on it without bothering to match versions or to break 
> anything for someone, and at the same time be reasonably sure no one 
> accidentally breaks PPC build.
> 
> However, we seldom make arch-specific ports, so I assume, it may not be 
> considered desirable.
> 
> Which way should I go here? Ultimately I am fine with either option, but it 
> will save time to decide first rather than having to rewrite later something 
> completely.
> 
> 
> P. S. Re status of the thing itself:
> 
> Given that FreeBSD seems to build the current VLC 3.x for 32-bit archs, 
> including PPC (may be untested, but still), chances are it can be fixed. 
> However, support for Qt4 has to be restored or otherwise Qt should be 
> foregone completely.
> 
> Building of VLC2 I have fixed for PPC tonight. It works in some aspects (GUI 
> is acceptably okay, audio output seems perfect), but video either does not or 
> works partly (I cannot tests all output modes right now for technical 
> reasons).
> So it is not a matter of tomorrow’s PR yet, but if it works, it may work 
> rather soon.
> 
> 

Re: Go Ports: Update PG to Ensure Ports Aren't Built if Version Required Not Available

[Ken Cunningham]

The last time I looked at this, go had moved on to use newer features of the 
Security.Framework that couldn't be duplicated for older systems, so it was 
stuck at an  older pegged version.

I see here and there that some folks have managed to get newer versions of the 
Security.Frameworks from Apple Open Source building on older systems. It would 
be great if someone might get that to happen for MacPorts, as that is getting 
to be a problem for a number of ports.

Ken


On 2023-07-27, at 10:49 AM, Kirill A. Korinsky via macports-dev wrote:

> I may try to make some magic and bring fresh go 﫣
> 
> -- 
> wbr, Kirill
> 
>> On 27. Jul 2023, at 18:39, Christopher Nielsen  
>> wrote:
>> 
>> At present, our Go port is pinned at an older version - 1.17.3 - for macOS 
>> 10.12 and earlier. With the result being that many Go-based ports simply 
>> fail to build for those releases, wasting precious buildbot time.
>> 
>> Just as importantly, the user experience isn’t great, either: There’s no 
>> checking what’s supported where, so ports fail to build, with no indication 
>> as to why. Instead, we should be informing the user that port xyz isn’t 
>> supported on these older releases, if they require a Go version of 1.18+.
>> 
>> While I’m confident we could support the latest version of Go for older 
>> macOS releases too, that work hasn’t been done. There’s been discussion 
>> related to it here-and-there, and folks have offered helpful suggestions. 
>> But little to no tangible progress so far.
>> 
>> In the near term, to both ensure a better user experience - and stop wasting 
>> buildbot time - I’d like to see the ‘golang’ portgroup do the right thing. 
>> At this point, the check is trivial: If a given port requires Go >= 1.18, 
>> and macOS <= 10.12, the port isn’t buildable. Easy-peasy.
>> 
>> Thoughts/concerns?
>> 
>> Cheers,
>> -Chris
> 

macports-legacy-support PR 61 could be the end of Tiger support for MacPorts....

[Ken Cunningham]

Some interested users discovered a deficiency in a part of legacy-support’s 
fdopendir implementation, and have come up with a fix.

due to the way the system on 10.4 works, however, it looks like this fix will 
not work on Tiger.

Unless someone comes up with a trick for this, this could be the end of Tiger 
support for MacPorts.

We all know this is coming one day, but there are some dedicated Tiger users 
out there who will be disappointed by this.

Ken

Re: SDL2 for older systems: which components we need enabled? Cocoa vs X11

[Ken Cunningham]

As I recall, 2.08 built with his patches, but did not actually work, using the 
cocoa interface. This was about 5 years ago, so you’d have to find the ticket. 
I kept the last version that DID work in Leopardports.

If you believe that using sdl2 via x11 will allow some port requiring a newish 
sdl to run usefully on ppc, have a try and see what happens. No need to have a 
long discussion about whether it will or won’t here…. you’ll know soon enough.

My point is that it needs actual testing for FUNCTION, not just building.

K





> On Jul 20, 2023, at 03:36, Sergio Had  wrote:
> 
> 
> P. S. I wonder now if the current SDL2 gonna build with X11 backend and Cocoa 
> off. Given that upstream concentrated efforts on skillfully breaking Cocoa 
> beyond repair, everything else might be intact.
>> On Jul 20, 2023 07:15 +0800, Ken Cunningham 
>> , wrote:
>> As far as I know, we don't have any ports that use SDL2 via X11/Xquartz. All 
>> the ports use the Cocoa interface.
>> 
>> The modifications that were made to SDL2 by miniupnp to run on Tiger and 
>> Leopard were fairly extensive, to an older version of SDL2, but they worked 
>> to allow a number of ports that required libsdl2 to work on those systems. I 
>> have those mods tucked away in the archives of the TigerPorts and 
>> LeopardPorts repos.
>> 
>> Any newer version of libsdl2/SDL2 was not able to be adjusted to be useful 
>> on those older systems. We did have one newer version that would build, but 
>> was so broken by the hacks needed to make it build that it was useless in 
>> practical use.
>> 
>> Which brings me to the next point.
>> 
>> It is quite possible to make hacks/patches to software that will allow it to 
>> build -- at an extreme, you and #if 0 / #endif out that entire source, and 
>> it will compile just fine.
>> 
>> But especially for things like SDL2, what is needed is more than that -- you 
>> have to see if software built against such patched versions will actually 
>> work, and this sometimes takes some fairly extensive testing to see what the 
>> warts might be.
>> 
>> 
>> 
>> Ken
>> 
>> 
>> 
>>> On Jul 19, 2023, at 8:32 AM, Sergey Fedorov  wrote:
>>> 
>>> libsdl 2.0.22 (our Snow Leopard port) builds on PowerPC with unoffensive 
>>> fixes, however I had to disable cocoa video and joystick for that.
>>> They are likely fixable (though no idea whether and how they gonna work), 
>>> but at least cocoa video gonna require a massive rewrite – or perhaps 
>>> falling back to an earlier implementation. (Well, this is not a kind of 
>>> code I can genuinely rewrite – only adapt patches and maybe improve 
>>> something a bit.)
>>> 
>>> However, if X11 implementation is a meaningful replacement, it builds fine 
>>> with no trickery.
>>> 
>>> Any thoughts?
>>> 
>>> P. S. ICE on hidapi is trivially fixable – I just reverted a commit which 
>>> has broken that. After that, hidapi builds fine.
>> 

Re: SDL2 for older systems: which components we need enabled? Cocoa vs X11

[Ken Cunningham]

As far as I know, we don't have any ports that use SDL2 via X11/Xquartz. All 
the ports use the Cocoa interface.

The modifications that were made to SDL2 by miniupnp to run on Tiger and 
Leopard were fairly extensive, to an older version of SDL2, but they worked to 
allow a number of ports that required libsdl2 to work on those systems. I have 
those mods tucked away in the archives of the TigerPorts and LeopardPorts repos.

Any newer version of libsdl2/SDL2 was not able to be adjusted to be useful on 
those older systems. We did have one newer version that would build, but was so 
broken by the hacks needed to make it build that it was useless in practical 
use.

Which brings me to the next point.

It is quite possible to make hacks/patches to software that will allow it to 
build -- at an extreme, you and #if 0 / #endif out that entire source, and it 
will compile just fine.

But especially for things like SDL2, what is needed is more than that -- you 
have to see if software built against such patched versions will actually work, 
and this sometimes takes some fairly extensive testing to see what the warts 
might be.



Ken



> On Jul 19, 2023, at 8:32 AM, Sergey Fedorov  wrote:
> 
> libsdl 2.0.22 (our Snow Leopard port) builds on PowerPC with unoffensive 
> fixes, however I had to disable cocoa video and joystick for that.
> They are likely fixable (though no idea whether and how they gonna work), but 
> at least cocoa video gonna require a massive rewrite – or perhaps falling 
> back to an earlier implementation. (Well, this is not a kind of code I can 
> genuinely rewrite – only adapt patches and maybe improve something a bit.)
> 
> However, if X11 implementation is a meaningful replacement, it builds fine 
> with no trickery.
> 
> Any thoughts?
> 
> P. S. ICE on hidapi is trivially fixable – I just reverted a commit which has 
> broken that. After that, hidapi builds fine.

Re: rldicl / rldicr for 32-bit powerpc?

[Ken Cunningham]

Adding it into cctools for the standard assembler to use whenever it might be 
needed would be something of a project, to be sure...

However, patching it into a source file that needs it on a case-by-case basis 
is probably a fairly trivial thing to do.



> On Jul 15, 2023, at 11:45 AM, Sergio Had  wrote:
> 
> Well, I didn’t mean copy-pasting the patch, of course, it was just the only 
> relevant thing that was found.
> 
> NodeJS uses those instructions in some procedures (either in codebase or 
> PPC-specific patches), and I am looking to fixing it finally for 32-bit.
> On Jul 16, 2023 02:39 +0800, Fred Wright , wrote:
>> 
>> On Sat, 15 Jul 2023, Sergey Fedorov wrote:
>> 
>>> Is there an implementation to replace these on ppc32?
>>> 
>>> There is some Linux version online which I found:
>>> https://patchwork.kernel.org/project/kvm/patch/1403472217-22263-30-git-send-email-ag...@suse.de/
>>> But since it is a magic code, no idea if it is portable or not.
>> 
>> You'd have to be more specific about the intended context. AFAIK,
>> OSX/macOS didn't have anything like KVM until 10.10, so this specific
>> patch wouldn't be relevant.
>> 
>> Fred Wright

3272 R supporting ports ...

[Ken Cunningham]

Although I am truly awed by the amount of effort it required to generate this 
many portfiles from the CRAN network, I'm curious how we are going to try to 
keep this many R supporting ports even marginally up to date with their various 
intertwined updates, dependencies, etc.

Without some kind of automation, this task seems superhuman...or a full-time 
job for someone.

Ken

Re: [MacPorts] #66723: pcre2 @10.42: no such instruction: `lzcnt %eax, %eax'

[Ken Cunningham]

Everything is always open for discussion, being an opensource, volunteer
project, for sure.

We may never do what I suggested, or perhaps some variation of it. Someone
may want to keep around clang-3.4 or 3.7 for some reason.

I just look for the simplest, most direct approach.

gcc10-bootstrap is the last gcc version that can reliably boot from system
roots on all systems (even Tiger, headaches though there may be). So that
will be the launchpad for all the newer gcc versions (gcc12 and 13 at
present). All older systems will need to have access to that. Most users
should get it as a prebuilt binary from the build servers.

The current gcc10-bootstrap is not right yet. It will need to be rebuilt
differently. For example, the "universal" gcc10-bootstrap on Leopard has
the powerpc part as powerpc code and the Intel part as intel code -- so it
is not universal. A powerpc mac cannot use it to build Intel code, for
example.

But once gcc10-bootstrap is properly sorted out someday, using it to build
clang11-bootstrap, and usng that to build a current macOS toolchain and the
latest clang compiler it can build (probably clang-14) seems just sensible.
There is no reason to go through the current clang mess of clang-3.4 ->
clang-3.7 -> clang-9.0 -> clang-12 (I think) -> clang-14 -> clang-current.
That is just -- well -- insanity really.

By "how many involved" if you mean humans, no idea. Anyone who cares to be,
although too many opinions leads to paralysis, as we have seen here before.
Probably not even will be me involved, to be honest, as I have too much too
do elsewhere and I am mostly using an arm Mac running Ventura at present.

On Fri, May 12, 2023 at 6:21 AM MacPorts  wrote:

> #66723: pcre2 @10.42: no such instruction: `lzcnt %eax, %eax'
> -+-
>   Reporter:  kencu   |  Owner:  larryv
>   Type:  defect  | Status:  closed
>   Priority:  Normal  |  Milestone:
>  Component:  ports   |Version:
> Resolution:  fixed   |   Keywords:  leopard
>   Port:  pcre2   |
> -+-
>
> Comment (by mascguy):
>
>  Replying to [comment:6 kencu]:
>  > By the way, my "long term" plan for the toolchain on older systems
>  (everything < 10.11, say), would be to have gcc10-bootstrap build
>  clang-11-bootstrap, and then use that to build the toolchain.
>  >
>  > So clang-3.3, 3.4, 5.0, 6,0, 7.0, 8.0, 9.0, and 10 would all disappear.
>
>  While I like that idea in principle, it's also nice to be able to have a
>  slimmed-down MacPorts installation. But if folks have to wait many hours -
>  or several days, for old PPC machines - for toolchain components to build
>  from source... yikes!
>
>  Just curious, how many would be involved, with the new approach?
>
> --
> Ticket URL: 
> MacPorts 
> Ports system for macOS
>

some jackass hosed the wikistart page

[Ken Cunningham]

don't recognize the username

Re: For anyone looking for a worthy project -> not one of the boost ports can build universal x86_64/arm64, which prevents a lot of ports from building universal

[Ken Cunningham]

building boost 176 universal on my M1 bogs down in the selection of the 
assembly context files. All the correct assembly files are not included, so the 
link phase fails.

It looks fixable, but have to sort out how to get them right.

Re: For anyone looking for a worthy project -> not one of the boost ports can build universal x86_64/arm64, which prevents a lot of ports from building universal

[Ken Cunningham]

thanks, that looks like a good start !

For anyone looking for a worthy project -> not one of the boost ports can build universal x86_64/arm64, which prevents a lot of ports from building universal

[Ken Cunningham]

just thought I'd point that one out, for interested folks.

Best,

Ken

Re: Legacy Support for GHC-Based Projects

[Ken Cunningham]

I sorted out the issue I was having with Template Haskell not finding it's 
shared libraries, thankfully not too hard in the end to fix.

I also sorted out how to force the use of only system libraries.

Finally, I made a static archive with the emulated TLS objects (same procedure 
that gcc uses, as it only uses emulated TLS too), and embedded that into the 
ghc executable, so I don't think there will be any more external linkages to 
any libraries or symbols any longer.

This x86_64 archive of pandoc 3.0 works on 10.6.8, 10.7, and on an arm64 
Ventura system under Rosetta.

https://github.com/kencu/ghc-for-older-darwin-systems/releases/download/9.4.4/pandoc-3.0-x86_64-apple-darwin10.zip


I can show someone how to reproducibly build this, I believe, using my 
ghc-for-older-systems toolchain, legacysupport, and the emutls.a archive I 
made, but making a portfile for it would be a bit of a project. The cabal 
config file needs some interesting additions to make everything work and force 
the system libs...

Hope this is useful. Perhaps it might be used as a binary at least, until 
things are further sorted.

Ken




> On Jan 28, 2023, at 6:57 PM, Ken Cunningham  
> wrote:
> 
> So, some success. I have now managed to build pandoc on 10.6.8, and it seems 
> to work as expected.
> 
> A small bit of unpleasant hackery is currently involved, that with any luck 
> will be fixed upstream somehow. Exactly how to fix this upstream is not clear 
> to me just yet:
> 
> https://github.com/haskell/cabal/issues/8704
> 
> https://github.com/jgm/unicode-collation/issues/13
> 
> I still have a few packaging issues to work out (it links to MacPorts’ libz 
> instead of the system libz, for one, and it uses 10.6.8’s version of 
> thread-local-storage using emutls that will need to be sorted out before this 
> binary could be used on 10.7+, but the basic plan does work.
> 
> Ken
> 

Re: ports website says port has been deleted ... but it is there.

[Ken Cunningham]

oh, maybe it’s because the ports installation of macports does not accept the 
extract.rename option yet because it hasn’t been updated yet…

K

> On Feb 3, 2023, at 07:55, Ken Cunningham  
> wrote:
> 
> Perhaps because the buildbots are down? Not sure why else this would say the 
> port is deleted..
> 
> https://ports.macports.org/port/codeblocks-devel/
> 
> but here it is:
> 
> https://github.com/macports/macports-ports/blob/master/devel/codeblocks-devel/Portfile
> 
> Ken

ports website says port has been deleted ... but it is there.

[Ken Cunningham]

Perhaps because the buildbots are down? Not sure why else this would say the 
port is deleted..

https://ports.macports.org/port/codeblocks-devel/

but here it is:

https://github.com/macports/macports-ports/blob/master/devel/codeblocks-devel/Portfile

Ken

Re: Legacy Support for GHC-Based Projects

[Ken Cunningham]

So, some success. I have now managed to build pandoc on 10.6.8, and it seems to 
work as expected.

A small bit of unpleasant hackery is currently involved, that with any luck 
will be fixed upstream somehow. Exactly how to fix this upstream is not clear 
to me just yet:

https://github.com/haskell/cabal/issues/8704

https://github.com/jgm/unicode-collation/issues/13

I still have a few packaging issues to work out (it links to MacPorts’ libz 
instead of the system libz, for one, and it uses 10.6.8’s version of 
thread-local-storage using emutls that will need to be sorted out before this 
binary could be used on 10.7+, but the basic plan does work.

Ken




> On Jan 26, 2023, at 3:28 AM, Steven Smith  wrote:
> 
> The path to Haskell is paved with good intentions—there’s a ticket for this 
> now because pandoc stopped building on some older systems after I specified 
> stack as the build tool: https://trac.macports.org/ticket/66764
> 
> Back to cabal.
> 
>> On Jan 25, 2023, at 11:29 AM, Ken Cunningham 
>>  wrote:
>> 
>> Stack from MacPorts doesn’t build on snow leopard, and I don’t recall it 
>> ever built in previous years.
>> 
>> The port health page can be pretty misleading, to be honest.
>> 
>> You can get a much better idea of what is really building here:
>> 
>> https://packages.macports.org/stack/
>> 
>> https://packages.macports.org/ghc/
>> 
>> 
>> Ken
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Jan 25, 2023, at 7:27 AM, Steven Smith  wrote:
>>> 
>>> I’d recommend starting with the low-hanging fruit. These are all 
>>> stack-based builds, and stack can build itself back to Snow Leopard: 
>>> https://ports.macports.org/port/stack/details/
>>> 
>>> Why doesn’t stack-based pandoc also build back to Snow Leopard? Is this a 
>>> MacPorts issue or a Haskell-world issue?
>>> 
>>>> On Jan 24, 2023, at 11:56, Ken Cunningham 
>>>>  wrote:
>>>> 
>>>> At least some of the buildbot ghc builds might be fixable — one of them 
>>>> failed due to a missing png-config I believe, for example.
>>>> 
>>>> Because of the way upstream builds ghc on macos, their older system 
>>>> support has become more limited. They use homebrew, and current systems, 
>>>> with an older deployment target set. This has become less viable to run on 
>>>> older systems as time goes by.
>>>> 
>>>> It is possible to build up from older versions of ghc on an older system, 
>>>> however… and by doing that, with a couple of tiny patches, for strnlen 
>>>> etc, and stepping up system by system, up to the current ghc 9.4.4 runs as 
>>>> far back as 10.6 at least, and maybe could be made to work on 10.5 Intel. 
>>>> 
>>>> i386 builds had bitrotted last I tried, as had ppc builds, so I gave up on 
>>>> those arches.
>>>> 
>>>> Once you have ghc, you can bootstrap a build of cabal-install from the 
>>>> bootstrap folder in their git repo. Legacy-support is required. I have 
>>>> several current cabal versions running back to 10.6 anyway, though, that 
>>>> could be used instead of bootstrapping cabal. These are available in the 
>>>> repo below.
>>>> 
>>>> Once you have cabal, you can build a version of stack using cabal from the 
>>>> stack git repo. Because of the way stack downloads current ghc versions 
>>>> from upstream, much of stack won’t be usable anyway, although you can 
>>>> override the ghc selected (works), add legacy-support, and sometimes it 
>>>> will build something that cabal won’t build.
>>>> 
>>>> Then you can build most of what you want, like pandoc and shellcheck. 
>>>> There will be occasional minor patches needed to “cbits” parts, though, in 
>>>> some packages. 
>>>> 
>>>> I have this working locally, but have not Portfiled it. Binaries and some 
>>>> initial instructions are here:
>>>> 
>>>> 
>>>> https://github.com/kencu/ghc-for-older-darwin-systems
>>>> 
>>>> https://github.com/kencu/ghc-for-older-darwin-systems/releases/tag/9.4.4
>>>> 
>>>> 
>>>> I did find one minor hiccup building something on 10.7 one time, where the 
>>>> emutls symbol used on 10.6 for TLS was not found when building something 
>>>> using TLS on 10.7. I didn’t sort that out as yet.
>>>> 
>>>> Is it something that could be Portfiled? Sure, anything can be. I haven’t 
>>>> approached that as yet.  
>>>> 
>>>> Perhaps it would be acceptable to make the binaries of pandoc and 
>>>> shellcheck that run on older systems available? Usually this is not 
>>>> considered OK, but .. 
>>>> 
>>>> I’ll work on it some more as I get time. Building the most current pandoc 
>>>> is stuck at the moment as it uses Template Haskell in one of its support 
>>>> packages, and there is a linker error occurring related to that. 
>>>> 
>>>> Debugging the builds of ghc software is harder than clang or gcc builds… 
>>>> everything is quite different, often.
>>>> 
>>>> Ken
>>>> 
>>>> 
>> 
> 

Re: Legacy Support for GHC-Based Projects

[Ken Cunningham]

Stack from MacPorts doesn’t build on snow leopard, and I don’t recall it ever 
built in previous years.

The port health page can be pretty misleading, to be honest.

You can get a much better idea of what is really building here:

https://packages.macports.org/stack/

https://packages.macports.org/ghc/


Ken







> On Jan 25, 2023, at 7:27 AM, Steven Smith  wrote:
> 
> I’d recommend starting with the low-hanging fruit. These are all stack-based 
> builds, and stack can build itself back to Snow Leopard: 
> https://ports.macports.org/port/stack/details/
> 
> Why doesn’t stack-based pandoc also build back to Snow Leopard? Is this a 
> MacPorts issue or a Haskell-world issue?
> 
>> On Jan 24, 2023, at 11:56, Ken Cunningham  
>> wrote:
>> 
>> At least some of the buildbot ghc builds might be fixable — one of them 
>> failed due to a missing png-config I believe, for example.
>> 
>> Because of the way upstream builds ghc on macos, their older system support 
>> has become more limited. They use homebrew, and current systems, with an 
>> older deployment target set. This has become less viable to run on older 
>> systems as time goes by.
>> 
>> It is possible to build up from older versions of ghc on an older system, 
>> however… and by doing that, with a couple of tiny patches, for strnlen etc, 
>> and stepping up system by system, up to the current ghc 9.4.4 runs as far 
>> back as 10.6 at least, and maybe could be made to work on 10.5 Intel. 
>> 
>> i386 builds had bitrotted last I tried, as had ppc builds, so I gave up on 
>> those arches.
>> 
>> Once you have ghc, you can bootstrap a build of cabal-install from the 
>> bootstrap folder in their git repo. Legacy-support is required. I have 
>> several current cabal versions running back to 10.6 anyway, though, that 
>> could be used instead of bootstrapping cabal. These are available in the 
>> repo below.
>> 
>> Once you have cabal, you can build a version of stack using cabal from the 
>> stack git repo. Because of the way stack downloads current ghc versions from 
>> upstream, much of stack won’t be usable anyway, although you can override 
>> the ghc selected (works), add legacy-support, and sometimes it will build 
>> something that cabal won’t build.
>> 
>> Then you can build most of what you want, like pandoc and shellcheck. There 
>> will be occasional minor patches needed to “cbits” parts, though, in some 
>> packages. 
>> 
>> I have this working locally, but have not Portfiled it. Binaries and some 
>> initial instructions are here:
>> 
>> 
>> https://github.com/kencu/ghc-for-older-darwin-systems
>> 
>> https://github.com/kencu/ghc-for-older-darwin-systems/releases/tag/9.4.4
>> 
>> 
>> I did find one minor hiccup building something on 10.7 one time, where the 
>> emutls symbol used on 10.6 for TLS was not found when building something 
>> using TLS on 10.7. I didn’t sort that out as yet.
>> 
>> Is it something that could be Portfiled? Sure, anything can be. I haven’t 
>> approached that as yet.  
>> 
>> Perhaps it would be acceptable to make the binaries of pandoc and shellcheck 
>> that run on older systems available? Usually this is not considered OK, but 
>> .. 
>> 
>> I’ll work on it some more as I get time. Building the most current pandoc is 
>> stuck at the moment as it uses Template Haskell in one of its support 
>> packages, and there is a linker error occurring related to that. 
>> 
>> Debugging the builds of ghc software is harder than clang or gcc builds… 
>> everything is quite different, often.
>> 
>> Ken
>> 
>> 

Re: Legacy Support for GHC-Based Projects

[Ken Cunningham]

At least some of the buildbot ghc builds might be fixable — one of them failed 
due to a missing png-config I believe, for example.

Because of the way upstream builds ghc on macos, their older system support has 
become more limited. They use homebrew, and current systems, with an older 
deployment target set. This has become less viable to run on older systems as 
time goes by.

It is possible to build up from older versions of ghc on an older system, 
however… and by doing that, with a couple of tiny patches, for strnlen etc, and 
stepping up system by system, up to the current ghc 9.4.4 runs as far back as 
10.6 at least, and maybe could be made to work on 10.5 Intel. 

i386 builds had bitrotted last I tried, as had ppc builds, so I gave up on 
those arches.

Once you have ghc, you can bootstrap a build of cabal-install from the 
bootstrap folder in their git repo. Legacy-support is required. I have several 
current cabal versions running back to 10.6 anyway, though, that could be used 
instead of bootstrapping cabal. These are available in the repo below.

Once you have cabal, you can build a version of stack using cabal from the 
stack git repo. Because of the way stack downloads current ghc versions from 
upstream, much of stack won’t be usable anyway, although you can override the 
ghc selected (works), add legacy-support, and sometimes it will build something 
that cabal won’t build.

Then you can build most of what you want, like pandoc and shellcheck. There 
will be occasional minor patches needed to “cbits” parts, though, in some 
packages. 

I have this working locally, but have not Portfiled it. Binaries and some 
initial instructions are here:


https://github.com/kencu/ghc-for-older-darwin-systems

https://github.com/kencu/ghc-for-older-darwin-systems/releases/tag/9.4.4


I did find one minor hiccup building something on 10.7 one time, where the 
emutls symbol used on 10.6 for TLS was not found when building something using 
TLS on 10.7. I didn’t sort that out as yet.

Is it something that could be Portfiled? Sure, anything can be. I haven’t 
approached that as yet.  

Perhaps it would be acceptable to make the binaries of pandoc and shellcheck 
that run on older systems available? Usually this is not considered OK, but .. 

I’ll work on it some more as I get time. Building the most current pandoc is 
stuck at the moment as it uses Template Haskell in one of its support packages, 
and there is a linker error occurring related to that. 

Debugging the builds of ghc software is harder than clang or gcc builds… 
everything is quite different, often.

Ken

Re: Location to store Rust binaries

[Ken Cunningham]

Here is a commit where I installed a binary from the packages server onto a 
different system than it belonged to.

Something similar might work to install the 10.9 binary of rust-bootstrap on 
10.5 through 10.8…

https://github.com/macports/macports-ports/commit/39f5b1344934fd8777143d548c2fb04ef4affec6



Ken

Re: Location to store Rust binaries

[Ken Cunningham]

although the 10.9 one needed has not as yet been built it seems.You would also have to manually access and download the 10.9 binary on older systems, as the automatic mechanism to install it wouldn’t work where it’s needed.KOn Dec 22, 2022, at 05:02, Ken Cunningham  wrote:they are thereIndex of /rust-bootstrappackages.macports.orgOn Dec 22, 2022, at 01:30, Chris Jones  wrote:On 22 Dec 2022, at 4:02 am, mcalh...@macports.org wrote:As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.The problem is that the Rust binaries provided by upstream only work on macOS 10.9 and above.To get around this, there is a rust-bootstrap port that build Rust binaries on 10.9+ intended to build Rust on previous macOS version.Currently, these binaries are stored on using my personal GitHub account.So the entire upgrade process is essentially:1) Update the version in rust-bootstrap.2) Build Rust binaries on a 10.9 VM.3) Upload Rust binaries to GitHub account.4) On older machines, use MacPorts Rust binaries to build Rust.    On newer machines, us the upstream provides binaries to build Rust.This is far from ideal, but it has allowed us to get Rust working back to 10.5 (both i386 and x86_64).This entire procedure may be modified, and there are a few suggestions on the mailing list(https://lists.macports.org/pipermail/macports-dev/2022-December/thread.html#44855).However, until consensus is reached about major changes, it would be nice to make some incremental improvements.The easiest change: does anyone know of a better place to store the MacPorts generated binaries?More challenging: can anyone think of a way to automate the process of building the MacPorts Rust binaries after rust-bootstrap is update?I am sure I am missing something but if the bootstrap binaries are generated via a port, rust-bootstrap, why cannot the usual mechanism for distributing the port as a binary not be used ?Chris-Marcus

Re: Location to store Rust binaries

[Ken Cunningham]

they are thereIndex of /rust-bootstrappackages.macports.orgOn Dec 22, 2022, at 01:30, Chris Jones  wrote:On 22 Dec 2022, at 4:02 am, mcalh...@macports.org wrote:As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.The problem is that the Rust binaries provided by upstream only work on macOS 10.9 and above.To get around this, there is a rust-bootstrap port that build Rust binaries on 10.9+ intended to build Rust on previous macOS version.Currently, these binaries are stored on using my personal GitHub account.So the entire upgrade process is essentially:1) Update the version in rust-bootstrap.2) Build Rust binaries on a 10.9 VM.3) Upload Rust binaries to GitHub account.4) On older machines, use MacPorts Rust binaries to build Rust.    On newer machines, us the upstream provides binaries to build Rust.This is far from ideal, but it has allowed us to get Rust working back to 10.5 (both i386 and x86_64).This entire procedure may be modified, and there are a few suggestions on the mailing list(https://lists.macports.org/pipermail/macports-dev/2022-December/thread.html#44855).However, until consensus is reached about major changes, it would be nice to make some incremental improvements.The easiest change: does anyone know of a better place to store the MacPorts generated binaries?More challenging: can anyone think of a way to automate the process of building the MacPorts Rust binaries after rust-bootstrap is update?I am sure I am missing something but if the bootstrap binaries are generated via a port, rust-bootstrap, why cannot the usual mechanism for distributing the port as a binary not be used ?Chris-Marcus

Re: Dev guide updated for github/easy instructions?

[Ken Cunningham]

I believe you’re looking for this:4.6. Local Portfile Repositoriesguide.macports.orgOn Dec 19, 2022, at 07:05, Watson Ladd  wrote:On Mon, Dec 12, 2022, 1:55 PM Nils Breunese  wrote:Does https://guide.macports.org/chunked/project.github.html help?A bit. What I don't know how to do is get macports to use the modified port file. The best I can figure out is use the whole different tree, which is mildly annoying if I forget to set it back.

Nils.

P.S. I believe macports-...@lists.macosforge.org is the old address of this mailing list, macports-dev@lists.macports.org is the new one.

> Op 12 dec. 2022, om 16:35 heeft Watson Ladd  het volgende geschreven:
> 
> This morning I realized that Pari is lagging behind, so went ahead to
> start contributing a version bump. Unfortunately i completely forgot
> the song and dance to make Macports process the portfile I produced,
> and then the documentation was very pre-github migration (assumes
> individual port files vs checking out the repo).
> 
> Perhaps we should have a development guide update, and in the meantime
> do i just update the sources to include my local checkout? I could
> have sworn I've done this before, but just forgot how.
> 
> Sincerely,
> Watson
> 
> -- 
> Astra mortemque praestare gradatim

Re: The State of Rust in MacPorts Today

[Ken Cunningham]

It looks like Marcus is working on this.

K

Refined Github

[Ken Cunningham]

For anyone who uses GitHub a lot, like the people on this list likely do, I 
came across Refined Github a few months ago, and I find it is quite helpful.

It’s browser extension that adds considerable functionality to Github, 
basically.

Thought I’d share:

https://github.com/refined-github/refined-github


K

Re: using /usr/bin/python3 on Ventura +

[Ken Cunningham]

Well, it didn’t take very long for that to be a problem. Building llvm and 
clang-9.0 went OK, but building lldb-9.0 fails:

- Check size of el_rfunc_t - done
-- Found PythonLibs: 
/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib
 (found version "3.10.8")  CMake Error at 
tools/lldb/cmake/modules/LLDBConfig.cmake:234 (message):
  Found incompatible Python interpreter (3.9) and Python libraries (3.10)
Call Stack (most recent call first):
  tools/lldb/CMakeLists.txt:20 (include)


-- Configuring incomplete, errors occurred!
See also 
"/opt/local/var/macports/build/_opt_macportsofficial_macports-ports_lang_llvm-9.0/lldb-9.0/work/build/CMakeFiles/CMakeOutput.log".
See also 
"/opt/local/var/macports/build/_opt_macportsofficial_macports-ports_lang_llvm-9.0/lldb-9.0/work/build/CMakeFiles/CMakeError.log".
Command failed:  cd 
"/opt/local/var/macports/build/_opt_macportsofficial_macports-ports_lang_llvm-9.0/lldb-9.0/work/build"
 && /opt/local/bin/cmake -DCMAKE_INSTALL_PREFIX='/opt/local/libexec/llvm-9.0' 
-DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON 
-DCMAKE_C_COMPILER="$CC" -DCMAKE_COLOR_MAKEFILE=ON -DCMAKE_CXX_COMPILER="$CXX" 
-DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_MAKE_PROGRAM=/usr/bin/make 
-DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules 
-DCMAKE_SYSTEM_PREFIX_PATH="/opt/local/libexec/llvm-9.0;/opt/local;/usr" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -Wno-dev 
-DCMAKE_SYSTEM_PREFIX_PATH="/opt/local/libexec/llvm-9.0;/opt/local;/usr" 
-DLLVM_LINK_LLVM_DYLIB=ON -DLLVM_ENABLE_ASSERTIONS=OFF -DLLVM_ENABLE_RTTI=ON 
-DLLVM_INCLUDE_TESTS=OFF -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_ENABLE_FFI=ON 
-DLLVM_BINDINGS_LIST=none -DFFI_INCLUDE_DIR=`pkg-config --cflags-only-I libffi 
| sed 's/-I//'` -DFFI_LIBRARY_DIR=/opt/local/lib 
-DDARWIN_osx_ARCHS="x86_64;x86_64h" -DLLDB_CODESIGN_IDENTITY=- 
-DCLANG_ENABLE_ARCMT=OFF -DCLANG_INCLUDE_TESTS=OFF 
-DCLANG_ENABLE_STATIC_ANALYZER=OFF -DLLVM_BUILD_RUNTIME=ON 
-DLIBCXX_ENABLE_SHARED=OFF -DLIBCXX_INSTALL_LIBRARY=OFF 
-DPYTHON_EXECUTABLE=/usr/bin/python3 -DCMAKE_C_FLAGS_RELEASE="-DNDEBUG" 
-DCMAKE_CXX_FLAGS_RELEASE="-DNDEBUG" -DCMAKE_OSX_ARCHITECTURES="x86_64" 
-DCMAKE_OSX_DEPLOYMENT_TARGET="13.0" 
-DCMAKE_OSX_SYSROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk" 
../llvm-9.0.1.src  Exit code: 1


I think we have to spec the pythons, rather than mess around with the system 
versions. It works sometimes to use the system versions, but not reliably 
enough to count on all the time.

Ken



> On Nov 26, 2022, at 11:13 AM, Ken Cunningham 
>  wrote:
> 
> Trying to sort out some builds that need a python, as python2.7 is now gone 
> from /usr/bin on newer systems.
> 
> It looks like you can reliably use /usr/bin/python3 on these systems if you 
> have either the CLTs or Xcode installed.
> 
> The version is currently 3.9.6 on Ventura, and may not be the same from 
> release to release, but that may be OK for simple “needs a python” uses, like 
> configuring llvm.
> 
> You folks OK with using this, or do you want the full python3.10 installation 
> instead?
> 
> 
> 
> % DEVELOPER_DIR=/Library/Developer/CommandLineTools /usr/bin/python3 --help
> usage: /Library/Developer/CommandLineTools/usr/bin/python3 
> 
> % /usr/bin/python3 --help
> usage: /Applications/Xcode.app/Contents/Developer/usr/bin/python3 
> 
> 
> 
> 

using /usr/bin/python3 on Ventura +

[Ken Cunningham]

Trying to sort out some builds that need a python, as python2.7 is now gone 
from /usr/bin on newer systems.

It looks like you can reliably use /usr/bin/python3 on these systems if you 
have either the CLTs or Xcode installed.

The version is currently 3.9.6 on Ventura, and may not be the same from release 
to release, but that may be OK for simple “needs a python” uses, like 
configuring llvm.

You folks OK with using this, or do you want the full python3.10 installation 
instead?



% DEVELOPER_DIR=/Library/Developer/CommandLineTools /usr/bin/python3 --help
usage: /Library/Developer/CommandLineTools/usr/bin/python3 

% /usr/bin/python3 --help
usage: /Applications/Xcode.app/Contents/Developer/usr/bin/python3 

Re: having the "+test" or "+tests" variant propagate causes unexpected builds

[Ken Cunningham]

I wonder if there was consideration given way-back-when to the idea of having 
NO propagation of variants at all.

Anything you wanted to apply to every port, you would put in variants.conf. 
Otherwise, your variant applied to the port you were currently installing, and 
that is it.

To me — that makes quite a bit of sense, actually…might solve a lot of problems.

But I’m sure some scenario arises where it was needed.

K

having the "+test" or "+tests" variant propagate causes unexpected builds

[Ken Cunningham]

Various ports implement a “test” or “tests” variant to allow extra features and 
deps required for testing to be enabled.

This variant, when requested, will propagate up the chain to all the ports, 
however.  There is no real use case where someone would desire the test/s 
variant to propagate up.

This generates needless builds, and often enables features people neither need 
nor want, and then guarantees manual rebuilds, forever, of the involved ports.

I recently came back to a massive building project involving clang and llvm 
when I was trying to build “mesa +tests”. Because clang-15 and llvm-15 also 
have a “+tests” variant, and had not yet been installed, port was building 
those (and possibly others) with the tests variant rather than use the prebuilt 
binary.

Of course I just aborted the huge llvm/clang-15 build, cleaned them up, and 
installed them separately. But others would probably not know to do this.

I had suggested a few years ago we might namespace the test/tests variants, by 
having a convention that the portname be prepended to the test variant, to be 
more specific and avoid this — but not a widely acceptable idea at that time. 
So we’re still in the same situation…

Is it possible that a “test” or “tests” variant might not be propagated up the 
ports chain by base, instead? 


K



PS. A similar thing happens with “+debug” variants, another common variant that 
you *usually* don’t want propagated up to *every single port* in the chain 
either. 

This one is occasionally something that people would want up their chain, but 
it is so fragile of a plan to rely on variant propagation (ie if you have the 
port installed already, it won’t be reinstalled with the “+debug” variant), 
that such rare users might best install each port they want to be installed as 
“debug” do that specifically. Certainly most of us don’t want clang-15 
installed with it’s debug variant when you’re trying to debug some little port.

Re: MacPorts 2.8.0-beta1 now available for testing

[Ken Cunningham]

the only other thing I noticed was that these helpful pre-fetch messages were 
no longer being displayed:

https://github.com/macports/macports-ports/blob/c7a8d3cf75b8b48a90139cbb35e385bb7bcbd165/x11/xorg-server/Portfile#L103


Instead there was just a message saying the build was known to fail, but try 
anyway?

But the instructions about what to actually do are gone now…

Perhaps no way around that?

K

transient error with macports-base 2.8: Error: Unable to execute port: sqlite error: another row available (100) while executing query: SELECT cxx_stdlib FROM registry.ports WHERE id=109

[Ken Cunningham]

FYI, I saw this issue after upgrading to macports-base 2.8 on 10.13 from 
current git master 2.8 release:

$ sudo port -v destroot fluxbox
Error: Unable to execute port: sqlite error: another row available (100) while 
executing query: SELECT cxx_stdlib FROM registry.ports WHERE id=109

$ sudo port clean fluxbox
--->  Cleaning fluxbox

$ sudo port -v destroot fluxbox
Error: Unable to execute port: sqlite error: another row available (100) while 
executing query: SELECT cxx_stdlib FROM registry.ports WHERE id=109

$ port -v
MacPorts 2.7.99
Entering shell mode... ("help" for help, "quit" to quit)
> quit
Goodbye



So I installed a couple of other ports (wget, aria2) and then tried again, and 
there was no such error after that.

$ sudo port -v destroot fluxbox
--->  Computing dependencies for fluxbox.
--->  Fetching distfiles for fluxbox
--->  Verifying checksums for fluxbox
--->  Checksumming fluxbox-1.3.7.tar.bz2
--->  Extracting fluxbox
--->  Extracting fluxbox-1.3.7.tar.bz2

— and so on


I was hoping for a nice, tight, reproducible error report, but this is what I 
have instead. FWIW.



Ken

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

[Ken Cunningham]

As per the ticket, I noted system apps (like iCal) crash when I upgraded the 
libc++ on Lion to the one we supply with libcxx, so that, for me, is 
unreliable. I didn’t try every system or every app of course.

Mixing libc++ versions in one executable’s dylib space crashes unpredictably 
sometimes. 

libc++ specifically does not promise that structures are identical between 
libc++ versions, even if the ABI is the same. So although you can use a newer 
libc++ with an older application, via accessors etc, that doesn’t mean you can 
pass structures/objects between different libc++ versions.

The best way to add filesystem to older systems is probably to add it to 
compiler_rt on older systems. And might as well do the three missing exception 
handlers at the same time.

(Adding it to legacysupport is harder because of the compiler requirements to 
build it.)

K

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Ken Cunningham]

Steve, some thoughts, as I helped you fix issue this last time.

> Also, I’m perplexed with this doesn’t just work with the default MacPorts 
> compiler.cpath and compiler.library_path settings. 

It seems this prebuilt bootstrap library you are using:

> /opt/local/var/macports/build/_opt_local_ports_lang_ghc/ghc/work/bootstrap/opt/local//lib/ghc-9.4.2/lib/x86_64-osx-ghc-9.4.2/base-4.17.0.0/libHSbase-4.17.0.0.a

Has been prebuilt against the system iconv with the system symbol names, and as 
it is prebuilt, you can’t change it. So you are forced to link against the 
system libiconv, as MacPorts libiconv will not be able to provide the needed 
symbols. 

The simplest way to accomplish that is to either clear LIBRARY_PATH like we did 
before to fix this, or set LIBRARY_PATH=/usr/lib, but I guess that either 
doesn’t work with hadrian or doesn’t do what you need it to do for some other 
reason.


Another way to force a specific libiconv.dylib is to specify the full pathname 
to the libiconv library you need to use, rather than use -liconv, like this:

LIBRARY_PATH='/opt/local/lib' clang -o hello -Wl,/usr/lib/libiconv.dylib hello.c

% otool -L hello
hello:
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 
7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1311.100.3)



NB. just don’t leave the old -liconv dangling as well, or you get this mess, 
which you surely don’t want:

LIBRARY_PATH='/opt/local/lib' clang -o hello -Wl,/usr/lib/libiconv.dylib 
-liconv  hello.c
% otool -L hello
hello:
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 
7.0.0)
/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current 
version 9.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1311.100.3)



Note, it can be fragile to force /usr/lib/libiconv.dylib, as if there is 
anything else from MacPorts building and linking against libiconv with that 
link line, it will now try to link against the system libiconv version rather 
than the MacPorts version, and it will error out due to incorrect names, but in 
the opposite way.  

So — have to see what happens in that case, but there are ways that might be 
worked around too, by forcing -I to pick up the system iconv.h first.

Ken

EGL support on MacOS?

[Ken Cunningham]

I am not an expert on OpenGL support on any system, just trying to get
things built, and looking for someone who might know more about it for
ideas...

The linux world seems to be moving towards EGL based on a number of recent
changes I have seen in webkit2-gtk, gtk4, and other places, that I think at
least in part are due to improvements in EGL support, performance, and
moving to Wayland.

Newer software, for example the x11 version of gtk4, seems to assume EGL is
present. Although it might be possible to #ifdef into the source to make
this not happen on Apple, and use what I believe is the fallback of GLX,
that is getting to be work and may not be much tested upstream.

An EGL implementation for Apple would be a more easily supportable fix, it
would seem.

There is one in mesa, currently disabled in our port, that I was able to
get to build with a small patch and a toggle in the Portfile. That allowed
libepoxy to build with EGL support as well (with a toggle and two small
patches). But performance seemed poor, and there were lots of warning
messages and errors running software built with that. Looks quite raw.

Many projects (webkit, etc) seem to be moving to ANGLE for this support.
This is actively maintained and as far as I can see, looks to be the future
for a GL compatibility layer. Some ports (webkit2-gtk at least) bundle
ANGLE and it builds on MacOS. There is no MacPorts port for ANGLE as yet,
at least that I can see.

You can see the ANGLE build in webkit2-gtk like this:

nm /opt/local/lib/libwebkit2gtk-4.0.37.44.4.dylib | grep ANGLE

So - that is where my current knowledge ends. I am imagining that we will
need an EGL implementation, possibly via ANGLE (or mesa, if it is
performant), to allow (reasonably easy) ongoing support of x11 software
builds.

If anyone has a nice depth of knowledge in this area and can shed more
light on it / knows a better plan / knows of a current EGL solution I have
missed so far, please add what you wish.

Ken

Re: ld: waning messages -- Frameworks out of sync.

[Ken Cunningham]

Yes, exactly -- I made a new TBD file for the library using "tapi stubify"
and replaced the old TBD file with it, for the ones that were outdated.

The script seems like a nice way to automate the process -- thanks for
finding that.

K

On Thu, Aug 18, 2022 at 1:32 PM Robert Kennedy  wrote:

> Thanks Ken!
>
> Letting me know that the "tapi" command is the key to the fix was a big
> help.
>
> I did a quick google search for "tapi stubify" and found that someone has
> already created a ruby script to fix the problem.  But one needs to disable
> System Integrity Protection (SIP) first before running the script.  Once
> the script is run, one can re-enable SIP.
>
> See
> https://gist.github.com/sv99/c9d8c155db7db83325847bd33b25e1d0
>
> I assume you used *tapi stubify *and did manually what was in this script.
>
> If you used a different approach, please let me know.
>
> Rob
> --
> *From:* macports-dev  on behalf
> of Ken Cunningham 
> *Sent:* August 18, 2022 2:34 PM
> *To:* MacPorts Developers 
> *Subject:* Re: ld: waning messages -- Frameworks out of sync.
>
> > Otherwise, one needs to set SDKROOT as follows:
>
> > export SDKROOT=$(xcrun --show-sdk-path)
>
> > It is best to set SDKROOT in one's ~/.bash_profile
>
> If you do that, you will possibly override MacPorts setting of SDKROOT, and 
> this is likely to cause you many problems when building ports.
>
> I would suggest you just ignore the warning -- the linker knows to use the 
> library if the TBD file is out of sync, as it has said in it's message.
>
> Otherwise, you can fix the TBD file (which is what I did) by using the tapi 
> tool:
>
> $ tapi
> OVERVIEW: Text-based Stubs Tool
>
> USAGE: tapi [--version][--help]
>tapi  []
>
> Commands:
>   archive Merge or thin text-based stub files
>   stubify Create a text-based stub file from a library
>   installapi  Create a text-based stub file by scanning the header files
>   reexportCreate a linker reexport file by scanning the header files
>
> See 'tapi  --help' to read more about a specific command.
>
> Of course, you may not want to do that -- but that is less intrusive than 
> setting the SDKROOT I would say, if the warnings are really bothersome to you.
>
> Best,
>
> Ken
>
>

Re: ld: waning messages -- Frameworks out of sync.

[Ken Cunningham]

> Otherwise, one needs to set SDKROOT as follows:

> export SDKROOT=$(xcrun --show-sdk-path)

> It is best to set SDKROOT in one's ~/.bash_profile

If you do that, you will possibly override MacPorts setting of
SDKROOT, and this is likely to cause you many problems when building
ports.

I would suggest you just ignore the warning -- the linker knows to use
the library if the TBD file is out of sync, as it has said in it's
message.

Otherwise, you can fix the TBD file (which is what I did) by using the
tapi tool:

$ tapi
OVERVIEW: Text-based Stubs Tool

USAGE: tapi [--version][--help]
   tapi  []

Commands:
  archive Merge or thin text-based stub files
  stubify Create a text-based stub file from a library
  installapi  Create a text-based stub file by scanning the header files
  reexportCreate a linker reexport file by scanning the header files

See 'tapi  --help' to read more about a specific command.

Of course, you may not want to do that -- but that is less intrusive
than setting the SDKROOT I would say, if the warnings are really
bothersome to you.

Best,

Ken

Re: compilers PortGroup

[Ken Cunningham]

> Error: Rank mismatch between actual argument at (1) and actual argument at 
> (2) (rank-1 and scalar)
> To work around this, you need to add -fallow-argument-mismatch to the FFLAGS 
> inside Makefile:

Funny, that is exactly the argument that:
compilers.allow_arguments_mismatch yes
is supposed to add for you to fix this. Now I wonder why it doesn’t add it?

What port are you trying to build again? Something fishy here, it seems.

K

Re: compilers PortGroup

[Ken Cunningham]

> :info:build 595 | call isortii(nodef,iorder,nopes,kflag) 
> :info:build | 1 
> :info:build Error: Rank mismatch between actual argument at (1) and actual 
> argument at (2) (scalar and rank-1) 
> :info:build make: *** [gencontelem_n2f.o] Error 1 

perhaps it might be worth trying this option?

compilers.allow_arguments_mismatch


https://github.com/macports/macports-ports/blob/8f07e286eac6e7fa7c9bcd282cc461ee945c7c8d/_resources/port1.0/group/compilers-1.0.tcl#L49

Re: Using on macOS 10.13 with clang++-mp-13

[Ken Cunningham]

> On Jul 13, 2022, at 2:33 PM, Ryan Schmidt  wrote:
> 
> On Jul 3, 2022, at 13:38, Ken Cunningham wrote:
> 
>> You can (sometimes) use macports-libcxx to get past this. This however 
>> introduces two versions of libc++.dylib into the softare mixture, and this 
>> sometimes causes errors due to incompatibilities between libc++ versions 
>> (ODR errors). If you are taking this route, linking in the newer libc++.a 
>> statically has a higher chance of working properly (that is what Chrome does 
>> on older MacOS systems).
> 
> If a port X links to a static library provided by a port Y, you should 
> increase the revision of port X whenever port Y is updated to a new version 
> so that your port X receives the new version of the static library. A comment 
> should be left in port Y advising whoever updates it to do that.
> 
> 

If anyone is ever motivated to update macports-libcxx beyond libcxx-11 it would 
be best to be very careful.

ODR errors due to divergence from older libcxx versions are thought to increase 
as of llvm/libcxx-12, so lots of testing might be needed.

This whole plan is obviously very fragile.

K

Re: Using on macOS 10.13 with clang++-mp-13

[Ken Cunningham]

This is an issue that will need solving, otherwise as filesystem is used
more (and it seems popular) all the systems prior to 10.15 will be left
behind.

Filesystem uses features in libc++.dylib that are only present in 10.15 and
newer. You are blocked from trying to use them on 10.14 and below by a
blocker in the clang "__config" header, that is easy to override, but when
you try to use filesystem, it will not find the libc++.dylib features and
will fail.

You can (sometimes) use macports-libcxx to get past this. This however
introduces two versions of libc++.dylib into the softare mixture, and this
sometimes causes errors due to incompatibilities between libc++ versions
(ODR errors). If you are taking this route, linking in the newer libc++.a
statically has a higher chance of working properly (that is what Chrome
does on older MacOS systems).

You can use gcc/libgcc, and newer versions of that have filesystem support,
but that causes it's own issues.

There was an early version of filesystem available as
 with a linking static library on older versions
of clang. I forget when that disappeared, but maybe clang-8.0. It is
possible that this might be brought forward to newer clangs and made
available to older systems with modest effort. This is likely the most
robust approach going forward, as it is the same code (although older).

There are a few versions of filesystem available from other places, some
header-only, that might or might not work in a general sense. These have
the disadvantage of having nothing to do with clang/llvm, therefore I
presume the chances of unfavourable interactions would be somewhat higher.

Hope this is helpful,

Ken

On Sun, Jul 3, 2022 at 4:12 AM Mojca Miklavec  wrote:

> Hi,
>
> I'm trying to build some sources that require  on 10.13
> using clang 13 (I can try with clang 14, but I doubt that it helps).
>
> What's the correct way to compile the following minimal example? Do I
> need to link against a newer libc++ somehow?
>
> If it's not feasible to do that, I'll target a newer OS, I was just
> silently hoping to have some success ;)
>
> Thank you,
> Mojca
>
> #include 
> #include 
>
> int main() {
> auto cwd = std::filesystem::current_path();
> printf("%s", cwd.c_str());
> return EXIT_SUCCESS;
> }
>
> > clang++-mp-13 test.cpp -o test
> test.cpp:5:16: error: no member named 'filesystem' in namespace 'std';
> did you mean 'std::__fs::filesystem'?
> auto cwd = std::filesystem::current_path();
>^~~
>std::__fs::filesystem
> /opt/local/libexec/llvm-13/bin/../include/c++/v1/filesystem:268:1:
> note: 'std::__fs::filesystem' declared here
> _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM
> ^
> /opt/local/libexec/llvm-13/bin/../include/c++/v1/__config:816:58:
> note: expanded from macro '_LIBCPP_BEGIN_NAMESPACE_FILESYSTEM'
>   _LIBCPP_BEGIN_NAMESPACE_STD namespace __fs { namespace filesystem {
>  ^
> 1 error generated.
>
> > clang++-mp-13 -std=c++17 test.cpp -o test
> Undefined symbols for architecture x86_64:
>   "std::__1::__fs::filesystem::__current_path(std::__1::error_code*)",
> referenced from:
>   std::__1::__fs::filesystem::current_path() in test-1b2bbf.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>

Re: help with a regex please

[Ken Cunningham]

thanks Fred, saw your answer afterwards, much appreciated.

Ken

Re: help with a regex please

[Ken Cunningham]

thanks for the clue, indeed that was on track.

this worked, in the end, once I finally remembered I had to use the “-E” 
enhancement to reinplace to make it obey the regex — that took an extra hour :>

reinplace -E -q {s| --host=[^ ]+||g}   ${dir}/bin/jemalloc-config
reinplace -E -q {s| host_alias=[^ ]+||g}${dir}/bin/jemalloc-config


trying to build without the “host” parts in the first place let to the 
configure script erroring out as it was unable to run the test executables 
built as arm64 on Intel.

fixed!

K




> On Jun 19, 2022, at 2:47 PM, Eric Borisch  wrote:
> 
> I would think: 
>   s/--host(_alias)?=[^ ]*//a
> 
> On Sun, Jun 19, 2022 at 3:34 PM Ken Cunningham 
> mailto:ken.cunningham.web...@gmail.com>> 
> wrote:
> to fix the universal build of some ports, eg jemalloc, I would like to strip 
> out the host bits from these text strings, eg convert this:
> 
> echo "--prefix=/opt/local --with-jemalloc-prefix= 
> --host=aarch64-apple-darwin21.5.0 host_alias=aarch64-apple-darwin21.5.0 
> CC=/usr/bin/clang”
> 
> to this:
> 
> echo "--prefix=/opt/local --with-jemalloc-prefix= CC=/usr/bin/clang”
> 
> however, my regex-fu is not strong.
> 
> Anyone know the secret reinplace regex that might do that?
> 
> thx 

Re: help with a regex please

[Ken Cunningham]

> On Jun 19, 2022, at 3:24 PM, Joshua Root  wrote:
> 
> On 2022-6-20 06:34 , Ken Cunningham wrote:
>> to fix the universal build of some ports, eg jemalloc, I would like to strip 
>> out the host bits from these text strings, eg convert this:
>> echo "--prefix=/opt/local --with-jemalloc-prefix= 
>> --host=aarch64-apple-darwin21.5.0 host_alias=aarch64-apple-darwin21.5.0 
>> CC=/usr/bin/clang”
>> to this:
>> echo "--prefix=/opt/local --with-jemalloc-prefix= CC=/usr/bin/clang”
>> however, my regex-fu is not strong.
>> Anyone know the secret reinplace regex that might do that?
>> thx
> 
> Why not just not add it in the first place?
> 
> - Josh

Now that you mention it, I think you’re right, the muniversal PG is adding it 
and I might be able to turn that off.

I recall doing that with libvpx a while back. I will try that.

K

help with a regex please

[Ken Cunningham]

to fix the universal build of some ports, eg jemalloc, I would like to strip 
out the host bits from these text strings, eg convert this:

echo "--prefix=/opt/local --with-jemalloc-prefix= 
--host=aarch64-apple-darwin21.5.0 host_alias=aarch64-apple-darwin21.5.0 
CC=/usr/bin/clang”

to this:

echo "--prefix=/opt/local --with-jemalloc-prefix= CC=/usr/bin/clang”

however, my regex-fu is not strong.

Anyone know the secret reinplace regex that might do that?

thx 

Re: MacPorts Status

[Ken Cunningham]

> If you are looking for some serious effort, it's the wrong
> place; there is none here, they are all volunteers sadly...
> 

> That's what I said, no coherence or coordination.
> So what are your reasons to not use HomeBrew?
> The right questions is how it needs to be,
> probably more on the organisational side
> of things than the technical I would say...

Just ignore this flamebait.
Ken

Re: Reason for rpath usage on arm64

[Ken Cunningham]

Iain has added what MacPorts needed to the gcc branches he maintains, and
plans to push them through. This option will let us add the needed rpath to
where MacPorts puts the gcc libraries.

--with-darwin-add-path=


Also, re cmake PG, changing the cmake option for in-build library paths
should have no affect on the final installed files.

Best,

Ken


On Sun, May 29, 2022 at 23:56 Ryan Schmidt  wrote:

> On May 30, 2022, at 01:01, Ken Cunningham wrote:
>
> > ah yes, your question was arm64-specific so that led to the gcc
> assumption.
> >
> > the way the cmake PG configures cmake breaks testing on all archs and
> systems.
>
> It worked for me on Catalina x86_64 but not on Big Sur arm64, and I was
> trying to understand why this difference exists.
>
>
> > this comes up regularly, eg
> >
> >
> https://lists.macports.org/pipermail/macports-dev/2021-September/043754.html
> >
> > Perhaps it might beneficially be changed.
>
> I'm assuming that just changing the default in the cmake 1.1 portgroup
> could cause problems (or at least nonreproducibility) for ports already
> using the portgroup, so perhaps this change, plus any others we want to
> make to the cmake portgroup, should be in a new cmake 1.2 portgroup.
>
>

Re: Reason for rpath usage on arm64

[Ken Cunningham]

ah yes, your question was arm64-specific so that led to the gcc assumption.

the way the cmake PG configures cmake breaks testing on all archs and
systems.

this comes up regularly, eg

https://lists.macports.org/pipermail/macports-dev/2021-September/043754.html

Perhaps it might beneficially be changed.

K

On Sun, May 29, 2022 at 22:17 Ryan Schmidt  wrote:

> On May 24, 2022, at 10:22, Ken Cunningham wrote:
> >
> >> Does anyone know why things seem to be using rpath on arm64 builds
> >
> > Basically, it comes down to the fact that Apple has disallowed
> DYLD_LIBRARY_PATH to work on newer systems.
>
> > So gcc is installing it’s libraries with the @rpath linkage
>
> So you're talking about how SIP doesn't pass DYLD_LIBRARY_PATH to child
> processes on El Capitan and later, which breaks the gcc test suite,
> therefore gcc now uses @rpath at build time to fix the problem, and does
> not rewrite the install_names at install time, therefore things with @rpath
> get installed.
>
> That's not the issue that prompted me to start this thread.
>
> When I enabled the test suite for the portmidi port (which does not use
> gcc)...
>
>
> https://github.com/macports/macports-ports/commit/fd447d210e1814b1303c5013d088efa673470d77
>
> ...I set "DYLD_LIBRARY_PATH=." in test.env so that the executable it runs
> can find the library it just built. This worked fine on Catalina x86_64 but
> on Big Sur arm64 it failed with the error message:
>
> dyld: Library not loaded: @rpath/libportmidi.2.dylib
>   Referenced from: /path/to/portmidi/work/build/./qtest
>   Reason: image not found
>
> Seeing "@rpath" in this error message, I added
> "-DCMAKE_BUILD_WITH_INSTALL_RPATH=OFF" to configure.args (to counteract
> "-DCMAKE_BUILD_WITH_INSTALL_RPATH=ON" set by the cmake portgroup) and the
> problem went away.
>
> Perhaps placing the blame on @rpath was the wrong conclusion, since I now
> realize that the install_names also use @rpath on Catalina x86_64 yet the
> test worked there. I just don't understand then why disabling @rpath on Big
> Sur arm64 made the tests work.
>
> It seemed to me like I was seeing a lot of @rpath-related issues
> especially on arm64 lately, and this latest instance with portmidi prompted
> me to ask about it, but it could be that most or all of the other instances
> were related to the gcc situation you already discussed. I know we are
> using a different branch of gcc for arm64 so maybe that explains why the
> @rpath-related changes you mentioned only appear on arm64 so far.
>
>

Re: Reason for rpath usage on arm64

[Ken Cunningham]

Oh, nothing whatsoever to do with arm64 specifically. This is going to
affect all gcc builds on all darwin-supported architectures once Iain
pushes it through to all the branches he plans to keep supporting.

On Tue, May 24, 2022 at 9:50 AM Joshua Root  wrote:

> On 2022-5-25 01:22 , Ken Cunningham wrote:
> >> Does anyone know why things seem to be using rpath on arm64 builds
> >
> > Basically, it comes down to the fact that Apple has disallowed
> > DYLD_LIBRARY_PATH to work on newer systems.
>
> This is the first I've heard of it. Is this supposed to be the case only
> on arm64? I know DYLD_* variables are ignored when running SIP-flagged
> executables, but that wouldn't apply to something that has just been built.
>
> We use DYLD_LIBRARY_PATH in our own build system:
> <https://github.com/macports/macports-base/blob/master/vendor/tclsh.in>
>
> - Josh
>

Re: Reason for rpath usage on arm64

[Ken Cunningham]

That comes right from Iain - here's the relevant gcc ticket I believe:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88590

I'm sure Iain would be delighted to find a way around this.



On Tue, May 24, 2022 at 9:50 AM Joshua Root  wrote:

> On 2022-5-25 01:22 , Ken Cunningham wrote:
> >> Does anyone know why things seem to be using rpath on arm64 builds
> >
> > Basically, it comes down to the fact that Apple has disallowed
> > DYLD_LIBRARY_PATH to work on newer systems.
>
> This is the first I've heard of it. Is this supposed to be the case only
> on arm64? I know DYLD_* variables are ignored when running SIP-flagged
> executables, but that wouldn't apply to something that has just been built.
>
> We use DYLD_LIBRARY_PATH in our own build system:
> <https://github.com/macports/macports-base/blob/master/vendor/tclsh.in>
>
> - Josh
>

Re: Reason for rpath usage on arm64

[Ken Cunningham]

> Does anyone know why things seem to be using rpath on arm64 builds

Basically, it comes down to the fact that Apple has disallowed 
DYLD_LIBRARY_PATH to work on newer systems.

gcc for Darwin has one developer working on it, practically. Iain. He has been 
maintaining it for 10+ years, wrote the objective C implementation it uses, and 
is pretty much the only reason gcc works on Darwin at all. Perhaps someone 
would fill his shoes if he stopped doing it, hard to say.

He maintains hardware machines from 10.5 to the current, and he tries to keep 
as many versions of gcc as possible running on as many systems as he can.

Once Apple disallowed DYLD_LIBRARY_PATH, he has had a lot of trouble running 
the test suites on the gcc libraries, as he can’t force the libraries under 
test to be the ones used. Instead the libraries installed are the ones used, 
which means he has to actually install the gcc before testing it.

Multiply that by perhaps 6 active gcc versions on each system, and 50+ test 
runs of gcc weekly, and you can see the problem.

Using @rpath gets around that problem very nicely.

Now, LLVM and many other software projects have the same issue. They also use 
@rpath to do it. But on INSTALLATION these @rpaths can be rewritten 
automatically by cmake (or meson) to be full pathnames. So that is what 
MacPorts does.

gcc’s build system does not currently offer that installation option. I don’t 
know how hard it would be to add it (any volunteers?) but for now at least, 
Iain is not keen on adding that @rpath rewrite-on-install business to gcc.

So gcc is installing it’s libraries with the @rpath linkages — it’s not just 
arm, by the way. It’s just arm right now because that is the tip of the spear. 
Very soon ALL gcc installs will use @rpaths, as that is (for now, barring a 
better option) the only way Iain can maintain gcc at all on Darwin.

Ken

Re: latest git version no longer detected by base ==> and it is a pain to use

[Ken Cunningham]

the new git is causing headaches for me too.

It delivers errors based on the ownership of directories above it, to address 
this:

https://github.blog/2022-04-12-git-security-vulnerability-announced/

which means that any kind of git work in the macports trees (owned by macports) 
even as root now causes errors unless folder by folder exceptions are made. Yuk.

I rolled back to the last git before this fix for the time being.

Ken

Re: [10.6.8] certbot & pyOpenSSL problems

[Ken Cunningham]

I used this set of instructions and the tool referenced in the first 
comment myself:


https://www.youtube.com/watch?v=EJA4OUIDa7Q

to upgrade the firmware in a macmini 1,1 to 2,1, to allow it to see the 
rest of the installed RAM. It was, for me, very quick and very painless.


As you noted, many macOS systems of this vintage (and other makes using 
the same Intel chipsets) can only use a little over 3GB of the 4GB of 
RAM due to hardware addressing constraints, even when running other 
operating systems like linux.



Best,


Ken

Re: [10.6.8] certbot & pyOpenSSL problems

[Ken Cunningham]

> System Version: Mac OS X 10.6.8 (10K549) Kernel Version: Darwin 10.8.0 

It appears that you are running a 10.6.8 system (on a macmini, I think I saw?) 
and I think you appear to be using it as a server for various things.

In another spot, I see that it is a 32bit EFI Mac:

> platform: macOS-10.6.8-i386-64bit 

If you are not using for much else beyond being a server, I thought I would let 
you know that this tiny like c program:

https://github.com/demonicsweaters/make_single_eltorito.c

that compiles in 10 seconds or so, will slightly modify an Ubuntu 64 bit 
installer image to properly boot a 32bit EFI Mac, and you can then install 
Ubuntu 64 bit on there.

Once it is installed, you’re good to go, and you can use 64bit software 
everywhere, including any 64 bit software you download rather than get from the 
main repo, like Spotify, Google Chrome, etc.

I have this now running on 3 older Macs with 32bit EFI, and it works just 
beautifully. And if you are just using that as a server, you would be most 
likely many miles ahead to be running Ubuntu 20.04 with webmin than trying to 
keep teasing SnowLeopard along as a server.

Just my $0.02 for whatever.

Ken


(PS - dual booting a MacOSX install of 10.6 or 10.7 works just fine too, using 
ReFIND: https://www.rodsbooks.com/refind/ )

Re: OWL - wayland for mac

[Ken Cunningham]

In fact I have OWL running on my Mojave system now. It built in about 10 
minutes last week, with only minor tweaking.



However, so far I can only get wayland clients to connect to it, and 
indicate a successful connection, but not display anything. I think 
perhaps the supported wayland protocol spec has drifted a bit?


If you find a wayland client example that works with OWL, please let me 
know.


Sergey has not yet responded to my email about which clients he has been 
using to test.



Ken

Re: port:libcxx - why so old

[Ken Cunningham]

> On Nov 28, 2021, at 12:30 PM, Ken Cunningham 
>  wrote:
> 
>> Hi,
>> 
>> Judging from the version number, port:libcxx ships a version that's long 
>> outdated. Is there a reason for that, like it's the latest version that 
>> builds on all OS X versions that require the libc++ conversion?
>> 
>> I have a local version that is currently at v8.0.0 on my 10.9.5 system and 
>> have had that install the runtime shared libraries (= not the ones used by 
>> the linker) in $prefix/lib via an additional +runtime variant which also 
>> installs a launch wrapper that adds $prefix/lib to DYLD_INSERT_LIBRARIES 
>> (DYLD_LIBRARY_PATH typically isn't enough on Mac). It's a lot newer than my 
>> system versions even (than v5.0.1) and yet I can't recall having had any 
>> issues with it. On the contrary, it fixed a number of strange C++ runtime 
>> warnings in certain KDE software and must give me that bit more performance 
>> because built with a more recent clang, full CPU-specific optimisation and 
>> LTO.
>> 
>> R.
>> 
> 
> libcxx 5.0 is quite new in fact — it supports libcxx features that only show 
> up in 10.13+ (which give us the strange fact of ports that build on 10.6, and 
> 10.13+, but nothing in between. :>
> 
> I had libcxx 7.0 ready to push, which I was going to do if I ever sorted out 
> how to bootstrap it to the full Thread_Local_Storage supporting version 
> without tricks.
> 
> But I never noticed a single port that built with libcxx 7.0 that would not 
> build with libcxx 5.0, so there was no big rush.
> 
> I did replace the libc++.dylib on my 10.7.5 system with the one from llvm-5.0 
> and promptly found certain applications (ical, for example) crashing 
> regularly.
> 
> So I gave up on the plan of a blanket replacement, and came up with 
> macports-libcxx instead, which had more general use across the entire lineup 
> of systems.
> 
> 
> There are definite ABI changes between libcxx versions. It is 100% not 
> guaranteed that things that are built against libcxx-11.0 will work with 
> things built against libcxx-5.0, or the system libcxx, and there are known 
> examples I have worked through with upstream where such backward 
> incompatibility caused errors, and was specifically never going to be fixed 
> by upstream.
> 
> The exact comment was something like: “We don’t want to encourage people to 
> think this should work, so we won’t support any fixes for it”.
> 
> And then a bit of a slap for still being on 10.6.8, don’t you know that is 
> insecure, etc.
> 
> So I dropped all of that line of discussion a year or two ago.
> 
> Ken
> 
> 

Oh, BTW you can build our libcxx-5.0 with any compiler you want to — we do 
already get LTO, but if you want to build it with clang-9.0, or clang-13 to see 
if you get even newer super-duper LTO on steroids or something, go ahead. I did 
build it with clang-9.0 I think; I haven’t tried with clang 13, but it would 
probably build.

The real change in libcxx (I think it was you who pointed it out in fact) that 
was likely to break libcxx against the system libc++.dylib software was around 
llvm-8.0.

Somewhere there is a ticket where you pointed that out.

So that’s why I never personally tried a full replacement with libcxx-8.0, and 
left it libcxx-7.0 at the most (for my personal systems).

Ken

Re: port:libcxx - why so old

[Ken Cunningham]

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

libcxx 5.0 is quite new in fact — it supports libcxx features that only show up 
in 10.13+ (which give us the strange fact of ports that build on 10.6, and 
10.13+, but nothing in between. :>

I had libcxx 7.0 ready to push, which I was going to do if I ever sorted out 
how to bootstrap it to the full Thread_Local_Storage supporting version without 
tricks.

But I never noticed a single port that built with libcxx 7.0 that would not 
build with libcxx 5.0, so there was no big rush.

I did replace the libc++.dylib on my 10.7.5 system with the one from llvm-5.0 
and promptly found certain applications (ical, for example) crashing regularly.

So I gave up on the plan of a blanket replacement, and came up with 
macports-libcxx instead, which had more general use across the entire lineup of 
systems.


There are definite ABI changes between libcxx versions. It is 100% not 
guaranteed that things that are built against libcxx-11.0 will work with things 
built against libcxx-5.0, or the system libcxx, and there are known examples I 
have worked through with upstream where such backward incompatibility caused 
errors, and was specifically never going to be fixed by upstream.

The exact comment was something like: “We don’t want to encourage people to 
think this should work, so we won’t support any fixes for it”.

And then a bit of a slap for still being on 10.6.8, don’t you know that is 
insecure, etc.

So I dropped all of that line of discussion a year or two ago.

Ken

Re: upgrade to openssl 3.0.0

[Ken Cunningham]

Well thanks, Rene!  

I’m so glad to see this is actually happening now, after a momentary delay.

I think my comment about enabling the openssl3 FIPS mode was somehow missed; it 
has to be specifically turned on in openssl3, but it does allow more things to 
work with openssl3 I believe.

Ken




> On Nov 6, 2021, at 6:34 AM, Renee Otten  wrote:
> 
> Dear all, 
> 
> 
> Chris has done the work to add the openssl3 port and openssl-1.0 PortGroup to 
> ease the transition towards openssl v3. There is now an open PR 
> (https://github.com/macports/macports-ports/pull/12807 
> <https://github.com/macports/macports-ports/pull/12807>) to switch en masse  
> the default openssl version to 3. The Apache-2 license of openssl3 will allow 
> many ports that are currently not, to become distributable as there will be 
> no license conflict anymore.
> 
> If maintainers want to pro-actively test whether “their” ports build properly 
> with the latest openssl version please do so now. If that doesn’t work 
> out-of-the-box then the status quo (i.e., building with openssl v1.1) can 
> easily be restored by the adding the following code to the Portfile:
> 
> PortGroup openssl 1.0
> openssl.branch1.1
> 
> and depending on the build-system one can also specify “openssl.configure” 
> which takes the options: 'pkgconfig' (default), 'build_flags', or 'cmake’. 
> 
> For other options, please refer to the PortGroup code: 
> https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/openssl-1.0.tcl
>  
> <https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/openssl-1.0.tcl>.
>  
> 
> Given the number of maintainers and ports involved we should probably leave 
> the above mentioned PR open for a bit more than the usual 72 hours, but I’d 
> imagine that in about a week or so from now someone will re-run the script to 
> revbump affected ports and push the merge button. Ideally most of the ports 
> will just work with openssl3, whereas others might have been set to build 
> with openssl1 by their maintainers by then. Yes, there will for sure be some 
> breakage of unmaintained ports that will need fixing, but that will need to 
> happen at some point anyway so we can as well just flip the switch soon and 
> deal with it.
> 
> 
> 
> 
>> On Oct 7, 2021, at 12:16 PM, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> 
>> https://github.com/macports/macports-ports/pull/12514 
>> <https://github.com/macports/macports-ports/pull/12514>
>> 
>> 
>>> On 6 Oct 2021, at 5:46 pm, Christopher Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> 
>>> I’m working on the basic changes to implement my suggestion at the moment. 
>>> Once that is there testing specific ports against version 3 ’the canaries’ 
>>> will be trivial. more in a bit.
>>> 
>>>> On 6 Oct 2021, at 5:40 pm, Ken Cunningham >>> <mailto:ken.cunningham.web...@gmail.com>> wrote:
>>>> 
>>>> For whoever gets up the enthusiasm to take on the storm of nay-sayers:
>>>> 
>>>> Although I found about 90% of the 100 or so ports I tried built without 
>>>> any changes against openssl 3.0.0 (rust, cargo, qt5, qt4-mac, etc, etc), 
>>>> and the rest were easy < 5 min fixes to use our openssl11 port, I noted in 
>>>> the openssl 3 migration guide that the FIPS mode is disabled by default on 
>>>> the openssl 3 build, and has to be expressly enabled.
>>>> 
>>>> I recall that most of the (very few) build failures I saw were in fact 
>>>> FIPS failures, so enabling that module might fix a bunch of them.
>>>> 
>>>> Best,
>>>> 
>>>> Ken
>>>> 
>>>> 
>>>> On Tue, Oct 5, 2021 at 12:54 PM Fred Wright >>> <mailto:f...@fwright.net>> wrote:
>>>> 
>>>> On Mon, 4 Oct 2021, Christopher Jones wrote:
>>>> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham 
>>>> >> >>> >> <mailto:ken.cunningham.web...@gmail.com>> wrote:
>>>> >>
>>>> >> I was hoping to move this along for the overwhelming benefit of the 
>>>> >> license, but TBH the push-back so far is 99.99% negative about moving 
>>>> >> to openssl 3.0.0 this year, so too controversial for me to get involved 
>>>> >> with. I'll sit back for six to twelve months and see what you guys work 
>>>> >> out over the coming year.
>>>> >
>>>> > All the more reas

Re: upgrade to openssl 3.0.0

[Ken Cunningham]

For whoever gets up the enthusiasm to take on the storm of nay-sayers:

Although I found about 90% of the 100 or so ports I tried built without any
changes against openssl 3.0.0 (rust, cargo, qt5, qt4-mac, etc, etc), and
the rest were easy < 5 min fixes to use our openssl11 port, I noted in the
openssl 3 migration guide that the FIPS mode is disabled by default on the
openssl 3 build, and has to be expressly enabled.

I recall that most of the (very few) build failures I saw were in fact FIPS
failures, so enabling that module might fix a bunch of them.

Best,

Ken


On Tue, Oct 5, 2021 at 12:54 PM Fred Wright  wrote:

>
> On Mon, 4 Oct 2021, Christopher Jones wrote:
> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham <
> ken.cunningham.web...@gmail.com> wrote:
> >>
> >> I was hoping to move this along for the overwhelming benefit of the
> >> license, but TBH the push-back so far is 99.99% negative about moving
> >> to openssl 3.0.0 this year, so too controversial for me to get involved
> >> with. I'll sit back for six to twelve months and see what you guys work
> >> out over the coming year.
> >
> > All the more reason to follow my suggested migration path then I would
> > say, as it allows an openssl30 port to be made available, and those
> > ports that wish to can use it via the new PG, but it doesn’t have to
> > become the default until some later date.
>
> The PR thread contained (approximately) the following two statements:
>
> 1) Unless v3 is the default, nobody will bother to use it.
>
> 2) Everybody is really, *really* anxious to move to v3 for the more
> permissive license.
>
> Clearly those two statements are in conflict.
>
> At Google, we had a process called "canarying".  Although technically a
> misnomer, it referred to the "canary in the coal mine" concept, with the
> idea that rolling out new stuff with possible issues should start small,
> so that problems could be found (and hopefully fixed) before they caused
> large-scale breakage.
>
> If the OpenSSL folks were committed to maintaining backward compatibility,
> then none of this nonsense would be necessary, but it's clear that they're
> not.  And there's no reason to assume that they won't pull the same crap
> again in the future (having done so at least twice already), so having a
> mechanism for multiple coexisting OpenSSL "major" versions could have
> long-term value beyond the v3 transition.
>
> > TBH I also was quite dubious of making 3.0.0 the default any time ’soon’
>
> I agree, especially if the only end benefit is the license.  Remember,
> OpenSSL is the poster child for why *not* to assume that that newer is
> more secure. :-)
>
> Fred Wright

Re: upgrade to openssl 3.0.0

[Ken Cunningham]

as you wish, Chris.


I was hoping to move this along for the overwhelming benefit of the
license, but TBH the push-back so far is 99.99% negative about moving to
openssl 3.0.0 this year, so too controversial for me to get involved with.
I'll sit back for six to twelve months and see what you guys work out over
the coming year.

K

On Mon, Oct 4, 2021 at 8:18 AM Chris Jones  wrote:

>
> Reading this thread again, I think there is some confusion over what I
> am suggesting, compared to Renee/Ken, as really the differences are
> minor and cosmetic packaging differences.
>
> The main difference is I am suggesting aiming for consistency across
> where all the openssl ports install to. Instead of having some install
> to libexec, and then one 'blessed' default port install directly into
> ${prefix} have opensslXYZ ports for *all* versions we need, that all
> install to their own libexec area. Then, have a trivial shim port for
> the general 'openssl' port that just installs a few sym links from
> whatever the 'default' openssl version is deemed to be (currently 1.1.1)
> into the primary ${prefix} install.
>
> We could do this, right now, i.e. move the current openssl port to an
> isolated libexec openssl11 port, and update openssl to just be a shim to
> that install. This would be completely transparent to all ports using
> openssl.
>
> The advantage of this to me would be
>
> 1. Consistency across all the openssl ports, as they would all,
> regardless of their version, be treated (installed) the same way.
>
> 2. Once there, we could then introduce a new port group that extends
> what the current old_openssl PG does but in a more general way, as it
> would work for not just 'old' openssl versions, but also the current
> default and also new ones. e.g. we could then add a openssl30 port and
> allow a few ports to experiment with it.
>
> 3. Once we are OK with a few ports using openssl30 we could 'throw the
> switch' and update the shim port to point to the 3.0 version.
>
> The above, if you think about it, is really no different to what
> Ken/Renee are suggesting in terms of what ports have to do. If ports are
> OK with just relying on the default they can carry on using the
> 'openssl' (shim) port, just as they are now. Nothing is forcing us to
> change these ports. *If* ports wanted to migrate to use the new PG that
> is fine, but its an optional choice (unless they are not compatible with
> 3.0 of course, but then they will need updating anyway once 3.0 is the
> default).
>
> So why do the above instead of what Ken/Renee suggest ? for me the
> primary reason is we end up with a system where in future it will be
> much easier to deal with future new major versions, without having to
> have these discussions again... Say 3.1 or 4.0 comes out, a new isolated
> opensslXY port can be added to provide that, that will live alongside
> the current ones. A few ports could be tested against it, and as and
> when we are ready the default can be flipped again to point to it.
>
> Chris
>
>
> On 04/10/2021 10:24 am, Christopher Jones wrote:
> >
> >
> >> On 2 Oct 2021, at 8:06 pm, Ken Cunningham
> >>  >> <mailto:ken.cunningham.web...@gmail.com>> wrote:
> >>
> >> That is exactly the approach that I don't find workable, Chris.
> >>
> >> Specifically:
> >>
> >> 1. every single port (think: rust, ghc, blah blah) will have to be
> >> needlessly managed to build against an alternate openssl location.
> >
> > why ? They can start of using the shim port and only use the isolated
> > builds as and when they are ready
> >
> >> 2. there will be no default openssl ever in prefix.
> >
> > why not ? The boost set has one and I see no reason why openssl cannot
> > as well.
> >
> > Chris
> >
> >>
> >> So I am not on board for trying to implement that myself, but should
> >> that be the selected course I will watch from the sidelines as others
> >> proceed down that path.
> >>
> >> K
> >>
> >>> On Oct 2, 2021, at 12:02 PM, Chris Jones  >>> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Personally I would strongly recommend following a migration path that
> >>> does not require an enmass change but allows ports to migrate  at
> >>> their own pace. I would personally very much recommend an approach
> >>> similar to that we used for boost recently
> >>>
> >>> 1. Introduced a set of new isolated opensslXYZ ports that install
> >>> specific versions into isolated install areas un

Re: upgrade to openssl 3.0.0

[Ken Cunningham]

That is exactly the approach that I don't find workable, Chris.

Specifically:

1. every single port (think: rust, ghc, blah blah) will have to be needlessly 
managed to build against an alternate openssl location.
2. there will be no default openssl ever in prefix.

So I am not on board for trying to implement that myself, but should that be 
the selected course I will watch from the sidelines as others proceed down that 
path.

K

> On Oct 2, 2021, at 12:02 PM, Chris Jones  wrote:
> 
> Hi,
> 
> Personally I would strongly recommend following a migration path that does 
> not require an enmass change but allows ports to migrate  at their own pace. 
> I would personally very much recommend an approach similar to that we used 
> for boost recently
> 
> 1. Introduced a set of new isolated opensslXYZ ports that install specific 
> versions into isolated install areas under libexec.
> 2. Create a new portgroup that handles the confirmation of ports to pick the 
> openssl version they wish to use, with some default, and performs various 
> standard configurations for standard build systems such that for most ports 
> they work out the box with the new portgroup. For those that don’t provide 
> various proc methods that return the configured install paths such that ports 
> can used them to configure themselves as required.
> 3. Make the current openssl port a basic shim port that just installs sym 
> links into the primary install area to the default openssl version (for now 
> 1.1.1), so ports building against the current openssl port carry on working 
> just as they are now, but are redirected to use the same versioned 1.1.1 port 
> as those using the PG.
> 
> Once this is in place, ports can be migrated to use the new PG individually 
> as and when we want.
> 
> Chris
> 
>> On 2 Oct 2021, at 6:17 pm, Ken Cunningham  
>> wrote:
>> 
>> 
>> openssl 3.0.0 is out, with a new and very favourable Apache-2 license that 
>> will let many previously non-distributable ports become distributable.  
>> However, there are 758 ports that indicate they link against openssl. That 
>> is a daunting number of ports indeed.
>> 
>> One option might be to move all of our openssl ports (1.0, 1.1, and 3.x) 
>> into subdirectories out of ${prefix}, have no default openssl installed in 
>> $[prefix} directly, create a new PortGroup, openssl_select or some such, add 
>> that PG to all 758 ports, default it to openssl 1.1.1, and then allow people 
>> to gradually move the 758 ports to openssl 3.0.0 as they get to it.
>> 
>> Although that is possible with suitable effort, I don’t think that is 
>> workable for many reasons, the most obvious being that we would then have to 
>> modify every single port in some way to find an openssl installed into a 
>> non-default prefix. Creating the PG and adding it to 758 ports might be work 
>> enough, but then finding the right way to force all 758 ports to build 
>> properly against an openssl that is not in the default prefix is the real 
>> horror, and seems like a nightmare of wasted labours.
>> 
>> So it would appear that the same option that was chosen last time, ie 
>> upgrade the default openssl in ${prefix} to the newer openssl, and then fix 
>> the subset of ports that will not build against it to use an older openssl 
>> appears both the better option and lot less work (assuming most ports do 
>> build against openssl 3.0.0, which seems to be the case so far). Some will 
>> disagree, but I put it to you that it is going to be far less work in the 
>> end to force a few % of the ports to a specific alternate openssl than force 
>> all of them, all the time, forever.
>> 
>> Most things I have attempted to rebuild over the past few days have rebuilt 
>> without any issues, but a few things don’t build with openssl 3.0.0 yet and 
>> will need to stay with openssl 1.1.1 for a while until patched or updated 
>> (or forever). That will require both forcing those ports to find an 
>> alternate openssl installation, and also (the tricky part) forcing them to 
>> ignore the openssl in the default prefix.
>> 
>> To support this, there is a new openssl11 port that provides openssl 1.1.1 
>> tucked away in a subdir, much like we have openssl10, and a few new options 
>> were added to the old_openssl PortGroup to allow most ports to be forced to 
>> the alternate openssl with minimal fuss. Add the PortGroup, spec the branch, 
>> and choose the method, for the most part.
>> 
>> If this plan holds, I would anticipate that we move ports that we find need 
>> to stay on openssl 1.1.1 to openssl11 using the old_openssl PortGroup soon 
>&g

Re: upgrade to openssl 3.0.0

[Ken Cunningham]

All the pythons build against openssl 3.0.0, so that python issue with all it's 
trail-down conflicts will disappear with the upgrade and python revbump.

A very very large % of ports do as well (and those that don't now soon will, as 
everyone moves to openssl 3.0.0 as the default, which homebrew did pretty much 
the second openssl 3 came out).

So I am hoping that this upgrade is the beginning of the end of this particular 
PITA for all of us.

Ken


> On Oct 2, 2021, at 11:37 AM, Jason Liu  wrote:
> 
> That was also the Blender devs' claim, which I assume is why they decided it 
> wasn't necessary to include the GPL-OpenSSL exception text, since any 
> licensing conflicts would self-resolve once Blender starts using OpenSSL 3.0. 
> But currently, their pre-built release binary downloads and compiles OpenSSL 
> 1.1.1g, which is still under the OpenSSL license, not Apache 2.0.
> 
> -- 
> Jason Liu
> 
> 
> On Sat, Oct 2, 2021 at 2:25 PM Joshua Root  > wrote:
> Blender is GPL-2+, which means it can be distributed when linked with 
> OpenSSL 3.0, since GPL-3 is compatible with Apache-2.
> 
> - Josh
> 
> On 2021-10-3 05:09 , Jason Liu wrote:
> > I hope the question that I'm about to ask doesn't induce 
> > "Inception"-style migraines, but since it directly relates to one of the 
> > ports I maintain, here goes. What if one of my ports indirectly uses 
> > openssl through one of its dependencies, and the licensing terms in the 
> > current version of my port only covers openssl 1.1.1, but not 3.0?
> > 
> > To use a specific example, Blender uses openssl 1.1.1 indirectly, by way 
> > of using networking through python. I contacted the Blender devs about 
> > this, and even though they acknowledged that they were unknowingly using 
> > OpenSSL without including the OpenSSL license, the only thing they ended 
> > up doing was to add the OpenSSL license to their licenses directory. 
> > They refuse, even now, to add the chunk of text specifying the 
> > GPL-OpenSSL exception to their licenses. Somehow their legal team seems 
> > to think that's enough to allow them to distribute pre-compiled 
> > binaries, but the MacPorts automatic license checking is flagging my 
> > Blender port as being non-distributable. Since my port is a couple of 
> > versions behind the latest release of Blender (there are some new 
> > dependent libraries that I need to submit first), how should we specify 
> > in our Portfiles that one of the dependencies should continue using the 
> > old openssl11, without adding the old_openssl PortGroup, and thus a 
> > direct dependency on openssl? Does this mean that the dependencies which 
> > are directly dependent on openssl will need new variants, e.g. +openssl 
> > and +openssl11?
> > 
> > -- 
> > Jason Liu

upgrade to openssl 3.0.0

[Ken Cunningham]

openssl 3.0.0 is out, with a new and very favourable Apache-2 license that will 
let many previously non-distributable ports become distributable.  However, 
there are 758 ports that indicate they link against openssl. That is a daunting 
number of ports indeed.

One option might be to move all of our openssl ports (1.0, 1.1, and 3.x) into 
subdirectories out of ${prefix}, have no default openssl installed in $[prefix} 
directly, create a new PortGroup, openssl_select or some such, add that PG to 
all 758 ports, default it to openssl 1.1.1, and then allow people to gradually 
move the 758 ports to openssl 3.0.0 as they get to it.

Although that is possible with suitable effort, I don’t think that is workable 
for many reasons, the most obvious being that we would then have to modify 
every single port in some way to find an openssl installed into a non-default 
prefix. Creating the PG and adding it to 758 ports might be work enough, but 
then finding the right way to force all 758 ports to build properly against an 
openssl that is not in the default prefix is the real horror, and seems like a 
nightmare of wasted labours.

So it would appear that the same option that was chosen last time, ie upgrade 
the default openssl in ${prefix} to the newer openssl, and then fix the subset 
of ports that will not build against it to use an older openssl appears both 
the better option and lot less work (assuming most ports do build against 
openssl 3.0.0, which seems to be the case so far). Some will disagree, but I 
put it to you that it is going to be far less work in the end to force a few % 
of the ports to a specific alternate openssl than force all of them, all the 
time, forever.

Most things I have attempted to rebuild over the past few days have rebuilt 
without any issues, but a few things don’t build with openssl 3.0.0 yet and 
will need to stay with openssl 1.1.1 for a while until patched or updated (or 
forever). That will require both forcing those ports to find an alternate 
openssl installation, and also (the tricky part) forcing them to ignore the 
openssl in the default prefix.

To support this, there is a new openssl11 port that provides openssl 1.1.1 
tucked away in a subdir, much like we have openssl10, and a few new options 
were added to the old_openssl PortGroup to allow most ports to be forced to the 
alternate openssl with minimal fuss. Add the PortGroup, spec the branch, and 
choose the method, for the most part.

If this plan holds, I would anticipate that we move ports that we find need to 
stay on openssl 1.1.1 to openssl11 using the old_openssl PortGroup soon or now, 
before we upgrade to openssl 3.0.0 to minimize fuss. Then once we have done 
that, upgrading the default openssl to 3.0.0 and revbumping the deps would 
occur.

So I am asking that anyone with an interest in a port that uses openssl please 
try building it against openssl 3.0.0 in the PR below, and if there is a 
problem that can’t be solved by an update or a patch, consider trying to use 
the old_openssl PortGroup to fix the build and move it over. As there are so 
many ports, it would help if people pitched in with the ones that are important 
to them.

The openssl 3.0.0 upgrade PR is here:

https://github.com/macports/macports-ports/pull/12410 


and my own WIP repo of a few ports that I have found won’t build with openssl 
3.0.0 at present and fixed to use the old_openssl PG is here:

https://github.com/kencu/mybigsuroverlay/ 


the idea is that the ports in that repo would be moved into the main repo as we 
work through the main ones that use openssl at least.


K

PS. One thing I have not yet sorted out how to do is how to support libressl in 
the setting of needing to force a port to openssl 1.1.1 using the old_openssl 
PortGroup. Open to any thoughts on this. This case wsa basically just ignored 
last time with openssl10, and we may have to do the same again unless someone 
has a bright idea.

Re: changing 'configure' options for testing

[Ken Cunningham]

Ryan asked (when he had this same issue about six months ago) why our cmake
PortGroup sets it ON when it breaks all the in-tree tests, and whether we
should change the PG to turn it OFF all the time. (The default is OFF I
believe.)

In fact, we probably should. I'm not sure why we set it like it was.

Ken

On Tue, Sep 28, 2021 at 1:49 PM Daniel J. Luke  wrote:

> Thanks Ken and Jason!
>
> This is helpful (now I just need to figure out why a couple of tests fail
> when run this way vs. when run against the installed libraries).
>
> I was worried that the installed rpath would be different with
> CMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF, but it looks like it gets set to
> $prefix in destroot, so the installed binaries are fine.
>
> > On Sep 28, 2021, at 11:38 AM, Jason Liu  wrote:
> >
> > In addition to the code Ken just provided, he and others have helped me
> with some test-related "protection" code, so that in addition to a +tests
> variant, there is the following section of code (I usually place it after
> any build-related sections, and before any destroot-related sections, in
> order to keep my portfiles laid out in the same order as the port phases):
> >
> > pre-test {
> > if {![variant_isset tests]} {
> > ui_error "'tests' variant must be activated to enable test
> support"
> > error "Please enable the 'tests' variant and try again"
> > }
> > }
> >
> > --
> > Jason Liu
> >
> >
> > On Tue, Sep 28, 2021 at 11:13 AM Ken Cunningham <
> ken.cunningham.web...@gmail.com> wrote:
> >
> > On 2021-09-28 7:44 a.m., Daniel J. Luke wrote:
> > > On Sep 20, 2021, at 10:20 AM, Daniel J. Luke 
> wrote:
> > >> On Sep 20, 2021, at 8:15 AM, Frank Dean  wrote:
> > >>> Daniel J. Luke  writes:
> > >>>> The newest version of clamav uses cmake for builds. In the
> 'configure' stage, I have it disabling tests because otherwise it won't
> build without the test dependencies installed (check and pytest).
> > >>>>
> > >>>> Do we have a template or example of a canonical way to handle this?
> I don't see an obvious hook for when someone is running `port test` to
> change configure.args (I could, of course, add a post-extract/pre-configure
> and do some non-declaritive test to see if `port test` is being run and use
> that to branch - but that feels like a bad design choice).
> > >>> The rapidjson port implements a 'tests' variant to handle a similar
> > >>> situation.  I used the same pattern for the libosmium port.  The
> tests
> > >>> can then be run with `sudo port -d test current +tests`.
> > >> That works, I guess.
> > >>
> > >> Is there interest in having base auto-add +tests if `port test` is
> called? (I haven't looked at base/ code in a while, but it seems possible).
> I like to imagine a future where we have enough infrastructure that we
> would run `port test` for any ports that have test.run set.
> > > On this same train of thought - clamav tests run against the installed
> libraries (like some other ports tend to do) - in long-ago times I'd solve
> this by setting DYLD_LIBRARY_PATH - but since SIP started removing these
> that no longer works normally. I think trace mode has a(n elaborate)
> workaround where it copies binaries and executes the copies, but that
> doesn't seem like something I should implement in a portfile ;-) [This is
> another instance where if trace mode were the default, things would 'just
> work']
> > >
> > > Has anyone else already solved this?
> >
> >
> > The way our cmake PortGroup sets things up, running tests is harder. You
> > can configure cmake to allow testing to find the libraries in the build
> > tree. See for example what I did in libcbor:
> >
> >
> > variant tests description {enable tests} {
> >  depends_test-append port:cmocka
> >  configure.args-append   -DWITH_TESTS=ON
> >  configure.pre_args-replace -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON
> \
> > -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF
> >  test.runyes
> >  test.target test
> > }
> >
> > Ken
>
> --
> Daniel J. Luke
>
>

Re: changing 'configure' options for testing

[Ken Cunningham]

On 2021-09-28 7:44 a.m., Daniel J. Luke wrote:

On Sep 20, 2021, at 10:20 AM, Daniel J. Luke  wrote:

On Sep 20, 2021, at 8:15 AM, Frank Dean  wrote:

Daniel J. Luke  writes:

The newest version of clamav uses cmake for builds. In the 'configure' stage, I 
have it disabling tests because otherwise it won't build without the test 
dependencies installed (check and pytest).

Do we have a template or example of a canonical way to handle this? I don't see 
an obvious hook for when someone is running `port test` to change 
configure.args (I could, of course, add a post-extract/pre-configure and do 
some non-declaritive test to see if `port test` is being run and use that to 
branch - but that feels like a bad design choice).

The rapidjson port implements a 'tests' variant to handle a similar
situation.  I used the same pattern for the libosmium port.  The tests
can then be run with `sudo port -d test current +tests`.

That works, I guess.

Is there interest in having base auto-add +tests if `port test` is called? (I 
haven't looked at base/ code in a while, but it seems possible). I like to 
imagine a future where we have enough infrastructure that we would run `port 
test` for any ports that have test.run set.

On this same train of thought - clamav tests run against the installed 
libraries (like some other ports tend to do) - in long-ago times I'd solve this 
by setting DYLD_LIBRARY_PATH - but since SIP started removing these that no 
longer works normally. I think trace mode has a(n elaborate) workaround where 
it copies binaries and executes the copies, but that doesn't seem like 
something I should implement in a portfile ;-) [This is another instance where 
if trace mode were the default, things would 'just work']

Has anyone else already solved this?



The way our cmake PortGroup sets things up, running tests is harder. You 
can configure cmake to allow testing to find the libraries in the build 
tree. See for example what I did in libcbor:



variant tests description {enable tests} {
    depends_test-append port:cmocka
    configure.args-append   -DWITH_TESTS=ON
    configure.pre_args-replace -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
-DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF
    test.run    yes
    test.target test
}

Ken

Re: Help offered (macOS VMs)

[Ken Cunningham]

I find Parallels is also very good for macOS VMs.

I have a 24-core MacPro 5,1 with 32GB RAM that I mostly use for systems I don’t 
have as hardware, and have VMs set up in Parallels for MacOS 10.5 through 
BigSur. I usually give a dozen cores and 16GB of RAM to the VM when I’m working 
with it, but it runs with much less. They can be run headless in the background 
as well.

For emulating Tiger i386 I use VirtualBox. I give it 3GB of RAM and one core. 
In the past, with VirtualBox 5.x, I could use two cores, but with VB 6.x there 
is some regression and now Tiger will only run with one core otherwise kernel 
panic. Still, quick for Tiger, with a current fast processor. I also have Tiger 
i386 on hardware.

I have qemu installations of 10.4 PPC and 10.5 PPC, but they are just awfully 
slow; they can only use 1 emulated processor. If they could multicore up to 4 
processors I might consider them usable, but that doesn’t work last time I 
tried it a year or so ago. For PPC work I just use one of my G5s; they are 
pretty quick and usably fast.


> On Sep 22, 2021, at 12:18 PM, Blake Garner  wrote:
> 
> Is there a reason macports would not use VMware Fusion for x86 versions? It 
> has the best macOS support and I'm sure that macports could get some licenses 
> as needed for free. For PPC I have had good luck with qemu in the past. 
> 
> On Tue, Sep 7, 2021 at 1:41 AM Ruben Di Battista  > wrote:
> I'm also very slowly working on this (the `slowly` is PhD related) and I was 
> targeting KVM. I'll probably give a try also to Hyper-V since I started using 
> Windows 11 with WSL for development. 
> 
> You can probably search in the list posts from me where we discussed this a 
> bit in details. 
> 
> On Tue, 7 Sep 2021, 10:09 Bjarne D Mathiesen,  > wrote:
> Mojca Miklavec wrote:
> > 5.) We're looking for someone willing to play around with macOS VMs,
> > in particular the older ones: 10.6 (or even 10.4/10.5 for utter geeks)
> > and newer. We currently run CI jobs just on what GitHub provides (2 or
> > 3 latest OSes), but it would be nice to set up disposable VMs where we
> > could fire up a VM, build the ports from CI, and destroy the VM.
> 
> What hypervisor it the target ?
> 
> I have tried to get a 10.6.8 to work in VirtualBox; but
> 1) it kept crashing
> 2) I couldn't get it to up the RAM above 2GB
>even though some mac systems ran 10.6 up to at least 8GB
> 
> -- 
> 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: Haskell Stack Ports on Apple Silicon

[Ken Cunningham]

> On Aug 15, 2021, at 5:16 AM, Steven Smith  wrote:
> 
>> Cannot install shellcheck for the arch 'arm64’ because


IF shellcheck had supported_archs x86_64 in the Portfile, it should never try 
to install the arm64 arch in the first place.

So I’m guessing probably that was missing.



It seems to work like this:

1. you try to install a haskell port on arm64
2. there is no supported_archs in the Portfile you are trying to install
3. base will try to build for the native arch (arm64)
3. base then examines all the deps.
4. If the deps don’t support arm64, you get an error.

Done.


So:

1. set supported_archs x86_64 in all the haskell ports
2. try to install a haskell port on arm64
3. base sees arm64 is not supported, but x86_64 is a supported_arch
4. base uses x86_64 as a fallback arch
5. base examines all the deps. All build as x86_64.
6. Good to go.