| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
scales better for all platforms.
http://jogamp.org/git/?p=ant-cpptasks.git
commit 8353e0cc85705ca8f81f8563ad975026978b6745
|
|
|
|
|
|
| |
set since API level 23
TODO: Do this for all JogAmp modules!
|
|
|
|
|
|
|
|
|
| |
directives for apk
The 'Name <folder>' leads new apk to claim the missing resources (the folder actually)
and fails to install the apk.
Hence removed tagging the folders sealed.
|
|
|
|
|
|
|
| |
http://jogamp.org/git/?p=ant-cpptasks.git
commit e1933c74b9c256332cd12c9a1094e4687b535112
Bug 1417 Android clang support: Introduce clangLinkerOption '-target <abi>'
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
supposedly detected mandatory new properties
Move new detected build properties build.dynamiclibs, build.staticlibs and output.lib.type
from gluegen.cpptasks.detect.os.1 to gluegen.cpptasks.detect.os.
This enables setting these mandatory properties always, as gluegen.cpptasks.detect.os.1 gets overriden
by custom cross-compilation configurations.
Also moving the property dump from gluegen.cpptasks.detect.os.1 to gluegen.cpptasks.detect.os
for same reasons.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document Java8 target constraints, i.e. where we need to set source, target and bootclasspath
to ensure target runtime Java8 compliance.
Fix one odd compile issue!
Using two theorethical identical GNU/Linux Debian 10 machines with same set of installed software,
one passes (like MacOS, Windows) and one fails.
The failure was due to the CStructAnnotationProcessor's @SupportedSourceVersion tag.
This downgrades the SourceVersion's previous bump from 6->11 (commit 610493b1724b5d91327f478338ff5d029bdcc032)
down to 8.
Interesting times ..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
test.
We allow java [8-10] to pass even thought we require java 11 or greater.
This gives us the opportunity to run the junit tests on a java 8 VM (tested).
|
| |
|
|
|
|
| |
make/lib/gluegen-cpptasks-*
|
|
|
|
| |
detailed build commandline.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
'all*' targets.
This shall ensure that build-temp gets deleted before and after build,
removing the transitionary previous build state.
|
|
|
|
| |
Regression from commit 8ce56955f989f0d8ac21335ea563f9c7eb111154
|
|
|
|
| |
f54e4fbaebfec36bd3b523dc4e23f744e8e6a4ef
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for traditional layout and JEP 220(Java 9+)
JEP 220 states it is now optional to use the <arch> subfolder in 'lib' to store native libraries,
i.e. 'lib/<arch>/libjava.so' can be flattened to 'lib/libjava.so'.
Further the jre subfolder is no more used according to the JEP 220, however, it can be used.
Therefor we scan for 'java.home.dir' in the following order:
- if '<java.home>/../jre' exists, i.e. we are within the 'jre' folder, use '<java.home>/..'.
- otherwise assume <java.home> reflect the flattened actual base folder and use it as is.
We scan for 'java.lib.dir.platform' in the following order:
- if exists <java.home>/jre/lib/i386/libjava.so -> <java.home>/jre/lib/i386
- if exists <java.home>/lib/i386/libjava.so -> <java.home>/lib/i386
- defaults to flattened <java.home>/lib
This way we keep the historical arch information for each platform
and stay most flexible for any SDK build layout.
|
| |
|
|
|
|
| |
These were flagged as errors by Eclipse, and appear legitimate, but
didn't make the command line build fail.
|
|
|
|
|
|
| |
In Java 9+, there's no longer a "jre" directory in the installation, so
removed references to it. The tools.jar file also no longer exists in
Java installations (it's now stored in a secret non-JAR format), so
removed that as well.
|
|
|
|
| |
compile time build
|
|
|
|
|
| |
The javah command was removed in Java 10, so now native headers must be
generated in javac instead.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |
| |
| |
| | |
and comment-out verbose OSX compiler/link flags, as well as removing one dead linker cfg target.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
libgluegen-rt[.so] -> libgluegen_rt[.so|.a]
Recognize Java9+ ..
- Recognize new Java9+ version string as of JEP 223
- Avoid Classpath's private findLibrary call
+++
Support JEP 178 static linkage (OpenJDK 1.8)
- Need to change native library basename: libgluegen-rt[.so] -> libgluegen_rt[.so|.a]
since the dash '-' is not supported in a ANSI-c function name.
- Added 'JNI_OnLoad_gluegen_rt' to recognize statical linked JNI code
- Added JNI_VERSION_1_8 to jni/jni.h
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
| |
Added CC Task Option: 'usehighleveltool' to give user option to
prefer the high-level tool like gcc or clang for static linkage
where usually 'ar' is being used.
|
|
|
|
|
|
| |
target
like gluegen.build.java.impl, as the .impl may be skipped.
|
|
|
|
| |
well
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clean 'base.compile' order w/ matching build -> package tuples,
having gluegen.build.shasum after the last actual build
and before packaging.
- init,
- android-launcher.build,
- gluegen.build.java,
- gluegen.build.native,
- gluegen.build.shasum,
- gluegen.package.java,
- gluegen.package.native,
- android-launcher.package
Further properly utilize a 'gluegen.package.*.done' property,
corresponding with the 'gluegen.build.skip.*' property.
Drop 'build.javaonly' gluegen.build.native exclusion
|
|
|
|
|
| |
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.
|