I build the cobalt with platform "linux-x64x11" on Ubuntu as below：
$cat /proc/version
Linux version 3.13.0-119-generic (buildd#lcy01-08) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #166-Ubuntu SMP Wed May 3 12:18:55 UTC 2017
But this Ubuntu can't not support GLES3 because coredump happens, I have to modify the src/starboard/linux/shared/gyp_configuration.gypi file, and substitute "system_gles3" with "system_gles2" to make Cobalt run successfully.
May I ask which linux distribution version support GLES3 perfectly? Otherwise I have to upgrade my opengles library in this Ubuntu.
Wait for help, thanks,
Jenson.
What is your Cobalt version? My up-to-date Cobalt on Linux falls back to GLES2 gracefully.
It looks Ubuntu 17.04 official repository does not have GLES3 yet. If you want to use GLES3, you need to manually install it. Or set the "gl_type" to "system_gles2". I recommend the latter.
Related
I'm trying to make a sample kernel extension like from here
but, I can't find where the mac_policy.h is with next command
sudo find / -iname 'mac_policy.h'
where is it?
should I download something?
my environment is like below.
macOS Catalina 10.15.1
$ uname -rsv
Darwin 19.0.0 Darwin Kernel Version 19.0.0: Thu Oct 17 16:17:15 PDT 2019; root:xnu-6153.41.3~29/RELEASE_X86_64
Xcode 11.2.1 (11B500)
The MAC Framework has officially never been supported by Apple for 3rd party kexts, and they don't guarantee ABI compatibility across versions. (The callbacks can have different function signatures in different macOS versions, which makes kernel panics likely.) Its headers were removed from the Kernel.framework around the macOS 10.13 SDK to reflect this lack of support
From macOS 10.15 onwards, you are supposed to use EndpointSecurity instead.
I am trying this on Windows: https://github.com/cfenollosa/os-tutorial/tree/master/01-bootsector-barebones
E:\Code\MyOS\os>D:\qemu\qemu-system-x86_64.exe boot_sect_simple.bin
WARNING: Image format was not specified for 'boot_sect_simple.bin' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
Unexpected error in aio_context_set_poll_params() at /home/stefan/src/qemu/repo.or.cz/qemu/ar7/util/aio-win32.c:413:
D:\qemu\qemu-system-x86_64.exe: AioContext polling is not implemented on Windows
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
This also gives the same error:
D:\qemu\qemu-system-x86_64.exe -drive format=raw,file=boot_sect_simple.bin
QEMU version:
E:\Code\MyOS\os>D:\qemu\qemu-system-x86_64.exe -version
QEMU emulator version 2.11.90 (v2.12.0-rc0-11704-g30195e9d53-dirty)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
NASM version:
E:\Code\MyOS\os>E:\Code\MyOS\nasm-2.13.03\nasm.exe -version
NASM version 2.13.03 compiled on Feb 7 2018
This is a bug in the (release-candidate rc0) version of QEMU you are using: https://bugs.launchpad.net/qemu/+bug/1761027
It was fixed in the final 2.12.0 release. So you should upgrade your QEMU (either to 2.12.0 or to the more recent 3.0).
In general it's a bad idea to run with release-candidate versions unless you're using them specifically to test them before a full release.
How to download latest Firefox (49.0) package for Solaris 10.
Please share the build procedure to create Firefox package for Solaris 10 machine.
You can find this page
Latest version now for Solaris: Firefox-52.0.2esr
With a notice:
X multithread is re-enabled on Solaris 10.
If you have drag & drop X hang issue, update your Xserver or stay with 45.x.
If you are on Sun Ray, stay with 45.x.
Solved the exit crash issue.
Fontconfig 2.8.0 or above is required for version > 45.0.
A library of fontconfig 2.8.0 is included in Firefox/Thunderbird
for Solaris 10 contrib build.
For OpenSolaris, you need to install Fontconfig 2.8.0 by yourself.
[Updated]
You can check this link
Oracle shared a link which provided Solaris package only for Firefox 45.2.0esr.
But Firefox 45.2.0 have multiple vulnerabilities. Need latest Firefox 48.0 or 49.0 package for Solaris.
The latest version of Firefox that I have found and that works fine on Solaris 10 on Sparc is 52.0.2 ESR.
https://ftp.mozilla.org/pub/firefox/releases/52.0.2esr/contrib/
Extract it and run it with ./firefox
I want to cross-compile my own kernel module for a BeagleBone Black using my desktop PC which has AMD-64bit architecture, and is running debian. The BeagleBone Black is also running debain, but the two machines have different kernels.
I just want to install the kernel headers for the ARM on my desktop PC, but I can't figure out which deb(s) need to be installed. I have the arm-linux-gnueabi-* version of gcc installed.
The kernel on the BeagleBone Black is this:
Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux
What kernel-headers deb do I need for this?
These are the ones that I already have installed:
linux-headers-3.2.0-4-all
linux-headers-3.2.0-4-all-amd64
linux-headers-3.2.0-4-amd64
linux-headers-3.2.0-4-common
linux-headers-3.2.0-4-common-rt
linux-headers-3.2.0-4-rt-amd64
Apparently this is not possible yet - there don't seem to be any Linux header packages in Debian later than 3.2.*
We just had our hosting provider build out a new RHEL 5 box for us to test some legacy stuff on:
uname -a: Linux myserver.foo.com 2.6.18-164.9.1.el5 #1 SMP Wed Dec 9 03:29:54 EST 2009 i686 i686 i386 GNU/Linux
cat /etc/redhat-release: Red Hat Enterprise Linux Server release 5.4 (Tikanga)
gcc -v: gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
I'm having a hell of a time figuring out how to get gcc-3.2.2 installed on this machine:
I can't seem to compile 3.2.2 with the gcc 4.1.2 compiler
I can't seem to find a 3.2.2 installation via yum
I'm afraid of what would happen if I rpm'd it manually
Any advice?
EDIT: thanks for the suggestions so far, but just to clarify - the "legacy stuff" I mentioned isn't actually my company's legacy stuff. It's a 3rd party package and I don't have access to the code (and wouldn't want to change it even if I did)
I guess I'll look into the chroot thing, because at this point going back to a different RHEL seems heartbreaking.
You could try to install a RHEL 4 machine, it has gcc 3.4 which might work to build your stuff. Then you could try running the binaries on your RHEL 5.
It may just be easier to debug the legacy code to work on gcc 4.
What I would suggest is installing the rpm manually within a chroot. You would have to google a lot for the method but it should in theory work well. Alternatively you could just rewrite/update your legacy code (yes, I know it is easier said than done).