summaryrefslogtreecommitdiffstats
path: root/make/gluegen-cpptasks-base.xml
Commit message (Collapse)AuthorAgeFilesLines
* MacOS: Add fat universal build w/ x86_64 + aarch64; Bump min SDK version >= 11.0Sven Gothel2023-01-141-2/+6
|
* native.tag.jar: Revert explicit inclusion of *.symbols file -> implicit ↵Sven Gothel2020-01-041-3/+18
| | | | | | | inclusion/exclusion based on build.dynamiclibs Exclude *.symbols files implicitly when building 'build.dynamiclibs' and include *.symbols files implicitly when not building 'build.dynamiclibs' (static libs)
* native.tag.jar: include *.symbolsSven Gothel2020-01-021-0/+1
|
* 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.
* iOS: Fix native symbol generation for WindowsSven Gothel2019-08-181-1/+2
| | | | Regression from commit 8ce56955f989f0d8ac21335ea563f9c7eb111154
* 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-161-18/+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.
* Merge branch 'java11'Sven Gothel2019-08-161-9/+1
|\
| * Bug 1363: Java 11: Initial Host/Target Compiler Selection: Java8Sven Gothel2019-06-131-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-211-0/+19
| |
* | iOS: Bump required iOS default version to 11.0Sven Gothel2019-06-201-4/+4
| |
* | Update cpptask.jar to commit 18e04a2fb9c2a3556040091213f82fc570bc5736Sven Gothel2019-06-171-4/+5
| | | | | | | | and comment-out verbose OSX compiler/link flags, as well as removing one dead linker cfg target.
* | iOS: Initial iOS support commit: build.xml targets, java code-path etcSven Gothel2019-06-171-7/+129
|/ | | | | | | | | | | | 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
* Complete jogamp-env.xml TARGET_* readout; Use parsed env in cpptasks-base as ↵Sven Gothel2019-04-081-2/+2
| | | | well
* Bug 1190: Fix arm6hf + aarch64 gcc options, adapt glibc-compat-symbols.hSven Gothel2019-04-071-3/+11
| | | | | | - 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 1316: MacOSX: Keep *.dylib (Don't move to *.jnilib)Sven Gothel2019-03-301-1/+0
| | | | | | | | 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-261-2/+55
|\
| * Support architecture ppc64le (Debian ppc64el).Gilles Filippini2015-10-281-2/+55
| |
* | Merge pull request #25 from ghost/masterSven Gothel2019-03-261-1/+13
|\ \ | | | | | | adding support for android x86 targets - revised
| * | added android x86 support.Xavier Hallade2015-02-161-1/+13
| | |
* | | Bug 1295: Add linux-aarch64 GNU/Linux AArch64 supportXerxes Ranby2016-12-111-1/+1
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | Bug 1172: Use the same in-jar folder structure for native jars as the fat-jarXerxes Rånby2015-08-121-1/+3
| |
* | GCC Linker Config: Add '-static-libstdc++' in case libstdc++ is being linkedSven Gothel2015-07-191-0/+13
| | | | | | | | | | Linking libstdc++ dynamically might cause issues on platforms where a huge variation of named library exists - or none even is installed.
* | Use GlueGen's JNI header for native compilation (java.includes.dir, ↵Sven Gothel2015-07-141-26/+12
|/ | | | | | | | java.includes.dir.platform) Using the same cross-platform JNI header for native compilation as for GlueGen code generation allows using a more determined (well defined) and simplified environment.
* Fix regression of commit 3caf446e29a3934900b9983dfd72cb8aa0d9e8d7: Win64 is ↵Sven Gothel2015-02-031-2/+0
| | | | not LP64
* Bug 1126 - Remove static query requirement of MachineDescriptor, find ↵Sven Gothel2015-02-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | matching StaticConfig at runtime; Fix PPC (Bug 1056) and MIPSLE (Bug 1014) issues. Currently the StaticConfig is being queried via the key[OSType, CPUType ..] as pre-determined by Java properties or the ELF parser. This adds complication to maintain different platforms and the key query might not even be sufficient. The MachineDescriptor's StaticConfig only purpose shall be to speed-up native data size and offset/alignment retrieval. This is done by using the StaticConfig index within all StaticConfig[]s as a lookup-index for the precomputed struct's size and offset tables. +++ Solution: Rename: MachineDescriptor -> MachineDataInfo Rename: MachineDescriptorRuntime -> MachineDataInfoRuntime After having defined os.and.arch (OSType, CPUType and ABIType) w/ the optional help of the now self containing ELF Reader (Bug 1125), the native gluegen-rt library gets loaded enabling JNI methods. It is satisfactory to retrieve MachineDataInfo at runtime w/ JNI and find the matching/compatible StaticConfig. Only in case none is found, the program needs to abort. Otherwise the found MachineDataInfo.StaticConfig and MachineDataInfo are stored for further use (see above). This removes above complication and key to StaticConfig mapping. New platforms simply need to add a new unique entry into the StaticConfig[] table. ++ Also fixes Bug 1056 (PPC), thanks to tmancill [@] debian [.] org, and Bug 1014 (MIPSLE), thanks to Dejan Latinovic. Parts of the patch for Bug 1014 from Dejan Latinovic are included. also solved by this change set.
* Bug 1122: Reflect __LP64__ and _aarch64__ in GlueGen's stdint/stddef and ↵Sven Gothel2015-01-301-0/+9
| | | | Android compilerflags
* Bug 1122: Add AArch64 support (Android, GNU/Linux and in general)Sven Gothel2015-01-301-3/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add AArch64 detection via - Elf Parser - Android properties - Java properties - Android: Validate CPUType.Family _and_ ABIType - MachineDescription - Remove redundant Type ID and its field - Reuse X86_64_UNIX for AArch64 (static config) New ARCH 'aarch64' for ant: <os arch> armv8a aarch64 New CPUType.ARM64 (ARM): java: os.arch aarch64 arm64 New CPUType.ARMv8_A (ARM): java: os.arch armv8-a arm64-v8a New ABIType: EABI_AARCH64
* gluegen-cpptasks's compiler.cfg.linux.*: always "-include ↵Sven Gothel2014-07-301-0/+8
| | | | make/stub_includes/platform/glibc-compat-symbols.h" ensuring using low versioned GLIBC symbols
* Bug 1024: Add fallback for native-jar-file location via classpathSven Gothel2014-07-111-1/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In situations, where the native-jar file is not located within the same parent URI as it's java-jar file, our location mechanism fails. This patch adds a classloader based native-jar file location mechanism as a fallback, requiring the native jar file to be included in the users CLASSPATH. Classloader based location algorithm in JNILibLoaderBase.addNativeJarLibsImpl(..): - Extract the 'module-name' from the given classFromJavaJar's package name, i.e. the last package-part: 'jogamp.common.Debug' -> 'common' Hence it is important to pass a 'classFromJavaJar', which last package segment reflects the module-name! - <os.and.arch> -> <os_and_arch_dot>, e.g. linux-amd64 -> linux.amd64 (linux/amd64) - Locate class 'jogamp.nativetag.<module-name>.<os_and_arch_dot>.TAG', e.g. 'jogamp.nativetag.common.linux.amd64.TAG' - Use located class's JarFile URI .. continue as usual Injection of above mentioned TAG class via gluegen-cpptasks-base.xml macro 'native.tag.jar': - Creates dummy TAG.java code - Compiles TAG.java - Creates the native-jar file Example: <native.tag.jar objdir="${build}/obj" nativejarfile="${build}/gluegen-rt-natives-${os.and.arch}.jar" manifestfile="${build}/Manifest-rt-natives.temp" module="common" includelibs="*gluegen-rt.${native.library.suffix}" /> Note that the manifest file uses a matching Extension-Name: Extension-Name: jogamp.nativetag.common
* Use 'gluegen-clang.properties' for generic clang and ↵Sven Gothel2013-11-171-2/+2
| | | | | | | | 'gluegen-xcode_clang.properties' for OSX xcode-clang ; Add GNU/Linux LLVM/clang build scripts Use 'gluegen-clang.properties' for generic clang and 'gluegen-xcode_clang.properties' for OSX xcode-clang. Add GNU/Linux LLVM/clang build scripts
* Bug 871 - Add optional xcode.clang support for all modules: Fix 'isCLANG' ↵Sven Gothel2013-10-251-1/+5
| | | | detection ; echo 'gcc.compat.compiler'
* Fix Bug 871 - Add optional xcode.clang support for all modules (Extends Bug ↵Sven Gothel2013-10-241-0/+1
| | | | | | | | | | 837 w/ xcode's xcrun) Bump make/lib/cpptasks.jar to a65cc99054a5a6684784bf9a9e8c13fe866b81ad make/lib/gluegen-clang.properties: Defaults to xcode.clang make/jogamp-env.xml: Show env. SDKROOT
* Bug 800 - Add Windows 8 Touch Event Support / Enable Win 7 definitions via ↵Sven Gothel2013-10-131-4/+4
| | | | WINVER/_WIN32_NT 0x0601
* Add clang support: 'gluegen.properties' adds 'gcc.compat.compiler' = ['gcc', ↵Sven Gothel2013-09-131-45/+55
| | | | 'clang']; Use 'gcc.compat.compiler' for all gcc based compiler/linker definitions.
* Fix Bug 650: Use toolchain default arch & float options for default arm ↵Sven Gothel2013-04-231-6/+8
| | | | | | | | cc/ld target in make/gluegen-cpptasks-base.xml Specialized arch & float arm options are defined in - lib/gluegen-cpptasks-linux-armv6.xml (armv5te + softfp), or - lib/gluegen-cpptasks-linux-armv6hf.xml (armv6 + hardfp)
* make/gluegen-cpptasks-base.xml: Expose evaluated 'isI386' and 'isAMD64' ↵Sven Gothel2013-04-201-26/+24
| | | | property, allowing to trigger x86_64 -> x86_32 crosscompilation.
* OSX/Java7 darwin/jawt_md.h Workaround ; Disable OSX/i386 if compiled w/ ↵Sven Gothel2013-02-171-4/+20
| | | | | | | | | | | | | | Java7 [1.7 - 2.0]; Valid Java range [1.6 - 2.0]. - OSX/Java7 darwin/jawt_md.h Workaround Include JOGL's JNI MacOSX platform headers, since Oracle's Java7 darwin/jawt_md.h has X11 dependencies and does not define JAWT_SurfaceLayers. - Disable OSX/i386 if compiled w/ Java7 [1.7 - 2.0] Set macosx32 depending on 'ant.java.version' - Valid Java range [1.6 - 2.0] Foresee new Java versions 1.9 and 2.0 :)
* OSX Java6/Java7: Adapt to used JDK (Apple's Java6 or Oracle's Java7)Sven Gothel2013-02-171-16/+31
| | | | | | | | | | | | - Pick-up OSX Java7 locations if setup via ${java.home} and files available - host.rt.jar, target.rt.jar - java.home.dir - java.includes.dir - java.includes.dir.platform - java.lib.dir.platform - Remove 'very old' Java4/5 OSX locations - Remove java.osx.frameworks.dir, since JavaNativeFoundation.h dependencies are removed
* Adding gcc linker cfg: '-static-libgcc' for all def. build platforms:Sven Gothel2012-10-131-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | - linker.cfg.linux - linker.cfg.linux.x86 - linker.cfg.linux.amd64 - linker.cfg.linux.armv6 - linker.cfg.solaris - linker.cfg.solaris.spacv9 - linker.cfg.solaris.amd64 - linker.cfg.macosx - linker.cfg.linux64.mingw64 - linker.cfg.linux64.mingw32 - linker.cfg.win32.mingw32 - linker.cfg.win32.mingw64 - android.armv6 - android.armv7 - linux.armv6 - linux.armv6hf These flags shall now go through autobuild and results will be validated, i.e.: - working - memory footprint
* Change/Lower ARM Requierements for GNU/Linux & Android-GNU/Linux ARM: ↵Sven Gothel2012-08-161-44/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ARMv7hf -> ARMv6hf, ARMv7-soft -> ARMv5te/ARMV6 (soft) platform build config files: lib/gluegen-cpptasks-linux-armv7.xml -> lib/gluegen-cpptasks-linux-armv6.xml lib/gluegen-cpptasks-linux-armv7hf.xml -> lib/gluegen-cpptasks-linux-armv6hf.xml properties: isLinuxARMv7 -> isLinuxARMv6 isLinuxARMv7Armel -> isLinuxARMv6Armel isLinuxARMv7Armhf -> isLinuxARMv6Armhf isAndroidARMv7 -> isAndroidARMv6 isAndroidARMv7Armel -> isAndroidARMv6Armel isAndroidARMv7Armhf -> isAndroidARMv6Armhf targets: compiler.cfg.linux.armv7 -> compiler.cfg.linux.armv6 linker.cfg.linux.armv7 -> linker.cfg.linux.armv6 compiler.cfg.linux.armv6: <compilerarg value="-fpic" /> <compilerarg value="-march=armv5te" /> <compilerarg value="-marm" /> <compilerarg value="-mfloat-abi=softfp" /> <linkerarg value="-fpic" /> <linkerarg value="-march=armv5te" /> <linkerarg value="-marm" /> <linkerarg value="-mfloat-abi=softfp" /> <linkerarg value="-nostdlib" /> <linkerarg value="-Bdynamic" /> compiler.cfg.linux.armv6hf: <compilerarg value="-fpic" /> <compilerarg value="-march=armv6" /> <compilerarg value="-marm" /> <compilerarg value="-mfloat-abi=hard" /> <linkerarg value="-fpic" /> <linkerarg value="-march=armv6" /> <linkerarg value="-marm" /> <linkerarg value="-mfloat-abi=hard" /> <linkerarg value="-nostdlib" /> <linkerarg value="-Bdynamic" /> gluegen-cpptasks-android-armv6.xml: <compilerarg value="-fpic" /> <compilerarg value="-march=armv6" /> <compilerarg value="-mfloat-abi=softfp" /> <compilerarg value="-marm" /> <linkerarg value="-march=armv6" /> <linkerarg value="-mfloat-abi=softfp" /> <linkerarg value="-marm" /> <linkerarg value="-nostdlib" /> <linkerarg value="-Bdynamic" />
* Partially revert commit 5efbe805c553a2ac21a79386c3e2147858d4308b - Linux / ↵v2.0-rc6Sven Gothel2012-04-191-30/+0
| | | | Solaris x86* requires stdlib.
* Relaxed Unix linker flags for Linux + Solaris ; Refined Linux Armv4 flagsSven Gothel2012-04-191-14/+44
| | | | | | | | | | | | | | Relaxed Unix linker flags for Linux + Solaris + <linkerarg value="-nostdlib" /> + <linkerarg value="-Bdynamic" /> Refined Linux Armv4 flags: - <compilerarg value="-msoft-float" /> + <compilerarg value="-marm" /> + <compilerarg value="-mfloat-abi=soft" /> Xerxes figured out these are required on pre-NEON and ARMv4 soft float boards, the latter is true for Rasperry PI at least.
* Fix EABI Armel/Armhf selection incl. os.and.archSven Gothel2012-03-281-25/+53
|
* Add support for armhf/gnueabihf resulting in new 'os.and.arch' := [ ↵Sven Gothel2012-03-281-2/+30
| | | | | | | | | | | | | | | | 'android-armv7hf' and 'linux-armv7hf' ] - Platform gets new ABIType [ GENERIC, ARMEL, ARMHF ] - Platform impl. needs to guess ABIType in case of ARM, since no Java system property ('os.arch' ..) reflects the new EABI. I consider this a bug, since this will also hinder JNLP to work. The latter also uses 'os.arch' sys property to determine the nativelib resource! (See Platform.guessABITypeImpl(..) for details how we guess the type.) - Adding symbolic links to ubuntu's gnueabihf cross tool chain - Adding armhf crossbuild script
* build: Move c.compiler.debug, c.compiler.use-debug and c.compiler.optimise ↵Sven Gothel2012-03-071-0/+7
| | | | | | | from build.xml -> gluegen-cpptasks-base.xml - unifies definition - echo values
* Exposing custom gluegen-cpptask.file for crosscompilation presets, adding ↵Sven Gothel2012-02-241-1/+12
| | | | | | gluegen-cpptasks-linux-armv7.xml Env: GLUEGEN_CPPTASKS_FILE -> property: gluegen-cpptasks.file
* Fix [linux] armv7 cross build (regression of commit ↵Sven Gothel2012-02-191-1/+10
| | | | 196c325aa3dddb0d775e8fb80e26333208fe6c7e) - generalize env. TARGET_JAVA_LIBS
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-16 23:09:12 +0000