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

[Robert K. <rl...@al...>]

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