I'm working on a project in Xamarin.iOS, and it happens to go through a build server (running on a Mac).
The build seems to commonly fail, but even with the --verbose or -v it seems to Silently fail. For example, right now, it seems to fail after optimizing the graphics for iOS. The last line of the build says Build complete -- 0 errors, 0 warnings. But then I get a Build step 'Execute shell' marked build as failure from Jenkins. I know that this is a failure in the mdtool build, because I have had a successful build before, and I know there are several more steps before it actually succeeds.
The next step in the successful process should be Compiling to native code, but for some reason it fails before getting to that, or at least outputting it to the console.
Thanks in advance for the help!
There's a few places in the mdtool build logic that didn't properly catch exceptions when executing shell programs which I (hopefully) fixed for Xamarin Studio 4.0.2.
Without seeing the full build log it's hard to say for sure, but it might be that whatever shell command that it is trying to execute either doesn't exist or isn't marked with execute permissions.
The programs that I can think of off the top of my head that mdtool will invoke for the iOS builds are:
pngcrush (optimizes .png files)
plutil (optimizes .plist and .strings files)
codesign (although this one gets called after compiling to native code)
and of course, mtouch which is what is used to compile IL to native code. The mtouch command is part of Xamarin.iOS while the other 3 utilities are part of Mac OS X (or Xcode).
The solution for the other person with a similar problem that I helped debug a week or 2 ago was because he had modified his PATH environment that launchd launched apps with to not include /usr/bin and so mdtool couldn't find the utility programs listed above.
I'm not very familiar with Jenkins (I know we use it at Xamarin, but I'm not part of the team that does), so make sure that the PATH environment that it launches mdtool under is setup to include /usr/bin.
Hope that helps.
Related
The library mylib consists of the library proper, in directory lib/, and a test suite, in directory test/. It is completely under CMake control:
mylib/CMakeLists.txt:
...
add_subdirectory(lib)
add_subdirectory(test)
...
mylib/lib/CMakeLists.txt:
...
add_library(my_lib ${src_files})
...
mylib/test/CMakeLists.txt:
...
add_executable(mytest mytest.c)
target_link_libraries(mytest mylib)
Build steps are:
mkdir build
cd build
cmake ..
make
ctest # or make test
make install
Works under Linux, stable since many years. Under Windows10 though, a message window pops up, entitled "mytest.exe - System error": "The code execution cannot proceed because mylib.dll was not found. Reinstalling the program may fix this problem."
No, installing (rather than reinstalling) would not be a good solution: I need to first test the library before I install it (btw: this excludes most solutions proposed in response to somewhat similar questions).
Isn't CMake supposed to work cross-platform? What is the minimally invasive adjustment to make the above build steps work under Windows?
The right way of doing this on Windows is to populate the PATH environment variable for the test run:
set_tests_properties(your_test_name
PROPERTIES
ENVIRONMENT PATH="path-containing-your-dll")
I believe you can use generator expression if path-containing-your-dll is a function of an artifact that you generate in your build.
Cherry on top: since cmake 3.13, the variable VS_DEBUGGER_ENVIRONMENT can also be set on the target for having a nice debugging behaviour inside Visual Studio (eg. being able to debug the application directly from Visual instead of going through ctest).
I've seen this question asked but never specifically for Mac. My company is using TeamCity on a Mac Mini to do our iOS and android builds. We would use windows but, iOS builds require a Mac with Xcode. I have not been able to satisfy this condition. I can see that there are multiple versions of MSBuild (and Xbuild) already on my machine. Here is what I tried:
set an environment variable for MSBuildTools12.0_x86_Path using launchctl setenv (tried the bin directory of every instance of MSBuild existing on my machine), rebooted before checking TC
setting env.MSBuildTools12.0_x86_Path entry in buildAgent.properties
setting system.MSBuildTools12.0_x86_Path entry in buildAgent.properties
logging into TeamCity, going to my build configuration, going to the "parameters" tab and adding a new parameter for env.MSBuildTools12.0_x86_Path
After all of the above failed to satisfy the condition, I tried grabbing version 12 of MSBuild from a Windows machine, copying it to my Mac and pointing to its "Bin" directory instead, and repeating all bullets above.
The path was /Users/myusername/MSBuild/12.0/Bin. This bin directory contains MSBuild.exe, an MSBuild folder, a bunch of DLLs and more.
Again, this failed to change the outcome of the unmet condition in TeamCity. The frustrating thing is that TeamCity isn't giving me details. I don't know if it's still complaining that the path isn't even set (and where it is even looking for that path definition), or if it SEES that the path is set but it's not pointing to a folder it recognizes as MSBuild. I'm completely in the dark.
Does anyone have any guidance for me on this? I feel I've exhausted all paths to a solution. Thank you so much, in advance.
I figured it out on my own. On the Mac, you have to do an "MSBuild" runner type and pick "Mono xbuild 4.5" for the version. I used "x86" for the run platform and set a parameter for Mono4.5_x86 to point to xbuild. But it was trying to run the 64 bit version of mono and I found no way to set a command line argument for mono to tell it I want --arch=32 so I ended up having to link the mono executable to mono-sgen32 to get the build to finally work.
During linking I get this message:
LINK : fatal error LNK1101: incorrect MSPDB120.DLL version; recheck installation of this product
I have seen solutions for similar errors on previous versions of VC2013 but those did not work for me. Those include:
running C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat
adding %VS120COMNTOOLS% environment variable to the PATH environment variable
Reinstall or Repair the installation of MSVC2013 (NOT RECOMMENDED)
The first time I got this error I went ahead with a full reinstall of VC2013. I chose to take this rout because I thought maybe I had screwed up the install by installing older versions of VC after installing VC2013. Although reinstalling worked the first time, I can't recommend doing this. The MS installer seems rather broken and hung up on me on repeated attempts, resulting in the loss of 5+ hours of my life.
What are some other solutions to this problem if the first 2 options do not work?
Open Task Manager.
Check for the currently running processes mspdbsrv.exe and kill it if it is running and try again. I don't know why this works, but I have to do it every once in a while. The process comes back each time you compile and it seems random whether or not it gets stuck on this step.
Alternatively, if you do not need debug information generated, you can skip this process altogether by setting:
Project Properties -> Linker -> Debugging -> Generate Debug Info ->
No
I just had this happen. In my case, I had a statically-linked shared 'helper' lib that was compiled with the cl.exe CRT flags "-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE", whereas my target app that linked in this helper lib did not have these set. Once I added these flags to the app's cl.exe flags, all was good.
I get this error message when another compile (jenkins) is still running in the background.
Waiting for it to finish, and retry fixes the error.
I am trying to build the facebook-ios-sdk as part of my project build phases.
In short, the script checks for the build folder, and if it does not exist runs scripts/build_framework.sh
When executing the build phase script I get the following error:
Check dependencies [BEROR]CodeSign error: code signing is required for
product type 'Static Library' in SDK 'Simulator - iOS 6.0'
The build works as expected when running from the terminal.
The closest SO answer I saw was this, but it appears to be for an older version, and the link to the tutorial provided is no longer valid.
XCode is setting a lot of environment variables, and these must be interfering with the script. If you knew which environment variables were the culprit, you could clear them before running your script, but there are dozens and I didn't want to spend the time figuring that out.
Instead, I decided to run the script without XCODE's environment variables. If you run the script this way, you will only get the PATH environment variable in your new shell. This seems to fix things for me:
env -i PATH=$PATH ./Submodules/facebook-ios-sdk/scripts/build_framework.sh
I am quantitatively studying various metrics associated with automated tests. Chrome seems to have a reasonable set, so I wanted to add it to my data set. I downloaded the Chrome source code and tried to build it with VisualStudio but got several hundred errors--types not defined, identifiers not defined, etc. Has anyone out there succeeded in building Chrome under Windows? Are there tricks I need to know?
From the Chromium dev page:
Compilation failures
Some common things to think about when you have weird compilation failures:
Make sure you have SP1 for Visual Studio 2005. It's required. Really.
Sometimes Visual Studio does the wrong thing when building Chromium and gets stuck on a bogus error. A good indication of this is if it is only failing for one person but others (including the Buildbots) are not complaining. To resolve this, try the following steps:
Close Visual Studio.
Sync to the tip of tree and ensure there are no conflicts ("svn st" should not show any "C"s in front of files that you've changed).
If there were conflicts, sync again after resolving them.
Manually erase the output directory (chrome\Debug and chrome\Release. Using the command line, you can use "erase /S /Q Debug Release" from the chrome directory to do this, or "rm -rf Debug Release" if you have Unix-like tools installed.
Restart Visual Studio and open the Chromium solution.
Rebuild the solution.
If it still doesn't work, repeating this process probably won't help.
chrome_kjs.sln tempfile problems
If, while building JavaScriptCore, you see errors like:
3>Error in tempfile() using /tmp/dftables-XXXXXXXX.in: Parent directory (/tmp/) is not writable
3> at /cygdrive/c/b/slave/WEBKIT~1/build/webkit/third_party/JavaScriptCore/pcre/dftables line 236
3>make: *** [chartables.c] Error 255
...it's because the Cygwin installation included in the Chromium source is having trouble mapping the NT ACL to POSIX permissions. This seems to happen when Chromium is checked out into a directory for which Cygwin can't figure out the permissions in the first place, possibly when the directory is created from within a Cygwin environment before running mkpasswd. Cygwin then imposes its own access control, which is incorrectly restrictive. As a workaround, do one of the following:
Edit the NT permissions on third_party\cygwin\tmp to allow Modify and Write actions for Everyone and machine\Users. Cygwin is able to figure this out. Or,
Figure out what went wrong with your checkout and try again - try doing the checkout from cmd instead of from a Cygwin shell, then verify that the permissions aren't completely blank in your Cygwin installation. Or,
Bypass Cygwin's access control (NT's will still be in effect) by editing webkit\build\JavaScriptCore\prebuild.bat and webkit\build\WebCore\prebuild.bat to include the following line before invoking anything that uses Cygwin:
set CYGWIN=nontsec
Only one of these solutions should be needed.