I'm using AWS EC2 Ubuntu 14.04 to test my OpenGL + SDL2 application. I am using SDL version 2.0.2. Because AWS EC2 is headless, I am using xvfb and use this script in /etc/init.d/xvfb:
XVFB=/usr/bin/Xvfb
XVFBARGS=":99 -ac -screen 0 1024x768x24"
PIDFILE=/tmp/cucumber_xvfb_99.pid
case "$1" in
start)
echo -n "Starting virtual X frame buffer: Xvfb"
/sbin/start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile --background --exec $XVFB -- $XVFBARGS
echo "."
;;
stop)
echo -n "Stopping virtual X frame buffer: Xvfb"
/sbin/start-stop-daemon --stop --quiet --pidfile $PIDFILE
rm -f $PIDFILE
echo "."
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: /etc/init.d/xvfb {start|stop|restart}"
exit 1
esac
exit 0
These are the linux command before i run the app :
export DISPLAY=:99.0
sh -e /etc/init.d/xvfb start
sleep 3
But I got "Failed to connect to the Mir Server" error from calling SDL_Init(SDL_INIT_VIDEO | SDL_INIT_TIMER)
I am actually doing this because I follow instruction from https://docs.travis-ci.com/user/gui-and-headless-browsers/ and want to do the same in my AWS machine. I tried it also with travis, and The xvfb script is also taken from travis ci setup.
Not sure if this is gonna help but these are the output from glxinfo | grep OpenGL :
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits)
OpenGL version string: 2.1 Mesa 10.1.3
OpenGL shading language version string: 1.30
OpenGL extensions:
So, I guess essentially my question is : how to setup OpenGL (preferably version 3) + SDL2 in headless Ubuntu 14.04 ?
Thanks in advance
You have two options.
Use a real X11 server. Headless OpenGL is not supported by most OpenGL implementations. This will allow you to use hardware acceleration. You will need to choose an EC2 instance with the right hardware support.
Use OSMesa. This will give you a software-only implementation that does not require X11 or any other window server at all.
It is normal / expected to get Gallium + llvmpipe as the implementation when hardware acceleration is not available. This is fine. If you need a newer version of OpenGL, you will want to install a newer version of Mesa. Mesa 10.1.3 is more than two years old at this point (it's from May 2014). Getting a newer version of Mesa either means using an alternate repo, installing a different version of Ubuntu, or compiling Mesa yourself.
If you compile Mesa yourself, you can configure it for OSMesa ("off-screen Mesa") which means it will have no dependencies on X11. See Off-screen Rendering for more details.
So, It turns out I need to put this into ~/.bashrc :
export DISPLAY=:99.0
sh -e /etc/init.d/xvfb stop
sh -e /etc/init.d/xvfb start
sleep 3
so that the above script will be run everytime I connect to the machine.
But then, I got a different error saying that the SDL_GL_CreateContext failed. Like #dietrich-app said, I need to update my mesa. The oibaf's graphic drivers ppa are no longer working (every google searches seem to suggest to use that) because it does not support ubuntu 14.04 anymore. I tried to compile mesa on my own but compiling dependencies are very time consuming and cumbersome. Finally, after hours of searching, I found this https://wiki.ubuntu.com/Kernel/LTSEnablementStack and copy paste the following command from that link :
sudo apt-get install --install-recommends linux-generic-lts-wily xserver-xorg-core-lts-wily xserver-xorg-lts-wily xserver-xorg-video-all-lts-wily xserver-xorg-input-all-lts-wily libwayland-egl1-mesa-lts-wily
And I got my mesa updated, and can now run OpenGL + SDL2 on AWS EC2 headless
Thank you for all the helpo
Related
I tried to build a gdb for esp32 that works with qemu, but after many attempt, I didn't manage. All my attempts leaded me to the following error message after connecting to the remote target: Remote 'g' packet reply is too long.
Right now I am using the prebuilt version from Ebiroll: https://github.com/Ebiroll/qemu_esp32/blob/master/bin/xtensa-esp32-elf-gdb
but I would like to use a newer gdb version than 7.10, did anyone had success with this?
Here is how I built gdb:
git clone --depth 1 --branch esp-2021r2-gdb https://github.com/espressif/binutils-gdb.git
cd binutils-gdb
mkdir -p build
cd build
../configure --without-guile --host=x86_64-pc-linux-gnu --target=xtensa-esp32-elf --disable-werror
make
make install
(note from this branch the patch to apply from the Zephyr project, as described here https://github.com/Ebiroll/qemu_esp32#qemu-esp32, seems to already be included)
I also tried by applying the following patch (no success):
curl -L https://raw.githubusercontent.com/Ebiroll/gdb/master/gdb/xtensa-config.c.qemu --output binutils-gdb/gdb/xtensa-config.c
or patching qemu to fix the value of num_regs (tried 104 and 172, also no success).
Espressif's qemu wiki mentions setting an environment variable to only list the core registers:
export QEMU_XTENSA_CORE_REGS_ONLY=1
This needs to be set in the environment from where qemu will be executed.
My recommendation is to use both qemu and gdb (from the Esp32 tool chain) as provided by Espressif. I have recently used this combination with success. The latest release uses gdb 9.2.
I am trying to run a Docker image based on an ARMv7 container on a x86 computer. According to this site, it is possible by running this container first.
docker run --rm --privileged hypriot/qemu-register
This command works on Mac OS X and on an Ubuntu 19 virtual machine (with a Windows 10 host). However, when I try to run on CentOS 7 and one of the AWS A1 instances, I get the message standard_init_linux.go:211: exec user process caused "exec format error". The CPU for the CentOS 7 is an Intel Core i7-8700K and AWS A1 is based on the Graviton processor.
Anyone know what I'm missing here?
The complaint on the AWS A1 instance is with installing miniconda. I'm not sure if there is a way to say yes (to continue to install) since the -b flag already is supposed to get miniconda to install silently.
Step 6/11 : RUN /bin/bash /tmp/miniconda.sh -b -p /opt/miniconda
---> Running in ab9b5fef6837
WARNING:
Your processor does not appear to be an armv7l. This software
was sepicically build for the Raspberry Pi 2 running raspbian wheezy
(or above).
Are sure you want to continue the installation? [yes|no]
[no] >>> Aborting installation
AWS A1 instances do support running Armv7 binaries. Using the available Ubuntu 18.04 AMI for A1, run this on the command line:
cat /boot/config-4.15.0-1043-aws | grep "CONFIG_COMPAT=y"
If this succeeds, then the AMI and kernel have been built with support for running 32-bit executables on the 64-bit platform. To test this capability, install using apt-get install gcc:armhf libc6:armhf to get a minimal 32-bit build environment, create an executable and execute readelf -h on it. You should see the Machine listed as ARM, not AArch64. Execution should also succeed.
Testing docker with armv7 images also works out of the box on the Ubuntu 18.04 AMI on A1. I tested via docker pull armhf/ubuntu:latest and then entered interactive mode using bash and tried installing Miniconda3. The problem does appear to be with the Miniconda install script linked above. It tries this unconditionally on line 58:
if [[ `uname -m` != 'armv7l' ]]; then
echo -n "WARNING:
Your processor does not appear to be an armv7l. This software
was sepicically build for the Raspberry Pi 2 running raspbian wheezy
(or above).
Are sure you want to continue the installation? [yes|no]
[no] >>> "
read ans
if [[ ($ans != "yes") && ($ans != "Yes") && ($ans != "YES") &&
($ans != "y") && ($ans != "Y") ]]
then
echo "Aborting installation"
exit 2
fi
fi
Docker does not do any rewriting of what uname -m returns, it will see AArch64 on the A1 instance and it will trip up there. Commenting this block out should get you going on the A1 instances.
For getting this to work on your x86 laptop, you will need to copy qemu-arm-static to the docker image to enable emulation. I am not sure, but I would suspect that uname would still not return the proper machine-type Miniconda expects.
I am using composer version 0.75v. When I try to create a archive with the following command:
composer archive create --sourceType dir --sourceName . -a ./dist/my-network.bna
I get this back:
/Users/fabianhinsenkamp/Documents/businessNetwork
/usr/local/lib/node_modules/composer-cli/node_modules/yargs/yargs.js:1079
else throw err
^
ParseException: Expected "#", "." or "\"" but "-" found. Line 14 column 20
Do you know what is the problem? I tried to change the network files but it doesn't seem to be the problem.
would have to firstly check that your supported node/npm/docker versions matched these ->
Operating Systems: Ubuntu Linux 14.04 / 16.04 LTS (both 64-bit), or Mac OS 10.12
Docker Engine: Version 17.03 or higher
Docker-Compose: Version 1.8 or higher
Node: 6.x (note version 7 is not supported)
npm: 3.10.x
Note: we are (ie at time of writing) on Hyperledger Composer v0.9.2 - suggest to get this level of Hyperledger Composer (as there have been quite a few changes, since 0.7.5, including syntax in model transactions for example). You can try out your business network definition (ie modeled assets, participants, transactions etc in the online playground https://composer-playground.mybluemix.net/ to verify that everything is OK.
When running an app that uses Qt 4.7 on my Fedora 19 box I am getting the following errors from the application:
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
libGL: Can't open configuration file /home/Matthew.Hoggan/.drirc: No such file or directory.
libGL error: failed to load driver: swrast ERROR: Error failed to create progam.
I do not see these errors in a stock X11 application where the context is configured using glx. I am assuming this is because Qt uses egl underneath. The same thing happens when using the EGL 3 emulator from http://malideveloper.arm.com/develop-for-mali/tools/opengl-es-3-0-emulator/ while running their cube example.
I have already verified that both xorg-x11-drv-nvidia-libs.i686 and yum install xorg-x11-drv-nvidia-libs.x86_64 rpms are installed.
My system information is:
Linux localhost.localdomain 3.11.9-200.fc19.x86_64 #1 SMP Wed Nov 20 21:22:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
And glxinfo is:
[Matthew.Hoggan#localhost QtTest]$ glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL core profile version string: 4.3.0 NVIDIA 331.38
OpenGL core profile shading language version string: 4.30 NVIDIA via Cg compiler
OpenGL version string: 4.4.0 NVIDIA 331.38
OpenGL shading language version string: 4.40 NVIDIA via Cg compiler
Any suggestions here or is more information needed?
We were able to get rid of the same error messages for octave-4.0.0-rc1 which also use Qt. The bug hunting history can be found here.
It turned out to be an incorrect runpath in a shared library (.so). The runpath contained /usr/lib64. Hence at runtime the /usr/lib64/libGL.so was loaded, instead of the right nvidia /usr/X11R6/lib64/libGL.so.
Workaround
Find the lib or executable which has the incorrect runpath with ldd <app or lib> and chrpath -l <app or lib>
Replace the wrong path with the correct one (without the offending /usr/lib64) using chrpath -r <correct path> <app or lib>
The following one-liner did this for liboctgui.so. Just replace "liboctgui.so" by your value.
chrpath -r $(chrpath -l liboctgui.so | cut -d '=' -f '2' | awk '{gsub(/\/usr\/lib64/, "")}; 1') liboctgui.so
Origin
The incorrect runpath was picked up at compilation time from an irrelevant
-L/usr/lib64 in libQt*.la files located in /usr/lib64.
The comment #18 explains why it is wrong.
And indeed, lib*.la files should not be packaged, according to OpenSUSE own recommendations
Avoid packaging libtool config files (.la files). If you do not
package a static library, and if you are also placing the shared
library in a standard search directory (i.e. %_lib, /usr/%_lib), they
will not be needed.
Removing lib*.la from /usr/lib64 and rebuilding fixed the problem for good.
When on MacOSX, "man glRotate" brings up the glRotate manpage.
On ubuntu, with manpages-dev and manpages-posix-dev insatlled, "man glRotate" doesn't bring up the glRotate manpage (though I can build and compile gl apps).
What am I missing? How do I setup this up?
sudo apt-get install opengl-4-man-doc opencl-1.2-man-doc
contains many man pages, e.g.:
man glDrawArrays
but it does not contain man glRotate. I think this is because the deprecated immediate APIs are not included.
apt-file search glRotate shows a few hits, but they don't seem "official".
Tested on Ubuntu 16.04.
Combine the Khronos OpenGL-Refpages repository with the PKGBUILD script from the Arch opengl-man-pages package.
# $Id$
# Maintainer: AndyRTR <andyrtr#archlinux.org>
pkgname=opengl-man-pages
pkgver=20170404
_commit=03552a8094ae3017e0b8b2ad44c602f81c03e848
pkgrel=1
pkgdesc="OpenGL Man Pages"
arch=('any')
url="https://github.com/KhronosGroup/OpenGL-Refpages"
license=('custom')
# OpenGL 4.x (current) API and GLSL pages - libxslt' 'docbook-xsl'
# OpenGL 3.x and older 'w3c-mathml2' 'docbook-mathml'
makedepends=('libxslt' 'docbook-xsl' 'w3c-mathml2' 'docbook-mathml' 'git')
source=(${pkgname}::git+https://github.com/KhronosGroup/OpenGL-Refpages#commit=$_commit
'LICENSE')
sha256sums=('SKIP'
'a7b2f6669d7ead91dcaf5a03620cdf9d37c54d83fd1899b4ef84683c7e6d4024')
# gl2.1 = OpenGL 2.1 (including fixed functionality)
# es3 = OpenGL ES 3.x (will always be the latest ES, currently 3.2)
# gl4 = OpenGL 4.x (current) API and GLSL pages
_mandirs=(gl4 es3 gl2.1)
pkgver() {
date +%Y%m%d
}
build() {
export WD=`pwd`
xmlcatalog --create --noout \
--add public "-//W3C//DTD MathML 2.0//EN" "file:///usr/share/xml/w3c/mathml2/mathml2.dtd" \
--add public "-//W3C//DTD MathML//EN" "file:///usr/share/xml/w3c/mathml2/mathml2.dtd" \
--add system "http://www.w3.org/TR/MathML2/dtd/mathml2.dtd" "file:///usr/share/xml/w3c/mathml2/mathml2.dtd" \
mathml2.cat
export XML_CATALOG_FILES="$WD/mathml2.cat /etc/xml/catalog"
for manpages in ${_mandirs[#]}; do
cd "${srcdir}/${pkgname}/${manpages}"
for file in gl*.xml; do
xsltproc --noout --nonet /usr/share/xml/docbook/xsl-stylesheets-*/manpages/docbook.xsl ${file}
done
done
}
package() {
install -d "${pkgdir}/usr/share/man/man3"
for manpages in ${_mandirs[#]}; do
cd "${srcdir}/${pkgname}/${manpages}"
install -m644 *.3G "${pkgdir}/usr/share/man/man3/"
done
# license
install -D -m644 "${srcdir}/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}
I had to install some extra packages on my Debian Stretch box to build the documentation:
sudo apt-get install xsltproc docbook-xsl docbook-xsl-ns w3-dtd-mathml docbook-mathml