| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed junit test: test1
- Create seperate native libraries to reflect a real world example:
test1 - the library to bind to (no more declaring __stdcall @nn functions)
BindingTest1p1 - the dynamic fixed linkage binding test1p1,
references dynamic library test1 at linktime.
BindingTest1p2 - the dynamic runtime linkage binding test1p2,
loads dynamic library test1 at runtime.
Generic:
- gluegen-cpptasks-base.xml
- target 'gluegen.cpptasks.detect.os'
Set new property 'system.env.library.path'
DYLD_LIBRARY_PATH (macosx)
LD_LIBRARY_PATH (unix)
PATH (windows)
- target 'gluegen.cpptasks.striplibs'
Strips the symbols out of the native libraries
in case c.compiler.debug is false.
Maybe configured with the properties:
c.strip.tool, c.strip.args
- Using system.env.library.path in junit call
to find the test1 library in case of runtime linkage and lookup (test1p2).
- Use gluegen.cpptasks.striplibs for all native libs ..
- Added macosx32 in analogy to macosx64, both defaults to true now
- com.jogamp.common.os.WindowsDynamicLinkerImpl:lookupSymbol()
- Added lookup for __stdcall @nn (stepping alignment 4, max-args: 12)
in case no undecorated __cdecl symbol is found.
Fixed Windows platform:
- Use proper path.seperator on Windows.
- test1.dll needs proper soname inside for fixed linkage (test1p1)
hence the output name must be test1.dll, not libtest1.so
+++
http://jogamp.org/bugzilla/show_bug.cgi?id=394
Fix MacOsX platform:
The commit of cpptasks.jar, git hash 129e783741d91e9ee5cd7da5d5c962c32ec96b0b,
broke the universal binary build on MacOSX.
The above change used cpptasks-1.05b with a few patches in regards to crosscompilation,
but missed one, which accepts the '-arch' argument for GccLinker undecorated.
The new cpptasks.jar is vanilla 1.05b + cpptasks-1.0b5-darwin-patch.diff,
the latter a more refined one.
This version accepts the '-arch' argument undecorated on the darwin platform.
+++
|
|
|
|
|
| |
-Warning: Reference antlr.classpath has not been set at runtime, but was found during runtime
-duplicated project name
|
|
Adding 'plain' junit tests.
Plain stands for the simple processing of:
ant.junit.compile: gluegen -> java/c files, javac/cc, jar
ant.junit.run: junit batch run
Avoiding 'black magic', ie kicking off gluegen and ant-compilation
from within the junit tests.
Same methodology as the JOGL junit tests,
junit test sources are under 'src/junit'
This way, the migration to other platform tests might be easier,
as well as the we don't need to pass through ant properties (ant - junit - ant),
see 3a32650d4229f9b4ad1f527d9e30c24ddb69bb3f.
|