In the JNA Javadoc, it says:
The String passed to the Native.loadLibrary(String,Class) (or NativeLibrary.getInstance(String)) method is the undecorated name of the shared library file.
If the library name is null, your mappings will apply to the current process instead of a separately loaded library. This may help avoid conflicts if there are several incompatible versions of a library available.
http://java-native-access.github.io/jna/4.4.0/javadoc/overview-summary.html#library-mapping
What does the spec mean when it says the mappings will apply to the current process?
Related
I have a legacy Windows project using the legacy 32 Bit C++ compiler. For various reasons I need to use the Windows 8+ function PathCchCanonicalizeEx. C++Builder seems to provide the header and some module definition file for that, but I can't find any library to link against:
[ilink32 Error] Error: Unresolved external 'PathCchCanonicalizeEx' referenced from C:\[...]\WIN32\DEBUG\TMP\FILE.OBJ
How am I supposed to fix this? Do I need to add a Windows 8.1 SDK? Is the necessary lib simply named differently and I can't find it? Something completely different?
According my tests, one has two options:
IMPLIB/MKEXP
I'm developing/testing a some Windows 10 21H2, which provides an implementation for PathCchCanonicalizeEx in some DLL already. So if that source DLL is known, one can use IMPLIB or MKEXP to create an import library manually. I did that and after adding the created library from IMPLIB to my project, the linker errors were instantly gone.
Though, it's not that easy to know where PathCchCanonicalizeEx is placed in. One pretty easily finds the api-ms-win-core-path-l1-1-0.dll, but that thing is NOT an actual file on the disk and therefore can't be used by IMPLIB or MKEXP. That name is only a virtual concept for the library loader to address the same named API set of modern Windows, the extension .dll doesn't mean it's a file at all.
You can use an API set name in the context of a loader operation such as LoadLibrary or P/Invoke instead of a DLL module name to ensure a correct route to the implementation no matter where the API is actually implemented on the current device. However, when you do this you must append the string .dll at the end of the contract name. This is a requirement of the loader to function properly, and is not considered actually a part of the contract name. Although contract names appear similar to DLL names in this context, they are fundamentally different from DLL module names and do not directly refer to a file on disk.
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets#api-set-contract-names
What you really need to work with is KernelBase.dll, which is even documented by MS.
implib "KernelBase x86.lib" C:\Windows\SysWOW64\KernelBase.dll
implib "KernelBase x86-64.lib" C:\Windows\System32\KernelBase.dll
Module Definition File
The downside of manually creating LIB files is that one needs to maintain those with the project. Things depend on if the target is 32 or 64 Bit, DEBUG or RELEASE, so paths might become a bit complex, one might need to create relative paths for libraries in the project settings using placeholders for the target and stuff like that.
It seems that all of this can be avoided with Module Definition Files, which's purpose is to provide IMPORT and EXPORT statements to either consume exported functions by other DLLs or make that possible for others with own functions. I've successfully resolved my linker problems by simply creating a file named like my app using the extension .def alongside my other project files. That file needs to be added to the project, though.
dbxml.cbproj
dbxml.cbproj.local
dbxml.cpp
dbxml.def
dbxml.res
[...]
The following content made the app use the correct function from the correct DLL. Though, what didn't work was using the API set name, which resulted in an error message by the linker.
IMPORTS
KernelBase.PathCchCanonicalizeEx
IMPORTS
api-ms-win-core-path-l1-1-0.PathCchCanonicalizeEx
[ilink32 Error] Invalid command line switch for "ilink32". Parameter "ItemSpec" cannot be null.
[ilink32 Error] Fatal: Error processing .DEF file
The latter is after restarting C++Builder, so I guess the format of the file is simply wrong because of the API set name.
I am a newbie with Autotools and currently trying to create a configure.ac file in order to check for several dependencies for the later installation of my program.
Now, I want to check the existence of certain libraries and I have found that using AC_CHECK_LIB can do the trick. I think PCK_CHECK_MODULES could help too but I would like to stick to the former unless PCK_CHECK_MODULES solved my problem:
AC_CHECK_LIB does what is expected to do which is to look for the library and perform an action if found or another one if not found, but, my question then is:
If AC_CHECK_LIB finds my library, how can I obtain the exact path of this library? That is to say, if the AC_CHECK_LIB I have is:
AC_CHECK_LIB (foo, function, [action-if-found], [action-if-not-found])
Is there any way for me to get the exact path of this foo library if it is found?
Thanks,
If AC_CHECK_LIB finds my library, how can I obtain the exact path of this library?
AC_CHECK_LIB does not provide any mechanism by which you could do so. It does not determine an actual location itself. Per its documentation, this is what it actually does:
Test whether the library library is available by trying to link a test
program that calls function function with the library. function should
be a function provided by the library.
When AC_CHECK_LIB succeeds, then, it knows only that the linker found a library corresponding to the given library name that provides a function having the specified function name. It doesn't know where the linker found it. On the flip side, when that macros does not find a library, that does not necessarily mean it is unavailable, but rather that the linker does not find it subject to the link options, if any, in effect at that point.
Note, too, that that's perfectly satisfactory for many purposes. You need to know the actual location only if you want to use that to locate some other, related resource. And it's rare that configure can find a library without help, yet needs extra information to locate related resources.
I'm building up some Dart code that I would like to use in an app where it is essentially a library to the javascript. I'm wondering how I can specify which Dart files I'd like in the project to be part of the library. For example, theres Foo.dart and Bar.dart. How can I have the created product include both Foo.dart and Bar.dart in one file? I'm also concerned about tree shaking since none of the classes are instantiated in Dart.
There's also a Baz.dart, and I would like to have a different build for compiling Foo.dart and Baz.dart into a single file (though this is less important, as I can accomplish this would separate projects and some symlinking).
Thanks!
This use case (build a JavaScript library with Dart) isn't supported yet.
The reworked js-interop package is supposed to allow to do that but I don't know about it's current state.
Below issues have been discussed in isolation but I could not find a solution which works. Hence posting the complete story and list of issues.
We are building an SDK(midlet jar) to be consumed by multiple apps. This SDK uses persistent store to store certain data. Now couple of issues plaguing us:
1. The key to access the store has been hard-coded in the SDK. Now multiple apps try to access the store with same key value resulting in conflicting issues.
2. The Persistable object package/class name is the same in multiple apps. Because of this we get the "Class Multiply defined" error while launching the apps.
Now for 2, we have been mulling over below options but none of them seem to solve the issue:
1. Do not extend the standard objects like Vector and use standard objects.
Issue: recycling of data is lost causing conflicts.
2. Build the library with a unique name for each application that uses it.
Issues: This would mean we will have to release a different SDK for every client who wants to use it.
3. Check if the Persistable object class already exists before loading the package for the next app.
Issues: What happens when the first package is unistalled? the class type would be deleted?
4. Ask the app to implement the Persistable interface and also pass the key in a callback.
This does not sound right to ask the app to pass some values just because we are not able to use the persistent store.
So as of now SDKs using Persistable objects seems to be totally broken. Or are we missing something?
Any other alternative suggestion to achieve the task is also very welcome.
if there is a library which functionality can be shared among different applications then make it as a library cod file, and specify this cod file as a library upon compiling the dependent projects.
For instance, if the library name is mylib_version1_00.cod then your other projects could contain the following files after compilation:
for Project1:
project1.cod
mylib_version1_00.cod
for Project2:
project2.cod
mylib_version1_00.cod
......
for for ProjectN:
projectN.cod
mylib_version1_00.cod
upon installation of every project you will install mylib.cod file, and if there's already installed mylib.cod file it will be overwritten, and it will avoid "class xxx multiply defined".
This error occurs because all applications are running under one JVM instance. So if you are uploading to device a cod file with the name, that already exists, it will be rewritten.
In case you will release the next version of your library, name the cod file as
mylib_version2_00.cod
and use version number in package name, for instance:
com.yourcompany.yourpoduct.yourlibary.version1
com.yourcompany.yourpoduct.yourlibary.version2
In this case you can have on the same device cod files: mylib_version1_00.cod and mylib_version2_00.cod and it won't produce "class xxx multiply defined" error.
Now about the persistence. Do not hardcode persistence key in your library. Make an abstract class and declare an abstract method like:
public long getPersistenceKey();
which returns a unique persistence key for an object. And use this method call in the code that persists the information in your abstract class.
and in children classes, used in your custom applications just override this method with different values for every product. And there won't be confilcts anymore.
Hope this helps.
There can be only one persistable class with a given classname on the entire device. If two apps have the same class which are persistable, you'll get a Class Multiply Defined verification error and the second app will not install at all.
The only way is to use the builtin persistable classes for storing persistable data in the SDK. However, this persitable data will not be deleted even when all the apps containing the SDK have been removed by the user. You will also have to take care of the versions of the data to be backward compatible.
You store the data using a builtin class like Hashtable, IntHashtable or Vector. Then you write a wrapper class which gets and sets this information. Basically you'll be mapping your persistable class to a Hashtable or Vector.
Again remember, you should never put any class that is not builtin into this datastore. Otherwise, the datastore will get deleted on the app uninstall.
Hope that helps.
I am currently building a program using GLEW, compiled with MinGW ( in Eclipse ). I built the GLEW libs from the source provided by the GLEW website.
I have been able to use the GLEW declared functions without a problem if I link with the .DLL. However, if I try to link with the static library ( libglew32.a ) with the "GLEW_STATIC" flag defined, I get an error for the function "glewInit()":
undefined reference to `imp_glewInit#0'
If I open up libglew32.a in a hex editor, I can see that there is an entry, but it is named _glewInit#0. So it seems like the disconnect is that my program's compile is trying to append this "imp" string to the front of the function name in the library.
It seems like there must be mis-match of the calling convention here, but I don't know what would cause it yet. There are certainly lots of different ways that GLEW declares the api functions in the header depending on what compiler definitions are set, but I haven't narrowed it down yet.
Any ideas out there?
It looks like that imp prefix gets added for function stubs that are intended to be loaded at runtime from a .DLL. In other words, I wasn't actually staticly linking against GLEW. It turned out that I didn't quite have my eclipse C++ symbols set up correctly, so GLEW_STATIC was not being defined. After making sure that it was set up in the g++ call, it links just fine.