summaryrefslogtreecommitdiffstats
path: root/make
Commit message (Collapse)AuthorAgeFilesLines
* 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-106-196/+197
| | | | | | | | | 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)
* 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.
* Fix JogAmp Next Release Number: 2.4.0Sven Gothel2019-09-041-1/+1
|
* Bug 1363: Java 11: Document Java8 target constraints; Fix one odd compile issueSven Gothel2019-08-192-0/+7
| | | | | | | | | | | | | | 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-195-16/+22
| | | | | | | | | | | | | | | | | | | 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).
* Build Update: CMake 2.8.10.2 -> 3.15.2 (Windows + MacOS), Mingw64 4.8.1 -> 8.1.0Sven Gothel2019-08-185-15/+19
|
* 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-181-9/+1
| | | | 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-182-6/+8
|
* 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.
* 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-171-0/+1
| | | | 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-162-20/+9
| | | | | | 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.
* 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.
* 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: 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-172-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-176-18/+250
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* build.xml:gluegen.build.native: Place unsetting into the conditional .impl ↵Sven Gothel2019-04-101-2/+4
| | | | | | target like gluegen.build.java.impl, as the .impl may be skipped.
* Complete jogamp-env.xml TARGET_* readout; Use parsed env in cpptasks-base as ↵Sven Gothel2019-04-082-2/+14
| | | | well
* Bug 1190: Define TARGET_PLATFORM_SYSROOT TARGET_PLATFORM_USRROOT ↵Sven Gothel2019-04-0812-20/+42
| | | | | | | | | | | | | 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
* Bug 1190: aarch64 + armhf ld symbolic link to actual x-tool binary of ld.bfdSven Gothel2019-04-082-2/+2
|
* Bug 1190: Fix arm6hf + aarch64 gcc options, adapt glibc-compat-symbols.hSven Gothel2019-04-079-146/+28
| | | | | | - 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
* Bug 1190: Updating crosstools and enabling aarch64 + armv6hf 'ontarget'Sven Gothel2019-04-0726-24/+141
| | | | | | | 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
* Bug 1369: SCC: Clarify & fix build dependencies in build.xmlSven Gothel2019-04-031-9/+26
| | | | | | | | | | | | | | | | | | | 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
* Bug 1369: SCC: Hide SHA Algorithm bit size in literals of SpecificationSven Gothel2019-04-039-90/+90
| | | | | 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'.
* Bug 1367: TempJarCache: Fix Unit Test using ReflectionsSven Gothel2019-04-031-2/+2
|
* OpenJDK8 Script Usage: Linux: Favor Debian default; Windows: Use AdoptOpenJDK8Sven Gothel2019-04-037-11/+31
|
* Bug 1369: Source Certification Contract (SCC): Initial SHA256 fingerprint & ↵Sven Gothel2019-04-039-56/+249
| | | | | | | | | | | | | | | | | | | | | 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
* Bug 1316: MacOSX: Keep *.dylib (Don't move to *.jnilib)Sven Gothel2019-03-304-22/+4
| | | | | | | | 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.
* Merge branch 'master' of git://github.com/pini-gh/gluegen into pini-gh-masterSven Gothel2019-03-263-3/+92
|\
| * Support architecture ppc64le (Debian ppc64el).Gilles Filippini2015-10-283-3/+92
| |
* | Merge pull request #25 from ghost/masterSven Gothel2019-03-266-1/+216
|\ \ | | | | | | adding support for android x86 targets - revised
| * | added android x86 support.Xavier Hallade2015-02-166-1/+216
| | |
* | | Bug 1219, Bug 1231: Re-add executable test by executionSven Gothel2019-03-253-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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'.
* | | Bug 1219, Bug 1231: Avoid deflating test-exe on Windows using ↵Sven Gothel2019-03-241-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 02:37:54 +0000