libusb, cups compatability...

libusb, cups compatability...

[idunham]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

I've been needing to set up printing, so I went ahead and compiled libusb
1.0.9 and cups 1.5.3.
libusb needs the  TIMESPEC_TO_TIMEVAL macro; for the time being, I added
the definition to libusb (diff attached for Gregor's sake).
It probably should go in sys/time.h with gnu | bsd visibility instead.
Other than that, libusb compiles.

CUPS builds for the most part; in ppdc, genstrings segfaults (haven't
built gdb, can't say what the issue is). make || make would finish,
though...
It _partly_ passes make -i test; I attached the logs it generated. CUPS
wants -D_BSD_SOURCE (some implicit definitions).





[-- Attachment #2: libusb-timespec.diff --]
[-- Type: text/plain, Size: 416 bytes --]

--- libusb-1.0.9/libusb/io.c
+++ libusb-1.0.9-musl/libusb/io.c
@@ -36,6 +36,17 @@
 
 #include "libusbi.h"
 
+/*
+ * Android and musl, at least, don't provide this macro
+ */
+#ifndef TIMESPEC_TO_TIMEVAL
+#define TIMESPEC_TO_TIMEVAL(tv, ts)		\
+do {						\
+	(tv)->tv_sec = (ts)->tv_sec;		\
+	(tv)->tv_usec = (ts)->tv_nsec /	1000;	\
+} while (0)
+#endif
+
 /**
  * \page io Synchronous and asynchronous device I/O
  *

[-- Attachment #3: cups-log.htm --]
[-- Type: text/html, Size: 106224 bytes --]

Re: libusb, cups compatability...

[Rich Felker]

On Tue, Jul 24, 2012 at 11:36:38PM -0700, idunham@lavabit.com wrote:
> I've been needing to set up printing, so I went ahead and compiled libusb
> 1.0.9 and cups 1.5.3.

Nice.

> libusb needs the  TIMESPEC_TO_TIMEVAL macro; for the time being, I added
> the definition to libusb (diff attached for Gregor's sake).
> It probably should go in sys/time.h with gnu | bsd visibility instead.
> Other than that, libusb compiles.

Is there a corresponding opposite-direction macro that should be
added?

> CUPS builds for the most part; in ppdc, genstrings segfaults (haven't
> built gdb, can't say what the issue is). make || make would finish,
> though...

This suggests a broken makefile, though most makefiles are broken in
the same regard... Because the program crashed while writing a target,
that target, probably corrupted, exists with a valid timestamp and
causes make to think it doesn't need to be generated the next time
around. Really, any command in make should move the successfully-built
file into place _atomically_ (e.g. first writing to a temp file then
moving it) so this can't happen.

Anyway, to get back on-topic, I suspect the generated file was
incomplete/corrupt and this might be causing problems later down the
line.

Rich

Re: libusb, cups compatability...

[idunham]

> On Tue, Jul 24, 2012 at 11:36:38PM -0700, idunham@lavabit.com wrote:
>> I've been needing to set up printing, so I went ahead and compiled
>> libusb
>> 1.0.9 and cups 1.5.3.
>
> Nice.
>
>> libusb needs the  TIMESPEC_TO_TIMEVAL macro; for the time being, I added
>> the definition to libusb (diff attached for Gregor's sake).
>> It probably should go in sys/time.h with gnu | bsd visibility instead.
>> Other than that, libusb compiles.
>
> Is there a corresponding opposite-direction macro that should be
> added?
Yes, TIMEVAL_TO_TIMESPEC. I didn't submit a header patch because I was too
impatient to implement the latter, and figured both should be added at
once.

>> CUPS builds for the most part; in ppdc, genstrings segfaults (haven't
>> built gdb, can't say what the issue is). make || make would finish,
>> though...
>
> This suggests a broken makefile, though most makefiles are broken in
> the same regard... Because the program crashed while writing a target,
> that target, probably corrupted, exists with a valid timestamp and
> causes make to think it doesn't need to be generated the next time
> around. Really, any command in make should move the successfully-built
> file into place _atomically_ (e.g. first writing to a temp file then
> moving it) so this can't happen.

It writes  sample.c (IIRC) which is apparently supposed to contain
localization strings (yes, it builds a C++ file to generate a C file that
has the localization hard-coded inside)...however, the file is empty in
this case.

> Anyway, to get back on-topic, I suspect the generated file was
> incomplete/corrupt and this might be causing problems later down the
> line.
Empty.
This is the main directory that causes trouble during make test; there may
be other issues causing segfaults at both points, however.