I'm trying to use Picasso with disk caching. To do so, I understand I need to include the okhttp and okio libraries. When I do so, I get the following:
compile 'com.squareup.okio:okio:1.0.1'
compile 'com.squareup.okhttp:okhttp:2.0.0'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.0.0'
compile 'com.squareup.picasso:picasso:2.3.4'
java.lang.NoSuchMethodError: No static method source(Ljava/io/File;)Lokio/Source; in class Lokio/Okio; or its super classes (declaration of 'okio.Okio' appears in /system/framework/okhttp.jar)
at com.squareup.okhttp.internal.DiskLruCache.readJournal(DiskLruCache.java:243)
at com.squareup.okhttp.internal.DiskLruCache.open(DiskLruCache.java:224)
at com.squareup.okhttp.Cache.<init>(Cache.java:146)
at com.squareup.picasso.OkHttpDownloader.<init>(OkHttpDownloader.java:74)
at com.squareup.picasso.OkHttpDownloader.<init>(OkHttpDownloader.java:51)
at com.squareup.picasso.OkHttpDownloader.<init>(OkHttpDownloader.java:41)
at com.squareup.picasso.Utils$OkHttpLoaderCreator.create(Utils.java:407)
at com.squareup.picasso.Utils.createDefaultDownloader(Utils.java:255)
at com.squareup.picasso.Picasso$Builder.build(Picasso.java:605)
at com.squareup.picasso.Picasso.with(Picasso.java:482)
This is with a brand new app.
Any ideas what's going wrong?
Switching to okhttp 1.6.0 seems to solve the crash. Although I'm still not able to get disk caching working
You can remove the Okio dependency, it's transitive.
The problem is that the L preview was improperly packaged and incorrectly exposed Okio on the system classpath. All crashes from this can be ignored completely as a function of pre-release software. The actual L release will not behave this way.
More details are available at https://github.com/square/okhttp/issues/967
Related
We are using a Jenkins Shared Library to centralize some code for all our (scripted) pipelines. Now we factored out some Groovy code into a .jar library (written in Kotlin, compiled to be Java 8 compatible). We published this library to our in-house maven repo and now want to use it in our Shared Libary.
We are using #Grab to load our library and up until that point it works like a charm. However we are getting NoSuchMethodError's. We pinpointed it down a bit, we are using OkHttp in our Kotlin lib. OkHttp internally uses Okio. When we call methods that internally call OkHttp-Code from our pipeline, everything is fine. However when the OkHttp-Code call Okio internally, we get a NoSuchMethodError.
We already checked the published .jar file, it contains the classes with the methods that seem to be missing. Does anybody have an idea what the issue could be?
While we are at it, we can't access environment variables set on Jenkins in our Kotlin library, is there a way we can fix this?
We figured it out. The problem was, that a Jenkins plugin used an older version of okio internally. Because plugins and shared libraries somehow share the same classpath, okio did not get loaded and the version from the plugin got used, therefore the class was not present.
We fixed this by repackaging all dependencies in our .jar, so package names would not interfere and we can make sure that our specified dependencies are being used.
Looking the dependencies here you have a few problems:
OKHttp - seems to expect some Android libraries
okio - depends on the Kotlin runtime
Any calls to these will result in method not found errors unless you find a way to make them available without causing problems in Jenkins
I have an iOS project in Xcode. It contains a load of linked libraries including GoogleInteractiveMediaAds.framework as well as an internal player library that I believe is also linked against this framework. Both are also embedded binaries.
The project compiles just fine but at runtime I get the following error:
Class GAD_GTMStringEncoding is implemented in both
/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds
and APP_PATH. One of the two will be used. Which one is undefined.
On simulator the app works as expected every time despite this warning - I get the pre-roll, mid-roll and post-roll ads that I'm expecting. Every time. On device it's a different story with the ads sometimes working and sometimes not. I'm aware that the above issue results in different behaviour on different targets and I suspect this conflict is to blame for the broken functionality on devices.
Solutions I've found here on SO suggest either changing the namespaces or removing the linkage from either my app or the library that I'm linking against. The problem is, if I remove the embedded binary in my project then it fails to compile:
dyld: Library not loaded:
#rpath/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds
Referenced from: APP_PATH
Reason: image not found
(lldb)
I've seen a few people suggest what would be removing the linkage from the app and using the player's internal instance (where I then have to hope that the player is compiled against the version that I need), but how on earth do you do that? And would that even work in this case?
Also, is there a way to find out for sure where this other instance of GoogleInteractiveMediaAds.framework is coming from? I'm only assuming that it's inside the internal player library but I don't know for sure as I don't have the source. The error message just provides me with the path to the compiled app which is of little help since there's like 30 linked libraries inside it.
Thanks in advance.
After initially insisting that the issue was somewhere in our code, the Google team responsible for this framework were eventually forced to admit (after we provided a sample app) that it was a problem with their code and not ours. It was resolved in an update.
Whenever I try to compile my Unity game in Xcode I get a 3 compile errors which are coming from the Unity Google Play Games plugin:
GPGSAchOrLbDelegate.h - Lexical or Preprocessor Issue 'GooglePlayGames/GooglePlayGames.h' file not found
GPGSRealTimeRoomDelegate.h - Lexical or Preprocessor Issue 'GooglePlayGames/GooglePlayGames.h' file not found
GPGSManager.h - Lexical or Preprocessor Issue 'GooglePlus/GooglePlayGames.h' file not found
I've no idea why this is happening, I followed all the setup instructions correctly.
Any help would be greatly appreciated!
one gotchya is they recently changed many of the method names in the library, in a recent update...
it's possible this has caught you out?
It's very hard to resolve this, but I found some discussion about this for example here,
http://answers.unity3d.com/questions/679424/google-play-games-plugin-for-unity-not-authenticat.html
it's a bit easier on iOS than Android.
Alternately: note that, essentially, you have not included the GooglePlayGames.h file. Include the link to "which" instructions you were following, to guess which step is problematic. (Most Unity plugins - like Prime31 - have a "preprocessor" stage that does that for you or in the case of Android fills in the damned manifest. Something is going wrong at that stage.)
I actually solved this myself by removing the plugin and starting afresh, and then starting a completely new xcode project rather than appending to an old one.
Irritating and time consuming but I got there in the end!
I am using an fmod plugin for Unity3D. Compiling to Windows and OSX is fine because I can dynamically load the DLL/dylib.
The problem comes when I compile for iOS. I use
[DllImport("__Internal")]
Because iOS requires statically linked libraries. When I compile though I get a
SystemException: Duplicate native method found : FMOD_System_CreateSound. Please check your source carefully.
I am quite sure I don't duplicate the symbol. I think this might be due to the fact that Unity imports FMODs itself and that the two might be colliding... But if this is the case, I am surprised that FMOD_System_CreateSound is the first one to get caught. Is there a way around this? thx!
As always, I will be happy to provide any additional details!
Here is a sample project that will cause the error:
Sample Unity Project with FMod
EDIT:
The conflict was caused by iOS not allowing functions to have the same name even though they don't have the same signature. After removing the same-named functions (thus removing some FMOD features that I didn't need), I can compile to iOS, but as expected, I still get an error when Initializing because FMOD is already initialized by Unity.
Unity3d already has a limited version of FMOD that is bundled with it, which is causing the conflict you are seeing. Unfortunately, it doesn't seem possible to disable it at this time, so that you can use the full version of FMOD
In reference to your edit and after looking at the sample, it is true that you cannot have two methods of the same name as the compiler will not recognize which to link to.
The easy fix is to obviously name them differently.
As for the initialization, if you can access the FMOD that Unity 3D already created, then you don't have to reinitialize it.
I assume that a pointer to that object will be sufficient to remove the duplicate initialization. Hope this is clear.
I'm working on porting a library onto AIX. It works on Solaris, Windows and Linux but AIX is giving me headaches. I'm at a point where it builds and runs but I have an issue with some of the libraries it's linking in. Ideally I want to be able to ship a library that just requires the c runtime to be available with no other dependencies. At the moment I'm having a problem with libpthread which I can see is a symlink to an AIX specific threading library.
My issue is this:
If I don't link pthread (I don't seem to need to on Solaris for the same code base) then I get undefined symbols. That's fine I am using pthreads. If I link it in then it works fine, except that any calling application also has to link to pthreads. I don't really understand is why does my calling app, which has no dependency on pthread, need to link against it just because it's calling a library which links to the shared object?
I'm on AIX 6.1 using gcc 4.2.4.
I'd be OK with shipping a library that requires pthreads to be present on the library path (ideally we'd get a static version) but I'm a bit unhappy about shipping a library that places linker rqeuirements on the client.
Any ideas on what I might be doing wrong?
I defeinitely seem to be going in circles. I removed the -shared flag on the linker to resolve an earlier problem and that, of course, makes the library static. So the behaviour is just normal behaviour in that if you depend on a dynamic library from a static one you have to link both into your app. So I've put the shared flag back and now half of my functions are no longer accessible. It does explain the problem I was seeing though.