summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Bug 1417 - Android: Resulting dynamic libraries require the 'soname' to be ↵Sven Gothel2019-12-101-1/+4
| | | | | | set since API level 23 TODO: Do this for all JogAmp modules!
* Bug 1417 - Android: Manifest*-android* can no more have 'Name: <folder>' ↵Sven Gothel2019-12-102-9/+0
| | | | | | | | | 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.
* Bug 1417 - Android: Add new x86 MachineDataInfo, differs due to smaller ↵Sven Gothel2019-12-101-0/+3
| | | | 'long double' than regular x86_32_unix
* Bug 1417 - Android: Update cpptasks.jarSven Gothel2019-12-101-0/+0
| | | | | | | http://jogamp.org/git/?p=ant-cpptasks.git commit e1933c74b9c256332cd12c9a1094e4687b535112 Bug 1417 Android clang support: Introduce clangLinkerOption '-target <abi>'
* Bug 1417 - Android: Complete 1st round: ↵Sven Gothel2019-12-107-197/+199
| | | | | | | | | 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
* Bug 1417 - Android: Support building using current SDK and NDK v20 as of ↵Sven Gothel2019-12-106-145/+375
| | | | | | | | | | | | | | | 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)
* Bug 1412 - JNI: GlueGen JavaEmitter: Check & Handle Exception after calling ↵Sven Gothel2019-12-061-0/+7
| | | | | | | back into Java The generated JNI code JVMUtil_NewDirectByteBufferCopy(..) calls Buffers.newDirectByteBuffer(..) and potential exceptions should be checked.
* Scripts: Macos /opt-share -> /usr/local (Catalina Read-Only)Sven Gothel2019-12-023-9/+9
|
* Fix gluegen-cpptasks-base.xml for crosscompilation, failed due to unset ↵Sven Gothel2019-11-291-64/+69
| | | | | | | | | | | | 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.
* minor autocleanup (final removed from static)Sven Gothel2019-11-281-1/+1
|
* Bug 1363: Java 11: Extract and extend sun.misc.Unsafe functionality to ↵java11iosSven Gothel2019-09-042-28/+234
| | | | | | | | | | | | | | | UnsafeUtil UnsafeUtil centralizes the workarounds (hack) of certain Java>=9 modularization encapsulation pitfalls, where no exports have been defined. The last resort. 1) Buffers utilizes UnsafeUtil for Java>=9 invokeCleaner. 2) To gain access for certain methods + fields w/o 'illegal access warnings', we have to temporarily disable the IllegalAccessLogger. Hence we provide a method 'T doWithoutIllegalAccessLogger(..<T> action)' for our essential module access under Java >= 9.
* Fix JogAmp Next Release Number: 2.4.0Sven Gothel2019-09-041-1/+1
|
* Bug 1363: Java 11: Use new Android SDK 24 for Eclipse Android .classpathSven Gothel2019-09-041-1/+1
|
* Bug 1363: Java 11: Revert CStructAnnotationProcessor's ↵Sven Gothel2019-08-191-1/+1
| | | | | | | | | | | | | | | | | @SupportedSourceVersion back to 11 Behold, the issue as documented at commit 2d89df89453c099d4e357aa17eae88efcf1d1b70, one build machine failing to compile SourceVersion.RELEASE_11 was due to an incomplete installation of openjdk-11-jdk on Debian GNU/Linux. Wow. I have re-installed the openjdk-11-jre and openjdk-11-jdk packages on said machine, ensured they are being used .. and it works. Another note here regarding usage of OpenJDK11 compile time environment and Java8 target. If using Eclipse, I had to set the system runtime JDK to JDK 8. Otherwise the 'editor clean-up' jobs would run against the JDK 11 classes and wrongly so change certain type castings etc, incompatible with Java 8. If anybody knows a solution here .. shoot.
* Bug 1363: Java 11: Document Java8 target constraints; Fix one odd compile issueSven Gothel2019-08-193-1/+8
| | | | | | | | | | | | | | 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 ..
* Windows Regression: Mingw64 8.1.0 using statical linked tool lib ↵Sven Gothel2019-08-196-16/+293
| | | | | | | | | | | | | | | | | | | 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.
* Bug 1363: Java 11: Refine Build and Runtime requirements. Fix Java compiler ↵Sven Gothel2019-08-191-9/+16
| | | | | | | 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).
* Bug 1363: Java 11: Resolve Buffers.Cleaner implementationSven Gothel2019-08-194-13/+68
| | | | | | | | | | | As of Java9, sun.misc.Cleaner has moved to jdk.internal.ref.Cleaner. However, access has been made (under the table) via sun.misc.Unsafe, which we are using for now as we cannot set the jdk.internal.ref.Cleaner method accessible. In this regard, we had to change our Cleaner.clean(..) method using a ByteBuffer instead of a Buffer object paramter. All tests have passed, no more illegal access case running on Java11 has been exposed.
* Build Update: CMake 2.8.10.2 -> 3.15.2 (Windows + MacOS), Mingw64 4.8.1 -> 8.1.0Sven Gothel2019-08-187-31/+39
|
* Bug 1363: Java 11: Complete renaming JEP 178 compatible native lib basename ↵Sven Gothel2019-08-187-9/+9
| | | | | | | | | | gluegen-rt -> gluegen_rt - Fix finding native library for Elf parsing - Fix one unit test - Fix comments Completes commit 330dad069dee5a0cc0480cf5cd9052000004223a
* Bug 1363: Java 11: Adopt java.lib.dir.platform changes to ↵Sven Gothel2019-08-184-4/+20
| | | | make/lib/gluegen-cpptasks-*
* Bug 1363: Java 11: Java version must be 11 or greater; Fix HowToBuild: Give ↵Sven Gothel2019-08-182-16/+27
| | | | detailed build commandline.
* Bug 1363: Java 11: Fix javadoc invocation, drop -source <release> for ↵Sven Gothel2019-08-183-6/+29
| | | | | | | | | | | | | | | | | 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.
* Update HowToBuild (gawk) and windows test scriptsSven Gothel2019-08-183-9/+20
|
* build.xml: Explicitly issue 'clean-temp' at start and in the end of default ↵Sven Gothel2019-08-181-7/+20
| | | | | | | 'all*' targets. This shall ensure that build-temp gets deleted before and after build, removing the transitionary previous build state.
* MacOS shall only scan for .dylib, dropping .jnilib search in NativeLibrarySven Gothel2019-08-181-5/+0
|
* iOS: Fix native symbol generation for WindowsSven Gothel2019-08-181-1/+2
| | | | Regression from commit 8ce56955f989f0d8ac21335ea563f9c7eb111154
* Bug 1363: Java 11: Align gluegen-cpptask-custom.xml template to commit ↵Sven Gothel2019-08-181-1/+5
| | | | f54e4fbaebfec36bd3b523dc4e23f744e8e6a4ef
* Bug 1363: Java 11: Refine 'java.home.dir' and 'java.lib.dir.platform' setup ↵Sven Gothel2019-08-181-37/+117
| | | | | | | | | | | | | | | | | | | | 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.
* Fixed JRE path for Linux AMD64 to work for Java 11Wade Walker2019-08-171-1/+1
|
* Fixed minor Ant buildfile consistency issuesWade Walker2019-08-172-1/+2
| | | | These were flagged as errors by Eclipse, and appear legitimate, but didn't make the command line build fail.
* Fixed java.home directory and removed obsolete tools.jarWade Walker2019-08-165-33/+21
| | | | | | 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.
* Fixed CStruct annotation processor to not use dummy Java variable typesWade Walker2019-08-162-2/+2
| | | | | | | | | 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.
* Fixed null pointer exception in logging printWade Walker2019-08-161-1/+4
|
* Fix warning in annotation processorWade Walker2019-08-161-1/+1
|
* Bug 1363: Java 11: build.xml fix some comments, javah replacement move and ↵Sven Gothel2019-08-161-12/+7
| | | | compile time build
* Fixed native header generation so it doesn't use javahWade Walker2019-08-161-8/+7
| | | | | The javah command was removed in Java 10, so now native headers must be generated in javac instead.
* Ported NativeTaglet to jdk.javadoc.doclet.TagletWade Walker2019-08-161-79/+66
| | | | The old com.sun.tools.doclets.Taglet was removed, so had to move to new API.
* Bug 1363: Java 11: HowToBuild UpdateSven Gothel2019-08-161-33/+55
| | | | Also update GNU/Linux and other platforms information to current OS versions and developer toolchains.
* Bug 1363: Java 11: Mod scripts for OpenJDK11 usageSven Gothel2019-08-1629-195/+137
|
* Merge branch 'java11'Sven Gothel2019-08-1619-554/+53
|\
| * Bug 1363: Java 11: Initial Host/Target Compiler Selection: Java8Sven Gothel2019-06-1319-554/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | iOS: NativeLibrary: Refine iOS, use proper alt system path for iOS+OSX, ↵Sven Gothel2019-06-214-36/+48
| | | | | | | | relax closeLibrary(..)
* | iOS: Generalize building the native symbols file via macroSven Gothel2019-06-212-16/+25
| |
* | iOS: Bump required iOS default version to 11.0Sven Gothel2019-06-201-4/+4
| |
* | Update cpptask.jar to commit 18e04a2fb9c2a3556040091213f82fc570bc5736Sven Gothel2019-06-173-8/+5
| | | | | | | | and comment-out verbose OSX compiler/link flags, as well as removing one dead linker cfg target.
* | Bug 1363: Java 11: Recognize Java9+ ..; Support JEP 178 static linkage ↵Sven Gothel2019-06-177-17/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | iOS: Initial iOS support commit: build.xml targets, java code-path etcSven Gothel2019-06-1714-29/+298
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | Update cpptask.jar to commit 757192655df20cc6a68affe8cbb4d7de387c9c67Sven Gothel2019-06-173-2/+3
|/ | | | | | 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.
* Update CSS; Add responsive viewport design tagSven Gothel2019-05-062-0/+4
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 04:38:10 +0000