Re: Fixed for MacOS 10.14 universal build uploaded

> On Feb 1, 2021, at 7:11 AM, Steve Letter via Gimp-print-devel <[email protected]> wrote:
> 
> 
>>> Michael, 
>>> 
>>> I tried so many things I was certain I had tried that. So certain I started to write an email about how that didn’t work. But then I thought I’d better make damn sure I had tried it so I did.
>>> 
>>> And man do I feel stupid. Of course that was the answer.  I have uploaded the new disk image (built from the same files as pre1) to
>>> 
>>> https://sourceforge.net/projects/gimp-print/files/snapshots/gutenprint-5.3.4-pre2.dmg/download
>>> 
>>> I am still hacking, I haven’t produced a scripted build yet but I will once we are satisfied it is building correctly. 
>>> 
>>> Steve Letter
>>> Sent from my Symbolics Lisp Machine using zmail. 
>>> 
>>>> On Jan 31, 2021, at 5:02 PM, Michael Sweet <[email protected]> wrote:
>>>> 
>>>> Steve,
>>>> 
>>>> You might need to list -lcupsimage before -lcups, in case the linker is using the definition from libcups first...
>>>> 
>>>> 
>>>>> On Jan 31, 2021, at 2:51 PM, Steve Letter via Gimp-print-devel <[email protected] <mailto:[email protected]>> wrote:
>>>>> 
>>>>> As suggested by Michael I linked libcupsimage.dylib but still got the message in the log file, 
>>>>> dyld: Symbol not found: _cupsRasterOpen
>>>>> Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3
>>>>> Expected in: /usr/lib/libcups.2.dylib
>>>>> 
>>>>> I verified that libcupsimage was linked in (with otool -L)
>>>>> 
>>>>> otool -L /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3                    
>>>>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3:
>>>>> 	/usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2..14.0)
>>>>> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
>>>>> 	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7..0.0)
>>>>> 	/usr/lib/libcupsimage.2.dylib (compatibility version 2.0.0, current version 2.3.0)
>>>>> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0)
>>>>> 	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
>>>>> 
>>>>> and that _cupsRasterOpen was indeed in libcupsimage
>>>>> Stephens-MacBook-Pro:cups sletter$ nm /usr/lib/libcupsimage.2.dylib | grep _cupsRasterOpen
>>>>> 00000000000035b8 T _cupsRasterOpen
>>>>> 00000000000035e3 T _cupsRasterOpenIO
>>>>> 
>>>>> Obviously there is something in my build that must be making the filter believe that _cupsRasterOpen is in libcups.  I thought I’d ask here for help before I go to the Apple developers group to ask what I have wrong.
>>>>> 
>>>>> Steve Letter

Success!! With macos 10.14.6 Mojave.  Install log looks clean, queue PPDs are updated, and it prints.  I checked a couple of binaries for the architectures included.  Both x86-64 and arm64 are listed.  The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble.

file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon 
/Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
/Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64):	Mach-O 64-bit executable x86_64
/Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64):	Mach-O 64-bit executable arm64

I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro.  I will check with at least Lion 10.7.

Matt

_______________________________________________
Gimp-print-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel