I am posting this question because I stumbled upon the solution, despite not being able to find anything online which helped my specific problem. I am posting the accidental fix as an answer.
Problem: I am using adt.jar via cmd and an ANT script to package the air tablet application. Everything works fine on my workstation, but ipa builds fail on the build machine. The build machine is just a re-purposed workstation with more memory, larger hdd, and runs tomcat/hudson. Both environments are Win7 SP1. By 'everything' I mean apk builds in various configurations, and ipa builds with testing and production provisions files.
Error messages varied a little bit, but here are the common two messages:
Compilation failed while executing : compile-abc
Error #1042: Not an ABC file.
The stack dump was just a bunch of parameters passed into adt -- application specific.
Things I tried based on many internet searches:
Update to latest air 17 beta (17.115) Did not work. I did not expect this to fix my problem, because the PC which successfully builds the ipa does not have this version of the sdk
Hunted down empty case blocks in the code. There were a couple, but again this did not fix the problem. Still works on my machine and not the build machine. I actually made sure the empty blocks existed on the functional environment to disprove this attempt. I am not using "-useLegacyAOT no", so this should not have helped.
Compared all relevant environment vars between the two systems, and matched the ones that were different. This did not fix the issue.
Checked the version of jdk pointed to by JAVA_HOME. Both were already "64-Bit Server VM (build 20.45-b01, mixed mode)" aka: jdk-6u45-windows-x64.exe
Out of desperation, I ran Windows Update on the environment which failed to produce ipa files. There was a recommended update to the .NET framework which something in my tool chain must depend on. This fixed the problem.
Microsoft .NET Framework 4.5.2 for Windows 7 x64-based Systems (KB2901983)
My personal workstation is always up to date, and I restart often. This was not the case for the build workstation.
EDIT: A second update was also installed at the same time. This could be what fixed things, but I'm not going to question it.
Update for Windows 7 for x64-based Systems (KB3021917)
Related
I have a private server that I've been slowly setting up for personal projects, but I've run into a bit of a roadblock. My server is running Arch linux [I like bleeding edge and minimalistic installs in situations like this] and I have Jenkins running on it so that I can have it automatically build projects. I have a project that I've been working on that is currently targeting the Win32/64 platform using MSVC, but I can't seem to find any info anywhere about setting up a job on Jenkins for this situation. I was hoping that I could maybe setup a Docker instance that would be able to provide the MSVC toolchain, especially since Visual Studio Code is available for Linux, and that I could use that as part of my Jenkins setup to generate Win binaries for me to test on my main machine. I mention this because naturally, Visual Studio is not a command line utility, and currently my server is a pure headless setup that only provides cli interaction, so if possible, I would like to avoid directly adding GUI packages to the server, but if it is the only way, I'd be willing to do so. Is there really no way to achieve what I'm going for with this?
Sorry if this lacks important details or is formatted poorly, this is my first time asking a question here as it's very rare for me to not be able to find the info I'm looking for in an already existing question.
After research, this is not currently possible as it stems from a misunderstanding of exactly what docker provides. Docker simply uses the underlying OS to provide everything and does not provide any virtualization of foreign OSs. Without a version of the MSVC toolchain that can run on linux, or possibly the use of WINE, there is not a way to achieve this short of a VM. Since WINE is not perfect, the most reliable solution as it appears to me is the VM, but YMMV. The other advantage to using a VM is that I can keep the server headless.
I can't answer this question completely, but this topic is interesting to me too.
Note: Visual Studio Code is open-source, but that's an Electron-based editor. Visual Studio IDE and MSVC are proprietary Windows-only apps.
The website https://blog.sixeyed.com/how-to-dockerize-windows-applications/ suggests it's possible to dockerize Windows apps, including Visual Studio.
Docker images for Windows apps need to be based on microsoft/nanoserver or microsoft/windowsservercore, or on another image based on one of those.
Once you get that working, I'd use Visual Studio command-line builds, like devenv /build file.sln [optionally /project file.vcxproj ]. (https://learn.microsoft.com/en-us/visualstudio/ide/reference/devenv-command-line-switches?view=vs-2017 ).
Note that the VS2017 installer does not function on Wine. I recently filed a bug for this (https://bugs.winehq.org/show_bug.cgi?id=45749 followed by https://bugs.winehq.org/show_bug.cgi?id=45757 ).
I personally use Appveyor for auto-building MSVC apps. Appveyor is a Windows-based centralized cloud service, not a self-hosted CI system.
I've checked googles and stacks and cannot find an answer for my issue, so I'm asking here.
I've installed Intel XDK 2 on my system (Win 7 64b Pro) but cannot get it to start up. I've uninstalled and reinstalled.
I have it installed in the default directory \users\\AppData\Intel\XDK (I think that was it) so there shouldn't be an issue with permissions.
It comes up with the "Initializing page" but nothing else. I've left it be for about 1 hour while I worked on something else, but the window never changes and the app doesn't start. If I kill it and reopen it says that it didn't close properly and asks if I want a normal or safe start; I've tried both options.
Anyone have any issue with this?
(and please don't suggest phonegap / cordova... I've tried to install that on Eclipse and Visual Studio and both have failed miserably to simply work, even with the googles assisting me).
Two things to try:
-- Make sure you have a valid hosts file, for some folks this has been a problem getting the XDK to start, for unknown reasons, some systems either are missing their hosts file or have invalid entries which can sometimes cause trouble. On Windows, your hosts file is located here:
\Windows\System32\drivers\etc
-- Uninstall the XDK and then completely remove these two directories from your system:
%AppData%\..\Local\XDK
%AppData%\..\Local\Intel\XDK
I need to work with Delphi 6 Update 2 in Windows 8.1 x64 (in case you were wondering, it's about maintaining an old application, migrating to a newer version is not an option. I can't use a VM because I use the same machine to connect to some peripherals that don't work in a VM).
The problem is that Update 2 has a 32 bit installer with a 16 bit stub. So the current behaviour is that the installer starts, it extracts the files in a temp location, starts the setup then nothing appears on screen.
So far, I gathered that it is impossible to do it. But the same behaviour I 've seen for SQL Server 2000 (don't ask) but there I was able to use msetup.exe (DemoShield) to open a sqlservr.dbd that started the script. However, there is no such dbd file. I guess I was lucky on SQLServer 2000.
So far I've tried compatibility mode, DosBox, replacing the setup file with both Installshield 3 and 5, waiting for hours for the setup to start (sometimes, W8 does that), even comparing files and registries on an XP machine before and after update 2 but this might be a bit too risky to apply on a real machine.
Since Windows 8.1 86 includes Hyper-V for running VMs, most modern hardware supports Hyper-V, and Windows 8 x86 can still run 16-bit based apps:
Install a Windows 8.1 x86 VM under your host physical machine, then install it there.
The up-tick: it is easy to move your VM to a new host without needing to reinstall a full new VM.
See http://www.techrepublic.com/blog/windows-and-office/get-started-with-windows-8-client-hyper-v-the-right-way/7893/ and http://www.infoworld.com/d/virtualization/5-excellent-uses-of-windows-8-hyper-v-208436 to get started with Hyper-V.
Hyper-V can redirect quite a bit of hardware from the host to the VM nowadays. For "old" hardware like COM and LPT ports you often can buy USB adapters that can be redirected.
If installing on x86 Windows 8.1 works and x64 fails, I think you have proved the assumption that the 16-bit portion of the installer is the culprit.
Maybe my blog post from last year can solve your problem:
http://blog.dummzeuch.de/2013/11/11/delphi-6-on-windows-8-1/
excerpt:
I just deleted the registry entry
HKCU\Software\Borland\Delphi\6.0\LM
(I did not make a backup, what would have been the point?)
I started Delphi 6, ignored the warning about incompatibilities (which was talking about Delphi 7 anyway) and went through the registration/activation process again. This time it worked.
Maybe I should mention, that I did not install any of my Delphi versions to c:\program files but put them into c:\Delphi instead to avoid any problems with access rights to the installation directory.
I am trying to build a dissector for Wireshark on Windows platform. But, I am getting an error.
I followed this link to install Wireshark from the source on windows, and I was able to build and run the software successfully.
Then using the README.plugins, I added a plugin, and did all the changes, mentioned in the file.
With the plugin, it built successfully, but whenever I tried running it, a dialog box appears stating The plugin 'ABC.dll' has neither a register routine, a register_tap_listener or a register_wtap_module or a register_codec_module routine.. Though wireshark is running fine, but my plugin is not included in it.
Linux Environment: I tried compiling and running on linux platform, and it worked fine, with the plugin included.Can anybody tell me, where I might be going wrong on the windows platform. Thanks.
There's a bit of magic which happens when building plugins on Windows so that certain symbols in the DLL are declared as exported so they can be found in the DLL at run-time. (I haven't recently dug into all the details, but the mechanism is different on *nix and so the results on each platform might be different).
What version of Wireshark are you building ? (How are you getting the Wireshark sources ?).
The specific error message you re getting suggests you might be building a version of WWireshark 1.10. (The message has changed in the Wireshark development version (1.11)).
In any case, something is not quite right (obviously) as to how the DLL is being built on Windows.
My suggestion as a starting point:
You might be able get an idea as to what's wrong by
comparing the plugin.c file (which is generated at build time) in your plugin directory on Windows with a plugin.c from one of the other Wireshark Windows plugin directories.
The magic occurs in that file.
Things like:
WS_DLL_PUBLIC_NOEXTERN void
plugin_reg_handoff(void)
{
{extern void proto_reg_handoff_unistim (void); proto_reg_handoff_unistim ();}
}
I wanted to do a couple of things and am wondering if they're possible, and if so, how to do them.
I was going to make a Virtual Machine to run code-signing in. That way if my computer dies I can hopefully minimize downtime by simply running the VM in a new system. I know the code keys are tied to the machine they're run on. If anyone has done code signing in a VM and switched the VM to another physical machine please let me know if the keys continued to work or not.
I also wanted to run more than one JDE in the VM to sign code for different OSes. From what I understand the code signing uses a code signing app located in each JDE's directory. Is it possible to run multiple JDE's on the same system and be able to sign code for a specific OS (I'm planning on having JDE 4.2.1, 4.5, 4.6.1, 4.7, and eventually 5.0 on the code-signing VM). If so, do I need multiple keys - one for each JDE version - or is there some way to use the same keys for the different versions?
Thanks for any help in answering this.
It's certainly possible to migrate the keys between machines - We have a set of keys that have been used on Windows XP, Mac OS X and Linux machines.
If you look in one of your BlackBerry JDE Component Package X.Y.Z\bin directories after you've used the signing tool manually you'll see these files:
sigtool.csk
sigtool.db
These are the files you need. Simply copy them to the equivalent location in the alternate JDE trees and you will be able to use them for 'multiple targets'. I've not done this with 4.7.0, but have with 4.6.0, 4.5.0, 4.3.0, and 4.2.1. We're run the signer using
java -jar bin/SignatureTool.jar
I'm not sure whether other methods would work.
Migrating to UNIX-like build machines introduces a twist, and this is why I think RIM say the keys are not portable - the SignatureTool application seems to not detect the operating system-specific directory path separator character. The upshot is that it looks for the key files in these locations, even on a UNIX machine (note the backslashes):
bin\sigtool.csk
bin\sigtool.db
when you'd think it would look for bin/sigtool.csk for example. A solution for this is simply to create soft links with these names that point to the actual files. In the component package top-level directory we do this:
ln -s bin/sigtool.db bin\\sigtool.db
ln -s bin/sigtool.csk bin\\sigtool.csk
I've only signed in one VM - a Windows XP image. It worked fine.
Another solution is to just fix the problem with SignatureTool (FYI, RAPC has similar issues), as this blog describes:
http://www.slashdev.ca/2008/03/16/using-sigtool-in-linux/