| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
When annotations were placed on dummy Java variables, the annotation
processor was emitting a RenameJavaType directive into the gluegen
config file that caused the emitted file to be named boolean.java
instead of RenderingConfig.java or Pixel.java. Turned off this behavior
when jname is given in the @CStruct annotation. I'm uncertain how much
this processor is even used, since I can't find any occurrences of
@CStruct outside the test code for it in gluegen.
|
| |
|
| |
|
|
|
|
| |
compile time build
|
|
|
|
|
| |
The javah command was removed in Java 10, so now native headers must be
generated in javac instead.
|
|
|
|
| |
The old com.sun.tools.doclets.Taglet was removed, so had to move to new
API.
|
|
|
|
| |
Also update GNU/Linux and other platforms information to current OS versions and developer toolchains.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
relax closeLibrary(..)
|
| | |
|
| | |
|
| |
| |
| |
| | |
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
|
|
|
|
| |
executables
|
|
|
|
| |
for System related Operations
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Minimum supported Debian version is now Debian 9 or Stretch to minimize maintenance.
Note: No other GNU/Linux version has been validated so far.
|
|\ |
|
| | |
|
|\ \
| | |
| | | |
Use system property to detect Android
|
| | | |
|
|\ \ \
| | | |
| | | | |
Bug 682: Rename com.sun.gluegen -> com.jogamp.gluegen in doc/**
|
| | |/
| |/| |
|
|\ \ \
| | | |
| | | | |
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.
|
|\ \ \ \ |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
testing executable of temp dir
This also avoids trying to unpack the test executable on Windows,
which may cause a virus scanner to halt the process or otherwise cause issues.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
save mapped ByteBuffer memory
Also:
- fix dbgDump(..) FileChannel access, test if openend.
- add DEBUG dumps on CTOR, Close and notifyLengthChangeImpl
|