Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
LLNode Windows support #17
I thought I’d open this issue to discuss whether Windows support for LLNode is something anyone wants.
I’ve got and LLDB build up and running on Windows so I had a chance to try building LLNode on Windows. Running gyp_llnode worked fairly well.
The resulting Visual Studio project created by gyp required a little tweaking (mostly things I could google for). The main issue was that LLNode uses the getopt library which isn’t on Windows by default. Given that the getopt problem could probably be fixed running LLNode on Windows looks do-able but would need a bit of work and would probably break fairly quickly unless someone was using it regularly.
There’s two reasons why someone might want to do this:
I’m not sure how important the first scenario is but the second one might be useful to developers with Windows machines who deploy to Linux. Of course you do have to get LLDB for Windows, probably by building it yourself, which isn’t hard but it is quite time consuming. (Developers with Mac’s who deploy to Linux are effectively already supported.)
Any thoughts? Does anyone else have a strong need for this? (I’m using a Mac so I’m neutral.)
referenced this issue
Jul 13, 2016
I think the moving the project under Node.js would be great, it would probably improve the visibility and hopefully adoption and participation as well.
The topic of finding a good home for work form the post-mortem WG is on the agenda for monday. See: nodejs/post-mortem#31. And more specifically this issue is to discuss the issue for work like llnode (as well as others) from the post-mortem WG: nodejs/post-mortem#30
So I was thinking it was more likely in the scope of the post-mortem WG than the diagnostics WG but there is likely some overlap between those WG's so that may not matter.
Trying LLDB/LLNODE on Windows. There seems to be a problem in API/SBDebugger.cpp (LLDB code). It has a hard-coded mangled name for the plugin entry point:
Not sure the comment is correct, as we have it working fine on OSX. Using Windows VS2015 the mangled name I get is