{"id":347,"date":"2012-04-28T08:33:18","date_gmt":"2012-04-28T08:33:18","guid":{"rendered":"http:\/\/blog.bachi.net\/?p=347"},"modified":"2012-04-28T08:46:36","modified_gmt":"2012-04-28T08:46:36","slug":"mingw-unix-incompatible-compile-verbose","status":"publish","type":"post","link":"https:\/\/blog.bachi.net\/?p=347","title":{"rendered":"MingW: UNIX incompatible &#038; compile verbose"},"content":{"rendered":"<p><a href=\"http:\/\/www.delorie.com\/howto\/cygwin\/mno-cygwin-howto.html\">Building Mingw executables using Cygwin<\/a><\/p>\n<p>One particular vexing source of error is when you include a file that<br \/>\nexists for Cygwin, but not for Mingw32; the compilation goes ok, but<br \/>\nthe compiler is really using the *WRONG* include file and you get link<br \/>\ntime errors.<\/p>\n<p>Let&#8217;s say you have some code that uses the POSIX\/BSD &#8220;times&#8221; function<br \/>\nwhich is not part of the ANSI standard and does not exist under Mingw32<br \/>\nruntime.<\/p>\n<pre class=\"brush: cpp; title: ; notranslate\" title=\"\">\r\n  #include\r\n  #include\r\n  int main () {\r\n      struct tms time_info;\r\n      times (&amp;time_info);\r\n      printf (&quot;user_time = %d, system_time = %d\\n&quot;,\r\n              time_info.tms_utime, time_info.tms_stime);\r\n      return 0;\r\n  }\r\n<\/pre>\n<p>Now build the &#8220;times&#8221; program:<\/p>\n<pre class=\"brush: cpp; title: ; notranslate\" title=\"\">\r\n  $ gcc -c -mno-cygwin times.c\r\n  $ gcc -o times -mno-cygwin times.o\r\n  times.o(.text+0x34):times.c: undefined reference to `times'\r\n  collect2: ld returned 1 exit status\r\n<\/pre>\n<p>Notice that the compilation goes just fine, but you get an undefined<br \/>\nreference to the &#8220;times&#8221; function.<\/p>\n<p>What happens is that Cygwin first looks in the mingw32 include directory<br \/>\nthe <code>&lt;sys\/times.h&gt;<\/code> file and it can&#8217;t find it; it then looks at the default<br \/>\ndirectory and does find it and uses it and everything is fine at this<br \/>\npoint. However, at link time, the Mingw32 runtime library lacks this<br \/>\nfunction and you get an undefined error. Sometimes these are so confusing<br \/>\nthat you may get sidetracked and not look at the real source of the<br \/>\nproblem &#8212; your own code!<\/p>\n<p>So, how do you diagnose these errors? Whenever you get such errors, use<br \/>\nthe <code>-v<\/code> (verbose) and <code>-H<\/code> (show include files) options when compiling<br \/>\nto see where include files are coming from. Then use <code>-v<\/code> option when<br \/>\nlinking to see what libraries are being linked in.<\/p>\n<p>Another source of error is creating Mingw DLLs using dllwrap. The current<br \/>\nversion of <code>dllwrap<\/code> does not know the <code>-mno-cygwin<\/code> option and will<br \/>\nincorrectly add Cygwin libraries when creating DLLs. The workaround is<br \/>\nquite simple: add the <code>--target=i386-mingw32<\/code> option instead. In the future,<br \/>\n<code>dllwrap<\/code> will simply translate the <code>-mno-cygwin<\/code> option to the <code>--target<\/code><br \/>\noption and it will just work.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Building Mingw executables using Cygwin One particular vexing source of error is when you include a file that exists for Cygwin, but not for Mingw32; the compilation goes ok, but the compiler is really using the *WRONG* include file and you get link time errors. Let&#8217;s say you have some code that uses the POSIX\/BSD [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-347","post","type-post","status-publish","format-standard","hentry","category-mingw"],"_links":{"self":[{"href":"https:\/\/blog.bachi.net\/index.php?rest_route=\/wp\/v2\/posts\/347","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.bachi.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.bachi.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.bachi.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.bachi.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=347"}],"version-history":[{"count":10,"href":"https:\/\/blog.bachi.net\/index.php?rest_route=\/wp\/v2\/posts\/347\/revisions"}],"predecessor-version":[{"id":359,"href":"https:\/\/blog.bachi.net\/index.php?rest_route=\/wp\/v2\/posts\/347\/revisions\/359"}],"wp:attachment":[{"href":"https:\/\/blog.bachi.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=347"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.bachi.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=347"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.bachi.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=347"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}