|
does this makes sense ??
jim@jim-desktop:/media/jim/DEV/BLUEZ/bluez-5.50$ sudo make install
make --no-print-directory install-am
/bin/mkdir -p '/usr/local/bin'
/bin/bash ./libtool --mode=install /usr/bin/install -c client/bluetoothctl monitor/btmon tools/rctest tools/l2test tools/l2ping tools/bccmd tools/bluemoon tools/hex2hcd tools/mpris-proxy tools/btattach '/usr/local/bin'
libtool: install: /usr/bin/install -c client/bluetoothctl /usr/local/bin/bluetoothctl
libtool: install: /usr/bin/install -c monitor/btmon /usr/local/bin/btmon
libtool: install: /usr/bin/install -c tools/rctest /usr/local/bin/rctest
libtool: install: /usr/bin/install -c tools/l2test /usr/local/bin/l2test
libtool: install: /usr/bin/install -c tools/l2ping /usr/local/bin/l2ping
libtool: install: /usr/bin/install -c tools/bccmd /usr/local/bin/bccmd
libtool: install: /usr/bin/install -c tools/bluemoon /usr/local/bin/bluemoon
libtool: install: /usr/bin/install -c tools/hex2hcd /usr/local/bin/hex2hcd
libtool: install: /usr/bin/install -c tools/mpris-proxy /usr/local/bin/mpris-proxy
libtool: install: /usr/bin/install -c tools/btattach /usr/local/bin/btattach
/bin/mkdir -p '/usr/local/libexec/bluetooth'
/bin/bash ./libtool --mode=install /usr/bin/install -c src/bluetoothd obexd/src/obexd '/usr/local/libexec/bluetooth'
libtool: install: /usr/bin/install -c src/bluetoothd /usr/local/libexec/bluetooth/bluetoothd
libtool: install: /usr/bin/install -c obexd/src/obexd /usr/local/libexec/bluetooth/obexd
/bin/mkdir -p '/usr/local/lib/cups/backend'
/bin/bash ./libtool --mode=install /usr/bin/install -c profiles/cups/bluetooth '/usr/local/lib/cups/backend'
libtool: install: /usr/bin/install -c profiles/cups/bluetooth /usr/local/lib/cups/backend/bluetooth
/bin/mkdir -p '/etc/dbus-1/system.d'
/usr/bin/install -c -m 644 src/bluetooth.conf '/etc/dbus-1/system.d'
/bin/mkdir -p '/usr/share/dbus-1/services'
/usr/bin/install -c -m 644 obexd/src/org.bluez.obex.service '/usr/share/dbus-1/services'
/bin/mkdir -p '/usr/share/dbus-1/system-services'
/usr/bin/install -c -m 644 src/org.bluez.service '/usr/share/dbus-1/system-services'
/bin/mkdir -p '/usr/local/share/man/man1'
/usr/bin/install -c -m 644 tools/rctest.1 tools/l2ping.1 tools/bccmd.1 tools/btattach.1 tools/hid2hci.1 '/usr/local/share/man/man1'
/bin/mkdir -p '/usr/local/share/man/man8'
/usr/bin/install -c -m 644 src/bluetoothd.8 '/usr/local/share/man/man8'
/bin/mkdir -p '/lib/udev/rules.d'
/usr/bin/install -c -m 644 tools/97-hid2hci.rules '/lib/udev/rules.d'
/bin/mkdir -p '/lib/systemd/system'
/usr/bin/install -c -m 644 src/bluetooth.service '/lib/systemd/system'
/bin/mkdir -p '/usr/lib/systemd/user'
/usr/bin/install -c -m 644 obexd/src/obex.service '/usr/lib/systemd/user'
/bin/mkdir -p '/lib/udev'
/bin/bash ./libtool --mode=install /usr/bin/install -c tools/hid2hci '/lib/udev'
libtool: install: /usr/bin/install -c tools/hid2hci /lib/udev/hid2hci
jim@jim-desktop:/media/jim/DEV/BLUEZ/bluez-5.50$
|
|
|
|
|
As a package install it looks OK, but as it is not something I am familiar with I can't really say whether it's correct or not.
|
|
|
|
|
still no go.
Not sure where is the liker looking for the "bluetooth".
I am including edited , FOR MOST PART DELETED , linker verbose output.
Maybe the crosslinking process needs help , more options. I just do not know.
Perhaps the highlighted part could help to figure this out.
Building target: VNAR_19350
Invoking: Cross G++ Linker
arm-linux-gnueabihf-g++ -L/media/jim/DEV/BLUEZ/BlueZ-5.50 -L/usr/lib/bluetooth/bluetoothd -L/usr/lib/bluetooth -L/usr/local/libexec/bluetooth/ -v -o "VNAR_19350" ./src/MODULES/SOURCE_CODE/src/ESA_BASE_BAD.o ./src/MODULES/M_WIRE/CLASSWIRE.o ./src/MODULES/M_VNARODULE_1602/C_SPI_LCD.o ./src/MODULES/MODULE_1602/C_SSP.o ./src/MODULES/MODULE_1602/C_gpio.o ./src/VNA_1022_BASE.o -lbluetooth.a -lbluetoothd -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-cross/arm-linux-gnueabihf/5/crtend.o /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib/crtn.o
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lbluetooth.a
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lbluetoothd
collect2: error: ld returned 1 exit status
make: *** [VNAR_19350] Error 1
makefile:80: recipe for target 'VNAR_19350' failed
"make all" terminated with exit code 2. Build might be incomplete.
I did use
-L /usr/lib/x86_64-linux-gnu -l bluetooth
and got a message about "invalid" file type - it tried to link to "libbluetooth.o"
I could go back and try that again and post the output if it helps.
|
|
|
|
|
5. At this point the linker , actually cross linker , references to anything "bluetooth" such as "-lbluethooth" or "-libbluetooth" yields " not found " cross linker error.
There's the problem. On your X86_64 box, you've installed bluez-X86_64. The linker will not link an X86_64 lib into an ARM target. Your X86_64 linux distribution may provide a libbluetooth-devel-arm package that will work with the cross compiler, but I doubt that.
I've just been poking about on my rpi-2 (raspian-debian jessie), and I think the following might work for you. Note that if you're on a pi3 or using something other jessie, things will be slightly different.
on the pi:
sudo apt-get install -d libbluetooth-dev
The -d flag downloads the package and puts it in /var/cache/apt/archives/, but doesn't actually install it. I see there's a lot of files there, so it might be worth checking to see if you've already got the package there already. On my system its libbluetooth-dev_5.23-2+rpi2_armhf.deb, so I expect yours will be similar.
on the X86_64, we'll assume that you've got a $HOME/tmp that you will use for copying and you will put the package contents in $HOME/rpi. Vary as necessary in the following:
cd $HOME/tmp
scp pi@10.0.1.76:/var/cache/apt/archives/libbluetooth-dev_5.23-2+rpi2_armhf.deb
mkdir $HOME/rpi
cd $HOME/rpi
dpkg -x $HOME/tmp/libbluetooth-dev_5.23-2+rpi2_armhf.deb
This will unpack the contents of the libbluetooth-dev package in the current directory. You should now have usr/include, usr/lib and usr/share in the $HOME/rpi directory, and you can now remove $HOME/tmp/libbluetooth-dev_5.23-2+rpi2_armhf.deb file. If you check your $HOME/rpi/lib/arm-linux-gnueabihf directory, you will probably find a broken link for libbluetooth.so. If you're happy just using the static linked .a library, you can delete the broken link. If you'd like to use the shared library, then scp /usr/lib/arm-linux-gnueabihf/libbluetooth.so.3.17.1 from the pi to $HOME/pi/lib/arm-linux-gnueabeihf (once again things may be different if you're on a different OS version than me).
Now add flags for -I $HOME/rpi/usr/include and -L$HOME/rpi/usr/lib/arm-linux-gnueabihf -lbluetooth to your IDE. (check the last part of the -L path if not on jessie). This way, at least, you have the same includes and libs available to your cross compiler as you have on the pi, but you'll have to remember to update the X86_64 if you update the bluetooth package on the pi.
Now, I haven't tried this, beyond unpacking the pi package (on the pi...) so it might not work, but I think it should. If there are any dependencies that libbluetooth-dev has that are needed, you'll need to repeat this process with them, too.
If this doesn't work, you may have to use the crosscompiler to build libbluetooth (and any of its dependencies).
Update:
I have had a chance to try this out, and can confirm it should work. Not knowing where to start with libbluetooth, I wrote a short ncurses program which I was able to cross-compile using the technique above and run on my rpi. I did run into an issue where libncurses has a dependency on libtinfo, so I had to track that down and add it to my $HOME/rpi, so you may have to do the same with any dependencies libbluetooth might have.
modified 5-Mar-19 20:22pm.
|
|
|
|
|
Thanks, just to make sure I understand .
You are saying the problem is crosscompiling on X86 to ARM the resultant bluez "library", build on X86 by the process I am using , cannot be used.
Since this is my first compile for Linux I cannot comment on that.
Two things are little bothersome - why am I getting "unable to find" - should the crosscomplier post a better descriptive error?
I am under the impression that it is the purpose of crosscompliler - to manage DIFFERENT OS / hardware.
Perhaps the difference is in crosscompling C++ source on X86 ( to ARM) as oppose utilizing / linking already complied (X86 libray) on different hardware as you pointed out.
But all this is still done on X86 - only the result executable is passed to ARM.
OR is the linking done on ARM? That is confusing.
In any case I'll try your approach.
Thanks
|
|
|
|
|
Vaclav_ wrote: You are saying the problem is crosscompiling on X86 to ARM the resultant bluez "library", build on X86 by the process I am using , cannot be used.
That is correct. You do have a cross-compiler, so you could build the library using that compiler to get an ARM compatible library. In order to do that you would need to let make know to use the cross compiler. On my system that would be:
$ export CC=arm-linux-gnueabihf-gcc CXX=arm-linux-gnueabihf-g++
$ configure --prefix=/usr/local/arm ...
$ make
$ sudo make install
Most packages use a configure, make, make install routine, but some use cmake to configure make. There's usually an install doc with any source tarball that will tell you how to build the package, and what dependencies are needed.
Vaclav_ wrote: why am I getting "unable to find" - should the crosscomplier post a better descriptive error?
I'm not sure what you'd like the linker to do. When using the cross-compiler, that runs the cross-linker which looks in standard places and any provided search paths (-L flags) for the cross linker for libraries. The linker doesn't know whether -lbluetooth is a valid library name or not, just as it doesn't know if -lbleutoof is a valid library name or not.
Vaclav_ wrote: I am under the impression that it is the purpose of crosscompliler - to manage DIFFERENT OS / hardware.
And that is what it is trying to do, but it does need target specific libraries to be able to complete its work.
Lets take a few steps back. Suppose we have the following code
$ cat hello.h
#ifndef HELLO_H
#define HELLO_H
void hello(void);
#endif
$ cat hello.c
#include <stdio.h>
#include "hello.h"
void hello()
{
printf("hello wolrd\n");
}
$ cat main.c
#include "hello.h"
int main()
{
hello();
return 0;
} That's just a simple "hello world" C program broken up into 2 parts, a main.c and a hello.c with its associated hello.h
working on the X86 we can compile the pieces and then link in two steps as follows:
$ gcc -Wall -Wextra -c main.c hello.c
$ gcc main.o hello.o -o hello.x86
$ file *.o hello.x86
hello.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
hello.x86: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=016de8ea587d3a1294bc3c2221aea11cba37c97f, not stripped The -c tells gcc to compile the .c files and produce .o files, but don't link everything together. The linking we do in the second command, and all works as expected.
Now suppose we delete the main.o and try to use the cross-compiler to create a main.o and then link everything together:
$ rm main.o
$ arm-linux-gnu-gcc -Wall -Wextra -c main.c
$ file main.o hello.o
main.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped
hello.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
$ arm-linux-gnu-gcc main.o hello.o -o main.arm
/usr/bin/arm-linux-gnu-ld: i386:x86-64 architecture of input file `hello.o` is incompatible with arm output
/usr/bin/arm-linux-gnu-ld: hello.o: file class ELFCLASS64 incompatible with ELFCLASS32
/usr/bin/arm-linux-gnu-ld: final link failed: File in wrong format
collect2: error: ld returned 1 exit status
We can see that the format of the two .o files is different one is ELF-32bit for ARM and the other is ELF-64bit for X86_64. These are incompatible object formats, so we should not be surprised that they do not link together.
The difference between the simple hello.o file, above, and a library (either a .so or a .a) is that the library is, if you like, just a bundle of .o files. When linking to a library, what the linker does, in essence, is extract the object (.o) files from the library and links them into the executable (for shared libraries [.so files] its a little different, in that the linker only needs to insert into the executable the binding information for any called fuctions, but the idea is similar).
Vaclav_ wrote: But all this is still done on X86 - only the result executable is passed to ARM.
OR is the linking done on ARM? That is confusing.
All the compiling and linking is done on the X86. If you were to shutdown the pi, the compilation and linking would still proceed in exactly the same manner.
|
|
|
|
|
Thanks for update.
I had few detours but now I have the correct package installed on RPi.
Will call it quits for tonight.
Later
Late night add
Looks as libbluetooth-dev by itself is available for different architecture.
I'll check that.
It also looks as "bluez" is NOT development package.
More confusion.
New addendum
I am not sure how to continue this thread.
I really need better understanding the general relations between Linux OS and anything related to bluetooth.
From this source BlueZ » Download[^]
it looks as Linux (kernel) contains "module" to interact with bluetooth.
That "module" is based on "bluez" and they call it "stack" which I do not get. Why "stack" - isn't stack related to memory usage?
Why would one care where is the "bluez" physically?
OS should take care of that.
Now "bluez" can be installed into "user space".
And used for what ?
To develop (C++) app for Bluetooth another app - "libbluetooth-dev" - has to be installed and configured for applicable architecture.
"libblutooth-dev" is based on "bluez".
Does that makes sense?
I am going to take a look at the above link "configure" to see if it can be optioned for specific architecture.
modified 6-Mar-19 9:17am.
|
|
|
|
|
Vaclav_ wrote: it looks as Linux (kernel) contains "module" to interact with bluetooth.
Correct. The linux kernel needs to know how to communicate with a bluetooth adapter much the same as it needs to know how to communicate to a USB port or a NIC, etc. Bluetooth is quite ubiquitous these days, so the bluetooth module has been folded into the mainline kernel for quite some time.
Vaclav_ wrote: That "module" is based on "bluez" and they call it "stack" which I do not get. Why "stack" - isn't stack related to memory usage?
"Stack" in this sense is similar to what's known as a solution stack. The LAMP stack (Linux, Apache, MySQL, PHP) is an example. In this case the bluetooth hardware driver and the user tools are the bluetooth management stack.
Vaclav_ wrote: Why would one care where is the "bluez" physically?
OS should take care of that.
As long as it all works, you don't need to worry about where various bits are, the distribution installation packages manage all that for you.
Vaclav_ wrote: Now "bluez" can be installed into "user space".
And used for what ?
The kernel module only provides the hardware protocols to the linux kernel. To be able to do anything useful, you need the user-space tools such as bluetoothctl or btattch. This is no different, really, than the kernel module for your NIC which supplies the hardware protocols for network access and user space tools like ifconfig, ping and ssh which provide user level control and access to the network.
Vaclav_ wrote: To develop (C++) app for Bluetooth another app - "libbluetooth-dev" - has to be installed and configured for applicable architecture.
"libblutooth-dev" is based on "bluez".
Does that makes sense?
libbluetooth-dev is not an app, its the extra things on top of the bluez package that allow you to develop software which will communicate with or via a bluetooth controller. Suppose you have a production system that needs bluetooth - then you would only deploy the bluez package there. Typically, production systems should not contain any development tools, as you don't want random people creating software, or stealing cycles, on production systems. Your development system, on the other hand, not only needs compilers (gcc, g++, rustc, etc), but also needs include-files, debug libraries, etc so you can develop your application. Those items are generally divided out into the -dev packages, to allow for development/production separation.
|
|
|
|
|
Thanks , I thing I am making progress.
|
|
|
|
|
It looks as I have jumped the gun , again.
This bluetooth "stack" / library named "bluez" is somehow included in OS.
I can get some info about bluetooth devices using "system" calls.
That does not mean it can be used coding in C++.
I need to start from scratch and build the "bluetooth" library
or "bluetoothd".
1. download the latest "Linux stack" bluez-5.18 (?) - done
I am not sure why "they" call it "stack" , but that is not important.
2. follow "readme" and configure "it" (stack?) - partially done
3. run "make" and here I am stuck because it fails....
... tomorrow...
I probably asked this before, but .. here it goes
I have installed "bluetooth" library
apt-get install bluez libbluetooth-dev
and still getting this linker error
C_SPI_LCD.o ./src/MODULES/MODULE_1602/C_SSP.o ./src/MODULES/MODULE_1602/C_gpio.o ./src/VNA_1022_BASE.o -lgomp -lbluetooth -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-cross/arm-linux-gnueabihf/5/crtend.o /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib/crtn.o
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lbluetooth
makefile:80: recipe for target 'VNAR_19321' failed
collect2: error: ld returned 1 exit status
make: *** [VNAR_19321] Error 1
"make all" terminated with exit code 2. Build might be incomplete.
The Cross G++ Linker has an option "-lbluetooth" but I only specify "bluetooth" , without the "-l"
I did try to locate bluetooth
jim@jim-desktop:~$ find -name "bluetooth"
find: ‘./.cache/dconf’: Permission denied
find: ‘./.dbus’: Permission denied
find: ‘./.config/configstore’: Permission denied
jim@jim-desktop:~$ sudo find -name "bluetooth"
[sudo] password for jim:
jim@jim-desktop:~$ sudo find -name "*bluetooth"
jim@jim-desktop:~$ sudo find -name "*bluetooth*"
./.local/share/icons/bluetooth-wizard.png
./.local/share/applications/bluetooth-wizard.desktop
./.cache/upstart/indicator-bluetooth.log.5.gz
./.cache/upstart/indicator-bluetooth.log.4.gz
./.cache/upstart/indicator-bluetooth.log.2.gz
./.cache/upstart/indicator-bluetooth.log.3.gz
./.cache/upstart/indicator-bluetooth.log.1.gz
./.cache/upstart/indicator-bluetooth.log.6.gz
./.cache/upstart/indicator-bluetooth.log.7.gz
jim@jim-desktop:~$
Here are my questions / comments :
1. apparently the IDE adds the
"-l" to link to library - find with me.
2. Do I have to specify directory using "-L" and how do I find it using Linux?
3. It looks as there are no conventions as far as naming the library - some sources quote "libbluetooth"
Thanks
modified 4-Mar-19 0:53am.
|
|
|
|
|
You do not appear to have a bluetooth library installed. It should have the name libbluetooth.so or libbluetooth.a. Check the log from your installation process to see where it is supposed to be installed.
|
|
|
|
|
Thanks
I'll take a look at the log.
I a hAve never done that so it will take a while.
|
|
|
|
|
Since you're cross compiling for arm, you'll need to install libbluetooth for arm - if your distribution provides that - otherwise you'll either have to compile libbluetooth for arm (which may include compiling supporting libraries, too), or do your builds on your arm device.
You may be able to copy the bluetooth libs from your arm device. They should be at /usr/lib/libbluetooth.so* or /usr/lib64/libbluetooth.so*, but I don't know where they would copy to on your compilation system - probably somewhere under usr/lib/gcc-cross/arm-linux-gnueabihf/ - there's probably a lib or lib64 directory under there containing .so and/or .a files.
|
|
|
|
|
|
Also a note about find: find -name "bluetooth" only searches the current directory for a file or directory that matches the name "bluetooth" excactly. Similarly, using -name "bluetooth*" finds files and directories that start with "bluetooth". What you want to do is probably find / -type f -name "bluetooth" That will search the entire filesystem for files that contain the string "bluetooth". Of course, this also searches /proc, /sys /dev, etc that probably aren't of interest, so perhaps adding the flag -xdev, which keeps find to the current filesystem might be in order, too.
|
|
|
|
|
Thanks.
I was aware that I was getting only current directory finds.
I did modify the CL , but now I am getting only directories.
jim@jim-desktop:~$ sudo find / -type f -name "bluetooth" -xdev
[sudo] password for jim:
find: warning: you have specified the -xdev option after a non-option argument -type, but options are not positional (-xdev affects tests specified before it as well as those specified after it). Please specify options before other arguments.
/etc/init.d/bluetooth
/usr/local/lib/cups/backend/bluetooth
/usr/bin/bluetooth
/usr/lib/cups/backend/bluetooth
jim@jim-desktop:~$ sudo find / -type f -name -xdev "bluetooth"
find: paths must precede expression: bluetooth
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec|time] [path...] [expression]
jim@jim-desktop:~$ sudo find / -xdev -type f -name "bluetooth"
/etc/init.d/bluetooth
/usr/local/lib/cups/backend/bluetooth
/usr/bin/bluetooth
/usr/lib/cups/backend/bluetooth
jim@jim-desktop:~$
|
|
|
|
|
I think I need to link , using "_L" option to highlighted file and its directory.
jim@jim-desktop:~$ sudo find / -xdev -type f -name "libbluetooth*"
/var/lib/dpkg/info/libbluetooth3:amd64.md5sums
/var/lib/dpkg/info/libbluetooth3-dbg.list
/var/lib/dpkg/info/libbluetooth-dev.md5sums
/var/lib/dpkg/info/libbluetooth3:i386.shlibs
/var/lib/dpkg/info/libbluetooth3:amd64.list
/var/lib/dpkg/info/libbluetooth3:i386.symbols
/var/lib/dpkg/info/libbluetooth3-dbg.md5sums
/var/lib/dpkg/info/libbluetooth3:i386.md5sums
/var/lib/dpkg/info/libbluetooth3:amd64.triggers
/var/lib/dpkg/info/libbluetooth-dev.list
/var/lib/dpkg/info/libbluetooth3:amd64.symbols
/var/lib/dpkg/info/libbluetooth3:i386.triggers
/var/lib/dpkg/info/libbluetooth3:i386.list
/var/lib/dpkg/info/libbluetooth3:amd64.shlibs
/usr/lib/i386-linux-gnu/libbluetooth.so.3.18.10
/usr/lib/x86_64-linux-gnu/libbluetooth.a
/usr/lib/x86_64-linux-gnu/unity-control-center-1/panels/libbluetooth.so
/usr/lib/x86_64-linux-gnu/libbluetooth.so.3.18.10
jim@jim-desktop:~$
Addendum
Looks better , but now cannot link to "gomp" - lining to wrong "_L" ??
MODULES/MODULE_1602/C_1602.o ./src/MODULES/MODULE_1602/C_LCD2_CPP.o ./src/MODULES/MODULE_1602/C_SPI.o ./src/MODULES/MODULE_1602/C_SPI_LCD.o ./src/MODULES/MODULE_1602/C_SSP.o ./src/MODULES/MODULE_1602/C_gpio.o ./src/VNA_1022_BASE.o -lgomp -llibbluetooth -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-cross/arm-linux-gnueabihf/5/crtend.o /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib/crtn.o
/usr/lib/x86_64-linux-gnu/libgomp.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
make: *** [VNAR_19321] Error 1
makefile:80: recipe for target 'VNAR_19321' failed
"make all" terminated with exit code 2. Build might be incomplete.
modified 3-Mar-19 13:34pm.
|
|
|
|
|
Nope.
That's an X86_64 binary, so it won't link with the ARM binary.
Additionally, if you'd bothered to even look at an OpenMP tutorial, as I suggested elsewhere, you would have realized that my suggestion to use -lgomp when compiling OpenMP source was wrong. The correct thing to do is to use -fopenmp, which enables #pragma omp ... processing. Whether cross compilation permits OpenMP or not, is unknown to me. If not, you're going to have to find another way to approach this.
|
|
|
|
|
Getting of the subject with sarcasm (... if you'd bothered to even look...)is not the way I am used to communicate here.
I really do not care about OpenMP (for now) , but as you can see fopenmp is also missing the "-L" .
Looks as the crosscompiler is smarter then expected and "skips" the wrong library anyway.
gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib/crtn.o
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lfopenmp
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -llibbluetooth
makefile:80: recipe for target 'VNAR_19321' failed
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.so when searching for -lm
collect2: error: ld returned 1 exit status
make: *** [VNAR_19321] Error 1
"make all" terminated with exit code 2. Build might be incomplete.
What is bothersome - the crosssompilier "runs" on "86" but the app will run on arm.
But I'll try to get bluez library for arm next.
|
|
|
|
|
No. Its not -lfopenmp, it is -fopenmp.
Given this hello.cpp:
#include <iostream>
int main()
{
std::cout << "hello world\n";
return 0;
}
then g++ -fopenmp hello.cpp -o hello produces an executable. We can use ldd to check the libraries linked in and we can see:
ldd hello
linux-vdso.so.1 (0x00007ffed35fb000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc385128000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc384fa0000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x00007fc384f68000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc384f48000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc384f20000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc384d58000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc3852e8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc384d50000)
So using -fopenmp adds in libgomp (and turns on other OpenMP processing for you, too).
I'm wondering if you've produced any cross-compiled executables, yet. I'm using Fedora29, which doesn't seem to provide libstdc++ or any of the c++ include files for cross compiling arm. You're apparently using a non red-hat derived system, so your mileage will definitely vary, or you may already have resolved the cross-compilation issues, in which case, kudos!
|
|
|
|
|
Vaclav_ wrote: /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -llibbluetooth
Because the option should be -lbluetooth the lib prefix is always assumed by the linker.
|
|
|
|
|
I am using Eclipse IDE and learned long time ago to "add" just name ( bluetooth) in "-l" option.
Eclipse is crazy - the file name is actually bluetooth.a , but the linker is optioned as "-lbluetooth". I could post the linker verbose output , but it is little too long.
My present problem is locating the "library" directory.
I did not install it properly and I am basically starting over.
|
|
|
|
|
Looking at the ld man page, I think you need a different form of the -l option. Try -l:bluetooth.a - note the colon and the .a suffix. When you just use -lbluetooth then the linker will search for a file called libbluetooth.a. I am not sure how you set these options in eclipse (a long time since I used it) but there is probably somewhere in the project settings.
As to the library directory, it should not be too difficult with a find command.
|
|
|
|
|
Looks like you learn something new every day (unless you're careful  ). I did not know about the -l:<filename> option for ld. In the past, when I needed to link to static (.a) libs I'd use gcc flags -Wl,-Bstatic -l<lib> -l<lib> ... -Wl,-Bdynamic. The -l:<lib> is nicer, I think. Note that if you omit the trailing -Wl,-Bdyanmic in my solution, then any static system libs (e.g. libc, libstdc++, etc) get linked statically, too, which may not be what you want.
I just tried this and can confirm it works, but you need to use the full filename i.e. -l:libxxxx.a e.g.
$ ls /usr/lib64/lib*.a
/usr/lib64/libc_nonshared.a /usr/lib64/libldc-jit-rt.a /usr/lib64/libmvec_nonshared.a
/usr/lib64/libg.a /usr/lib64/libmcheck.a /usr/lib64/libpthread_nonshared.a
$ g++ hello.cpp -l:mcheck.a -o hello
/usr/bin/ld: cannot find -l:mcheck.a
collect2: error: ld returned 1 exit status
$ g++ hello.cpp -l:libmcheck.a -o hello
$ . That means if your lib actually is $PATH_TO_LIBS/bluetooth.a then -l:bluetooth.a is correct.
|
|
|
|
|
$ g++ hello.cpp -l:mcheck.a -o hello
/usr/bin/ld: cannot find -l:mcheck.a
collect2: error: ld returned 1 exit status
$ g++ hello.cpp -l:libmcheck.a -o hello
Now why are you using the -l: version for a normally named library? For files named libxxx.a all you need is -lxxx, as I explained in my previous post (and in the man page). The only time you need the colon version is if the name does not begin with the lib prefix.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
