|
The Architecture type x86_64 tells you the hardware is 64 bit Intel architecture. The operating modes tell you it can run 32-bit or 64-bit applications.
|
|
|
|
|
|
I have given up on building bluez library from source.
Now my question is
how to option / instruct (gcc) compiler / linker to use libbluetooth-dev on native OS?
I have downloaded correct version but have no clue how to or where to option the compiler / linker.
I also like to use correct terminology for the "libbluetoooth-dev" .
Is is a libray or package or what ?
When get the above answered I should be able to apply it to different architecture.
I have also run into some kind of "foregin package " options, but not sure I need it. Maybe later.
Help is much appreciated.
Cheers
|
|
|
|
|
What is "libbluetoooth-dev"? Unix/Linux libraries should have a .a (archive) or .so (shared object) extension to identify the type of library. I have explained a number of times that to include a library named libxxx.a or libxxx.so, you should add an option of the form -lxxx to your build (either gcc or ld). If the name of the library does not follow the standard conventions, then use -l:filename.
For all ld opions see ld(1): GNU linker - Linux man page[^].
|
|
|
|
|
Partially answered my own question - libbluetooth-dev is a "package".
Using it / linking to it is non issue.
|
|
|
|
|
I have made some progress in tracing the "configure" script, all the way to
****
@ line 6764 debug START converting (?)
@ line 6765 --build = x86_64-pc-linux-gnu (?)
@ line 6766 --host = armv7l-unknown-linux-gnueabihf (?)
****
checking how to convert x86_64-pc-linux-gnu file names to armv7l-unknown-linux-gnueabihf format... ****
@ line 6831 unhandled host =armv7l-unknown-linux-gnueabihf (and normal native builds) (?)
****
****
@ line 6853 (?)
****
func_convert_file_noop
Now I do not get why "they" are converting build NAME to host FORMAT, but since the triplet "case " switch does not check for anything near "linux" and falls thru to "unhandled " I am beginning to wonder it the source I got from www.bluez.org is for Windowze only.
Is there a away to very that?
I am also stuck as far as what does "func_convert_file_noop" do.
Addendum
Here is a part of "configure" script I believe is responsible in instructing the compiler to build a libray of --host architecture.
As far as I can tell it does not evaluate for "Linux" as OS in optioned triplet , but falls thru to "unhandled" and then the conpiler buidls "native " AKA --build architecture libraries.
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking how to convert $build file names to $host format" >&5
$as_echo_n "checking how to convert $build file names to $host format... " >&6; }
if ${lt_cv_to_host_file_cmd+:} false; then :
$as_echo_n "(cached) " >&6
else
case $host in
*-*-mingw* )
case $build in
*-*-mingw* ) # actually msys
lt_cv_to_host_file_cmd=func_convert_file_msys_to_w32
;;
*-*-cygwin* )
lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32
;;
* ) # otherwise, assume *nix
lt_cv_to_host_file_cmd=func_convert_file_nix_to_w32
;;
esac
;;
*-*-cygwin* )
case $build in
*-*-mingw* ) # actually msys
lt_cv_to_host_file_cmd=func_convert_file_msys_to_cygwin
;;
*-*-cygwin* )
lt_cv_to_host_file_cmd=func_convert_file_noop
;;
* ) # otherwise, assume *nix
lt_cv_to_host_file_cmd=func_convert_file_nix_to_cygwin
;;
esac
;;
* ) # unhandled hosts (and "normal" native builds)
lt_cv_to_host_file_cmd=func_convert_file_noop
;;
esac
fi
to_host_file_cmd=$lt_cv_to_host_file_cmd
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_to_host_file_cmd" >&5
$as_echo "$lt_cv_to_host_file_cmd" >&6; }
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking how to convert $build file names to toolchain format" >&5
$as_echo_n "checking how to convert $build file names to toolchain format... " >&6; }
if ${lt_cv_to_tool_file_cmd+:} false; then :
$as_echo_n "(cached) " >&6
else
#assume ordinary cross tools, or native build.
lt_cv_to_tool_file_cmd=func_convert_file_noop
case $host in
*-*-mingw* )
case $build in
*-*-mingw* ) # actually msys
lt_cv_to_tool_file_cmd=func_convert_file_msys_to_w32
;;
esac
;;
esac
fi
to_tool_file_cmd=$lt_cv_to_tool_file_cmd
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_to_tool_file_cmd" >&5
$as_echo "$lt_cv_to_tool_file_cmd" >&6; }
modified 28-Mar-19 16:24pm.
|
|
|
|
|
1) the configure script is AUTOGENTERATED by the autoconf tool set. There's generally no good that can come from messing about in it.
2) I have told you several times use --host=arm-linux-gnueabihf.
From your post 3 days ago:
Quote: sudo ./configure --prefix=/usr/local/BLUEZ/bluez-5.50 --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var --enable-library --disable-systemd --host=armv7l-unknown-linux-gnueabihf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for armv7l-unknown-linux-gnueabihf-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking how to create a pax tar archive... gnutar
checking for style of include used by make... GNU
checking for armv7l-unknown-linux-gnueabihf-gcc... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
Now, I would expect anyone paying any attention (and surely anyone who's as nit-picky as you seem to be) to think to themselves:
Hmm ... looks like the configure script is trying to use armv7l-unknown-linux-gnueabihf-gcc. That prefix is what I supplied as the value of the --host argument. I don't have arm7l-unkown-linux-gneabihf-gcc on my system. I do have, however arm-linux-gnueabihf-gcc - maybe I'll try --host=arm-linux-gneuabihf and see if that works.
And lo-and-behold configure completes, and you can start make. and wonder of wonders it uses arm-linux-gnueabihf-gcc, just like we want it too. Result!
BUT,BUT, and again BUT: until you've got the prerequisites (GLib, D-Bus) built for armhf make will fail anyway!
3) if you do some googling around for autoconf --target you should find information about the so called candian cross Cross-Compilation (automake). Take the time to read down to the bottom of the page. There it tells you that --target is used when compiling compiler tools i.e. ld, ar, as, etc (binutils) in a three-way cross-compilation. For example, when you are compiling binutils on an X86 to run on an armhf but will produce code for PowerPC. --target has NOTHING to do with cross compiling in the normal way. I have not tried it by suspect that since configure is AUTOGENERATED that the --target option always shows up in the script, whether its required or not.
Now, stop elephanting around.
|
|
|
|
|
pi@pi $ sudo bash config.guess
armv7l-unknown-linux-gnueabihf
|
|
|
|
|
Stop using sudo for everything. That's like using Run as Administrator all the time.
As it happens, I do know what I'm talking about. As an example I'll cross compile grep for you. grep does have an optional dependency on libpcre - perl regular expressions, which I won't complicate this by also compiling. Fortunately we can disable that by using --disable-perl-regex
$ ls
grep-3.0 grep-3.0.tar.xz
configure can build in a directory other than the source directory, so lets do that. We'll use --prefx=$HOME/apt so we don't need to use sudo to install.
$ mkdir build
$ cd build
$ ../grep-3.0/configure --host=arm-linux-gnueabihf --prefix=$HOME/arm --disable-perl-regexp > configure.out 2>&1 && echo Success || echo Failed
Success
did we configure for cross compile?
$ grep cross configure.out
checking whether we are cross compiling... yes
checking for working fcntl.h... cross-compiling
lets make and install ...
$ make > make.out 2>&1 && echo Success || echo Failure
Success
$ ls $HOME/arm
ls: cannot access '/home/k5054/arm': No such file or directory
$ make install > make_install.out 2>&1 && echo Success || echo Failure
Success
so far so good ... lets see what I have in $HOME/arm
$ cd $HOME/arm
$ ls
bin share
$ cd bin
$ ls
egrep fgrep grep
$ file *
egrep: POSIX shell script, ASCII text executable
fgrep: POSIX shell script, ASCII text executable
grep: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-, for GNU/Linux 3.2.0, BuildID[sha1]=b44e80774f0b6413d50f10c1bd7f57d10e88a6af, with debug_info, not stripped
so we've got an ARM EABI5 executable for $HOME/arm/bin/grep. how does that compare to /bin/grep?
$ file /bin/grep
/bin/grep: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=0b72a4b88afe6711c7154541e1f002331041c71f, stripped
so that's an X86_64 executable ... things are looking good, lets copy that over to the pi and see if it will work
$ scp -r -q arm pi3:
$ ssh pi3
Linux pi3 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l
Last login: Thu Mar 28 00:33:06 2019 from 192.168.235.202
lets test arm/bin/grep
k5054@pi3:~ $ ./arm/bin/grep --version
grep (GNU grep) 3.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Mike Haertel and others, see <http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.
that worked! how does that compare to /bin/grep?
k5054@pi3:~ $ /bin/grep --version
grep (GNU grep) 2.27
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Mike Haertel and others, see <http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.
it's a different version, very good! - now lets try a grep pattern, and count the number of times the word "is" appears in the version text of /bin/grep
k5054@pi3:~ $ /bin/grep --version | arm/bin/grep -c '\<is\>'
2
looks like my cross-compiled grep is working fine
k5054@pi3:~ $ logout
well, looks like that all worked -- seems --host=arm-linux-gnueabihf is the right thing after all
|
|
|
|
|
I hope this is my last post on bluez package.
I made wrong choice.
END OF STORY
FYI update
guess what I DID NOT find in "configure"?
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
#CCC ADD
# looks as there is no NEED for target
_ACEOF
Will update - pending actual test of the bluez build and C++ link.
This is a SPECIFIC follow-up on the original post.
If you have an issue with this - please ignore me.
I have managed to recompile Linux "stack " - bluez for armhf
sudo dpkg -l "bluez"
[sudo] password for jim:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii bluez:armhf 5.50-1 armhf bluez-5.50
I have verified that I do have "libbluetooth.so" file linked via -L option and linker did same.
I am still getting this error telling me the file format is wrong.
Is it possible that gcc crosscompile prefix arm-linux-gnueabihf and "bluez" package architecture armhf is causing this?
I did try to checkinstall for arm-linux-gnueabihf architecture but it did not go.
I also build same package for armv7l architecture with same results.
-L/usr/local/BLUEZ/bluez-5.50/lib -L/usr/lib/gcc-cross/arm-linux-gnueabihf/5 -L/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib ./src/BLUE_CROSS.o -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/local/BLUEZ/bluez-5.50/lib/libbluetooth.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
makefile:45: recipe for target 'BLUE_CROSS_193210' failed
modified 1-Apr-19 11:52am.
|
|
|
|
|
what does file /usr/local/BLUEZ/bluez-5.50/lib/libbluetooth.so return? If it is not ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), then you need to review your installation of the bluez library for armhf.
|
|
|
|
|
"return"?
Forgive me my ignorance , but how do I do that?
jim@jim-desktop:/usr/local/BLUEZ/bluez-5.50/lib$ ls
a2mp.h cmtp.h libbluetooth.la sdp.h
amp.h cups libbluetooth.so sdp_lib.h
bluetooth hci.c libbluetooth.so.3 sdp.lo
bluetooth.c hci.h libbluetooth.so.3.18.16 uuid.c
bluetooth.h hci_lib.h mgmt.h uuid.h
bluetooth.lo hci.lo pkgconfig uuid.lo
bluez.pc hidp.h rfcomm.h
bluez.pc.in l2cap.h sco.h
bnep.h libbluetooth-internal.la sdp.c
jim@jim-desktop:/usr/local/BLUEZ/bluez-5.50/lib$ file libbluetooth.so
libbluetooth.so: symbolic link to libbluetooth.so.3.18.16
<pre lang="text">
jim@jim-desktop:/usr/local/BLUEZ/bluez-5.50/lib$ stat libbluetooth.so
File: 'libbluetooth.so' -> 'libbluetooth.so.3.18.16'
Size: 23 Blocks: 0 IO Block: 4096 symbolic link
Device: 812h/2066d Inode: 919828 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2019-03-22 11:41:14.976991502 -0500
Modify: 2019-03-22 11:09:42.000000000 -0500
Change: 2019-03-22 11:29:48.319241561 -0500
Birth: -
modified 22-Mar-19 19:37pm.
|
|
|
|
|
|
OK, I missed the "symbolic link".
Now I need to go back to "configure" to find out why the library is build for host and
not the target.
Thanks very much for your help, appreciate it,
PS
It would have been helpful if the linker told me this.
Maybe there is an option somewhere to do that.
jim@jim-desktop:/usr/local/BLUEZ/bluez-5.50/lib$ ls
cups libbluetooth.la libbluetooth.so libbluetooth.so.3 libbluetooth.so.3.18.16 pkgconfig
jim@jim-desktop:/usr/local/BLUEZ/bluez-5.50/lib$ file libbluetooth.so.3.18.16
libbluetooth.so.3.18.16: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=55d60353934d3672e2c88fbc64ceaba37c4d0442, not stripped
jim@jim-desktop:/usr/local/BLUEZ/bluez-5.50/lib$ file libbluetooth.so
libbluetooth.so: symbolic link to libbluetooth.so.3.18.16
jim@jim-desktop:/usr/local/BLUEZ/bluez-5.50/lib$ file libbluetooth.so.3
|
|
|
|
|
Vaclav_ wrote: It would have been helpful if the linker told me this.
The linker's role is to combine different object code files into an executable. It expects all objects to be in the correct format, so if they are not then it can only reject them. It cannot be expected to analyse the content of every 'foreign' object to tell the user what it is.
|
|
|
|
|
You can check where your apt installed your package using
$ dpkg -L bluez
/.
/bin
/bin/hciconfig
/etc
/etc/bluetooth
/etc/bluetooth/input.conf
/etc/bluetooth/main.conf
...
/usr/share/man/man1/rctest.1.gz
/usr/share/man/man1/rfcomm.1.gz
/usr/share/man/man1/sdptool.1.gz
/usr/share/man/man8
/usr/share/man/man8/bluetoothd.8.gz
/usr/sbin/bluetoothd
$
Note that if you're querying packages, you don't need to sudo to execute dpkg. Also note that the normal package for bluez does not include libbluetooth. For that you need packages libbluetooth3 and libbluetooth-dev (for headers, etc).
$ dpkg -L bluez | grep libbluetooth.so
$ dpkg -L libbluetooth3 | grep libbluetooth.so
/usr/lib/arm-linux-gnueabihf/libbluetooth.so.3.18.14
/usr/lib/arm-linux-gnueabihf/libbluetooth.so.3
$ dpkg -L libbluetooth-dev | grep libbluetooth.so
/usr/lib/arm-linux-gnueabihf/libbluetooth.so
$
I expect if you've built these packages for armhf and installed them on your X86 sytem, then they may not be in the locations listed here.
|
|
|
|
|
Thanks for reply.
After Richard's post I can correctly identify the file wrong architecture - as already suspected and reported by the linker.
Upon preliminary investigation it looks as "bluez" package "configure" is flaky.
It's sketchy documentation clearly states that it is smart enough to sort-of self option itself.
I can prove otherwise as far as --build, --host and --target options go.
I really do not care how it "automatically " determines them, but it totally ignores --target when given as an option!
Not only that - it also selectively ignores other architecture options.
I can provide "configure" file outputs if anybody cares.
Here is a snippet
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
Yes, I did search for "target" - nothing , nada
The real question is - how to resolve this?
www.bluez.org is useless
Ubuntu forum probably does not care
other forums are off limits and I really do not want to be just statistic anyway
If it is bug - where do I go next?
I guess learn how to edit "configure " is my real option.
But I need to verify if the target architecture I am using is valid , since I cannot rely on "configure" to tell me !
For example - this passed --target=armv7l, but was ignored.
I am open to suggestions,
|
|
|
|
|
Try opening the configure script with your favourite editor and do a search for the keywords mentioned above. You should then be able to see what options it is able to handle.
|
|
|
|
|
Did that already.
There is no "checking ..target..." similar to "host" and "build".
|
|
|
|
|
where did this come from? Your X86 or your PI?
sudo dpkg -l "bluez"
[sudo] password for jim:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii bluez:armhf 5.50-1 armhf bluez-5.50
Are you building a .deb package on the X86 and installing it there? If so then presumably you might also have libbluetooth and libbluetooth-dev packages that you could install also which reduce the pain you're going through.
Vaclav_ wrote: checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
From configure --help
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
If you don't specify --host, the default is the same as for --build (which configure will guess at using config.guess. For a PI, the host should be
arm-linux-gnueabihf I think I figured that out because I tried something like host=arm7 and you get a configure error saying something like arm7-gcc not found.
You do realize that you're going down a rabbit hole, trying to do this via cross-compilation. In order to build bluez, you'll need to have all the prerequisites:
In order to compile Bluetooth utilities you need following software packages:
- GCC compiler
- GLib library
- D-Bus library
- udev library (optional)
- readline (command line clients)
So you'll need to build all those for arm before you can build bluez --- and those probably have dependencies, etc, etc, etc. After each package is build and installed you'll need to figure out how to tell successive packages where to find their dependencies. That might be as simple as something like adding --with-glib=<path-to-armhf-glib> to the configure command line, or you may have to use make's CFLAGS (C compiler flags), CPPFLAGS (c-pre-prossor flags e.g -I<path>), CXXFLAGS (C++ flags), LDFLAGS (linker flags e.g -L<path>), LDLIBS (linker libraries e.g -l<lib>) environment varialbes. Also see configure --help. At the end there's a long list of environment variables you can set to tell configure where to find things. To set those you can either
$ export CPPFLAGS=-I/usr/local/arm/inlcude
$ export LDFLAGS=-L/usr/local/arm/lib
$ export LDLIBS=-lglib -ldbus -ludev
$ ./configure <args> or
$ CPPFLAGS=-I/usr/local/arm \
LDFLAGS=-L/usr/local/arm/lib \
LDLIBS="-lglib -ldbus -ludev" \
./configure <args>
Vaclav_ wrote: I guess learn how to edit "configure " is my real option.
Almost nobody ever edits configure files. They are generated by the autom4te, autoconf, and automake tools. I've not used them myself, so I can't tell you much about how they work. But there's plenty of reading if you google for it.
|
|
|
|
|
1. Yes, I am building on X86 , but with --target=arhnmf
2. "configure" has an option --enable-library which builds the library , but for X86.
And that is the problem.
I did look at "configure" again and see no code to implement --target.
I believe that is the main issue I need to solve before anything else.
I am also finding that I better reboot and remove the .../lib in its entirety before making another run at "configure".
Last time it deleted the .../lib and never rebuild it.
I am still looking for another full / zipped source of "bluez" to compile from , this one from www.bluez.org is unreliable.
|
|
|
|
|
|
Sorry, done that too.
It is getting harder to keep up the discussion and troubleshooting same time.
I am still trying to find where / how I can modify "configure" to add some feedback on "target" processing.
"configure" is not tracking target code at all, but it is there and I cannot find how it is getting the host / build as incorrect default.
I'll try to keep you posted so you do not have to duplicate what I have already done.
|
|
|
|
|
I am getting frustrated as far as where to post - so here it is
Progress report
I managed to convince "configure" that "host" is
pi@pi:~ $ sudo bash ./config.guess
armv7l-unknown-linux-gnueabihf
as reported by "config.guess" running on RPi. No errors.
However,
"checkinstall" now complains when I try to change the architecture to -A armv7l-unknown-linux-gnueabihf - which is whole point of this exercise!
dpkg: error processing archive /media/jim/DEV/BLUEZ/bluez-5.50/bluez_5.50-1_armv7l-unknown-linux-gnueabihf.deb (--install):
package architecture (armv7l-unknown-linux-gnueabihf) does not match system (amd64)
Errors were encountered while processing:
/media/jim/DEV/BLUEZ/bluez-5.50/bluez_5.50-1_armv7l-unknown-linux-gnueabihf.deb
Of course the library file format is still wrong - as expected - nothing changed it
jim@jim-desktop:/usr/local/BLUEZ/bluez-5.50/lib$ file libbluetooth.so.3.18.16
libbluetooth.so.3.18.16: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=55d60353934d3672e2c88fbc64ceaba37c4d0442, not stripped
At this stage I have to ask -
assuming the documentation of "configure" IS CORRECT (?) - I should be able to change the "host" architecture BUT
how . where , by whom it is actually changed / processed ?
It sure looks as it is NOT being changed.
As soon as I resolve this , I can tackle the "checkinstall" complaint.
Addendum
there is something strange in "configure" output
sudo ./configure --prefix=/usr/local/BLUEZ/bluez-5.50 --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var --enable-library --disable-systemd --host=armv7l-unknown-linux-gnueabihf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for armv7l-unknown-linux-gnueabihf-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking how to create a pax tar archive... gnutar
checking for style of include used by make... GNU
checking for armv7l-unknown-linux-gnueabihf-gcc... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
The other note specifically said "use host to crosscomplie..."
modified 24-Mar-19 12:13pm.
|
|
|
|
|
I specifically told you:k5054 wrote: From configure --help
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
If you don't specify --host, the default is the same as for --build (which configure will guess at using config.guess. For a PI, the host should be
arm-linux-gnueabihf I think I figured that out because I tried something like host=arm7 and you get a configure error saying something like arm7-gcc not found.
Try again.
Better yet, just build your PI part on the PI. If eclipse is too slow on the pi, then maybe learn vi, emacs or gedit and how to build a Makefile. I think if you had gone that route, you would have made significant progress on your project. OTOH, maybe the point of all this pain you're going through is to learn how to cross-compile. Hows that going for you?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
