| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
make/stub_includes/platform/glibc-compat-symbols.h" ensuring using low versioned GLIBC symbols
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
'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
|
|
|
|
| |
detection ; echo 'gcc.compat.compiler'
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
WINVER/_WIN32_NT 0x0601
|
|
|
|
| |
'clang']; Use 'gcc.compat.compiler' for all gcc based compiler/linker definitions.
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
| |
property, allowing to trigger x86_64 -> x86_32 crosscompilation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 :)
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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" />
|
|
|
|
| |
Solaris x86* requires stdlib.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'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
|
|
|
|
|
|
|
| |
from build.xml -> gluegen-cpptasks-base.xml
- unifies definition
- echo values
|
|
|
|
|
|
| |
gluegen-cpptasks-linux-armv7.xml
Env: GLUEGEN_CPPTASKS_FILE -> property: gluegen-cpptasks.file
|
|
|
|
| |
196c325aa3dddb0d775e8fb80e26333208fe6c7e) - generalize env. TARGET_JAVA_LIBS
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
for compiler/linker.
As Wade Walker suggests, use '-mmacosx-version-min=10.5' compiler/linker flag,
which doesn't break 10.6 nor 10.7 builds, still need confirmation whether it
works on 10.5!
|
| |
|
|
|
|
| |
dummy-value properly
|
| |
|
|
|
|
| |
-isystem (which come after -I)
|
|
|
|
| |
reducing the burden to add a license file etc.
|
|
|
|
| |
resolution
|
|
|
|
|
|
|
|
|
|
|
| |
- android minor build fix
- started dex'ing (gluegen-rt.apk, more to come for full junit tests)
- android remote dalvikvm launch works (crosstest-java-android-armv7-rel.sh)
- android detection, incl version (reflection)
- Platform:
- Add JAVA_VM_NAME and JAVA_VM_RUNIME
- OSType maybe ANDROID, where the OS name (String) is Linux ! (ok ?)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- linux-armv7 (ubuntu)
- added scripts/make.gluegen.all.linux-armv7-cross.sh
- added symbolic links to cross toolchain (gcc, ld, ..)
allowing gluegen's cpptask to pick it up
- android-armv7 (android)
- we have scripts/make.gluegen.all.android-armv7-cross.sh
|
|
|
|
| |
linux-x86_32 spec. removed android props, we use custom xml files
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Platform:
- enum CPUFamily is part of CPUType
- DALVIK -> ANDROID
- ARM: ARM + ARMv[567]
MachineDescription
- self contained
- static size/alignment Config (enum) for unix32, unix64, win32, win64 and armeabi
- add 'long double'
- Removed MachineDescription32Bit, MachineDescription64Bit
- createStatic(..) uses OS/CPU to fetch best match if not at runtime
FIXES: JavaEmitter's struct-emit: Proper 32/64 struct sizes
TODO: StructAccessor's mapping to <Type>Buffer w/ index os sizeof(<Type>)
doesn't work, since offset may not be multiple of sizeof(<Type>)!
i.e.
typedef struct {
int8_t bits1; // +1 - 0
// +3 (p32)
int32_t id; // +4 - 4
int8_t bits2; // +1 - 8
// +3 (p32) -
int64_t long0; // +8 - 12
so "longBuffer.get(<type-sized index>)" is invalid,
but "byteBuffer.getLong(<byte index>)" must be done.
The actual impl. doesn't matter, hence dropping the other nio type mappings is good.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Preparation.
Currently GlueGen fails for type long (size) and some alignments (see package.html).
- The size and alignment values shall be queried at runtime.
- Compound alignment needs to follow the described natural alignment (also @runtime).
-
- Build
- add Linux Arm7 (EABI)
- junit test
- added compound/struct tests, pointing out the shortcomings of current impl.
- package.html
- Added alignment documentation
- remove intptr.cfg
- add GluGen types int8_t, int16_t, uint8_t, uint16_t
- move MachineDescription* into runtime
- Platform
- has runtime MachineDescription
- moved size, .. to MachineDescription
- use enums for OSType, CPUArch and CPUType defined by os.name/os.arch,
triggering exception if os/arch is not supported.
This avoids Java String comparison and conscious os/arch detection.
- MachineDescription:
- compile time instances MachineDescription32Bits, MachineDescription64Bits
- runtime queried instance MachineDescriptionRuntime
- correct size, alignment, page size, ..
|
|
|
|
|
| |
- /System/Library/Frameworks/JavaVM.framework/Headers/ Java 10.6 Update 4
- /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Headers/ Prev. Version
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
appropriate for all.
|
| |
|
|
|
|
| |
sake of clarity)
|
| |
|
|
|
|
| |
isFreeBSDAMD64
|
|
|
|
|
|
|
|
|
| |
mingw linker option: --enable-stdcall-fixup
mingw x86: link against JVM lib file, due to unresolved symbol:
JAWT.dll x32: _JAWT_GetAWT@8 (stdcall)
JAWT.dll x64: JAWT_GetAWT (clean)
Looks like the stdcall fixup doesn't work ..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- mingw linker option: --enable-auto-import
- mingw now links against DLLs not libs,
due to a runtime error while linking against JAWT
x86: Using mingw 20100514, gcc 4.5.0
- clean
- passed all junit.run tests
x86_64: Using mingw-w64-bin_x86_64-mingw_20100515_sezero.zip, gcc 4.4.5 20100513
- clean
- passed all junit.run tests
|
|
|
|
|
|
|
|
|
|
| |
x86: Using mingw 20100514, gcc 4.5.0
- clean
- passed all junit.run tests
x86_64: Using mingw-w64-bin_x86_64-mingw_20100515_sezero.zip, gcc 4.4.5 20100513
- clean
- passed most junit.run tests, still buggy
|