Check in your sysroot folder under usr/lib/arm-linux-gnueabihf.
Jon
On Tue, Oct 27, 2020 at 6:16 PM 'Jeremias Ramirez' via BeagleBoard <
beagleboard@googlegroups.com> wrote:
>
> Hi again, sorry for the delay.
>
> Well, i finally can build Qt with OpenGL. :D
> A few hours later, the -make process
Hi again, sorry for the delay.
Well, i finally can build Qt with OpenGL. :D
A few hours later, the -make process finishes, I ran make install and all
was perfect.
After that, I upload to the BBB the /sysroot folder.
I try to build an example and it fails.
I configure QtCreator with the Qmake from
I believe if you respond directly from the Google Groups Beagleboard Forum
it will automatically add the previous conversation content. If you extend
the '...' then you will see what is being added. I just respond directly
in GMail and avoid the quotes unless I find them necessary.
Jeremias,
If
On Mon, 26 Oct 2020 14:24:54 -0300, in gmane.comp.hardware.beagleboard.user
"'Jeremias Ramirez' via BeagleBoard"
wrote:
>Dennis, to be honest, the quotes I see are only three little dots at the
>end of the mail that I simply ignore. I don't know where are you reading
>this, but I didn't realize t
I just checked that and you are right, my board is a BeaglBone Black with
ARM v7.
I mixed the term cortex-8 with the Arm version.
So, I don't know why, but I've been working with this well.
I will correct it as soon as possible.
Thanks.
El lun., 26 de oct. de 2020 14:42, jonnymo escribi贸:
> Je
Jeremias,
Which Beagleboard are you compiling for?
My Beaglebone Black reports as an ARMv7 and not an ARMv8 so are you sure
that is the correct toolchain for a BB Black.
*debian@beaglebone:~$ cat /proc/cpuinfo | grep -i arm*
*model name : ARMv7 Processor rev 2 (v7l)*
Jon
On Mon, Oct 26,
Dennis, to be honest, the quotes I see are only three little dots at the
end of the mail that I simply ignore. I don't know where are you reading
this, but I didn't realize that quotes may be annoying.
My apologies.
Now running make again. Let's see what happens next.
Thanks again for the support
Dennis,
Yeah, that is the intent of INCLUDEPATH since the location of the includes
in the toolchain are in a different location than where Qt is looking. I
did see a post where it was suggested to remove the Default path but there
were other comments in the same post where it did not work. What
On Mon, 26 Oct 2020 13:35:09 -0300, in gmane.comp.hardware.beagleboard.user
"'Jeremias Ramirez' via BeagleBoard"
wrote:
>/opt/qt5129bbb/gcc-linaro-7.5.0-2019.12-x86_64_armv8l-linux-gnueabihf/armv8l-linux-gnueabihf/include/c++/7.5.0/cstdlib:75:15:
>fatal error: stdlib.h: No such file or directory
Okay, i owe you another coffee.
I corrected the paths, but forgot just the arm8.
Was:
/opt/qt5129bbb/gcc-linaro-7.5.0-2019.12-x86_64_armv8l-linux-gnueabihf/arm-linux-gnueabihf/include/c++/7.5.0
Must be:
/opt/qt5129bbb/gcc-linaro-7.5.0-2019.12-x86_64_armv8l-linux-gnueabihf/arm
*v8l*-linux-gnueabihf/
Ok! Checking the paths again...
The only difference I see against your setup is that I'm using the Arm8
version of the toolchain.
Regards, Jeremias.
El lun., 26 oct. 2020 a las 13:41, jonnymo () escribi贸:
> I had that issue but it seemed to be resolved by adding the following line
> in the qmake
I had that issue but it seemed to be resolved by adding the following line
in the qmake.conf file:
*INCLUDEPATH +=
/home/bbbuild/develop/bbuild/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/include/c++/7.5.0*
Ensure you adjust the path, and other paths, to match your co
Well, I can't compile it. 馃樁
I got those errors after a while:
In file included from
/opt/qt5129bbb/gcc-linaro-7.5.0-2019.12-x86_64_armv8l-linux-gnueabihf/armv8l-linux-gnueabihf/include/c++/7.5.0/bits/stl_algo.h:59:0,
from
/opt/qt5129bbb/gcc-linaro-7.5.0-2019.12-x86_64_armv8l-linux
You cannot imagine how I feel when see this on my terminal:
EGL yes
OpenVG . no
OpenGL:
Desktop OpenGL ... no
OpenGL ES 2.0 yes
OpenGL ES 3.0
Okay, I think I have something that works. This completes the configure
step, completes make, and make install.
As far as the issue where it is still picking up the previous toolchain in
your config, each time after I compile or run into an issue, I remove the
build, the qt source, the toolchain f
That looks good.
In the meantime I try to fully understand what are you doing and how to
replicate it, you say you will add the other items in the config later. How
do you will do that? I have an VirtualBox snapshot on my laptop (another Qt
installation) just after the -make step, so, to try re
Okay, a bit of success.
With it picking up the older toolchain, look in the folders you are using
for any '.qt*. files. There are files that get created as '.' when running
the configure script.
For me,
I downloaded Qt 5.12.5 and unpacked it in a folder.
Then I created 3 folders for the prefix, e
Well, i'm not sure if this is something useful, but, I try to use an older
version of the Linaro compiler.
I was using 7.5 and i try 6.5
I think there's something weird updating links, because i change the
./configure, and the script still trying to use the 7.5v, look:
+ cd qtbase
+ /opt/qt5bbb/
Yeah, I tried with Debian 9.13 64-bit and it still shows the same error for
the OpenGL ES libs.
Must be missing something.
Jon
On Thu, Oct 22, 2020 at 2:03 PM 'Jeremias Ramirez' via BeagleBoard <
beagleboard@googlegroups.com> wrote:
> I don't know how path vars work in this kind of files, but,
I don't know how path vars work in this kind of files, but, if you see that
file, at the start includes an linux.conf file, that file also make
reference to the $varPaths whom we are trying to especify.
El jue., 22 de oct. de 2020 17:09, jonnymo escribi贸:
> Yeah, I just downloaded 5.12.9 and tie
Yeah, I just downloaded 5.12.9 and tied that but got the same end result
but more info in the log.
Also, I am following these two links and ensured both my Host and BB have
the proper libs installed and such.
https://mechatronicsblog.com/cross-compile-and-deploy-qt-5-12-for-raspberry-pi/#comment-17
I'm working with 5.12.9, so I think isn't a version issue either.
El jue., 22 de oct. de 2020 14:20, jonnymo escribi贸:
> Qt 5.15.1 from source.
>
> On Thu, Oct 22, 2020 at 9:58 AM 'Jeremias Ramirez' via BeagleBoard <
> beagleboard@googlegroups.com> wrote:
>
>> Jon, which version of Qt are you tr
Qt 5.15.1 from source.
On Thu, Oct 22, 2020 at 9:58 AM 'Jeremias Ramirez' via BeagleBoard <
beagleboard@googlegroups.com> wrote:
> Jon, which version of Qt are you trying to build?
>
> El jue., 22 de oct. de 2020 13:33, jonnymo escribi贸:
>
>> I have a Debian 9.13 Docker instance on Ubuntu 20.04
Jon, which version of Qt are you trying to build?
El jue., 22 de oct. de 2020 13:33, jonnymo escribi贸:
> I have a Debian 9.13 Docker instance on Ubuntu 20.04 that I have been
> building so that might be an option. I could try a 64-bit Debian
> VirtualBox image but only have a 32-bit in place no
I have a Debian 9.13 Docker instance on Ubuntu 20.04 that I have been
building so that might be an option. I could try a 64-bit Debian
VirtualBox image but only have a 32-bit in place now. However, I am not
seeing anything that would indicate it is an Ubuntu vs Debian thing but it
is possible and
I think I can run the Debian image from the board memory, I have the SD
with the Ubuntu distro and I don't have other SD available rigth now.
I will try with that sysroot in a couple hours.
Thanks.
El jue., 22 de oct. de 2020 12:11, Jeremias Ramirez <
iguanadeje...@googlemail.com> escribi贸:
> Hi
Hi again.
Yes, the BBB is running Ubuntu 18.04 for Arm.
The workstation is running Ubuntu 18.04 too.
El jue., 22 de oct. de 2020 12:07, Dennis Lee Bieber <
dennis.l.bie...@gmail.com> escribi贸:
> On Wed, 21 Oct 2020 10:50:12 -0700, in gmane.comp.hardware.beagleboard.user
> jonnymo wrote:
>
> >If
On Wed, 21 Oct 2020 10:50:12 -0700, in gmane.comp.hardware.beagleboard.user
jonnymo wrote:
>If they are doing cross compiling from a remote host, then should they not
>be using the BB specific libs under sysroot and not the host OpenGL libs?
>
Based upon the OP's response, they are buildi
On Wed, 21 Oct 2020 12:51:23 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user "'Jeremias Ramirez' via BeagleBoard"
wrote:
>Hi Dennis, thanks for the reply.
>This is the output of the apt search commands:
Okay, I'm out of ideas -- other than maybe burn a Debian image and try
the same
I will try to reproduce your way to log the error, maybe can throw some
light on this.
Thanks for your time. I really appreciate it.
El jue., 22 de oct. de 2020 03:53, jonnymo escribi贸:
> I've tried to set this up and I am seeing a similar issue. I piped the
> output to tee and a log file and f
I've tried to set this up and I am seeing a similar issue. I piped the
output to tee and a log file and found it is not able to locate a lib which
from what I can tell is there.
This is the configure statement I used:
./configure -no-gcc-sysroot -device linux-beagleboard-g++ -device-option
CROSS
Hi Dennis, thanks for the reply.
This is the output of the apt search commands:
ubuntu@beaglebone:~$ apt search libgles
Sorting... Done
Full Text Search... Done
libgles1/bionic-updates,now 1.0.0-2ubuntu2.3 armhf [installed,automatic]
Vendor neutral GL dispatch library -- GLESv1 support
libgles2
If they are doing cross compiling from a remote host, then should they not
be using the BB specific libs under sysroot and not the host OpenGL libs?
Jon
On Wed, Oct 21, 2020 at 10:15 AM Dennis Lee Bieber <
dennis.l.bie...@gmail.com> wrote:
> On Wed, 21 Oct 2020 07:11:31 -0700 (PDT), in
> gmane.c
On Wed, 21 Oct 2020 07:11:31 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user "'Jeremias Ramirez' via BeagleBoard"
wrote:
>
>Trying source 1 (type makeSpec) of library opengl_es2 ...
>None of [libGLESv2.so libGLESv2.a] found in [] and global paths.
>None of [libEGL.so libEGL.a] found in [] a
34 matches
Mail list logo
