Re: [Gimp-print-devel] macos Gutenprint gutenprint52+cups backend

[Steve L. <sle...@ya...>]

I will rebuild insuring it includes a static version. Mea culpa. 

Steve Letter
System Software Engineer, Embedded

> On Apr 10, 2019, at 10:02 PM, Robert Krawitz <rl...@al...> wrote:
> 
> On Wed, 10 Apr 2019 20:44:33 -0500, Matt Broughton wrote:
>>> On Apr 10, 2019, at 7:40 PM, Robert Krawitz <rl...@al...> wrote:
>>> 
>>>> On Wed, 10 Apr 2019 15:55:00 -0500, Matt Broughton wrote:
>>>> Pulling the issue from other threads so it is easier to find:
>>>> 
>>>> Out of curiosity, I tried calling the gutenprint52+cups backend without argument.  I am not sure this is valid reasoning or not.  In any event, the output may be informative.
>>>> 
>>>> ~ matt$ sudo /usr/libexec/cups/backend/gutenprint52+usb Password:
>>>> dyld: Library not loaded: /usr/local/lib/libusb-1.0.0.dylib
>>>> Referenced from: /usr/libexec/cups/backend/gutenprint52+usb
>>>> Reason: image not found
>>>> Abort trap: 6
>>>> ~ matt$ 
>>>> 
>>>> It sure looks like it may be showing a crash on signal 6.
>>> 
>>> So that suggests that gutenprint52+usb has an unsatisfied runtime
>>> dependency on libusb (or in other cases it could be another library --
>>> unfortunately, it looks like CUPS isn't capturing that -- but libusb
>>> seems lke the most likely culprit).
>>> 
>>> I take it libusb isn't a standard component on OS X, so we need some
>>> way to ensure it gets installed (either by static linking if possible,
>>> in which case we'd have to distribute the source, as it's LGPL2.1+, by
>>> bundling, or by otherwise arranging for it to be installed on
>>> Gutenprint installation).
>> 
>> I'll have to leave to technical, coding stuff to you and Steve.
>> When we started producing the gutenprint52+cups backend, we needed
>> to have libsub compiled in the $PATH.  As I understand it, the
>> backend was built against the library but it wasn't required in the
>> final distribution.  Would this be the difference between building
>> against a static library and a dynamic library?  If so, it looks
>> like Steve built against the *.dyld rather than *.a.
> 
> I think that likely is what happened.
> 
> My difficulty is that I'm simply not familiar with the Mac
> environment, and this is really a Mac environment issue.  Linux
> distributions bundle Gutenprint, and handle the necessary dependencies
> (or users can install it themselves, and are responsible for the
> dependencies likewise, but people who do that are usually familiar
> with it).  That isn't how OS X resolves dependencies for unbundled
> products.
> 
>> I can't remember if I was doing the releases when our backend was
>> introduced.  I think there may have been some discussion about the
>> need to bundle the source code as the library itself was not being
>> distributed.
> 
> You were, IIRC.
> 
> I see no harm in distributing a tarball of the relevant libusb source.
> The bzip2-compressed tarball is only 600K (or we could just provide
> the pre-autogen code, which is 300K).  Doesn't mean people have to
> install it, but we could put it in the .dmg for people who are
> interested.  If that's the price to pay for avoiding this problem,
> it's a very small one.
> -- 
> Robert Krawitz                                     <rl...@al...>
> 
> ***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
> Member of the League for Programming Freedom  --  http://ProgFree.org
> Project lead for Gutenprint   --    http://gimp-print.sourceforge.net
> 
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel