Lazarus
Programming => Operating Systems => Linux => Topic started by: Curt Carpenter on October 20, 2019, 06:31:57 am
-
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!
-
Have you changed the Config and Target compiler options in the Project settings?
-
Thanks for the reply.
Yes I've tried changing the project options, but haven't found any way to remove the "1386" element from the error message. Lazarus seems to think that I'm compiling on a 386 box still, not a RPi.
-
Perhaps your app is using a package which has some hard-coded path(s) in its options?
-
Better to compile on the Raspberry Pi itself (as long as you extend the swap file that works. even fast)
Cross compilation relies on so many things.
I can give you my configuration for win64-x86_64 to arm-linux-eabihf if you want. But that does not rely on external code like your libusb.
My advice is to simply compile native on the Raspberry Pi itself.
-
Thanks for the input.
I'm not trying to cross-compile, and am in fact compiling my program on the RPi3b+, Lazarus 1.6.
Lazarus on the RPi in general seems to be working fine. Just the library problem.
My program compiles and runs on my linux PC, but can't get it to compile on the RPi due to the error.
-
try
sudo apt-get install libusb-dev
-
My program consists of only three units, and I sure can't see anything that indicates I may have a hard-coded path.
The unit causing the problem starts like this:
Unit libusb;
Interface
{$LINKLIB c}
{$LINKLIB usb}
I'll try installing libusb-dev. Thanks again for the inputs.
...
Interestingly, libc appears to load with not problem.
-
Thank you Thaddy. The program compiles now, but I get an External:SIGSEGV error.
I can work on that!
So thanks again for your help.
-
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