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

[Gagan Sidhu via macports-dev]

hi lads/ladettes,

as an update, i was independently provided a solution by by jonathan alland aka 
mr wowfunhappy and a man mononymously known as ‘krackers, and mr phil dennis 
jordan (whom i call God because of his macintosh knowledge).

both suggested the linker was the problem, and indeed it was. changing 
-fuse-ld=lld to -fuse-ld=ld64 fixed the issue.

thank you everyone!

Thanks,
Gagan

> On Jun 10, 2024, at 10:21 AM, Ken Cunningham 
>  wrote:
> 
> 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 

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

[Gagan Sidhu via macports-dev]

ugh apologies for anothe dupe
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: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-a

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

[Gagan Sidhu via macports-dev]

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 
>>>>  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 
>>>>>  wrote:
>>>>> 
>>&g

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

[Gagan Sidhu via macports-dev]

> 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
>>>  
>>> <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
>>> 
>> 
> 

paging the macports devs about NSObject between Lion and Mountain Lion

[Gagan Sidhu via macports-dev]

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: question for marcus about rust's compiler_builtins and macosx_deployment_target

[Gagan Sidhu via macports-dev]

nt to believe that there can be some small changes (in the form of a 
compile-time argument) that can enforce 10.9 compatibility to make these last 4 
warnings go away.

Thanks,
Gagan

