[Mingw-w64-public] [patch] mingw-w64-crt/Makefile.am: Move compiler intrinsics to libkernel32.a
Hi, today we got a report on the cygwin-developers mailing list, which reported that linking a certain library fails, because some of the inline functions in winnt.h can't be resolved by the linker under Cygwin: http://cygwin.com/ml/cygwin-developers/2013-04/msg00010.html The problem here is that the intrinsics are linked into libmingwex.a, but libmingwex.a doesn't exist in the w32api and thuis isn't available under Cygwin. Kai and I discussed this privatly on IRC and we came to the conclusion that the most generic solution is to include the intrinsics in libkernel32.a, rather than in libmingwex.a. This allows to link against the intrinsics on both platforms, Mingw-w64 as well as Cygwin. It also matches the expectations of application programmers when reading MSDN. Apart from the fact that the functions are implemented as compiler intrinsics, their documentation on MSDN claims their availability in kernel32.lib, see, for instance, http://msdn.microsoft.com/en-us/library/windows/desktop/ms683597%28v=vs.85%29.aspx, in the Requirements section. The below patch implements this. It strips the intrinsic functions from the src_libmingwex variable and introduces a src_intrincs variable instead. It also renames src_libmingwex32 and src_libmingwex64 to src_intrincs32 and src_intrincs64. Then it adds rules for building libkernel32.a for 32 and 64 bit targets, and includes the intrinsics functions to their sources. Is that ok to check in? Thanks, Corinna * Makefile.am (src_libmingwex): Split off intrinsic functions into... (src_intrincs): ...this new variable. (src_intrincs64): Rename from src_libmingwex64. (src_intrincs32): Rename from src_libmingwex32. (lib32_LIBRARIES): Add lib32/libkernel32.a. (lib32_libkernel32_a_SOURCES): New variable. (lib32_libkernel32_a_CPPFLAGS): New variable. (lib32_DATA): Remove lib32/libkernel32.a. (lib64_LIBRARIES): Add lib64/libkernel32.a. (lib64_libkernel32_a_SOURCES): New variable. (lib64_libkernel32_a_CPPFLAGS): New variable. (lib64_DATA): Remove lib64/libkernel32.a. Index: Makefile.am === --- Makefile.am (revision 5712) +++ Makefile.am (working copy) @@ -217,21 +217,6 @@ stdio/vscanf.c stdio/vsnprintf.c stdio/vsnprintf_s.c stdio/vsnwprintf.cstdio/vsscanf.c \ stdio/vswscanf.c stdio/vwscanf.c stdio/wtoll.c\ \ - intrincs/__movsb.cintrincs/__movsd.cintrincs/__movsw.c intrincs/__stosb.c intrincs/__stosd.c\ - intrincs/__stosw.cintrincs/_rotl64.cintrincs/_rotr64.c intrincs/bitscanfwd.cintrincs/bitscanrev.c \ - intrincs/bittest.cintrincs/bittestc.c intrincs/bittestci.c intrincs/bittestr.c intrincs/bittestri.c \ - intrincs/bittests.c intrincs/bittestsi.c intrincs/cpuid.c intrincs/currentfiber.c intrincs/currentteb.c \ - intrincs/fiberdata.c intrincs/ilockadd.c intrincs/ilockand.c intrincs/ilockand64.cintrincs/ilockcxch.c \ - intrincs/ilockcxch16.cintrincs/ilockcxch64.cintrincs/ilockcxchptr.c intrincs/ilockdec.c intrincs/ilockdec16.c \ - intrincs/ilockdec64.c intrincs/ilockexch.c intrincs/ilockexch64.c intrincs/ilockexchadd.c intrincs/ilockexchadd64.c \ - intrincs/ilockexchptr.c intrincs/ilockinc.c intrincs/ilockinc16.c intrincs/ilockinc64.cintrincs/ilockor.c\ - intrincs/ilockor64.c intrincs/ilockxor.c intrincs/ilockxor64.c intrincs/inbyte.cintrincs/inbytestring.c \ - intrincs/indword.cintrincs/indwordstring.c intrincs/inword.c intrincs/inwordstring.c intrincs/outbyte.c\ - intrincs/outbytestring.c intrincs/outdword.c intrincs/outdwordstring.c intrincs/outword.c intrincs/outwordstring.c \ - intrincs/rdtsc.c intrincs/readcr0.cintrincs/readcr2.c intrincs/readcr3.c intrincs/readcr4.c\ - intrincs/readcr8.cintrincs/readmsr.cintrincs/writecr0.c intrincs/writecr2.c intrincs/writecr3.c \ - intrincs/writecr4.c intrincs/writecr8.c intrincs/writemsr.c intrincs/RtlSecureZeroMemory.c \ - \ secapi/_cgets_s.c secapi/_cgetws_s.c \ secapi/_cprintf_s.c secapi/_cprintf_s_l.c \ secapi/_vcprintf_s.c secapi/_vcprintf_s_l.c \ @@ -249,8 +234,25 @@ secapi/_strtime_s.c secapi/_wstrtime_s.c \ secapi/wmemcpy_s.c secapi/memcpy_s.c +# These intrinsics are target independent: +src_intrincs= \ + intrincs/__movsb.cintrincs/__movsd.cintrincs/__movsw.c intrincs/__stosb.c intrincs/__stosd.c\ + intrincs/__stosw.cintrincs/_rotl64.cintrincs/_rotr64.c intrincs/bitscanfwd.c
Re: [Mingw-w64-public] [patch] mingw-w64-crt/Makefile.am: Move compiler intrinsics to libkernel32.a
On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen vinsc...@redhat.com wrote: Hi, today we got a report on the cygwin-developers mailing list, which reported that linking a certain library fails, because some of the inline functions in winnt.h can't be resolved by the linker under Cygwin: http://cygwin.com/ml/cygwin-developers/2013-04/msg00010.html The problem here is that the intrinsics are linked into libmingwex.a, but libmingwex.a doesn't exist in the w32api and thuis isn't available under Cygwin. Kai and I discussed this privatly on IRC and we came to the conclusion that the most generic solution is to include the intrinsics in libkernel32.a, rather than in libmingwex.a. This allows to link against the intrinsics on both platforms, Mingw-w64 as well as Cygwin. It also matches the expectations of application programmers when reading MSDN. Apart from the fact that the functions are implemented as compiler intrinsics, their documentation on MSDN claims their availability in kernel32.lib, see, for instance, http://msdn.microsoft.com/en-us/library/windows/desktop/ms683597%28v=vs.85%29.aspx, in the Requirements section. The below patch implements this. It strips the intrinsic functions from the src_libmingwex variable and introduces a src_intrincs variable instead. It also renames src_libmingwex32 and src_libmingwex64 to src_intrincs32 and src_intrincs64. Then it adds rules for building libkernel32.a for 32 and 64 bit targets, and includes the intrinsics functions to their sources. Is that ok to check in? I have nothing to offer on the concept behind the patch. However, I do feel the need to point out that with this patch, dlltool will no longer run to process the kernel32.def file when building libkernel32.a. There are two cases where we incorporate a def file into a lib. The easiest is when there are no other sources, and that is handled by the general make rule, ie: lib32/lib%.a: lib32/%.def $(DTDEF32) $ There is a kludgier case where we have sources, too. We do this by overriding the AR step of building the library so that we can run dlltool and then call AR as normal. For instance, here we are doing it for libksuser: lib64_LIBRARIES += lib64/libksuser.a lib64_libksuser_a_SOURCES = $(src_libksuser) lib64_libksuser_a_CPPFLAGS=$(CPPFLAGS64) $(sysincludes) lib64_libksuser_a_AR = $(DTLIB64) $(AR) $(ARFLAGS) Previously, libkernel32.a didn't have any sources, so it fell under the first method. You are now adding sources to it, and you correctly took it out of the def list for the first rule, but in order to incorporate the kernel32.def file, you need an accompanying AR line to run dlltool on it. I admit that the above situation isn't ideal, but the autotools don't really actively support windows-isms like dlltool. They said they would review a patch if I wrote it, but I don't know perl yet :( -lib32_LIBRARIES = lib32/libshell32.a +lib32_LIBRARIES = lib32/libkernel32.a +lib32_libkernel32_a_SOURCES = $(src_intrincs) $(src_intrincs32) +lib32_libkernel32_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include) $(AM_CPPFLAGS) Stick it in here +lib64_LIBRARIES = lib64/libkernel32.a +lib64_libkernel32_a_SOURCES = $(src_intrincs) $(src_intrincs64) +lib64_libkernel32_a_CPPFLAGS=$(CPPFLAGS64) -D_SYSCRT=1 -DCRTDLL=1 $(extra_include) $(AM_CPPFLAGS) And here On a second note the CPPFLAGS lines are different. Why are _SYSCRT and cRTDLL defined for the 64-bit case, but not the 32-bit case? And why not including sys_includes? Do the intrinsics not depend on mingw-w64-headers, only the internal crt headers? Any answer is ok to these last questions, as long as you have an answer :) -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] mingw-w64-crt/Makefile.am: Move compiler intrinsics to libkernel32.a
On Apr 2 03:00, NightStrike wrote: On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen vinsc...@redhat.com wrote: The below patch implements this. It strips the intrinsic functions from the src_libmingwex variable and introduces a src_intrincs variable instead. It also renames src_libmingwex32 and src_libmingwex64 to src_intrincs32 and src_intrincs64. Then it adds rules for building libkernel32.a for 32 and 64 bit targets, and includes the intrinsics functions to their sources. Is that ok to check in? I have nothing to offer on the concept behind the patch. However, I do feel the need to point out that with this patch, dlltool will no longer run to process the kernel32.def file when building libkernel32.a. There are two cases where we incorporate a def file into a lib. The easiest is when there are no other sources, and that is handled by the general make rule, ie: lib32/lib%.a: lib32/%.def $(DTDEF32) $ [...] I admit that the above situation isn't ideal, but the autotools don't really actively support windows-isms like dlltool. They said they would review a patch if I wrote it, but I don't know perl yet :( -lib32_LIBRARIES = lib32/libshell32.a +lib32_LIBRARIES = lib32/libkernel32.a +lib32_libkernel32_a_SOURCES = $(src_intrincs) $(src_intrincs32) +lib32_libkernel32_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include) $(AM_CPPFLAGS) Stick it in here +lib64_LIBRARIES = lib64/libkernel32.a +lib64_libkernel32_a_SOURCES = $(src_intrincs) $(src_intrincs64) +lib64_libkernel32_a_CPPFLAGS=$(CPPFLAGS64) -D_SYSCRT=1 -DCRTDLL=1 $(extra_include) $(AM_CPPFLAGS) And here Ok, done. The order of the variables is different between 32 and 64 bit. I did it the same way as in the following shell32.a rule for the same target to align to the surrounding style. On a second note the CPPFLAGS lines are different. Why are _SYSCRT and cRTDLL defined for the 64-bit case, but not the 32-bit case? And why not including sys_includes? Do the intrinsics not depend on mingw-w64-headers, only the internal crt headers? Any answer is ok to these last questions, as long as you have an answer :) Uhm... well, the answer *I* have is this: I fat-fingered my copy/paste. I *planned* to copy the CPPFLAGS from lib64_libmingwex_a_CPPFLAGS, but what I *did* was to copy the CPPFLAGS from lib64_libmingw32_a_CPPFLAGS, accidentally. Sorry about that and thanks for catching. This is fixed in the below updated patch. Thanks, Corinna * Makefile.am (src_libmingwex): Split off intrinsic functions into... (src_intrincs): ...this new variable. (src_intrincs64): Rename from src_libmingwex64. (src_intrincs32): Rename from src_libmingwex32. (lib32_LIBRARIES): Add lib32/libkernel32.a. (lib32_libkernel32_a_SOURCES): New variable. (lib32_libkernel32_a_AR): New variable. (lib32_libkernel32_a_CPPFLAGS): New variable. (lib32_DATA): Remove lib32/libkernel32.a. (lib64_LIBRARIES): Add lib64/libkernel32.a. (lib64_libkernel32_a_SOURCES): New variable. (lib64_libkernel32_a_CPPFLAGS): New variable. (lib64_libkernel32_a_AR): New variable. (lib64_DATA): Remove lib64/libkernel32.a. Index: Makefile.am === --- Makefile.am (revision 5712) +++ Makefile.am (working copy) @@ -217,21 +217,6 @@ stdio/vscanf.c stdio/vsnprintf.c stdio/vsnprintf_s.c stdio/vsnwprintf.cstdio/vsscanf.c \ stdio/vswscanf.c stdio/vwscanf.c stdio/wtoll.c\ \ - intrincs/__movsb.cintrincs/__movsd.cintrincs/__movsw.c intrincs/__stosb.c intrincs/__stosd.c\ - intrincs/__stosw.cintrincs/_rotl64.cintrincs/_rotr64.c intrincs/bitscanfwd.cintrincs/bitscanrev.c \ - intrincs/bittest.cintrincs/bittestc.c intrincs/bittestci.c intrincs/bittestr.c intrincs/bittestri.c \ - intrincs/bittests.c intrincs/bittestsi.c intrincs/cpuid.c intrincs/currentfiber.c intrincs/currentteb.c \ - intrincs/fiberdata.c intrincs/ilockadd.c intrincs/ilockand.c intrincs/ilockand64.cintrincs/ilockcxch.c \ - intrincs/ilockcxch16.cintrincs/ilockcxch64.cintrincs/ilockcxchptr.c intrincs/ilockdec.c intrincs/ilockdec16.c \ - intrincs/ilockdec64.c intrincs/ilockexch.c intrincs/ilockexch64.c intrincs/ilockexchadd.c intrincs/ilockexchadd64.c \ - intrincs/ilockexchptr.c intrincs/ilockinc.c intrincs/ilockinc16.c intrincs/ilockinc64.cintrincs/ilockor.c\ - intrincs/ilockor64.c intrincs/ilockxor.c intrincs/ilockxor64.c intrincs/inbyte.cintrincs/inbytestring.c \ - intrincs/indword.cintrincs/indwordstring.c intrincs/inword.c intrincs/inwordstring.c
Re: [Mingw-w64-public] [patch] mingw-w64-crt/Makefile.am: Move compiler intrinsics to libkernel32.a
On Tue, Apr 2, 2013 at 9:48 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Apr 2 03:00, NightStrike wrote: On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen vinsc...@redhat.com wrote: Ok, done. The order of the variables is different between 32 and 64 bit. I did it the same way as in the following shell32.a rule for the same target to align to the surrounding style. Ok. I have no idea why the lib32 ordering is different than lib64. Probably an oversight. On a second note the CPPFLAGS lines are different. Why are _SYSCRT and cRTDLL defined for the 64-bit case, but not the 32-bit case? And why not including sys_includes? Do the intrinsics not depend on mingw-w64-headers, only the internal crt headers? Any answer is ok to these last questions, as long as you have an answer :) Uhm... well, the answer *I* have is this: I fat-fingered my copy/paste. I *planned* to copy the CPPFLAGS from lib64_libmingwex_a_CPPFLAGS, but what I *did* was to copy the CPPFLAGS from lib64_libmingw32_a_CPPFLAGS, accidentally. Sorry about that and thanks for catching. This is fixed in the below updated patch. Looks good, thanks! -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] mingw-w64-crt/Makefile.am: Move compiler intrinsics to libkernel32.a
On Apr 2 11:05, NightStrike wrote: On Tue, Apr 2, 2013 at 9:48 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Apr 2 03:00, NightStrike wrote: On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen vinsc...@redhat.com wrote: Ok, done. The order of the variables is different between 32 and 64 bit. I did it the same way as in the following shell32.a rule for the same target to align to the surrounding style. Ok. I have no idea why the lib32 ordering is different than lib64. Probably an oversight. On a second note the CPPFLAGS lines are different. Why are _SYSCRT and cRTDLL defined for the 64-bit case, but not the 32-bit case? And why not including sys_includes? Do the intrinsics not depend on mingw-w64-headers, only the internal crt headers? Any answer is ok to these last questions, as long as you have an answer :) Uhm... well, the answer *I* have is this: I fat-fingered my copy/paste. I *planned* to copy the CPPFLAGS from lib64_libmingwex_a_CPPFLAGS, but what I *did* was to copy the CPPFLAGS from lib64_libmingw32_a_CPPFLAGS, accidentally. Sorry about that and thanks for catching. This is fixed in the below updated patch. Looks good, thanks! Thanks, applied. Corinna -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
