Menu
▾
▴
gimp-print-devel
|
From: Matt B. <wal...@ma...> - 2019-04-10 20:55:10
|
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. Matt -- Matt wal...@ma... |
|
From: Robert K. <rl...@al...> - 2019-04-11 00:40:45
|
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). -- 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 |
|
From: Matt B. <wal...@ma...> - 2019-04-11 01:44:41
|
> 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). > -- > Robert Krawitz <rl...@al...> 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 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. Matt -- Matt Broughton wal...@ma... |
|
From: Matt B. <wal...@ma...> - 2019-04-11 01:55:52
|
> On Apr 10, 2019, at 8:44 PM, Matt Broughton <wal...@ma...> 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). >> -- >> Robert Krawitz <rl...@al...> > > > 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 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. libusb not libsub ----- it is not included in macos. It has to be built and put in $PATH before Gutenprint ./configure is run. -- Matt Broughton wal...@ma... |
|
From: Robert K. <rl...@al...> - 2019-04-11 02:03:08
|
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 |
|
From: Steve L. <sle...@ya...> - 2019-04-11 13:22:02
|
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 |
|
From: PhotoBooth b. <rol...@gm...> - 2019-04-12 12:14:42
|
after you rebuild it, please post where I can download it from so I can test with my sony 200 printer. On Thu, Apr 11, 2019 at 6:22 AM Steve Letter via Gimp-print-devel < gim...@li...> wrote: > 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 > > _______________________________________________ > Gimp-print-devel mailing list > Gim...@li... > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X