| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
and packages
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
STL headers (default since NDK r18)
Using LLVM's c++_shared as of NDK r18: https://developer.android.com/ndk/guides/cpp-support.html
LLVM's c++ headers must come before other system header!
Also see https://github.com/android/ndk/issues/452 and https://gitlab.kitware.com/cmake/cmake/issues/17059
Also adapt make/lib/gluegen-cpptask-android* files:
- Compiler
-- align for potential C++ usage, i.e.:
-- don't use '-sysroot' not '-isysroot'
-- IF using C++ STL, prepend ANDROID_TOOLCHAIN_SYSROOT1_INC_STL
-- just add normal sysroot headers via '-isystem'
- Linker
-- Use ANDROID_TOOLCHAIN_SYSROOT1_LIB1 and ANDROID_TOOLCHAIN_SYSROOT1_LIB2 for '-L' search path
-- where ANDROID_TOOLCHAIN_SYSROOT1_LIB2 is for 'libc++' -> 'c++_shared'
|
|
|
|
|
|
|
|
|
| |
specific includes like asm/types.h
Also adapt make/lib/gluegen-cpptask-android* files:
- Set C++ stdlib = libstdc++
- Set isysroot (same as sysroot)
- Add isystem: *_SYSROOT1_INC, *_SYSROOT1_INC_ARCH and *_SYSROOT1_INC/c++/v1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
headers (compile)
Utilizing '-sysroot' with the linker, we require standard FS layout.
'~/Android/Sdk/ndk/20.1.5948944/platforms/android-24/arch-arm64'
contains the proper std FS layout for libraries under usr/lib,
but lacks the header files.
We call this 'ANDROID_TOOLCHAIN_SYSROOT0' and shall be used for linking.
'~/Android/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/linux-x86_64/sysroot'
native libraries are not under std FS layout,
but headers are under std FS layout for compilation under usr/include.
We call this 'ANDROID_TOOLCHAIN_SYSROOT1' and shall be used for compilation.
Identified while working on openal-soft Android compilation,
where we need to pass ANDROID_TOOLCHAIN_SYSROOT0
|
|
|
|
|
|
|
|
|
| |
make/lib/gluegen-cpptask-android-<abi>.xml and scripts
All aligned now
- gluegen-cpptasks-android-aarch64.xml
- gluegen-cpptasks-android-armv6.xml (this has ld flag --no-undefined disabled, due to internal missing symbols)
- gluegen-cpptasks-android-x86.xml
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2019-12-10 (GlueGen w/ android-aarch64 patched)
Default Platform: Android 7.0 Nougat, API level 24 supports Java 1.8
Reworked gluegen/make/scripts/setenv-android-tools.sh,
following canonical environment variables and sets all
required variables for cross-compilation.
See file's comments!
ant files:
- android.version -> android.api.level (default 24)
- android.jar defaults to ${gluegen.root}/make/lib/android-sdk/24/android.jar (provided)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test1p1Test1p1JavaEmitter
'com.jogamp.gluegen.test.junit.generation.Test1p1JavaEmitter' exposes a regression
using MingW64 8.1.0: System.loadLibrary() gives a "Can't find dependent libraries".
Here, 'Bindingtest1p1' is linked against 'test1' and fails to load
due to its wrong dependent library name within 'Bindingtest1p1'.
MingW64 8.1.0 dropped 'libtest1.so' into 'Bindingtest1p1.dll',
which is surely wrong. Even passing '-Wl,-soname=test1.dll' didn't help.
Note: Such constellation would only work with adding
the lib-path to PATH on Windows.
Since we don't utilize the method in any of our projects,
but use the dynamic library lookup method - this is not a blocker,
but wasted some good time.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compile time javac
Also prepare the 'target.releaselevel' property to be set by 'RELEASE_LEVEL' environment,
however - we do not use it at this point.
For now, we build gluegen-rt using '-source 1.8' '-target 1.8'
and the bootclasspath of openjdk8 rt.jar to ensure java8 compatibility.
Alternatively one could use '--release 8' instead using the java11
distributed modules. However, I think the above method is more safe,
only allowing java8 rt.jar to be used for compilation.
Further, gluegen.jar is build using '-target 1.8' only,
since it musty use java11 sources at least for the javadoc taglet.
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Current requirements are:
- Java 1.8 (Level 8.0)
- Android SDK API level 24 (Version 7.0 Nougat, released August 2016)
Official production builds are performed w/ Java 1.8.
- Java 1.8 (Level 8.0)
- Android SDK API level 24 (Version 7.0 Nougat, released August 2016)
Android 7 API level 24 supports Java 1.8,
see https://developer.android.com/studio/write/java8-support
Java 8 is chosen today, June 2019, since OpenJDK 1.8 is well supported
on desktop, mobile support is given w/ OpenJDK 9 and
Android also support these language features for almost 3 years.
++++
Current patch does require one to set the target.sourcelevel,
target.targetlevel and target.rt.jar properties or their equivalent
capital case environment variables.
Only allowed value is currently 1.8.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Current build system for JogAmp iOS Build is:
- Build Machine: OSX Mojave 10.14
- Using own (still proprietary) OpenJDK 9 iOS Build
- OpenJDK 1.8 (This will be replaced by OpenJDK 11 soon)
- Xcode 10.2
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TARGET_PLATFORM_USRLIBS for crosscompilation
Android Crosscompilation Usage:
- TARGET_PLATFORM_ROOT -> TARGET_PLATFORM_SYSROOT
General
- TARGET_PLATFORM_SYSROOT Crosscompiler and system specified 'sysroot' (as in gcc --print-sysroot)
- TARGET_PLATFORM_USRROOT Additional optional user headers and libraries for target
- TARGET_PLATFORM_USRLIBS Actual location of target user libraries within TARGET_PLATFORM_USRROOT
- TARGET_JAVA_LIBS Actual location of the Java libraries within TARGET_PLATFORM_USRROOT
|
|
|
|
|
|
| |
- arm6hf needs the fpu to be specified, we still use the lowest armv6 hard float denominator
- aarch64 shall have the -march compiler argument as well
- glibc-compat-symbols.h Finally drop the glibc versioning on memcpy for both
|
|
|
|
|
|
|
| |
Default is to crosscompile w/o testing, i.e. property 'isCrosscompilation' is set to 'true'.
'ontarget' includes testing, no crosscompilation.
Updated crosstools links to new build of jogamp-scripting commit e6692024687685d3af725555d9bb5490d85ecc8d
|
|
|
|
|
| |
Implementation currently uses 256 bit Secure Hash (SHA) algorithm, but this may change in the future.
Hence only use 'SHA' in the names, not 'SHA256'.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtime validation
This change implements a strong SHA256 signature over:
1) source tree inclusive make recipe (SHA256-Source)
2) all class files (SHA256-Classes)
3) all native libraries (SHA256-Natives)
4) the class files as deployed in the jar (SHA256-Classes-this)
5) the native libraries as deployed in the jar (SHA256-Natives-this)
and drops all of these in the deployed Jar file.
This allows SHA256 validation of (4) + (5) at runtime
and further complete validation (1), (2) and (3) offline.
Full SCC would now required (1) - (3) to be placed on a server for further validation.
Optionally we may use GPG <https://gnupg.org/> or PGP to validate the build entity to implement the chain of trust <https://en.wikipedia.org/wiki/Chain_of_trust>
The SHA256 runtime validation is tested via: com.jogamp.common.util.TestVersionInfo
|
|
|
|
|
|
|
|
| |
Since Java8 (or even earlier), JRE on OSX uses *.dylib native library suffix
instead of *.jnilib when automatically searching and loading them.
This is not easily being recognized by JogAmp, since we explicitly name
the native libraries with full path when testing with our TempJarCache.
|
|\ |
|
| | |
|
|\ \
| | |
| | | |
adding support for android x86 targets - revised
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Re-adding executable test by execution is required for 'blocker technology'
like Windows's 'Software Restriction Policies (SRP)',
which only gets activated by the actual execution attempt.
Merely testing the file's (ACL) execution flags via NIO's isExecutable is not sufficient.
Implementation first tests the file's (ACL) execution flags via NIO's isExecutable.
If the NIO test was successful or not available, the actual execution test is performed.
To mitigate the virus scanner's false positive, we use an executable shell script
per default now, which may be overriden by the new environment 'jogamp.gluegen.UseNativeExeFile=true'
Tested on GNU/Linux with one temp folder having mount options 'noexec'
and on Windows using Software Restriction Policies (SRP) disallowing one temp folder.
Both temp folder were first in line via environment 'java.io.tmpdir'.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
java.nio.file.Files.isExecutable(Path)
Attempt to resolved virus scanner false positive detection on Windows
while deflating the native code test-exe file in the temporary folder.
As Julien Gouesse suggested, using Java 1.7's java.nio.file.Files.isExecutable(Path)
_may_ resolve the issue, this has to be thorougly tested.
This patch favors the nio's isExecutable file's ACL test
over the more intrusive execution itself using a simple shell script file w/ set executable flag.
Mind that previous tests allowed the shell script's execution,
even if the temp folder did not allow execution of native code.
We have to see how our testing results will be on this attempt.
|
|\ \ \ |
|
| | | | |
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
make/lib/gluegen-cpptasks-linux-aarch64.xml:
Add missing -DisLinux=true required when crosscompiling
Remove -marm -mfloat-abi=hard flags unrecognisable by aarch64 crosscompile toolchain
make/lib/toolchain/aarch64-linux-gnueabi/bin/*:
Symlink to /usr/local/x-tools/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-*
make/scripts/make.gluegen.all.linux-aarch64-cross.sh:
New crosscompile script
make/stub_includes/platform/glibc-compat-symbols.h:
glibc 2.17 is the first glibc version that support aarch64
however memcpy is not versioned for aarch64
Disable versioning for linux glibc/aarch64
Signed-off-by: Xerxes Rånby <[email protected]>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
make/build.xml: New target declare.linux.aarch64
Update target declare.linux to depend on declare.linux.aarch64
make/gluegen-cpp-tasks-base.xml: Fix aarch64 jre/lib/arm -> jre/lib/aarch64
make/lib/gluegen-cpptasks-linux-aarch64.xml: Added
make/scripts/make.gluegen.all.linux-aarch64.sh: Added
Tested on DragonBoard 410c running Linaro Debian
Platform: LINUX / Linux 4.4.8-linaro-lt-qcom (4.4.8), aarch64 (ARM64, EABI_AARCH64), 4 cores, littleEndian true
MachineDataInfo: runtimeValidated true, 32Bit false, primitive size / alignment:
int8 1 / 1, int16 2 / 2
int 4 / 4, long 8 / 8
int32 4 / 4, int64 8 / 8
float 4 / 4, double 8 / 8, ldouble 16 / 16
pointer 8 / 8, page 4096
Platform: Java Version: 1.8.0_91 (1.8.0u91), VM: OpenJDK 64-Bit Server VM, Runtime: OpenJDK Runtime Environment
Platform: Java Vendor: Oracle Corporation, http://java.oracle.com/, JavaSE: true, Java6: true, AWT enabled: true
Signed-off-by: Xerxes Ranby <[email protected]>
|
|/ / / / |
|
| |_|/
|/| | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Uri to handle relative path
Fix IOUtil.cleanPathString(..) special case:
Special case '/a/./../b' -> '/b'
requires to resolve './' before '../'.
Allow IOUtil and Uri to handle relative path:
- IOUtil.getParentOf(..)
- IOUtil.cleanPathString(..)
Handle cases:
'a/./../b' -> 'b'
'.././b' -> '../b'
- Uri: Handle null scheme
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
ensure launched native exe process terminates.
See Bug 1219 comment 58: It seems that on some Windows platforms
the launched native process using our test-exe keeps running
even though we issued Process.waitFor().
Hence we issue Process.destroy() in the finalize block
to at least attempt to terminate it.
Note: The Process implementation is platform specific and may vary.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
IOUtil.testDirExe():
- Satisfactory when executed
Failure to execute produce an IOException right at ProcessBuilder.start().
Hence we can allow an unexpected process exit value,
since we only want to learn whether executable files are allowed.
- More debug options
DEBUG_EXE: 'jogamp.debug.IOUtil.Exe'
DEBUG_EXE_NOSTREAM: 'jogamp.debug.IOUtil.Exe.NoStream'
- if DEBUG_EXE
- a pre-existing 'jogamp_exe_tst'+<SUFFIX> will be used as-is.
- the test-exe will not be deleted
- StreamMonitor is being used to dump stdout/stderr
if !DEBUG_EXE_NOSTREAM.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Windows using 'exe-windows-i586-268b.bin' (Fix attempt #1)
Replacing the tiny 268 byte sized 'exe-windows-i586-268b.bin' PE file
w/ a regular 2048 byte sized PE file 'exe-windows-i386-2048b.bin'.
File is produced via:
c:\mingw\bin\gcc -nodefaultlibs -nostdlib -s -Os -o tiny.exe tiny.c
Adding the 305 byte sized gzipped version 'exe-windows-i386-2048b.bin.305b.gz'
to the gluegen-rt jar file to reduce the payload for non Windows platforms.
Adding special property 'jogamp.debug.IOUtil.Exe' to debug testing the exe file,
enable via '-Djogamp.debug.IOUtil.Exe'.
Passes here on all Windows machines, however, the prev. one worked here as well.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Use InterruptSource.Thread.create(..),
while reducing InterruptSource.Thread ctors to 3 variants.
- Use InterruptSource.Thread instead of java.lang.Thread where possible
- Use SourcedInterruptedException where possible
- SingletonInstanceServerSocket: start(), stop() and run()
- Persistent-Wait and Cancelable
- Add @since 2.3.2
|
| | | |
|
| | |
| | |
| | |
| | | |
'jogamp.debug.JNILibLoader.Perf'
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
'natives/os.and.arch', reducing JAR search.
Since all native libraries are now contained within 'natives/os.and.arch',
we don't need to search the whole JAR file anymore
but simply can copy the content of the defined folder - if existing.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
PlatformPropsImpl.findSysLib(..).
This patch partially reverts of commit d12e4d4ea279998b27457691038e709879dcaca6.
NativeLibrary.open(..) requires search of system libraries,
since it loads the actual 'tool library' for which we generate the JNI binding.
The 'tool library' is preferably the system wide installed version,
e.g. libGL.so etc.
PlatformPropsImpl.findSysLib(..) also requires finding system libraries
as needed for PlatformPropsImpl.queryElfFile(..), i.e. using libjava.so etc.
Only the JNI 'glue library', glueing java calls to the 'tool library',
shall not use the system wide library search since we shall only use
JogAmp provided instances here.
This patch also reinstates binary compatibility w/ prev. GlueGen JARs
since NativeLibrary.enumerateLibraryPath(..) is public.
+++
Further more 'NativeLibrary.enumerateLibraryPath(..)'
now adds OSX system framework search _before_ the user path
in case 'searchSystemPath && searchSystemPathFirst'.
Original code always added this search to the end,
which does not match the intended behavior (-> bug).
|
| | |
| | |
| | |
| | | |
and bitCount(), add unit test (passed)
|
| | |
| | |
| | |
| | | |
tests
|
| | | |
|