On Mon, Feb 10, 2014 at 11:06:27AM +0000, Bjoern A. Zeeb wrote: > > On 10 Feb 2014, at 04:18 , Wojciech A. Koszek <wkos...@freebsd.org> wrote: > > > On nie, lut 09, 2014 at 02:59:06 +0100, Juergen Lock wrote: > >> On Sun, Feb 09, 2014 at 02:56:24AM +0000, Wojciech A. Koszek wrote: > >>> On sob, lut 08, 2014 at 09:45:46 +0100, Juergen Lock wrote: > >>>> On Fri, Feb 07, 2014 at 08:49:28PM +0000, Wojciech A. Koszek wrote: > >>>>> On pi??, lut 07, 2014 at 09:12:08 +0100, Juergen Lock wrote: > >>>>>> Hi! > >>>>>> > >>>>>> This came up on irc so I tried to build a linux libusb port (before > >>>>>> I learned about ports/146895), mine uses linux_base-gentoo-stage3 > >>>>>> like linux_kdump with a src/lib/libusb head snapshot so it's more > >>>>>> up to date than wkoszek's build (ports/146895), and it's really > >>>>>> easy to update it again. Also maybe it can be used as linux > >>>>>> libusb-1.0.so too; I didn't actually test it tho. > >>>>>> > >>>>>> Should this be committed? Is wkoszek's version better since it > >>>>>> also builds on < 10.x? Comments welcome... > >>>>>> > >>>>>> wkoszek's version: > >>>>>> > >>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=146895 > >>>>>> > >>>>>> Mine: > >>>>>> > >>>>>> http://people.freebsd.org/~nox/tmp/linux_libusb.shar > >>>>>> > >>>>>> Distfile: > >>>>>> > >>>>>> > >>>>>> http://people.freebsd.org/~nox/tmp/distfiles/linux_libusb-11.0r261448.tar.bz2 > >>>>>> > >>>>>> 10/amd64 package: > >>>>>> > >>>>>> > >>>>>> http://people.freebsd.org/~nox/tmp/packages/10amd64/linux_libusb-11.0r261448.txz > >>>>>> > >>>>>> (built via: > >>>>>> > >>>>>> poudriere bulk -v -j 10amd64 -p custom devel/linux_libusb > >>>>>> > >>>>>> - btw for some reason the dependency emulators/linux_base-gentoo-stage3 > >>>>>> doesn't build for 10i386 in poudriere bulk, I get a pkg segfault. bapt > >>>>>> Cc'd...) > >>>>>> > >>>>> > >>>>> Juergen, > >>>> Hi! > >>>>> > >>>>> What would be the reason for this update? > >>>>> > >>>>> My stuff may be out of date, but it was all tested and working. I > >>>>> verified > >>>>> it with Linux'ish lsusb(1) and USB-based FPGA JTAG programmer, for which > >>>>> this stuff was written. > >>>>> > >>>> I was just thinking an updated version may be useful, but if it's > >>>> already working for everyone maybe less so... > >>>> > >>>> Or would it work as a linux libusb-1.0.so too? I know the libusb 1.0 > >>>> stuff added some functions since 9.x at least... maybe hps would know > >>>> (Cc'd.) > >>>> > >>> > >>> Juergen, > >>> > >>> I think this package is useful and is looking for maintainer, so if you > >>> have > >>> time and energy, I'm OK with upgrading it, but I suggest testing it first. > >>> Bjoern might be interested too. > >>> > >> You mean bz@ ? Cc'd. I tried testing lsusb from debian sid but it printed > >> nothing, neither with my nor with your older version, but maybe it's just > >> `too new' for our current linuxolator. > > > > I assume you have at least 1 USB device while trying this. I don't remember > > exactly, but while trying within Linuxolator, you may need devfs/procfs to > > be mounted under Linuxolator's root directory. > > My understanding and from looking at trace is that if we cannot find it in > /compat/linux we ale search in /; so no need for an extra mount unless maybe > you run chrooted. > > > > So you'll have to figure this out. > > > > Does it return with 0 exit code? > > > > If not, lsusb should be simple enough to let you place printf() all over the > > place and understand out when it's failing. > > For me the problem was a clock_gettime() call in the libusb which my glibc > did not provide. That made all things fail (silently) until I used linux > ?rtld" tracing to see the unresolved symbol from libusb/the commercial 3rd > party software dynamically loading libusb. > And my linux_kdump ends like this:
35607 lsusb CALL munmap(0x28247000,0x8000) 35607 lsusb RET munmap 0 35607 lsusb CALL linux_open(0x28090c31,0,0x28081e00) 35607 lsusb NAMI "/compat/linux/dev/usbctl" 35607 lsusb NAMI "/dev/usbctl" 35607 lsusb RET linux_open 3 35607 lsusb CALL linux_ioctl(0x3,0xffe5 ,0xffffc5d8) 35607 lsusb RET linux_ioctl 0 35607 lsusb CALL close(0x3) 35607 lsusb RET close 0 35607 lsusb CALL linux_exit_group(0x1) 35607 lsusb UNKNOWN(11) and the exit code is 1, so I guess it's failing on an unhandled syscall or something like that. Juergen _______________________________________________ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"