[Lldb-commits] MinGW compilation support

[Virgile Bello]

Sorry, quick patch update to fix
DataBufferMemoryMap::MemoryMapFromFileDescriptor.


On Sat, Jul 13, 2013 at 12:24 PM, Virgile Bello <virgile.bello at gmail.com>wrote:

> Ok, attached the updated patch.
> It improves quite a few things:
> - readded some libraries such as PluginObjectContainerBSDArchive and
> SymbolVendorELF
> - added missing functions in Windows.cpp
> - full support for cmake under MingW.
>
> Note that for automake build, you need to add std=c++11 and
> -DLLDB_DISABLE_PYTHON (automatic for cmake build).
>
>
> On Thu, Jul 11, 2013 at 10:02 AM, Virgile Bello <virgile.bello at gmail.com>wrote:
>
>> On Thu, Jul 11, 2013 at 4:18 AM, João Matos <ripzonetriton at gmail.com>wrote:
>>
>>> On Sun, Jul 7, 2013 at 10:44 AM, Virgile Bello <virgile.bello at gmail.com>wrote:
>>>
>>>> Here is a patch allowing compilation of LLDB with MinGW.
>>>> (it still compiles on Linux after the patch)
>>>> Can someone please review (and merge in trunk if everything seems good)?
>>>>
>>>> Soon some other patches should follow:
>>>> - 1 for MSVC compilation
>>>> - 1 to add a lldbProcessWindows using Win32 debugging API, so that
>>>> gdb/clang compiled programs can be debugged in Windows.
>>>>
>>>> Hopefully I can get all this into trunk quickly so that I don't need to
>>>> rebase/merge too much.
>>>> Thanks!
>>>>
>>>
>>> Just looked at the patch and it mostly LGTM. I think long-term it would
>>> be nice to have the POSIX-specific stuff a little better abstracted,
>>> instead of trying to hack around it in the Windows port, though for now it
>>> seems the way forward and it can be fixed incrementally in the future.
>>>
>> I agree. I tried to keep the changes as small as possible (my priority
>> was that it would be easy to integrate into trunk) but long-term it might
>> require some more abstraction.
>>
>>
>>>
>>> Some questions:
>>>
>>> 1. Why do we need to define these in "lldb-socket.h"?
>>>
>>> +#define NTDDI_VERSION NTDDI_VISTA
>>> +#define _WIN32_WINNT _WIN32_WINNT_VISTA
>>>
>>> Can't you just include "lldb-windows.h" which already includes Windows.h?
>>>
>> You're totally right.
>> Actually I thought that was in the MinGW patch but I did right after in
>> the MSVC branch.
>> I will backport it and improve this patch a little bit then, in order to
>> avoid further changes later.
>>
>>
>>> 2. Why are you excluding lldbPluginObjectContainerBSDArchive
>>> and lldbPluginSymbolVendorELF from the MinGW build?
>>>
>> No ar.h for lldbPluginObjectContainerBSDArchive  (same as before, I
>> patched it in MSVC branch so I should probably backport that as well).
>> For lldbPluginSymbolVendorELF I will double-check.
>>
>> I will soon get back to you with an updated patch covering 1 and 2.
>>
>>
>>> 3. Why add support for two build systems (CMake and automake)?
>>>
>>> IIRC LLVM and Clang are looking to kill all non-CMake build scripts to
>>> ease maintenance and reduce duplication, so IMHO LLDB being an umbrella
>>> project should do the same.
>>>
>> I see, so I don't need to support Automake makefile anymore? Good to
>> know. Actually I was still using it for the MingW build (and CMake for MSVC
>> build), but never tested CMake + MingW. I have to give it a try and check
>> everything works fine, esp. if it is the future-proof way.
>>
>>
>>>
>>> Apart from that, looking forward to see this getting in and for further
>>> Windows debugging patches.
>>>
>>> --
>>> João Matos
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20130714/16b1df23/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lldb-mingw32-v3.diff
Type: application/octet-stream
Size: 75805 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20130714/16b1df23/attachment.obj>