|
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.
|
|
|
|
|
Richard MacCutchan wrote: The only time you need the colon version is if the name does not begin with the lib prefix.
Or if you want to link to the static version of a library, but not use -static for the whole executable.
It was not clear to me from your post that -l:xxxx.a was looking for a file $SOMEPATH/xxxx.a, since normally a library shared or otherwise would be libxxxx.a. I'm reasonably sure the bluetooth lib the OP is looking for would be libbluetooth.a, since it is part of the bluez package.
|
|
|
|
|
k5054 wrote: It was not clear to me from your post
Which is why I specifically mentioned the ld man page, where it is explained.
k5054 wrote: I'm reasonably sure the bluetooth lib the OP is looking for would be libbluetooth.a, since it is part of the bluez package.
According to Re: Linking to library - Linux Programming Discussion Boards[^] OP specifies the file does not have the lib prefix.
|
|
|
|
|
OK, I am doing something stupid trying to get # of CPU's in Raspberry Pi.
This returns "syntax error : end of file unexpected " and # of CPU's 512
#include <omp.h>
int iCPU = system ("omp_get_num_procs()");
cout << "# of CPU's " << dec << +iCPU << endl;
exit(1);
Any second opinions ( leading to solution ) are welcome and appreciated.
Cheers
Vaclav
SOLVED
Was missing link to gomp library
modified 8-Feb-19 15:54pm.
|
|
|
|
|
See the man page for system() - its essentially a wrapper around execl() and vfork(). Unless you can execute "omp_get_num_procs()" from the command line, what you have won't work.
Why would you think you need a call to system() in this case?
|
|
|
|
|
This is response from CL on my PC
jim@jim-desktop $ omp_get_num_procs()
>
and this is coming from RPi
pi@pi $ jim@jim-desktop $ omp_get_num_procs()
-bash: syntax error near unexpected token `('
pi@pi $ >
-bash: syntax error near unexpected token `newline'
pi@pi $ sudo omp_get_num_procs()
The purpose / reason was posted in OP.
-bash: syntax error near unexpected token `('
pi@pi $ sudo omp_get_num_procs
sudo: omp_get_num_procs: command not found
pi@pi $
I'll check the man.
|
|
|
|
|
Let me try this another way.
In your last question to this discussion board (from "ls" to C++ buffer?) you asked about capturing the output from system() into your C++ program. I take it from that, that you know what the system() call does - i.e. calls a system command like ls, or ps or grep, etc. So now you seem to be wanting to call a function provided in the omp.h header via the system() call. That makes no sense to me. The only reason I could think you might want to do that was if you were trying to execute the function as a different user - in which case that is not the way to go about that. So my question stands - why are you trying to wrap what appears to be a normal, ordinary C function call inside a call to system()?
|
|
|
|
|
You do not need parentheses on command/program calls in the system. Change your code to:
int iCPU = system ("omp_get_num_procs");
Although I do not expect that a call to system will return the output from the command. Also I suspect you also need to wrap that code in a int main(){} block in order to compile it correctly.
|
|
|
|
|
int main() {
#ifdef STEP
cout << "Project VNAR-19270 VNA-1023 (6 base) Vector network analyzer" << endl;
cout << "DEBUG ****RUNNING WORKING COPY of VNA_2 " << endl;
#endif
int iCPU = 0;
iCPU = system ("omp_get_num_procs");
cout << "# of CPU's " << dec << +iCPU << endl;
exit(1);
Now returns omp_get_num_procs not found.
I think the problem is also in crosscompiler settings.
Also the "remote AKA RPi" OS has no OpenMP installed.
I need to check that.
I was just looking for an advise if my syntax is OK.
|
|
|
|
|
The syntax looks OK now. The error message implies the the omp_get_num_procs program cannot be found in any of the standard locations, so you may need to provide the full path. As I said before, you will not get the correct answer from the call to system; see the man page for details. In order to get the correct number you need to connect the external command's stdout stream to your application, which you can then read and process as required.
[edit]
You need to re-read k5054's message above.
[/edit]
modified 8-Feb-19 11:54am.
|
|
|
|
|
Richard MacCutchan wrote: The error message implies the the omp_get_num_procs program cannot be found in any of the standard locations
That's not surprising omp_get_num_procs() is a function call in the OpenMP library. I'm not sure why the OP thinks that it needs to be wrapped in a call to system(). If they could answer that question, maybe we can tell him why he's mistaken, and how to fix his mistake.
|
|
|
|
|
Thanks, I see from your previous message that you have explained that.
|
|
|
|
|
int iCPU = 0;
iCPU = omp_get_num_procs();
cout << "# of CPU's " << dec << +iCPU << endl;
exit(1);
Using system( ) because without it I get
./src/VNA_1022_BASE.o: In function `main':
/media/jim/DEV/Eclipse_2019_03_M1/workspace/eclipse-workspace/VNAR_19280/Debug/../src/VNA_1022_BASE.cpp:253: undefined reference to `omp_get_num_procs'
makefile:80: recipe for target 'VNAR_19280' failed
collect2: error: ld returned 1 exit status
make: *** [VNAR_19280] Error 1
"make all" terminated with exit code 2. Build might be incomplete.
I believe it is NOT only syntax issue, but something is missing in setting OpenMP.
I'll take a look at the verbose output of both complier and linker to see anything obvious.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
