[lsb-discuss] SANE and LSB: libusb does not compile

[Wichmann, Mats D]

> Now I succeeded to compile libusb by adding "#include <asm/ioctl.h>"
> to linux.h. This uses the platform-specific (32/64 bit)
> asm/ioctl.h of the LSB Build Environment chroot.
> 
> Problem is now libieee1284. Also adding "#include <asm/ioctl.h>" to
> every file with "#include <sys/ioctl.h>" and doing
> 
> perl -p -i -e 's/\bsize_t\b/long/g' `grep -l size_t */*`
> 
> due to "size_t" not existing in the LSB 

??? size_t certainly exists

You *might* be running into the problem described in bug 1505,
which has been addressed in the development version of the
LSB headers, but what happened here is size_t moving from one
file to another, not that it was missing before.


> I have tried without modification of LDFLAGS, but also with adding
> "/usr/lib/libc_nonshared.a" and get the result above. Adding
> "/usr/lib/libc.a" already gives an error in the "./configure" step.
> "./configure" tells that the compiler is not able to create
> executables. In config.log I get

You understand that you need both libc.so and libc_nonshared.a,
right? lsbcc does this for you, and you may be tripping over
something in ordering in trying to change stuff. You also must
have ligbcc for the unwind functions. 

> /usr/lib/libc.a contains the symbol "ioperm" (checked by
> simply grepping
> "ioperm"), /usr/lib/libc_nonshared.a and /opt/lsb/lib/libc* not.

ioperm is not in LSB, it's very hardware specific and would
not be of use to portable applications. If the library is not
trying to use it directly, and is just stumbling across a chain
of inclusions then in means not having the right library set.
You need a shared libc, always; and you must also be getting
libc_nonshared.a (lsbcc emulates what /usr/lib/libc.so does,
but internally rather than by use of that linker script).

I have a feeling this has not answered the question....