I have installed Lazarus 1.6 on my RPi3b+, and it seems to be working.
I've been trying to move a Lazarus application to the RPi. It uses the libusb library which is loaded into a pascal wrapper unit with {LINKLIB usb} command.
This program works on my i386 Linux Ubuntu system, but when I try to compile it on the RPi I get the following message:
"usr/bin/ld.bfd: cannont find /lib/i386-linux-gnu/libusb-0.1.so.4.4.4"
I don't understand this since the directory it should be looking in is /lib/arm-linux-gnueabifh, with nothing to do with i386.
Any hints would be most welcome!
HOLD IT: Debian-based. They've messed around with libusb trying to deprecate the older version of the library, and while they thought they'd got it right for stuff based on GNU ld it's by no means a complete solution.
This from notes I've put in my dynamicl-linking library to handle it:
FModuleHandle := LoadLibrary(FModuleName);
FLastError := GetLoadErrorStr;
if FModuleHandle = NilHandle then
{$IFDEF UNIX }
if (GetLastOSError = 0) and (Pos(': invalid ELF header', LastError) > 0) then begin
(* I believe this is a Debian special: libusb-0.1 has been declared obsolete *)
(* and "replaced by a linker script, in the hope it will make everybody happy." *)
(* The error message above might be subject to i18n, so users in non-English *)
(* speaking locales might have at least as much grief as I've just had. Blame *)
(* Aurelien Jarno :-) *)
revisedFilename := LastError;
SetLength(revisedFilename, Pos(':', revisedFilename) - 1);
revisedFilename := readSecondLine(revisedFilename);
if Pos('GROUP ( ', revisedFilename) = 1 then begin
Delete(revisedFilename, 1, Length('GROUP ( '));
SetLength(revisedFilename, Pos(' )', revisedFilename) - 1);
FModuleName := revisedFilename;
LoadModule; (* Recursive *)
(* Exits on success, otherwise raises the same exception as below. *)
exit
end
end;
{$ENDIF }
raise DynamicModuleException.Create(SysErrorMessage(GetLastOSError)
+ ' loading ' + FModuleName);
I'm not saying that's a fix, but I'm very suspicious that it's related.
(Later:)
Sorry about the lousy formatting on the original post. I can't speak for Ubuntu but note that on Debian- from which Ubuntu derives- there are two versions of the libusb packages:
libusb-0.1-4 - userspace USB programming library
libusb-dev - userspace USB programming library development files
libusb-1.0-0 - userspace USB programming library
libusb-1.0-0-dev - userspace USB programming library development files
libusb-1.0-doc - documentation for userspace USB programming
and that some of the files don't have the expected content:
$ find . -iname 'libusb*so*' -exec file {} \;
./x86_64-linux-gnu/libusb.so: ASCII text
./x86_64-linux-gnu/libusb-0.1.so.4: symbolic link to libusb-0.1.so.4.4.4
./x86_64-linux-gnu/libusb-1.0.so.0.1.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=859f22f61deb3055534f3598cf3515b21d4bec3e, stripped
./x86_64-linux-gnu/libusb-1.0.so.0: symbolic link to libusb-1.0.so.0.1.0
./x86_64-linux-gnu/libusb-0.1.so.4.4.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=b3e8faeb321c0f4f79f58c9fe6cb893231f86e6b, stripped
Also, as you've found out, there's at least one broken symlink in there:
$ find . -iname 'libusb-0.1*so*' -ls
393854 0 lrwxrwxrwx 1 root root 19 May 4 2018 ./x86_64-linux-gnu/libusb-0.1.so.4 -> libusb-0.1.so.4.4.4
393848 32 -rw-r--r-- 1 root root 31024 May 4 2018 ./x86_64-linux-gnu/libusb-0.1.so.4.4.4
$ ls libusb-0.1.so.4.4.4
ls: cannot access 'libusb-0.1.so.4.4.4': No such file or directory
MarkMLl