| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
native library path, supported throughout DynamicLibraryBundle[Info]
Motivation: It is helpful to retrieve the actually used native library pathname,
since loading a library w/o absolute path but lookup through LD_LIBRARY_PATH
may render it hard for the user to determine which library is used.
+++
+++
Windows implementation simply can use GetModuleFileNameA() with the native library handle.
POSIX implementation may utilize a symbol-name to retrieve its address within the
loading native library used to retrieved the library information
via dladdr().
To support this feature throughout DynamicLibraryBundle and DynamicLibraryBundleInfo,
the custom DynamicLibraryBundleInfo specializations shall provide
optional symbol-names per each tool-library-name for the POSIX implementation,
see above.
public interface DynamicLibraryBundleInfo {
...
/**
* Returns optional list of optional symbol names per {@link #getToolLibNames()}
* in same order for an OS which requires the symbol's address to retrieve
* the path of the containing library.
*/
public List<String> getSymbolForToolLibPath();
...
}
|
|
|
|
|
| |
Symbol could not be found w/ Android:
UnixDynamicLinkerImpl_JNI.c::Java_jogamp_common_os_UnixDynamicLinkerImpl_dlerror
|
|
|
|
| |
analyze llvm-vmkit libGL loading issue)
|
|
|
|
| |
Signed-off-by: Harvey Harrison <[email protected]>
|
|
|
|
|
|
|
| |
GluegenVersionActivity uses ApplicationContext
Hide DynamicLinker impl.:
- com.jogamp.common.os.*DynamicLinkerImpl -> jogamp.common.os
|
| |
|
| |
|
| |
|
|
|
|
| |
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/../svn-server-sync/gluegen/trunk@147 a78bb65f-1512-4460-ba86-f6dc96a7bf27
|
|
|
|
|
|
|
| |
on to trunk
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/../svn-server-sync/gluegen/trunk@146 a78bb65f-1512-4460-ba86-f6dc96a7bf27
|
|
principally to generally solve the problem of downloading dependent
libraries of GlueGen-generated native code, as in the case of JOAL and
OpenAL reported recently by Shawn Kendall on JOAL forums.
Autogenerated Java and native code associated with this new
NativeLibrary helper class is currently checked in to the GlueGen
workspace to make it easier to build across multiple platforms; it can
be regenerated by running the generate.nativelibrary.sources Ant
target in the GlueGen workspace. Building of the native code in the
GlueGen workspace is currently disabled by default and can be enabled
by specifying -Dbuild.native=1 on the ant command line. Use of the new
NativeLibrary class in JOAL is currently disabled by default and can
be enabled by specifying -Djoal.use.gluegen=1 to applications using
JOAL. New functionality has been lightly tested with JOAL on Windows
and appears to be working. More testing, including build and Java Web
Start deployment testing, to follow on other platforms.
git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/../svn-server-sync/gluegen/trunk@37 a78bb65f-1512-4460-ba86-f6dc96a7bf27
|