[Lldb-commits] MinGW compilation support

[João Matos]

LGTM.

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

> 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
>>>
>>>
>>>
>>
>


-- 
João Matos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20130713/d71fe8b9/attachment.html>