I have a C project that uses libc, and I need to compile it into a static library that will be added later to a different project.
My question is: what will happen if the second project (the one that will use my library) is already using a differnt version of libc? Will this fail during linkage? And if so, how can I overcome this problem?
Related
I have just updated my eclipse project from java 8 to java 11. But I am using external libraries in this project that were designed for java 8. I have successfully imported these libs into projects classpath as it used to be but eclipse just refuses to use them. When I try to import them it will highlight it as an error with a message "The type bla.bla.Foo is not accessible". I also tried to import these libs into projects modulepath and requires them in module-info.java which solves the problem in some way but I still keep receiving warning "Name of automatic module 'SomeLib' is unstable, it is derived from the module's file name." and "The type Foo from module SomeLib may not be accessible to clients due to missing 'requires transitive'" always when I try to use an object from these libs.
Note: I am using OpenJDK 11 with JavaFX 11.
Note: Libs that I am trying to import are https://github.com/PetoPetko/JavaFx-Image-Animation
Note: I'm also getting "The type com.sun... is not accessible" also on everything that is from com.sun... package but I'm not sure if this is related to this problem.
Well, I manage to solve this by myself in probably the most primitive way...
I simply import JavaFX into classpath and manually delete module-info.class from every JavaFx jar file making JavaFx not modular. Then I just run an app with the mentioned VM arguments and everything was just fine! I am sure many of you will be able to give me 10 reasons why removing module-info.class from existing lib is a bad idea but... if it works, and still I think there is no other solution to make my not modular project work with JavaFx 11.
What you did to solve your problem could be achieved in a much simpler way. Just add a line like the following to the file which contains your main class (assumed name MyApp) and then start your app by calling MyAppLauncher.main instead of MyApp.main.
class MyAppLauncher {public static void main(String[] args) {MyApp.main(args);}}
This does the trick so that you can put all jars on the classpath and that way igonre the module system completely without having to remove the module-info.classes manually.
I am setting up Selenium right now and i have to copy the Selenium files into my eclipse project. Unfortunately, every tutorial has different files which they are adding to the Eclipse project, mostly because they are using older Selenium versions.
Currently, i just added all jar. files from the "libs" folder and also the jar file called "client-combined-3.5.3-nodeps". So i hope these are all files i need.
My question is, what happens if some files are missing? Is Selenium then not usable correctly?
Selenium Java client provides us the APIs through different packages. So when we need to use the APIs we have to make the necessary imports as well.
Now, if you miss out to add certain Selenium related jars in your Project, some methods from your main() or #test Class may not get resolved due to absence of the imports. Hence your program/script will show you errors as unresolved methods and will the program will not get compiled/executed.
Hence, it's always a good idea to add all the jars in your project from the released Selenium Client SDK.
At times, there may exist certain methods which are defined in multiple packages. For example method abc() may be defined in java.util.pqr; as well as in org.openqa.selenium.xyz;. In those cases we have to make our imports wisely as per our requirement.
I wrapped a source github for b4a with Eclipse.
I added core.jar but when I compile the project in b4a it shows this error:
trouble processing "java/com/lsjwzh/widget/materialloadingprogressbar/CircleProgressBar$OvalShadow.class": Ill-advised or mistaken usage of a core class (java.* or javax.*) when not building a core library.
This is often due to inadvertently including a core library file in your application's project, when using an IDE (such as Eclipse). If you are sure you're not intentionally defining a core class, then this is the most likely explanation of what's going on.
However, you might actually be trying to define a class in a core namespace, the source of which you may have taken, for example, from a non-Android virtual machine project. This will most assuredly not work. At a minimum, it jeopradizes the compatibility of your app with future versions of the platform.
I changed package name from
java.com.lsjwzh.widget.materialloadingprogressbar
to
com.lsjwzh.widget.materialloadingprogressbar
Why show in error -
"java/com/lsjwzh/widget/materialloadingprogressbar/CircleProgressBar$OvalShadow.class"
?
I rebuilt the project in eclipse and compile with SimpleLibraryCompiler for b4a.
I forgot use
#DependsOn
for calling Additional jar in folder libs.
I am working on a portable class library and would like to understand the strategy used by NuGet to determine if it should use a PCL or a platform-specific library (if it exists).
I built a sample project that refers JSON.NET which has support for various platforms as well as a portable class library. Here's what JSON.NET offers from NuGet:
net20
net35
net40
sl3-wp
sl4
sl4-windowsphone71
winrt45
portable-net40+sl4+wp7+win8
First I created a library targeting NET 4.0 and added a reference to JSON.NET using NuGet. It added a reference to a net40 library. Okay, I assumed this is because there is an exact target platform match. Then I targeted NET 4.0.3. Still net40 version was referenced. Then I tried Silverlight 5 which didn't have exact match among non-portable libraries. But an sl4 library was chosen. And targeting Windows Phone 8 resulted in sl4-windowsphone71 library selection.
So it looks like whenever there is a non-portable compatible library for a target platform, it will be prioritized. In case of JSON.NET a PCL will only be selected if it's referenced by another portable library. If so, I am puzzled how the following situation will be resolved:
Library A has two versions:
net40
portable-net40+sl4+wp7+win8
Library B references A and has one version:
portable-net40+sl4+wp7+win8
Finally, library C references both A and B and has one version:
net40
How will be reference to a lib A resolved for C? Since C references A directly, it should get a net40 of A. But since C also references B which is portable, it should in addition get a portable version of A. So both portable and net40 versions of a library A must be deployed for C to resolve its dependencies. Am I correct?
UPDATE. I created a couple of test projects, and it looks like as long as a library C contains a direct reference to a non-portable library A, this version of library will win and overwrite the PCL version of A. So it looks like such scenario is not allowed - a library can't directly reference a non-portable lib if it also indirectly references a different (portable) version of it.
NuGet will use the "most specific", or the "narrowest" match possible when deciding which version of a library to reference.
The portable versions of your library should be compatible with the platform-specific versions of your library. I think of this as just the more general case of compatibility between different versions of a framework. In your example, replace net40 and portable with net45 and net40. In that case, NuGet should use the .NET 4.5 version of a dependency, but if you have another dependency compiled against the .NET 4 version, it should work if at runtime it has the .NET 4.5 version instead.
To be compatible, the different versions of your library should have the same identity (name, version number, and (if applicable) strong name key), and should be API compatible, which means that a version of your library for a specific platform should have all the same APIs as a portable version that can run on that platform (the platform specific version can add additional APIs, however).
I have to use two native libraries: one is my own and the other one is 3rd-party. As long as I used them in separate projects, everything was ok. But now I'm getting the Exception Ljava/lang/UnsatisfiedLinkError.
I'm using Eclipse.
I found out that if I place the existing library in libs/armeabi, Eclipse begins compilation of the native code and it fails. If I rebuild the JNI part from the command line, compilation succeeds but the 3rd party library disappears. Really stupid.
So how do I tell Eclipse to use an existing .so library along with a library that must be built? The libraries are independent.
The NDK allows for linking with prebuilt user libraries, using the PREBUILT_SHARED_LIBRARY variable.
Assuming that the library you need to link is librandom.so, create a libs folder in jni subfolder of the project folder:
mkdir -p jni/libs
cp librandom.so jni/libs
Then, just create a jni/libs/Android.mk file:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := random
LOCAL_SRC_FILES := librandom.so
include $(PREBUILT_SHARED_LIBRARY)
You can create a section for each prebuilt library, all placed in jni/libs.
Next, you just need to include the above file into your jni/Android.mk to get things to work. In the NDK docs, it is recommended that this be done at the end of the Android.mk, rather than the middle:
include $(LOCAL_PATH)/libs/Android.mk
However, you'll need to do this before the module that requires this library.
For linking, you'll need to add the following into the module section that links to the prebuilt library.
LOCAL_SHARED_LIBRARIES := random
Then when you do ndk-build, it will copy this library into libs/armeabi/ before building the module, and you're good to go.
Note: This does not solve problems with required headers. You'll still need to add the location of the headers for the library into the variable LOCAL_C_INCLUDES in the module that requires it.
This is what I have done for the moment. I will not accept (in stackoverflow sense) my own (this) answer beause it is unsatisfactory.
I have created a new project and copied all java files there. Then, I copied the .so library from the old project and the 3rd party library into libs/armeabi.
That's monstrous. But it works. For the moment. The worst thing is that the version control is torpedoed.