| 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();
...
}
|
|
|
|
|
|
|
|
|
|
|
| |
and 'searchSystemPathFirst' attributes
NativeLibrary can be instantiate by defining
'searchSystemPath' and 'searchSystemPathFirst' arguments,
allowing to specify the system path role while looking up the library.
Since NativeLibrary is utilized via DynamicLibraryBundleInfo upstream,
the latter interface shall allow users to specify those attributes.
|
|
|
|
| |
Signed-off-by: Harvey Harrison <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
access (2)
- Completes 23341a2df2d2ea36784a16fa1db8bc7385351a12
- Replace 'DynamicLinker' interface w/ well documented one
- All DynamicLinker methods are now considered secure, i.e.:
- open/lookup and close utilize reference counting on handle via a hash map.
- lookupSymbol(..) and close(..) impl. validate the passed library handle
whether it's retrieved via open*.
This is the fast path, not that expensive.
- lookupSymbolGlobal(..) performs
Check acccess of 'new RuntimePermission("loadLibrary.*")' if SecurityManager is installed.
This is the slow path.
- DynamicLibraryBundleInfo now reflects the security requirements,
i.e. whether priviledged access is needed.
|
| |
|
|
|
|
| |
/ API doc cleanup; DynamicLibraryBundle: Add getDefaultRunnableExecutor()
|
|
|
|
|
|
|
|
|
|
|
|
| |
thread to load native libraries. (Fix Bug 566)
Due to requirements of native libraries using tls_model("global-dynamic")
a thread can be designated to load the 'tool' native libraries.
In case the tool lib uses tls_model("global-dynamic"),
an implementation shall try to let the early most thread load it.
For example, AWT-EDT shall load Mesa8 (Ubuntu-TLS) libGL.so.1
|
|
|
|
| |
for int/size() for less temp objects
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Added JogAmp Community and common denominator:
New BSD 3-clause license
- Added note to make/lib binary file (source and license)
Added source and license text for external binaries used
in build process (make/lib folder).
Changed 'Sven Gothel' and 'Michael Bien' New BSD 3-clause license
to 'JogAmp Community' Simplified BSD 2-clause license.
|
|
loading and lookup
Add JNILibLoaderBase.loadLibrary(String libname, boolean ignoreError);
DynamicLibraryBundle provides Tool and JNI native library loading and lookup
New classes:
com.jogamp.common.os.DynamicLibraryBundle
com.jogamp.common.os.DynamicLibraryBundleInfo
com.jogamp.common.util.MiscUtils.java
Change: DEBUG/VERBOSE properties 'gluegen' -> 'jogamp'
|