Beastpatcher no longer builds with newer versions of libmtp or libusb

[LambdaCalculus]

Hey all,

I've tried building beastpatcher on my laptop (running Debian-testing, x86_64) so I could use it to restore a Gigabeat T that I have that was the subject of a porting effort from 10 years ago. However, on initial run of make in the beastpatcher source directory, the process crapped out with the following error:

Code: [Select]

robert@waterdeep:~/rockbox/utils/MTP/beastpatcher$ make
gcc -Wall -W -DWITH_BOOTOBJS -I../../../tools   -o bin2c ../../../rbutil/tools/bin2c.c
./bin2c bootloader.bin bootimg
gcc -Wall -W -DWITH_BOOTOBJS -I../../../tools   -DBEASTPATCHER -o beastpatcher beastpatcher.c bootimg.c mknkboot.c main.c mtp_libmtp.c /usr/lib/libmtp.a /usr/lib/libusb.a
gcc: error: /usr/lib/libmtp.a: No such file or directory
gcc: error: /usr/lib/libusb.a: No such file or directory
make: *** [Makefile:40: beastpatcher] Error 1
robert@waterdeep:~/rockbox/utils/MTP/beastpatcher$

I was able to locate libusb.a in another directory (on my setup, libusb.a was at /usr/lib/x86_64-linux-gnu/libusb.a) and symlink it to the right place, but I can't find libmtp.a anywhere (whereis tells me /usr/lib/x86_64-linux-gnu/libmtp.so). I have all the necessary libmtp packages needed, dev tools and all, installed, so I'm a little confused as to where libmtp.a could be on my system, unless I *could* use libmtp.so instead (which also sounds a little silly).

Perhaps a check could be added to the Makefile to check for these needed files in other locations instead?

[saratoga]

Random guess, but do you have libmtp-dev installed?

[bluebrother]

Looking at the Makefile this is not related to a new version of libmtp -- the path is hard coded (so it links to the static library), and the path used is the default path that was standard on 32bit distros back then. I guess building on a 32bit distro would still work

On my Debian box there's no static libmtp.a, though libusb.a does exist (in libusb-dev), seems libmtp packages don't ship a static binary. So the easy thing would be no simply dynamically link libusb and libmtp, though afair the original reason was to have a beastpatcher binary that doesn't (externally) depend on those libs. Given there's no release coming up we could simply go that way.

Btw, the Makefile shouldn't use hardcoded paths -- the linker should be able to find that. In your case, replace the LIBS value with -lusb -lmtp and you're good to go. Will cause a dynamically linked binary though, but that shouldn't be a problem

[LambdaCalculus]

Dynamically linked won't bother me so much. 

I did the LIBS value change as bluebrother recommended and I was able to build beastpatcher. There was one warning during the build, though:

Code: [Select]

robert@waterdeep:~/rockbox/utils/MTP/beastpatcher$ make
gcc -Wall -W -DWITH_BOOTOBJS -I../../../tools   -o bin2c ../../../rbutil/tools/bin2c.c
./bin2c bootloader.bin bootimg
gcc -Wall -W -DWITH_BOOTOBJS -I../../../tools   -DBEASTPATCHER -o beastpatcher beastpatcher.c bootimg.c mknkboot.c main.c mtp_libmtp.c -lmtp -lusb
mtp_libmtp.c: In function ‘mtp_send_firmware’:
mtp_libmtp.c:122:9: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
  122 |     int ret;
      |         ^~~
strip beastpatcher
robert@waterdeep:~/rockbox/utils/MTP/beastpatcher$