I was running an API 33 pixel 6 x64_86 that returned an error for a couple of apps I was trying to install: [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]
I found these run on armeabi-v7a. So I tried a second avd when I ran into a bunch of more problems.
The api 33 wouldnt run an armeabi-v7a, so I tried different combinations. Unfortunately every one of them had the same prompt that I should run an x86 image on an x86 host as its 10x faster. When I forced one to run on Nougat 7.1.1 armeabi-v7a, a nexus, the avd ran snail slow taking almost 10 mins to just start up and I could ultimately install neither of the apps.
Im now out of ideas. Can anyone help and mostly importantly, is there any way I can run the armeabi on the existing api33 x64_86 which is way faster?
Short answer, no.
These are different instruction sets designed for different CPU hardware. armeabi is for Arm CPUs, and x64_86 is for (e.g.) Intel/AMD CPUs.
Related
I've looked on shakebuild and it looks as though you have to have a haskell installation on a networked machine?
(verbiage to placate so follows)
Shake is a Haskell library for writing a build system. If you want to go for an air-gapped machine, you have three options:
If the build system won't change, you can compile a single static binary for your build system and ship it over to the machine. That's probably easiest. It will have no runtime dependencies.
If the build system changes a little bit, presumably it changes at a lower cadence than the code you are compiling. If so, just precompile the build system and ship it over with fresh code.
Finally, transfer enough stuff to the air gapped machine to build Haskell programs. If you are going that route, transferring enough to get the stack tool working is feasible - I've done it before. You are probably looking at several Gb of tools and libraries.
I'm running Windows 7 Pro, SP1 on a Dell Precision M2800 (I know it's out of date).
My VMWare Workstation version is 11.1.4 build 3848939. Right now I'm using it primarily for a VM with Windows 7 and a bunch of (latest) Rockwell/Keyence software.
I'm using CodeBlocks version 16.01 to compile C++. Packages I'm using in my code include various SDL libraries and the standard stuff.
The issue I'm having is repeatable for me:
I start both VMWare and CodeBlocks running on my host machine. I compile and test code in CodeBlocks while I wait for Rockwell to finish compiling/uploading/etc.. After a couple of times compiling and running programs with CodeBlocks, my host OS will lock up for a long time (more than an hour). I haven't waited long enough to see if it ever unlocks on its own.
The work-around I'm using right now is to just not use those programs at the same time. I'm not necessarily looking for a solution, (because I anticipate that everyone will just tell me to update Windows), although solutions are fine. I'm looking for information about the root cause. Anybody have ideas about why this might be happening?
Thanks in advance.
I'm having a problem trying to build mozilla firefox. Despite the fact that my system is quite decent (i5 processor, 16 gb ram, ssd) , the build is very slow. I've used mk_add_options MOZ_MAKE_FLAGS="-j4" option in the mozconfig but my CPU is still at 1-2% of usage.
Is there something that I am missing?
The initial build can take from 10 minutes to more than an hour, depending on the OS, the build machine specs, and the build configuration.
Has your build finished at all? What do you call "slow"?
What OS are you building on? Windows, for example, is much slower to build.
What version of Firefox are you building (m-c tip? an old version?)
What's your build configuration (mozconfig)? Are you doing a debug or a release build? Any non-standard options? Did you try artifact builds?
Paste the build log, in particular it prints how much resources it took to build just before the end of the build.
Do you have A/V or other system software? Did you instruct it to ignore the objdir?
I want to make a Windows store application using the monogame libraries, but for this purpose, I need to install Windows 8.1. The installation fails and gives me the error
0xC1900101 - 0x40017
This error is quite large and alot of people have had or still have it. I made alot of research on it and it seems that this problem is caused by driver incompatibility. I tried the installation about 15 times now, every time updating some drivers, installing updates, etc.
On the installation, it stops at 84% on "Applying PC parameters" step.
So I believe that the problem is that one of my drivers in incompatible and I need to remove it so here are my specs/peripherals:
ASUS G75VW qs71 laptop (16GB RAM, i7 ivy bridge) (I don't think it is the problem, since my friend has the same and it worked for him)
- Logitech G930 Gaming Headset
- Razer Orochi Mouse (Not the 2013, but the 2012)
If some of these drivers are incompatible, please tell me how to remove them.
Thank you.
P.S. I'm not sure if this question is relevant for this site, but it is somewhat programming related and I need it to do programmation.
I recently got a new Macbook Pro at work and noticed that building our codebase in Maven2 takes about 15 minutes while others on my team with slightly older Macbooks (but similar/same specs) build in about 5 minutes. After asking around, I've found one other person on my team whose builds take 15+ minutes. I'm talking about a fresh checkout of the code, with all of us on the same version of Maven (2.2.1) and Java version: 1.6.0_29, running 'mvn clean install' from the root of the project. Both of us with slow builds are on Lion (10.7.3), while the people with 5 minute builds are on Lion or Snow Leopard. My machine has 8GB RAM with 2.3 GHz i7, so it doesn't seem like that should be a problem. AFAIK, the machine came with Lion (versus upgraded from Snow Leopard) so I don't think it's that it was upgraded in place from Snow Leopard which it seems some people have had issues with. We with the slow builds both have 5400 RPM drives while most of the others have 7200 RPM drives, but alas, one of the other guys with the 5 minute builds has the exact same 5400 RPM drive as us ... so that sort of rules out that theory.
I've run a memory test (checked out fine), run disk verify and permissions repair in Disk Utility (fixed some permission issues, but didn't change build times), disabled swapping, made sure filevault was off, build from a different directory, all to no avail. A few interesting points which makes me suspect an OS issue:
I have a Ubuntu VM on said machine, and doing a 'mvn clean install' in there is even considerably faster than natively in OSX (10 minutes versus 15 minutes)! FYI, the native Ubuntu guys on our team also build around 5 minutes. And when I was running Ubuntu in a VM on my Windows box a few months ago, builds averaged 15-20 minutes.
Building the slowest component of our project by itself takes about 3-4 minutes normally. The interesting thing about this component is that there is very little code in it. In fact, all it is is one test case and 135 MB of resource files. Of the 3-4 minutes, I counted about 100+ seconds of it is sitting on "Copying 63 resources".
Running in OSX Safe Mode, building the aforementioned slowest component took only 42 seconds, of which about 7 seconds were spent on copying the 63 resources.
I'm not sure what else to try at this point, but I feel I'm so close to nailing it down. If it wasn't such a marked difference, I wouldn't worry about it so much, but 15 mins versus 5 mins is huge in my workflow. I don't feel real comfortable about giving my work computer to the Apple Genius guys, and our IT guy's not a Mac person. Reinstalling the OS seems to be the answer I've seen online, but that seems a bit excessive and intrusive. (I realize this is more of an OSX question than a Maven question, probably, but Maven's been my benchmark. I don't notice any other slowness, but it's hard to say without using others' computers)
Has anyone encountered something like this? Any ideas on what to try? Thanks
Run mvn -X ... command on your machine and on fast one and compare times from the log files what tasks/plugins take the most time. That should give you a starting point. The two slowest parts are file system scanning and network access for checking artifacts/dependencies/plugin updates.
The former can be improved by tuning disk access (e.g. cache or switching to the SSD).
The latter can be improved by adding Maven repository manager, such as Nexus or Artifactory that would cache and optimize access to all remote Maven repositories.