I am trying to build and deploy a gaia build from git repo in Windows. I am trying to deploy it in অ Flame.
I am trying to do it in a windows 7 with cygwin installed. After installing everything this is the error I am getting
This works just fine in a Linux machine, but I need to do this in Windows since right now I have access to it only.
Any pointers to what I am doing wrong here?
I'm afraid it's not going to work without significant effort for several reasons. Much better to use a VM with Linux on as even if it did work it will be really slow. Windows is slow at handling lots of file access and Cygwin slows it down even more.
For example in making a simple change to config.sh (full stack build) so it works on Cygwin I found it took hours to run (on a decent PC). And then I had a couple of corrupt git repos I had to hand fix.
I also looked at getting gaia's make to work, but stopped after the problem just got bigger.
Here's what I found for future reference
The build is not really portable, it expects a linux like environment
While cygwin gives good linux emulation most of the tools run are win32 native and handling path conversion for them requires not trivial changes due to assumptions. For example you can switch to the Win32 XPCshell and hack the command line paths to use cygpath, but environment variable are an extra source of dependency in the JS scripts and are all unix paths. ( I did manage this part).
these path and environment dependencies get magnified with the C build chain and other tools.
You need to change the mount to use noacl or else cygwin attaches ACLs to simulate file properties, thus breaking things. It's might even be a little faster without ACLS
I also tried MinGW which provides native versions without the emulation so should be faster. However it falls short of the requirements and its automatic path conversion heuristics get in the way.
you need to turn of any antivirus prog as they slow it down. in fact the very first time I used the old FIrefox WIndows build it would crash after a long time. Turned out to be a mem leak in the AV :(
So all-in-all it's too much hassle in terms of dev time to convert and probably maintain. A true Windows build would be better but then it's so easy these days to run a VM. You can even share directories between the guest and host so could flash from Windows.
I also tried with cygwin, but was unable to build the gaia source code on windows.
It's not straightforward to build the gaia source code on windows. Please follow these steps:-
Download Mozilla Build from MozillaBuild - Mozilla Wiki and install the tools in c:/mozilla-build (preferred). It includes everything (make, wget, python etc) you need to build gaia source code.
Run start-shell.bat. If build process failed with this batch file then run start-shell-msvc2013.bat if you have Visual Studio 2013 or start-shell-msvc2015.bat if you have Visual Studio 2015. (You need Visual Studio for the second step).
Browse to the gaia source code directory using the command cd Mozilla/gaia.
Run DEVICE_DEBUG=1 make command. Don't run DEVICE=1 make or make command (because you won't be able to debug the apps, I was able to connect to the Firefox OS 2.2 but was not able to debug the apps when I ran these commands).
If you are running this command for the first time, it will download the b2g_sdk otherwise it will create a folder profile with your custom profile.
Open the WEBIDE using Firefox (Nightly preferred) and point to the profile folder you just created.
Links for your reference:-
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Developing_Gaia
https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/Different_ways_to_run_Gaia
https://developer.mozilla.org/en-US/docs/Tools/WebIDE/Troubleshooting
https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/Making_Gaia_code_changes
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites
Related
Question
My app has some bugs that only occur on older macOS versions. How can I debug them?
Approaches
Below are all of the approaches I'm aware of.
Approach 1: Debug using Xcode
The idea is to just use Xcode to build and debug the project on the older macOS version.
Unfortunately the latest version of Xcode that is available on the old macOS cannot open my .xcodeproj file.
I have come accross 2 possible solutions:
1.2 Change Project Format
I have set the Project Format to be compatible with a very old version of Xcode (8.0) but that didn't help.
2.2. Change manually edit project files
You can manually edit the project file with a text editor and decrease the objectVersion to get the project to open. See this SO Answer.
This worked for me.
To get the project to compile on the old macOS version, I had to do a few more hacks:
Set objectVersion to 46
Comment out all code that uses unavailable APIs
Set 'minimumToolsVersion' in Interface Builder files your Xcode version
Set the Code Signing Identity to "Ad Hoc Code Sign" and disable hardened runtime on all targets
After these steps I could build and debug my app on the old macOS version! Some things didn't compile properly, but luckily, in my case, this was good enough to figure out all of the bugs that were occuring on older macOS versions!
Update:
I just tried to do the same thing with a Swift project (The other one was ObjC only) and it was so much work that I almost gave up on it. See the bottom of this post for more info.
Approach 2: Debugging from the command-line
The second idea is to use the lldb debugger directly from the command line on the old macOS. This works fine. But the problem here is that it will only show me assembly code. To debug in an efficient way you want to be able to step through source code line by line. This is achievable but it's complicated:
The following data needs to be present on the old macOS:
The app/executable itself
The source code used to build that executable
Some sort of 'debug data' that links machine instructions in the executable to lines in the the source code
You need to tell lldb how to link that data together
Here's an article on how to do this: https://medium.com/#maxraskin/background-1b4b6a9c65be
This approach is very promising but I gave up on it for now because the setup and debugging workflow sounds very slow and tedious and Approach 3 seemed to be much easier. However I can't get Approach 3 to work at all so far. I'll update this once I look into it more.
Sidenote about 'debug data'
I don't really understand some things about the 'debug data' mentioned above.
From what I gathered, this debug data normally comes in the so called DWARF data format. Debuggers usually extract this DWARF data directly from .o files. .o files are a byproduct when compiling C code (and code in other languages too?).
However for storing and transferring the DWARF data to other machines you can also store it in so called .dSym files.
Now what confuses me is what role does 'code stripping' play in all of this? Because code stripping is described on the internet to "remove debug data from the exectable". My question is - what kind of debug data is in the binaries when you don't strip them? Is it the same DWARF data from the .dSym and .o files which can be used to step through code line by line in a debugger? Or is it a subset of the DWARF data? Or is it something completely different?
Either way here's approach 3:
Approach 3: Remote debugging from the command-line
The lldb debugger has the built-in capability to connect to another machine remotely, then automatically upload the executable you want to debug to the remote machine, and then run and debug that executable.
In theory, this should also let the debugger automatically locate the source code files and the DWARF data - allowing you to step through source code line by line without any extra effort.
This would make the approach much more convenient than Approach 2! So I gave it a try, using the official tutorial.
There are many things that aren't explained in the official tutorial, and it was very hard to Google the various problems I ran into. Here are some things that I had to do which are not mentioned in the tutorial:
I downloaded the latest Xcode and got the debugserver and lldb command-line-tools that are buried deep inside that app bundle. I ran debugserver on the remote machine and connected to it using lldb on the local machine.
The official tutorial talks about using the lldb-server command-line-tool instead of debugserver. But I couldn't find lldb-server in the latest Xcode app bundle nor the latest Xcode Command Line Tools. (The ones that show up at /Library/Developer/CommandLineTools after using xcode-select --install). Older Xcode versions still contained both lldb-server and debugserver and from my testing they behave the same. Only the command line arguments they take are a little different. So I used debugserver instead of lldb-server.
Then I had to open a wifi hotspot on the remote machine using the Create Network... option in the menu bar, and then connect the local machine to that wifi hotspot.
On the remote machine I started the debugserver with this command debugserver 0.0.0.0:1234. 0.0.0.0 means "accept connections from any IP address" and 1234 means only accept connections on port '1234'
On the local machine I started lldb and inside the command prompt I used the following commands:
platform select remote-macosx
platform connect connect://<remote ip address>:1234
Replacing <Remote ip address> with the IP address of the remote machine which you can find under System Preferences > Network.
1234 means 'connect on port 1234'
I don't know where the structure of this URL comes from. I found it by accident
After this, lldb on local and debugserver on remote will both say they connected successfully.
target create <path to appbundle>
Replacing <path to appbundle> with the appropriate path
After this, lldb looks like it's uploading the files to the remote machine, but debugserver on the remote machine won't react. Not sure if that's normal.
process launch
This should launch the app on the remote machine, but instead it just give this cryptic error: error: attach failed: invalid host:port specification: '[<Remote ip address>]'. (Where <Remote ip address> is the actual IP address of the remote machine).
I tested this many times on different macOS versions. Local was always Ventura 13.0 and remote was 10.14 or 10.13. Both lldb and debugserver had version lldb-1400.0.38.13.
I don't know what else to try to make remote debugging using lldb work.
Sidenote about 'GDB'
I haven't looked into using the classic gdb debugger yet. Should I? I heard it's less buggy than lldb and I assume my problems with remote debugging are due to bugs in lldb. If it worked as advertised, remote debugging should be by far the easiest way to solve my problem.
I'll update this if I learn more about using GDB for remote debugging.
I'll be very grateful for any tips or clarifications! I will also update this post if I find out more, so this can hopefully be a useful resource for anyone trying to debug a Mac app on an older macOS version.
Update/Conclusion
Approach 1.2 worked for me!
(Approach 1.2 is getting the project to build in an older Xcode by manually editing project files.)
If you want to further explore the other approaches I've come across, here are my thoughts on how they compare with Approach 1.
Comparison to Approach 2
(Approach 2 is debugging from the command-line)
Pros of Approach 1
Much nicer debugging workflow - You can use the Xcode GUI instead of the command-line, and you won't have to copy over 3 different files to a new machine every time you want to test a change to your code.
Pros of Approach 2
You don't rely on hacking the project files which might not work for all situations. E.g. this might introduce new bugs in your compilation target that interfere with the bugs you actually want to debug.
Comparison to Approach 3
(Approach 3 is remote debugging from the command-line.)
Approach 3 is the holy grail. The debugging workflow would be very nice, no manually transferring files between computers like Approach 2, no weird brittle hacks like Approach 1.
Sadly I couldn't get Approach 3 to to work after days of trying, so I've given up on it now. If you have tips on how to make it work please do let me know!
Update 2
Approach 1.2 worked for my orginal project which was ObjC only. I've now tried to apply it to a Swift project and it's so much more work.
I had to spend hours rewriting code which was written for Swift 5.6 to compile under Swift 5.1 - it did work in the end but it took hours.
Unfortunately I haven't found a way to get a newer Swift version to compile under the older macOS, so I had to resort to this.
So if you're using Swift in your project, Approach 1.2 might be too much work to be feasible.
Update 3
Another possible solution might be using a Virtual Machine but I can't find any examples for how to do this on the internet.
First with the background...
We have a Linux server that supports multiple projects.
The Clearcase server and repository are installed on this Linux server.
Different projects require different cross-compilers and libraries, and all of them are installed on the server.
User can choose different tool sets by running different scripts, which exports different environment variable values such as include paths and compilers.
User needs to run cleartool to mount the repository.
Developers develop in Eclipse and have two options:
SSH into the server and run Eclipse through with X11 tunneling.
Install Eclipse locally on their Windows machine and invoke builds from the SSH terminal.
Now:
Problem with #1 is that Eclipse operations (typing, content assist, etc) are extremely laggy.
Problem with #2 is that the developers need to go through extra hoops to build their code.
This is what I have tried:
Set up Remote System Explorer, which allows remote editing of files and remote running of the compiler:
How to build a c++ project on a remote computer in Eclipse?
This approach works perfectly for files that do not need special environment variable values and mounting of Clearcase repository, but I could not figure out how to get all of these things to integrate.
It would be great if someone can let me know how I can direct RSE to run a script (may be different per project) to set the environment variables and to run the cleartool commands to mount the repository so that it can locate the files.
The cleartool command arguments would be different per user for setting up a particular view.
Some extra info that may help:
I have root access to the development server
The Clearcase filesystem is mapped to a drive on the Windows machine
Thanks in advance for saving me hours of frustration dealing with a slow network!
==================
Additional detail per comments:
- The VOB storage is located locally on the Linux server. We would SSH to the server and start Eclipse there, therefore the delay should not be due to dynamic vs snapshot view and GUI performance seems to be the real problem.
- We also mount the same view on Windows by using Region Synchronizer. When running the local copy of Eclipse installed on Windows, there is no performance problems.
So this question can probably be solved by answering either question:
1. How to improve X11 performance such that development on Linux will suffice?
2. How to set up Windows Eclipse to perform all the steps mentioned above when building projects?
I came here a similar question to your part two, but alas, no one has answered it. However, I have an answer to your part one: https://www.nomachine.com/. It speeds up X11 forwarding considerably.
I am having issues with finding all of the necessary files to actually install Cygwin correctly when not using the premade setup utility. The reason behind this is the fact that my company computer blocks the usage of the .exe, and won't give me clearance to install it, (they say it isn't needed for the job) but expects me to perform certain tasks that Cygwin would make much simpler.
So my question is thus; is there somewhere/someone that would have a list of packages that I would need to manually install from one of the mirrors to make Cygwin run correctly?
Well,
This is a new answer to an old question, but it might be helpful for someone...
Just run the installer with -B switch, for example:
setup-x86_64.exe -B
You should install it then on a path where you have rights.
If you don't need the full POSIX compatibility (which I'm guessing you don't, if the Unix subsystem isn't required for your job), I'd generally suggest you go with Mingw rather than Cygwin.
Sadly, Mingw also has an installer these days. It probably also requires admin (try it and see). However, you can download the individual components you need if you want to do it that way. That shouldn't require admin, so it would probably get you exactly what you want.
Mingw is also more corporate-friendly from a licensing standpoint, as its compiler doesn't render code built with it GPL like Cygwin's does.
Generally the rule is:
If you want to use Unixy tools to help with your native Windows development, you want Mingw.
If want to port a full (POSIX) Unix program to windows, you want Cygwin (and perhaps a support deal with Red Hat to get around the licensing problem).
There's a writeup on getting Cygwin [to work] on portable storage devices.
Boiling it down, you'd have to do this on a machine that does give you .exe/admin access to write to a 'stick, then run from the stick at work.
On the off-chance that super-lockdown-site allows you to run USB devices.
Use the GNUWIN32 utilities instead. http://gnuwin32.sourceforge.net/
That way you can choose only the .exe installs that you need, and it will be much easier to justify specific utilities than a humongous system install. If you hunt around on the site you can find the files directory where you can download a single utility, and if you get the -bin.zip version, then you can extract just the needed .exe file which would be even easier to justify and would not require your IT people to test an untrusted install package.
Stupid draconian rules or no, I would not recommend trying to thwart your employers rules. Try working to improve the situation or find another one.
But technically speaking if you can get a complete Cygwin install somewhere, you can copy the entire cygwin folder enmasse. There are a few things that you will want to change similarly to how I configured my cygwin installation to run from a thumb drive. I actually installed on my HD, copied it to the thumbdrive and then changed the batch file and a few other things to make it work. Here are the details: http://fadedbluesky.com/2011/portable-cygwin/
You could try installing it on another machine outside of work. After installing, copy the installed product's tree and Registry keys and environment settings to a CD or flash drive. Then you would have a DIY installation that you can copy and import settings manually. The installer doesn't do a whole lot else.
Don't count on job security if you're bypassing IT mandates after being explicitly told no, though. Getting an exception to the rule by submitting proper documentation through the proper process is usually the way to go.
You'll also have to hope that they aren't blocking the Cygwin programs and any Registry edits as well. It's not hard to find this sort of thing on a machine, either.
Greetings,
I feel kinda stupid for asking this, but I want to set the windows sdk build environment so that any process (including some non MS developer tools) can access the correct setup, without me trying to inject setenv.cmd /x86 into every process's startup.
I can't seem to find the right search terms for this, and I don't want to hand pick various exes and dirs to include them in the path.
Is there a way to make setenv.cmd effect the whole windows environment? (xp)
Best Regards
Seref
It isn't impossible, you could use Control Panel + System and add the environment variables set by the .cmd file. Doing so has several troublesome consequences though:
the build tools will only work on your machine, you'll have a hard time getting a build going on your colleagues' machine or a build server. Especially since you no longer try to keep it compatible.
you'll have a very hard time switching between a debug and release build or a x86 and a x64 build
you'll have a very hard time when you start using a new release of the SDK, especially when you temporarily need to switch back and forth between the old and the new release.
I'm pretty sure you'll deeply regret doing this, eventually.
I got a question of using Eclipse to develop for embedded Linux on a Windows host
Here are now I have and where I am.
1. a Windows host that have the latest Eclipse + CDT (c/c++ development tools) installed
2. a Ubuntu host (ssh + samba installed) that contains sources and toolschain to build the project. (the windows and ubuntu hosts are sitting within one network segment (In LAN).)
3. I can use the following commands to build this project under Ubuntu.
# chroot dummyroot
# cd /home/project/Build
# sh Build date +%Y%m%d%H%M%S
4. I am now trying to create an eclipse C++ project to achieve the goad of the step 3, but I have been stuck here for a while. any ideas of how it can be done?
Speaking from experience, attempting to develop embedded Linux on a Windows host is a world of pain and frustration. Emphasis on attempting -- I'd like to meet someone who completed a serious project in this way, or who can explain how working in Windows made job easier.
Windows can be a great development environment for many tasks, but it's a lousy, lousy environment for embedded Linux. There are tools out there to help you do this, but everything is much harder compared to working on a Linux host. The toolchains are older and buggier. You will constantly fight with your crosscompilers and GNU autotools trying to get packages to compile. (Wait till you try to compile one of the many packages that needs to build an intermediate binary and then executes that as part of its build process.)
You probably have reasons for keeping your desktop in Windows -- just run a Linux virtual machine.
Eclipse CDT can execute arbitrary commands, such as
ssh username#target build_script
using the external builder. If you are using gcc on the target eclipse cdt can parse the output of the gcc and make from the ssh session and send you to the correct source path (if that path matches the path generated by gcc). Although this might not work windows->linux
With Embedded Linux, I've attempted to run Virtual Machines using Ubunutu, Xubutunu, Debian. I have been developing for a long time. I design hardware and develop low level firmware, to test said hardware. I cannot get anything to work on instructions given, as in an unified IDE and development system such as I am used to (i.e. Codewarrior, MPLAB, Code Composer) If Embedded Linux is so useful and easy how is it I cannot get a single one of instructions from Yocto, Freescale, Timesys, anywhere to work? Every-time there is a directory change, or a directory that no longer exists, or even a file that is not there. Surely there something that I can use..