[Mono-dev] mono make on cygwin 32 including atomic.c windows x86 has atomic operations

Rodrigo Kumpera kumpera at gmail.com
Thu Sep 5 00:22:01 UTC 2013 

I just pushed a fix for that.


On Wed, Sep 4, 2013 at 7:32 PM, Mark Lintner <mlintner at sinenomine.net>wrote:

>
>
> I previously found an issue in mingw/include/ddk/ntapi.h
>
>
> /* FIXME: Unknown definitions */
>
>
> typedef PVOID POBJECT_TYPE_LIST;
>
> typedef PVOID PEXECUTION_STATE;
>
> typedef PVOID PLANGID;
>
>
> commenting out as follows:
>
>
> /* FIXME: Unknown definitions */
>
>
> typedef PVOID POBJECT_TYPE_LIST;
>
> //typedef PVOID PEXECUTION_STATE;
>
> typedef PVOID PLANGID;
>
>
>
> Is this a problem for Cygwin or ming?
> ----------------------------------------------
> went back to the mono directory and
>
> did make clean
> followed by make
>
> It looks like a mingw header problem not mono as I thought. It would seem
> like everyone should hit this now that mono must use mingw to do cygwin
> build. I guess this has to be fixed by mingw.
>
>
>
>
> -------------------------------------------------------------------------------------------------------------------
>
>
>
> Unfortunately build does not complete. There is more. Next stop is here.
> Why is atomic.c even here? I think somehow configure is setting up the
> makefile wrong.
>
>
>
> ogc.a -L../../eglib/src /usr/src/mono/eglib/src/.libs/libeglib.a -lws2_32
> -lpsap
> i -lole32 -lwinmm -loleaut32 -ladvapi32 -lversion
> ../utils/.libs/libmonoutils.a(atomic.o): In function
> `InterlockedCompareExchange
> 64':
> /usr/src/mono/mono/utils/atomic.c:240: undefined reference to
> `_imp__pthread_mut
> ex_lock'
> /usr/src/mono/mono/utils/atomic.c:246: undefined reference to
> `_imp__pthread_mut
> ex_unlock'
> collect2: error: ld returned 1 exit status
> Reaping losing child 0x8029f118 PID 6776
> Makefile:1243: recipe for target `pedump.exe' failed
> make[3]: *** [pedump.exe] Error 1
> Removing child 0x8029f118 PID 6776 from chain.
> make[3]: Leaving directory `/usr/src/mono/mono/metadata'
> Reaping losing child 0x800652c0 PID 8344
> Makefile:429: recipe for target `all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> Removing child 0x800652c0 PID 8344 from chain.
> make[2]: Leaving directory `/usr/src/mono/mono'
> Reaping losing child 0x80060de8 PID 8968
> Makefile:510: recipe for target `all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> Removing child 0x80060de8 PID 8968 from chain.
> make[1]: Leaving directory `/usr/src/mono'
> Reaping losing child 0x80088b28 PID 8692
> Makefile:437: recipe for target `all' failed
> make: *** [all] Error 2
> Removing child 0x80088b28 PID 8692 from chain.
>
>
>
> grep tells me this really is not defined
>
>
>
> me at My-PC <me at My-PC> /usr/src/mono
> $ grep -rl _imp__pthread_mutex_unlock .
> ./mono/utils/.libs/atomic.o
> ./mono/utils/.libs/libmonoutils.a
> ./mono/utils/atomic.o
>
>
>
>
>
> So looking at atomic.c
>
>
>
> #if defined (TARGET_MACH) && defined (TARGET_ARM) &&
> (defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) ||
> defined(__ARM_ARCH_7S__))
>
> gint64 InterlockedCompareExchange64(volatile gint64 *dest, gint64 exch,
> gint64 comp)  __attribute__ ((naked));
>
> gint64
> InterlockedCompareExchange64(volatile gint64 *dest, gint64 exch, gint64
> comp)
> {
>  __asm__ (
>  "push {r4, r5, r6, r7}\n"
>  "ldr r4, [sp, #16]\n"
>  "dmb\n"
> "1:\n"
>  "ldrexd r6, r7, [r0]\n"
>  "cmp r7, r4\n"
>  "bne 2f\n"
>  "cmp r6, r3\n"
>  "bne 2f\n"
>  "strexd r5, r1, r2, [r0]\n"
>  "cmp r5, #0\n"
>  "bne 1b\n"
> "2:\n"
>  "dmb\n"
>  "mov r0, r6\n"
>  "mov r1, r7\n"
>  "pop {r4, r5, r6, r7}\n"
>  "bx lr\n"
>  );
> }
>
> #else
>
> gint64
> InterlockedCompareExchange64(volatile gint64 *dest, gint64 exch, gint64
> comp)
> {
>  gint64 old;
>
>  pthread_mutex_lock (&spin);
>
>  old = *dest;
>  if(old == comp)
>   *dest = exch;
>
>  pthread_mutex_unlock (&spin);
>  return old;
> }
>
>
>
>
>
>
> Windows has interlocked operations. The if statement does not seem to be
> relevant to windows, neither option is correct for windows, I don't believe
> it should be building this file on windows and intel hardware. This all
> built fine a couple of months ago and it builds fine on Centos 6.4 but then
> Centos has pthreads.
>  ------------------------------
> *From:* Zoltan Varga [vargaz at gmail.com]
> *Sent:* Tuesday, September 03, 2013 11:45 PM
> *To:* Mark Lintner
> *Cc:* mono-devel
> *Subject:* Re: [Mono-dev] mono from git will not build on cygwin 32
>
>   Hi,
>
>    Try running with make V=1, that will print more information.
>
>             Zoltan
>
>
> On Wed, Sep 4, 2013 at 6:05 AM, mlgo <mlintner at sinenomine.net> wrote:
>
>> I updated Cygwin and now it no longer supports compilation of mono with
>> gcc.
>> There is no way to backlevel it. I found Zoltan's suggestion to use this
>> configure statement:
>>
>> "Hi,
>>
>>   mono master can be built on windows using the mingw cross-compiler gcc,
>> i.e. install the mingw-gcc package, and configure using:
>>
>> ./autogen.sh --host=i686-pc-mingw32
>>                   Zoltan"
>>
>>
>> I'm using mono from git. Cygwin has all the recommended packages and I did
>> not install the gcc-g++ but installed all mingw packages.  The build now
>> always stops here. I have reinstalled Cygwin several times and pulled a
>> new
>> mono each time. I'm wondering now since there is a 64 bit Cygwin and a I
>> have 64 bit machine should I be configuring with mingw64 or something.
>> However I had the old Cygwin environment down to a science and now I'm
>> crippled again. Has anybody seen this yet. This seems like something
>> configure is failing to generate properly to map ming types to mono types.
>> Zoltan will know what to do about this if anybody. It doesn't seem like it
>> could be a bug in ming.
>>
>> al':
>> process.c:912:3: warning: passing argument 1 of 'EnumProcesses' from
>> incompatibl
>> e pointer type [enabled by default]
>> In file included from ../../mono/io-layer/io-layer.h:34:0,
>>                  from ../../mono/metadata/domain-internals.h:15,
>>                  from ../../mono/metadata/metadata-internals.h:8,
>>                  from ../../mono/metadata/class-internals.h:10,
>>                  from ../../mono/metadata/object-internals.h:8,
>>                  from process.c:16:
>> /usr/i686-pc-mingw32/sys-root/mingw/include/psapi.h:108:13: note: expected
>> 'DWOR
>> D *' but argument is of type 'guint32 *'
>> Makefile:2221: recipe for target `libmonoruntime_la-process.lo' failed
>> make[3]: *** [libmonoruntime_la-process.lo] Error 1
>> make[3]: Leaving directory `/usr/src/mono/mono/metadata'
>> Makefile:429: recipe for target `all-recursive' failed
>> make[2]: *** [all-recursive] Error 1
>> make[2]: Leaving directory `/usr/src/mono/mono'
>> Makefile:510: recipe for target `all-recursive' failed
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/usr/src/mono'
>> Makefile:437: recipe for target `all' failed
>> make: *** [all] Error 2
>>
>>
>>
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/mono-from-git-will-not-build-on-cygwin-32-tp4660749.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130904/c78d7fd3/attachment.html>

More information about the Mono-devel-list mailing list