[Openmcl-devel] weird corruption of previously built MacOS application

Fri Mar 10 16:55:31 PST 2023

yes, my reference to app/var/lib was an abbreviation of a project specific folder. Replace it with one of your own.

- DM

> On Mar 10, 2023, at 16:34, Arthur Cater <arthur.cater at ucd.ie> wrote:
> 
> Thank you very much for the response. I wish I knew more about dynamic libraries. Well actually I wish I didn’t have to. :) or :( take your pick. Perhaps they explain more generally why what once worked is now broken.
> 
> There’s stuff in /usr/local/lib: a Perl5 folder, an ImageMagick-6.8.3 folder, and 42 files named libsvn_blahblahblah.  Nothing there updated since 4 Feb 2019.
> And I don’t know what  app/var/lib means. I’ve tried replacing ‘app’ with the ~/Desktop//14Feb… name of the app file but to no avail, in Terminal and in Finder’s ‘Go To Folder’.
> 
> Aside:
> Is all this Apple’s way of forcing me to get a newer computer or get stuffed? I’ve resisted upgrading beyond Mojave because previous upgrades always seemed to cause a cascade of problems. Now, as I say, what once worked is broken.
> 
>> On 10 Mar 2023, at 21:24, dbm at refined-audiometrics.com <mailto:dbm at refined-audiometrics.com> wrote:
>> 
>> FWIW,
>> 
>> We had a similar experience about 2-3 years ago (ask Shanon about it). 
>> 
>> It turned out that the Mac got confused by the existence of multiple different copies of a vital dynlib, located in two separate directories. It took us a while to track it down, but once we isolated the problem, and removed all extraneous copies (/usr/local/lib vs app/var/lib etc) we got things back to proper behavior. We settled by using our own var/lib folder for all our vital dynlibs. I would suspect anything still living in /usr/local/lib.
>> 
>> The Mac has a bunch of nonsense (e.g., pre-binding) going on to attempt to thwart dynlib injections. Perhaps that is your problem too?
>> 
>> - DM
>> 
>>> On Mar 10, 2023, at 14:10, Arthur Cater <arthur.cater at ucd.ie <mailto:arthur.cater at ucd.ie>> wrote:
>>> 
>>> Furthermore, my application built in Feb 2019 now says
>>> Implementation Version is Version 1.12-dev (v1.12-dev.4-4-gd9740256) DarwinX8664
>>> 
>>> I don’t think I got v1.12 until December 2022. I don’t think it existed in 2019. And I haven’t tampered with my system clock.
>>> 
>>> and the files-info shows
>>> <Screenshot 2023-03-10 at 20.58.16.png>
>>> 
>>> 
>>> The strange app name is created by a build script I used. How could it have been changed between Feb 2019 and May 2019? It seems I changed the icon.
>>> From Terminal,
>>> ArthursSSD:Desktop arthur$ cd 14Feb2019GoblinApp.app/
>>> ArthursSSD:14Feb2019GoblinApp.app arthur$ ls -l
>>> total 1184
>>> drwxr-xr-x  6 arthur  staff  192 14 Feb  2019 Contents
>>> -rw-r--r--@ 1 arthur  staff    0 10 May  2019 Icon?
>>> ArthursSSD:14Feb2019GoblinApp.app arthur$ 
>>> 
>>> 
>>> 
>>>> On 10 Mar 2023, at 19:55, Arthur Cater <arthur.cater at ucd.ie <mailto:arthur.cater at ucd.ie>> wrote:
>>>> 
>>>> I have been running a ccl application that I built in 2019 using ccl11 on my MacBook Pro running Mojave. Until a couple of hours ago this was working (though a bit flaky, sometimes crashing for no obvious reason in a way it didn’t back in 2019, and Search Files not working). I’d recently been starting it up several times a day.
>>>> 
>>>> Today I tried to build another one using ccl12, in a different folder. I had made a backup copy of my program’s sources and fails etc. I changed my build script to CD to the location of ccl12 instead of ccl11.
>>>> 
>>>> So the new ClozureCL64 application doesn’t want to start.  But listen, it’s worse.
>>>> 
>>>> The old application, with its ccl logical pathname set from the contents of a variable in my ccl-init.lisp file thus (the goblin::*ccl-translations* variable having been set before image creation)
>>>> 
>>>> #+:goblin-app
>>>> (progn
>>>>  (setf (logical-pathname-translations "ccl") goblin::*ccl-translations*)
>>>>  (defun goblin::format? () (cl-user::format?))
>>>>  (defun goblin::kreuger nil (cl-user::kreuger))
>>>>  (when goblin::*eval-queue-process*
>>>>    (process-kill (shiftf goblin::*eval-queue-process* nil))))
>>>> 
>>>> 
>>>> now has problems starting up, which it didn’t earlier. I’m getting this
>>>> 
>>>> ; Warning: Interface file #P"/Users/arthur/Desktop/darwin-x86-headers64/cocoa/constants.cdb" does not exist, and the containing directory does not exist.
>>>> ;          This may mean that that the "ccl:" logical-pathname host has not been properly initialized. 
>>>> ; While executing: CCL::CDB-OPEN, in process Listener(35).
>>>> ; Warning: Interface file #P"/Users/arthur/Desktop/darwin-x86-headers64/libc/constants.cdb" does not exist, and the containing directory does not exist.
>>>> ;          This may mean that that the "ccl:" logical-pathname host has not been properly initialized. 
>>>> ; While executing: CCL::CDB-OPEN, in process Listener(35).
>>>> ; Warning: Interface file #P"/Users/arthur/Desktop/darwin-x86-headers64/cocoa/vars.cdb" does not exist, and the containing directory does not exist.
>>>> ;          This may mean that that the "ccl:" logical-pathname host has not been properly initialized. 
>>>> ; While executing: CCL::CDB-OPEN, in process Listener(35).
>>>> ; Warning: Interface file #P"/Users/arthur/Desktop/darwin-x86-headers64/libc/vars.cdb" does not exist, and the containing directory does not exist.
>>>> ;          This may mean that that the "ccl:" logical-pathname host has not been properly initialized. 
>>>> ; While executing: CCL::CDB-OPEN, in process Listener(35).
>>>>> Error: Foreign variable "NSCommandKeyMask" not found
>>>>> While executing: CCL::%LOAD-VAR, in process Listener(35).
>>>>> Type cmd-/ to continue, cmd-. to abort, cmd-\ for a list of available restarts.
>>>>> If continued: Skip loading init file.
>>>>> Type :? for other options.
>>>> 1 > 
>>>> 
>>>> 
>>>> 
>>>> How can my existing application possibly get interfered with in this way? It happens even after restarting the computer. My mental model of the world is under siege. Is there some mechanism that causes strings used in pathnames to be quasi-magically linked across application bundles? I am really puzzled.
>>>> 
>>>> Arthur
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20230310/cac7816c/attachment.htm>