> On May 28, 2024, at 11:16 PM, mcalh...@macports.org wrote:
> 
> Greetings.
> 
> I am afraid it is very difficult to answer this question without having a 
> much greater insight into Firefox builds.
> I am not quite sure what libgkrust.a is, but if it is copying files from the 
> Rust supplied libcompiler_builtins-xxx.rlib, then it would make sense that 
> there would be a discrepancy.
> Rust was built with MACOSX_DEPLOYMENT_TARGET=10.14 because that is the host 
> system.
> If that is indeed the case, the only way I can think to eliminate the 
> warnings is to recompile rust from source with `macos_version=10.9` and 
> perhaps `os.major=13`.
> However, this is untested and unsupported.
> 
> -Marcus
> 
>> On May 27, 2024, at 11:55 AM, Gagan Sidhu via macports-dev 
>>  wrote:
>> 
>> hi marcus
>> 
>> i’m working on making a firefox that works all the way back to 10.9
>> 
>> right now i am using it on 10.14 without issue, and i think the only thing 
>> left is ensuring rust honours my macosx_deployment_target
>> 
>> it seems rustc from macports (1.77.1) honours this variable for the most 
>> part, but i noticed one unusual thing.
>> 
>> when i use the mozilla toolchain’s rust (1.78), which has an implicit 
>> minimum of 10.12, i would get this:
>> 
>>> 34:32.52 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(std-b3629cc59bb38ebe.std.991b467e8ac0a4ad-cgu.0.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.52 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(panic_abort-e0744c14fcbc8bcc.panic_abort.c40177b90b1e9efd-cgu.0.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.52 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(object-5c7ad728062c8a84.object.804ec97e1ad5a55c-cgu.0.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.53 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(memchr-90583dbfcd2cd9d8.memchr.5e40ebe02bc7fee7-cgu.0.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.53 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(addr2line-f8a104b41642d585.addr2line.738d67e118a72e5c-cgu.0.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.53 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(gimli-2dd3c1cbaa8c6ac2.gimli.25cd2fd39526eafa-cgu.0.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.53 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(rustc_demangle-4b94f82697827b68.rustc_demangle.f3e6ea9654b87c89-cgu.0.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.54 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(std_detect-526c5fbf4504f5c2.std_detect.cc21ff6764f76c21-cgu.0.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.54 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(hashbrown-8983e26402bf8df3.hashbrown.c235b46fdb144bda-cgu.0.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.55 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(alloc-81d461325d712857.alloc.803e2326cde23ec3-cgu.0.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.55 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(core-4015b3a6e383e0ad.core.b03ae248d863ca2a-cgu.0.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.55 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtins-d6175b4ffbd6f2cb.compiler_builtins.c536cea08157bc6d-cgu.021.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.55 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtins-d6175b4ffbd6f2cb.compiler_builtins.c536cea08157bc6d-cgu.027.rcgu.o)
>>>  has version 10.12.0, which is newer than target minimum of 10.9.0
>>> 34:32.56 ld64.lld: warning: 
>>> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtin

question for marcus about rust's compiler_builtins and macosx_deployment_target

[Gagan Sidhu via macports-dev]

hi marcus

i’m working on making a firefox that works all the way back to 10.9

right now i am using it on 10.14 without issue, and i think the only thing left 
is ensuring rust honours my macosx_deployment_target

it seems rustc from macports (1.77.1) honours this variable for the most part, 
but i noticed one unusual thing.

when i use the mozilla toolchain’s rust (1.78), which has an implicit minimum 
of 10.12, i would get this:

> 34:32.52 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(std-b3629cc59bb38ebe.std.991b467e8ac0a4ad-cgu.0.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.52 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(panic_abort-e0744c14fcbc8bcc.panic_abort.c40177b90b1e9efd-cgu.0.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.52 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(object-5c7ad728062c8a84.object.804ec97e1ad5a55c-cgu.0.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.53 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(memchr-90583dbfcd2cd9d8.memchr.5e40ebe02bc7fee7-cgu.0.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.53 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(addr2line-f8a104b41642d585.addr2line.738d67e118a72e5c-cgu.0.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.53 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(gimli-2dd3c1cbaa8c6ac2.gimli.25cd2fd39526eafa-cgu.0.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.53 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(rustc_demangle-4b94f82697827b68.rustc_demangle.f3e6ea9654b87c89-cgu.0.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.54 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(std_detect-526c5fbf4504f5c2.std_detect.cc21ff6764f76c21-cgu.0.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.54 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(hashbrown-8983e26402bf8df3.hashbrown.c235b46fdb144bda-cgu.0.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.55 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(alloc-81d461325d712857.alloc.803e2326cde23ec3-cgu.0.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.55 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(core-4015b3a6e383e0ad.core.b03ae248d863ca2a-cgu.0.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.55 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtins-d6175b4ffbd6f2cb.compiler_builtins.c536cea08157bc6d-cgu.021.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.55 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtins-d6175b4ffbd6f2cb.compiler_builtins.c536cea08157bc6d-cgu.027.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.56 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtins-d6175b4ffbd6f2cb.compiler_builtins.c536cea08157bc6d-cgu.034.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.56 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtins-d6175b4ffbd6f2cb.compiler_builtins.c536cea08157bc6d-cgu.035.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.56 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtins-d6175b4ffbd6f2cb.compiler_builtins.c536cea08157bc6d-cgu.061.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.56 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtins-d6175b4ffbd6f2cb.compiler_builtins.c536cea08157bc6d-cgu.080.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.57 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtins-d6175b4ffbd6f2cb.compiler_builtins.c536cea08157bc6d-cgu.084.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.57 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtins-d6175b4ffbd6f2cb.compiler_builtins.c536cea08157bc6d-cgu.097.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.57 ld64.lld: warning: 
> ../../../x86_64-apple-darwin/release/libgkrust.a(compiler_builtins-d6175b4ffbd6f2cb.compiler_builtins.c536cea08157bc6d-cgu.008.rcgu.o)
>  has version 10.12.0, which is newer than target minimum of 10.9.0
> 34:32.57 ld64.lld: warning: 
> 

Re: clang with webassembly support

[Gagan Sidhu via macports-dev]

might be on the wrong track here.

i thought it may have been worth having our own wasm library for our clang, but 
it turns out this wasm stuff is not as big as the developers/effort make it 
sound.

i am getting kind of queasy going down the webassembly/firefox rabbit hole. the 
avatars are… let’s just say… um, imaginative.

\m/

Thanks,
Gagan

i see you valerio! be ready dawg!


> On May 24, 2024, at 10:08 AM, Gagan Sidhu via macports-dev 
>  wrote:
> 
> do we got it?
> 
> tried a few a week ago and it seems like we don’t, as the firefox mach build 
> system would fail at the webassembly checks for clang.
> 
> 
> Thanks,
> Gagan
> 

Re: clang with webassembly support

[Gagan Sidhu via macports-dev]

might be on the wrong track here.

i thought it may have been worth having our own wasm library for our clang, but 
it turns out this wasm stuff is not as big as the developers/effort make it 
sound.

i am getting kind of queasy going down the webassembly/firefox rabbit hole. the 
avatars are… let’s just say… um, imaginative.

落
Thanks,
Gagan

> On May 24, 2024, at 10:08 AM, Gagan Sidhu via macports-dev 
>  wrote:
> 
> do we got it?
> 
> tried a few a week ago and it seems like we don’t, as the firefox mach build 
> system would fail at the webassembly checks for clang.
> 
> 
> Thanks,
> Gagan
> 

clang with webassembly support

[Gagan Sidhu via macports-dev]

do we got it?

tried a few a week ago and it seems like we don’t, as the firefox mach build 
system would fail at the webassembly checks for clang.


Thanks,
Gagan

Re: Ruby question: solution for dependency version specs?

[Gagan Sidhu via macports-dev]

dear fred,

i understand this is the dev mailing list and politeness does not supersede 
correctness given the topical nature of this mailing list.

i am the last one to be pedantic, but serge *did* qualify his statement with a 
“should” (i.e. expectation), meaning it was not absolute.

let us not be too strong with our correctness and trample the spirit of our 
already-scarce contributors, lest we want them to defect to our snooty 
fink-derived alcohol competitor.

ta ta’

Thanks,
Gagan

P.S/ valerio, you know what’s coming next time you post, so be ready. 
-i didn’t want to scare you off by saying it earlier this week, because 
i was already worried i scared you off the first time!

> On Mar 23, 2024, at 6:59 PM, Fred Wright  wrote:
> 
> 
> On Sun, 17 Mar 2024, Sergio Had wrote:
> 
>> I have no idea what is going on with archaic versions, but Ruby 3.1+ through 
>> ruby-devel (3.4) should work on every system.
> 
> Please stop posting falsehoods. Ruby 3.1-3.3 most certainly do *not* work on 
> every system (yet), and I posted a list of the failing cases in another 
> thread where you were a participant.  I haven't looked at 3.4.
> 
>> They are, and everything relevant is rb33-* etc. Unversioned one which use 
>> rb18 should re updated or removed: we have no reason to keep Ruby versions 
>> prior to 3.0, since 3.0 works on Tiger, and 3.1+ work on Leopard through 
>> Sonoma. That also includes PowerPC systems.
> 
> Again, false.
> 
> For at least the past few years, no version of Ruby has worked on all systems 
> until I personally fixed it, and I haven't had a chance to fix anything later 
> than 3.0 yet.  And contrary to popular belief, Ruby 3.0 isn't (quite) EOL yet.
> 
> As far as having multiple versions goes, Ruby is just like many other things, 
> where having multiple versions is useful for (at least):
> 
> 1) Testing code against multiple versions.
> 
> 2) Using a textbook that is based on a particular version.
> 
> 3) Avoiding brokenness in one or more versions.
> 
> No too long ago, the instructions for building the RaspberryPi docs stated 
> that asciidoctor needed to be run with Ruby 2.7 because it didn't work 
> properly with 3.0 (at least for their files).  While that no longer seems to 
> be the case, it does serve to illustrate that newer isn't always better, and 
> that it's best to give users a choice as to what version to use, rather than 
> inflicting someone else's notion of the one true best version on them.
> 
> On Sat, 16 Mar 2024, Austin Ziegler wrote:
> 
>> I also think that the `ruby` port needs to be renamed to `ruby18` and `port
>> install ruby` should *either* fail (like `port install python` or `port
>> install python3` does) or it should install the latest stable version
>> (updated on Christmas Day every year).
> 
> Agreed.  Presumably this came about because having multiple versions wasn't 
> initially anticipated.  It's unfortunate that (unlike some other packaging 
> systems) MacPorts doesn't have a way to directly make multiple versions of 
> something available without resorting to the kludge of building the version 
> number into the name.
> 
> Fred Wright

Re: GEDA site dead?

[Gagan Sidhu via macports-dev]

every time i see valerio’s name, i’m reminded of the scene from night at the 
roxbury referencing emilio estevez

i don’t know why it comes to mind, nor why i felt this was worth sharing, but 
whatever.

Thanks,
Gagan

> On Jan 27, 2024, at 5:00 PM, Dave Allured - NOAA Affiliate via macports-dev 
>  wrote:
> 
> Valerio, thanks for that reference.  Lepton-eda looks like a nice successor 
> to gEDA, and a good candidate for a new port.
> 
> 
> On Sat, Jan 27, 2024 at 10:25 AM Valerio Messina via macports-dev 
> mailto:macports-dev@lists.macports.org>> 
> wrote:
> domain was http://www.geda-project.org/ 
> see: https://en.wikipedia.org/wiki/GEDA 
> seems payd till October 2024 but now is down
> 
> gEDA development has always been with the main focus on Linux and have 
> never cared about macOS and Windows.
> In recent years, competition from KiCad (which is madly actively 
> developed cross platform by CERN and is still GPL) I think has killed 
> the development of gEDA. The only exception is GerbV which is still 
> maintained and is quite up to date for Linux and Windows, but not for macOS:
> https://github.com/gerbv/gerbv 
> 
> In reality GerbV has always been the only program in the package to 
> compile correctly for Windows, I generated it annually for Linux and 
> Windows colleagues, and due to its ease I still find it superior to the 
> one integrated into KiCad, even if it does not support the Gerber X2 
> standard is become obsolete.
> 
> 
> Take a look to Lepton:
> https://github.com/lepton-eda/lepton-eda 
> 
> seems mantained
> 
> Valerio
> 
> 
> On 1/27/24 1:46 PM, Nils Breunese wrote:
> > I’m not familiar with gEDA, but according to 
> > https://github.com/macports/macports-ports/blob/master/science/geda-gaf/Portfile
> >  
> > 
> >  the homepage is http://www.geda-project.org/ 
> > 
> > But requests to both the .com and the .org domains indeed fail for me.
> > 
> > Nils.
> > 
> >> Op 26 jan 2024, om 03:37 heeft Mark Anderson  >> > het volgende geschreven:
> >>
> >> I've been having trouble getting to http://www.geda-project.com/ 
> >>  - anyone else? This doesn't bode well for 
> >> the project / Portfile. It might be time to retire it, or mark it as 
> >> deprecated.
> >>
> >> —Mark

Re: More classes of maintainer

[Gagan Sidhu via macports-dev]

i agree with this.

i’m still pissed i can’t merge my legacy trac with the new git system. the fact 
they were separate in the first place is like, the antithesis of what the APPUL 
mantra USED to mean.

but whatever. mobile rulz. 2fa, mfa, gfy

tethered to a cancer box no matter what it seems, or maybe that’s what the 
“investors” behind the 2000 tech stocks, who remain the power players, are 
trying to force upon us.

i want to put all of my money into credit suisse first BAHSTUN, right away.

Thanks,
Gagan

> On Nov 3, 2023, at 9:29 PM, grey  wrote:
> 
> To chime in on this, and take what I write with a grain of salt since
> I still feel relatively new to MacPorts, but too much dependence on
> GitHub gives me the heebie jeebies.
> 
> I realize Trac isn't perfect, but there are far worse issue tracking
> systems that I have administered over the decades.
> 
> If anything, I think it would be fantastic (though obviously, a non
> trivial amount of effort) if MacPorts were more self sufficient and
> self hosted and treated closed source for-profit proprietary entities
> such as GitHub as read-only mirrors; or maybe facilitated other git
> front ends such as codeberg, etc.?

Re: [MacPorts] #66278: graphviz: installing with +smyrna flag fails on fresh install (was: installing with +smyrna flag fails on fresh install)

[Gagan Sidhu via macports-dev]

found the problem.

line 215 in graphviz/cmd/smyrna/main.c

char *path is not defined for macos.

after defining, build works. will post upstrema

thanks lads.

btw this new (“old” cause APPARENTLY an 8 core i9 w/ 64 gigs sucks compared to 
an M1 [lulz]) is DOPE

wish i had dashboard though. so the crapalina moniker will stick. better than 
monterey!

thanks,
Gagan

> On Nov 17, 2022, at 1:25 AM, MacPorts  wrote:
> 
> #66278: graphviz: installing with +smyrna flag fails on fresh install
> ---+
>  Reporter:  i3roly|  Owner:  ryandesign
>  Type:  defect| Status:  assigned
>  Priority:  Normal|  Milestone:
> Component:  ports |Version:
> Resolution:|   Keywords:
>  Port:  graphviz  |
> ---+
> Changes (by jmroot):
> 
> * owner:  (none) => ryandesign
> * status:  new => assigned
> * cc: mascguy (added)
> 
> 
> -- 
> Ticket URL: 
> MacPorts 
> Ports system for macOS