Re: [Mingw-w64-public] LTO status?
4.9 uses slim LTO information by default, which is hard to be recognized in GDB at present, so you can wait for next GDB period. And you can try to use -flto -ffat-lto-objects to enable fat LTO information. On Wed, Jul 2, 2014 at 7:05 AM, Antony Riakiotakis kal...@gmail.com wrote: That was the gcc manual: https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Optimize-Options.html#Optimize-Options quote: Link-time optimization does not work well with generation of debugging information. Combining -flto with -g is currently experimental and expected to produce unexpected results. On 27 June 2014 01:19, Riot rain.back...@gmail.com wrote: I currently use LTO in production code. I and my team have been using LTO since gcc 4.7, although as you say it's more mature in 4.9. We are a small games development house so performance is critical and LTO makes a big difference to our release builds. However, I have also seen a few spurious bugs that I was not able to isolate with 4.9.0 that were not present with 4.8; especially one case where perfectly valid and bug-free code was segfaulting when compiled with LTO; unless remedied by std::cout-ing one of the variables involved before it was used in the function call producing the segfault. We were later able to avoid the bug by not returning a container as we were doing before, but passing it by reference to the same function. I would have liked to be able to report it but i was never able to isolate a clean test-case, as changing other code in other compile units made it disappear or reappear arbitrarily (further confirming that it was specifically an issue with LTO). However, this was an isolated incident and we haven't had more of those since; also 4.9.1 is now out which may fix a lot of these issues. I should also note that we also optimise our release builds with -Ofast which enables unsafe math optimisations, which may have been a contributing factor in that case. It's hard to debug potential LTO issues because it doesn't play well with debugging symbols; in fact I recall reading somewhere that using both LTO and -g can produce undefined compiler behaviour, although I cannot now find this quote, so you may want to take that with a pinch of salt. TL;DR: LTO is mature enough to use in production code, and the benefit is large, but keep an eye out for any remaining bugs, and test your release build properly rather than assuming it'll work because your debug build works. SlowRiot On 25 June 2014 15:14, m...@morous.org wrote: Hello, when I tried LTO (link time optiomization) the last time (gcc 4.8 or 4.7, I do not remember precisely), it did not work much for me (frequent crashes during my project build with LTO enabled). I know gcc dev team spent a lot of time on improving LTO in 4.9. So, what is LTO status in mingw-w64 now? Do you consider it already a standard feature or is it still experimental thing and there may be lions hidden on the way? Anyone out there who already uses mingw-w64 with LTO in production? Thanks in advance for any feedback, Martin -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Best Regards, xunxun -- Open source business process management suite built on Java and Eclipse
Re: [Mingw-w64-public] [Project News | New Builds]
于 2014/4/25 星期五 22:54, Ruben Van Boxem 写道:
2014-04-25 16:34 GMT+02:00 JonY jo...@users.sourceforge.net
mailto:jo...@users.sourceforge.net:
On 4/25/2014 21:17, Dongsheng Song wrote:
On Fri, Apr 25, 2014 at 6:50 PM, JonY
jo...@users.sourceforge.net mailto:jo...@users.sourceforge.net
wrote:
On 4/25/2014 17:47, Dongsheng Song wrote:
I'm glad to upload my daily builds to mingw-w64, if someone
intersting
and give me (dongsheng) permission.
What is your configuration like? And what exactly do you have
in your
download?
For win64:
${GCC_SRC_ROOT}/configure \
--prefix=${SYS_ROOT} \
--with-sysroot=${SYS_ROOT} \
--build=${BUILD_TRIPLET} --host=${TARGET_TRIPLET}
--target=${TARGET_TRIPLET} \
--disable-multilib --disable-nls --disable-win32-registry \
--enable-checking=release --enable-languages=c,c++,fortran \
--with-arch=core2 --with-tune=generic
For win32:
${GCC_SRC_ROOT}/configure \
--prefix=${SYS_ROOT} \
--with-sysroot=${SYS_ROOT} \
--build=${BUILD_TRIPLET} --host=${TARGET_TRIPLET}
--target=${TARGET_TRIPLET} \
--disable-multilib --disable-nls --disable-win32-registry \
--enable-checking=release --enable-languages=c,c++,fortran \
--with-arch=i686 --with-tune=generic
Add --enable-fully-dynamic-string and
Shouldn't this already be enabled by default (you worked on a patch
for that which IIANM I tested back then)?
Should be a default option for MinGW64 target, but not for MinGW target.
--enable-version-specific-runtime-libs and everything is good.
This isn't strictly necessary and in my experience is quite
troublesome (can't find -lgcc_eh as a result)
Cheers,
Ruben
You may need to use winpthread if you want to use --enable-libgomp.
I have now added your login to allow uploads, please upload to
somewhere
like Toolchains targetting Win{32,64}/Personal
Builds/dongsheng-daily.
probably a good idea to rotate the files weekly to prevent uploads
from
getting too big (if there is such a thing as too big).
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
mailto:Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
--
Best Regards,
xunxun
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
于 2014/4/25 星期五 17:32, Dongsheng Song 写道: On Fri, Apr 25, 2014 at 4:39 PM, niXman i.nix...@autistici.org wrote: Hi, Just now I uploaded the first builds of MinGW-W64 based on GCC-4.9.0. Links: 32-bit: posix-sjlj: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-posix/sjlj/i686-4.9.0-release-posix-sjlj-rt_v3-rev0.7z posix-dwarf: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-posix/dwarf/i686-4.9.0-release-posix-dwarf-rt_v3-rev0.7z win32-sjlj: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-win32/sjlj/i686-4.9.0-release-win32-sjlj-rt_v3-rev0.7z win32-dwarf: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-win32/dwarf/i686-4.9.0-release-win32-dwarf-rt_v3-rev0.7z 64-bit: posix-sjlj: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-posix/sjlj/x86_64-4.9.0-release-posix-sjlj-rt_v3-rev0.7z posix-seh: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-posix/seh/x86_64-4.9.0-release-posix-seh-rt_v3-rev0.7z win32-sjlj: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-win32/sjlj/x86_64-4.9.0-release-win32-sjlj-rt_v3-rev0.7z win32-seh: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-win32/seh/x86_64-4.9.0-release-win32-seh-rt_v3-rev0.7z -- Regards, niXman Here is GCC daily builds with default configuration: https://sourceforge.net/projects/osb/files/gcc/ -- Dongsheng Did you use any patches or scripts for your build? -- Best Regards, xunxun -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
Well, I want to ask Dongsheng 在 2014-4-26 上午1:06，niXman i.nix...@autistici.org写道： xunxun 2014-04-25 20:40: Did you use any patches ... for your build? Yes: https://github.com/niXman/mingw-builds/blob/develop/scripts/gcc-4.9.0.sh#L50 Did you use any ... scripts for your build? Yes: https://github.com/niXman/mingw-builds/ -- Regards, niXman ___ Dual-target(32 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingw-w64/ ___ Another online IDE: http://liveworkspace.org/ -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 and gcc plugins
于 2014/1/16 星期四 22:13, Иван Иванов 写道: Hello! Is it possible to develop and use GCC plugins with MinGW-w64 on windows? Are there any MinGW-w64 binaries available that supports GCC plugins? I tried googling for it, but couldn't find any. Long long time ago, I ported DragonEgg plugin to Windows: https://code.google.com/p/pcxllvm/downloads/detail?name=Dragonegg_MinGW64CRT_gcc4.6.1_win32.7zcan=1q=#makechanges To build GCC plugin, you will need a special binutils ( can export all symbols ), you can use a my special one: https://code.google.com/p/pcxprj/downloads/detail?name=MinGW_GCC4.6.1_enable_plugin_experimental.7zcan=2q=#makechanges Because of long time, I have forgotten some details, you can refer to these links: http://mingw.5.n7.nabble.com/gcc-enable-plugin-experimental-built-on-windows-td14088.html http://mingw.5.n7.nabble.com/DragonEgg-3-0-for-win32-td5502.html -- Best Regards, xunxun -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 and gcc plugins
于 2014/1/17 星期五 6:45, Edscott Wilson 写道: I've used plugins fairly recently. No problem porting from Linux to Windows. Just compile the plugin as a dll and make sure you avoid C++ name mangling. You mean now we can build mingw(64) gcc with --enable-plugin smoothly? -- Best Regards, xunxun -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Announcement: mingw-builds and mingw-w64 are joining forces
于 2013/9/24 星期二 20:04, niXman 写道: 2013/9/24 xunxun Will you plan to build gcc/crt using PGO (or PGO and LTO)? Is it necessary? What for? You can see http://gcc.gnu.org/ml/gcc/2013-03/msg00210.html -- Best Regards, xunxun -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Announcement: mingw-builds and mingw-w64 are joining forces
于 2013/9/24 星期二 20:41, niXman 写道: 2013/9/24 xunxun: You can see http://gcc.gnu.org/ml/gcc/2013-03/msg00210.html Build time will be increased approximately by 400 percent, in order to increase compilation speed by 10 percent. I do not see the any point in doing this... 400% for the builder, but 10% for the user -- Best Regards, xunxun -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Announcement: mingw-builds and mingw-w64 are joining forces
于 2013/9/24 星期二 22:21, Alexey Pavlov 写道: 2013/9/24 xunxun xunxun1...@gmail.com: 于 2013/9/24 星期二 20:41, niXman 写道: 2013/9/24 xunxun: You can see http://gcc.gnu.org/ml/gcc/2013-03/msg00210.html Build time will be increased approximately by 400 percent, in order to increase compilation speed by 10 percent. I do not see the any point in doing this... 400% for the builder, but 10% for the user Now building all 8 bootstrapped toolchains under Windows taked about 1 day. Building them with PGO+LTO increase it to 4! days. It's very long time. You can only build native toolchain. I don't think PGO can be useful for cross toolchains. And as said by the link, PGO is much better than LTO at present, so you can only use PGO, which cost shorter time. Regards, Alexey. -- Best Regards, xunxun -- Best Regards, xunxun -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problem with ld...
于 2013/7/12 星期五 11:48, David Cleaver 写道: Hello everyone, I was previously using an old Ozkan build, from 2011-11-01. I compiled a project and when that got to the stage to use ld.exe, I got the following error: ld.exe: unrecognized option '--large-address-aware' I thought this may have been due to me using an old tool chain, so I just updated using mingw-builds-install.exe. I downloaded the GCC 4.8.1 x64 posix sjlj rev 2 package. I was able to successfully compile GMP 5.1.2, so this all seems to be working fine. I then tried to compile the original project again, and I still get the error: c:/mingw64-20130711/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: unrecognized option '--large-address-aware' When I type: ld --help I see in the output: --large-address-aware Executable supports virtual addresses greater than 2 gigabytes Also to show which ld is being used: $ which ld /c/mingw64-20130711/mingw64/bin/ld.exe The full command plus error is: gcc -O3 -fomit-frame-pointer -march=core2 -D_FILE_OFFSET_BITS=64 -DNDEBUG -D_LARGEFILE64_SOURCE -Wall -W -DMSIEVE_SVN_VERSION=\914\ -I. -Iinclude -Ignfs -Ignfs/poly -Ignfs/poly/stage1 -DNO_ZLIB demo.c -o msieve -Wl,--large-address-aware \ libmsieve.a -lgmp -lm -lpthread c:/mingw64-20130711/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: unrecognized option '--large-address-aware' c:/mingw64-20130711/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: use the --help option for usage information collect2.exe: error: ld returned 1 exit status make: *** [all] Error 1 So, I was wondering, if I'm compiling on a WinXP x64 system (inside of MSYS) and I'll be using the binary on WinXP x64 and Win7 x64, do I even need the --large-address-aware option to the MingW64 ld.exe? If so, how can I correct the above error? If not, then I can just remove the option and the compile will succeed. Thanks for any help you can provide. -David C. -Wl,--large-address-aware is only for x86 target -- Best Regards, xunxun -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] build wx with tdm-gcc successfully
I suggest not to use multiple lib gcc here, unless you know -m32 *windres*needs -F pe-i386. You can choose one gcc with only x86 or x64. On Tue, Jun 4, 2013 at 11:23 AM, zhangxinghai zxh19750...@163.com wrote: hello I have just succeeded in building wx 2.9.4 with tdm-gcc-64 4.7.1-3,I'm very glad.Thanks for all help. I invoke the command mingw32-make -f makefile.gcc -j4 BUILD=release SHARED=1 MONOLITHIC=0 UNICODE=1 CXXFLAGS=-m32 -pipe -fno-keep-inline-dllexport -Os LDFLAGS=-m32 CFLAGS=-m32 RCFLAGS=-F pe-i386 I also find I must change makefile.gcc,add RCFLAGS to MAKEARGS,and add $(RCFLAGS) to all windres command line. Is there an alternate way more quick and simple?Can I avoid modifying every windres command? Next I will try compile under msys using tdm-gcc,how to specify file format to pe-i386 for windres? I also try to build with ruben's toolchain. Best Regards -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Best Regards, xunxun -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Suggestion for FAQ Re _vswprintf and msvcrt.dll on XP SP1
于 2013/5/10 星期五 17:17, Jacek Caban 写道: On 05/10/13 11:11, xunxun wrote: 于 2013/5/9 星期四 10:40, xunxun 写道: 于 2013/5/9 星期四 6:27, Jacek Caban 写道: On 5/8/13 7:27 AM, xunxun wrote: 于 2013/1/21 星期一 21:07, Kai Tietz 写道: 2013/1/21 Jacek Caban ja...@codeweavers.com: On 01/21/13 13:39, JonY wrote: On 1/21/2013 09:43, Herb Thompson wrote: Q: Why do some 32-bit MinGW-w64 applications fail with '... _vswprintf could not be located in the dynamic link library msvcrt.dll' on Windows XP SP1? A: For C++, MinGW-w64 implements 'vswprintf (wchar_t *__stream, const wchar_t *__format, __builtin_va_list __local_argv)' as a call to '_vswprintf'. Older versions of msvcrt.dll, like the version in XP SP1, do not include '_vswprintf'. A workaround for this is to compile any C++ libraries and applications that use 'vswprintf' (with the preceding signature) with -D__USE_MINGW_ANSI_STDIO. For example, to build the wxWidgets library for applications to be deployed on XP SP1, build wxWidgets with the following command line: mingw32-make -f makefile.gcc CPPFLAGS=-D__USE_MINGW_ANSI_STDIO Done as https://sourceforge.net/apps/trac/mingw-w64/wiki/_vswprintf%20missing. Thanks. I've also added a caveat section on the side effects of using __USE_MINGW_ANSI_STDIO. Well, IMO we should fix bugs instead of documenting them... I may look at this, but I'm not sure when I will find time for that. Jacek Well, in general I agree. We might should do same hack (for older msvcrt versions) as we do for vscanf (as example). Cheers, Kai Can we do _vswprintf == vswprintf again? And XP SP3 msvcrt.dll doesn't contain _vswprint, too. We must fix it! I'm sorry, I forgot about this before I found the time to fix it. Can you prepare a patch? Thanks, Jacek Same with vsnprintf Index: mingw-w64-crt/lib32/msvcrt.def.in === --- mingw-w64-crt/lib32/msvcrt.def.in(revision 5847) +++ mingw-w64-crt/lib32/msvcrt.def.in(working copy) @@ -1116,7 +1116,7 @@ _vsprintf_p _vsprintf_p_l _vsprintf_s_l -_vswprintf +_vswprintf == vswprintf _vswprintf_c _vswprintf_c_l _vswprintf_l How do you think? Can we do that workaround change before a better detect method? Yes, the patch looks good to me, thanks. But this needs Kai's approval. Thanks, Jacek Can you commit it? Thanks. -- Best Regards, xunxun -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Suggestion for FAQ Re _vswprintf and msvcrt.dll on XP SP1
于 2013/5/9 星期四 10:40, xunxun 写道: 于 2013/5/9 星期四 6:27, Jacek Caban 写道: On 5/8/13 7:27 AM, xunxun wrote: 于 2013/1/21 星期一 21:07, Kai Tietz 写道: 2013/1/21 Jacek Caban ja...@codeweavers.com: On 01/21/13 13:39, JonY wrote: On 1/21/2013 09:43, Herb Thompson wrote: Q: Why do some 32-bit MinGW-w64 applications fail with '... _vswprintf could not be located in the dynamic link library msvcrt.dll' on Windows XP SP1? A: For C++, MinGW-w64 implements 'vswprintf (wchar_t *__stream, const wchar_t *__format, __builtin_va_list __local_argv)' as a call to '_vswprintf'. Older versions of msvcrt.dll, like the version in XP SP1, do not include '_vswprintf'. A workaround for this is to compile any C++ libraries and applications that use 'vswprintf' (with the preceding signature) with -D__USE_MINGW_ANSI_STDIO. For example, to build the wxWidgets library for applications to be deployed on XP SP1, build wxWidgets with the following command line: mingw32-make -f makefile.gcc CPPFLAGS=-D__USE_MINGW_ANSI_STDIO Done as https://sourceforge.net/apps/trac/mingw-w64/wiki/_vswprintf%20missing. Thanks. I've also added a caveat section on the side effects of using __USE_MINGW_ANSI_STDIO. Well, IMO we should fix bugs instead of documenting them... I may look at this, but I'm not sure when I will find time for that. Jacek Well, in general I agree. We might should do same hack (for older msvcrt versions) as we do for vscanf (as example). Cheers, Kai Can we do _vswprintf == vswprintf again? And XP SP3 msvcrt.dll doesn't contain _vswprint, too. We must fix it! I'm sorry, I forgot about this before I found the time to fix it. Can you prepare a patch? Thanks, Jacek Same with vsnprintf Index: mingw-w64-crt/lib32/msvcrt.def.in === --- mingw-w64-crt/lib32/msvcrt.def.in(revision 5847) +++ mingw-w64-crt/lib32/msvcrt.def.in(working copy) @@ -1116,7 +1116,7 @@ _vsprintf_p _vsprintf_p_l _vsprintf_s_l -_vswprintf +_vswprintf == vswprintf _vswprintf_c _vswprintf_c_l _vswprintf_l How do you think? Can we do that workaround change before a better detect method? -- Best Regards, xunxun -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Suggestion for FAQ Re _vswprintf and msvcrt.dll on XP SP1
于 2013/5/9 星期四 6:27, Jacek Caban 写道: On 5/8/13 7:27 AM, xunxun wrote: 于 2013/1/21 星期一 21:07, Kai Tietz 写道: 2013/1/21 Jacek Caban ja...@codeweavers.com: On 01/21/13 13:39, JonY wrote: On 1/21/2013 09:43, Herb Thompson wrote: Q: Why do some 32-bit MinGW-w64 applications fail with '... _vswprintf could not be located in the dynamic link library msvcrt.dll' on Windows XP SP1? A: For C++, MinGW-w64 implements 'vswprintf (wchar_t *__stream, const wchar_t *__format, __builtin_va_list __local_argv)' as a call to '_vswprintf'. Older versions of msvcrt.dll, like the version in XP SP1, do not include '_vswprintf'. A workaround for this is to compile any C++ libraries and applications that use 'vswprintf' (with the preceding signature) with -D__USE_MINGW_ANSI_STDIO. For example, to build the wxWidgets library for applications to be deployed on XP SP1, build wxWidgets with the following command line: mingw32-make -f makefile.gcc CPPFLAGS=-D__USE_MINGW_ANSI_STDIO Done as https://sourceforge.net/apps/trac/mingw-w64/wiki/_vswprintf%20missing. Thanks. I've also added a caveat section on the side effects of using __USE_MINGW_ANSI_STDIO. Well, IMO we should fix bugs instead of documenting them... I may look at this, but I'm not sure when I will find time for that. Jacek Well, in general I agree. We might should do same hack (for older msvcrt versions) as we do for vscanf (as example). Cheers, Kai Can we do _vswprintf == vswprintf again? And XP SP3 msvcrt.dll doesn't contain _vswprint, too. We must fix it! I'm sorry, I forgot about this before I found the time to fix it. Can you prepare a patch? Thanks, Jacek Same with vsnprintf Index: mingw-w64-crt/lib32/msvcrt.def.in === --- mingw-w64-crt/lib32/msvcrt.def.in(revision 5847) +++ mingw-w64-crt/lib32/msvcrt.def.in(working copy) @@ -1116,7 +1116,7 @@ _vsprintf_p _vsprintf_p_l _vsprintf_s_l -_vswprintf +_vswprintf == vswprintf _vswprintf_c _vswprintf_c_l _vswprintf_l -- Best Regards, xunxun Index: mingw-w64-crt/lib32/msvcrt.def.in === --- mingw-w64-crt/lib32/msvcrt.def.in (revision 5847) +++ mingw-w64-crt/lib32/msvcrt.def.in (working copy) @@ -1116,7 +1116,7 @@ _vsprintf_p _vsprintf_p_l _vsprintf_s_l -_vswprintf +_vswprintf == vswprintf _vswprintf_c _vswprintf_c_l _vswprintf_l -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Suggestion for FAQ Re _vswprintf and msvcrt.dll on XP SP1
于 2013/1/21 星期一 21:07, Kai Tietz 写道: 2013/1/21 Jacek Caban ja...@codeweavers.com: On 01/21/13 13:39, JonY wrote: On 1/21/2013 09:43, Herb Thompson wrote: Q: Why do some 32-bit MinGW-w64 applications fail with '... _vswprintf could not be located in the dynamic link library msvcrt.dll' on Windows XP SP1? A: For C++, MinGW-w64 implements 'vswprintf (wchar_t *__stream, const wchar_t *__format, __builtin_va_list __local_argv)' as a call to '_vswprintf'. Older versions of msvcrt.dll, like the version in XP SP1, do not include '_vswprintf'. A workaround for this is to compile any C++ libraries and applications that use 'vswprintf' (with the preceding signature) with -D__USE_MINGW_ANSI_STDIO. For example, to build the wxWidgets library for applications to be deployed on XP SP1, build wxWidgets with the following command line: mingw32-make -f makefile.gcc CPPFLAGS=-D__USE_MINGW_ANSI_STDIO Done as https://sourceforge.net/apps/trac/mingw-w64/wiki/_vswprintf%20missing. Thanks. I've also added a caveat section on the side effects of using __USE_MINGW_ANSI_STDIO. Well, IMO we should fix bugs instead of documenting them... I may look at this, but I'm not sure when I will find time for that. Jacek Well, in general I agree. We might should do same hack (for older msvcrt versions) as we do for vscanf (as example). Cheers, Kai Can we do _vswprintf == vswprintf again? And XP SP3 msvcrt.dll doesn't contain _vswprint, too. We must fix it! -- Best Regards, xunxun -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
于 2013/5/3 星期五 17:59, Ozkan Sezer 写道: On Fri, May 3, 2013 at 12:51 PM, niXman i.nix...@gmail.com wrote: Hi JonY, If you use -D__MINGW_USE_ANSI_STDIO=1, use %lld. If you DO NOT USE -D__MINGW_USE_ANSI_STDIO=1, use %I64d. Tell me please, what can be reasons to use '%I64d' and do not use '-D__MINGW_USE_ANSI_STDIO=1' ? I'm just curious, why not just use the GNU style format string? One may want to avoid mingw-provided print routines, which are linked statically, and want to use the ones from msvcrt.dll (which is shared code). Personally, I always use windows-native stuff, e.g. %I64 in cases such as this, but yes it may be hard to do so when porting posix and/or c99- compliant code which rely on pure conformance. Thanks. -- Regards, niXman -- O.S. Kai wants to set it by default on MinGW(64) -- Hi, this patch enables the POSIX-printf variant for mingw-hosts by default. ChangeLog 2013-03-22 Kai Tietzkti...@redhat.com * config/i386/xm-mingw32.h (__USE_MINGW_ANSI_STDIO): Enable POSIX-printf for mingw-hosted builds. Tested for i686-w64-mingw32, and x86_64-w64-mingw32. I will apply tomorrow, if there aren't any objections by other Windows-maintainers. Regards, Kai Index: gcc/config/i386/xm-mingw32.h === --- gcc/config/i386/xm-mingw32.h(Revision 196898) +++ gcc/config/i386/xm-mingw32.h(Arbeitskopie) @@ -29,6 +29,12 @@ along with GCC; see the file COPYING3. If not see /* The st_ino field of struct stat is always 0. */ #define HOST_LACKS_INODE_NUMBERS +#ifdef __MINGW32__ +#undef __USE_MINGW_ANSI_STDIO +#define __USE_MINGW_ANSI_STDIO 1 +#else /* MSVCRT does not support the ll format specifier for printing long long values. Instead, we use I64. */ #define HOST_LONG_LONG_FORMAT I64 +#endif + -- Best Regards, xunxun -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] OpenMP-related hangup with winpthreads
--with-arch=pentium4 --with-tune=core-avx-i
I only use it for some popurse or perf. (Some lto needs -msse2, or will
cause compiler ICE.)
--enable-cxx-flags='-fno-function-sections -fno-data-sections'
At present, MinGW target linker can't support --gc-sections, so
-fno-function-sections -fno-data-sections is not effective, and will
increase code size.
Kai has a patch to solve it, but after my test, something is wrong with
gcc4.7, I will check it again some time.
Ruben has explained other options.
And I don't know where is your problem, can you try my built :
http://pcxprj.googlecode.com/files/MinGW64CRT_gcc4.7.3release_sse2static_win32.7z
On Fri, May 3, 2013 at 1:53 AM, LRN lrn1...@gmail.com wrote:
On 01.05.2013 18:56, xunxun wrote:
于 2013/5/1 星期三 21:15, LRN 写道:
On 01.05.2013 10:32, xunxun wrote:
On Wed, May 1, 2013 at 3:13 AM, LRN lrn1...@gmail.com wrote:
On 30.04.2013 19:18, xunxun wrote:
于 2013/4/24 星期三 19:12, LRN 写道:
msgmerge.exe (from gettext, i guess) hangs up, consuming 100% of a
CPU
core, this is the backtrace:
#0 0x74d53b64 in SleepEx () from C:\Windows\syswow64\KernelBase.dll
#1 0x74d54498 in Sleep () from C:\Windows\syswow64\KernelBase.dll
#2 0x6494406b in _spin_lite_lock (l=0x64943003 mutex_ref+19) at
../winpthreads-svn-r5792/src/spinlock.c:256
#3 0x0001 in ?? ()
#4 0x64943003 in mutex_ref (m=0x11, m@entry=0x534fb4) at
../winpthreads-svn-r5792/src/mutex.c:60
#5 0x6494317f in pthread_mutex_lock_intern (timeout=4294967295,
m=0x534fb4) at ../winpthreads-svn-r5792/src/mutex.c:236
#6 pthread_mutex_lock (m=m@entry=0x534fb4) at
../winpthreads-svn-r5792/src/mutex.c:223
#7 0x64943482 in rwlock_gain_both_locks
(rwlock=rwlock@entry=0x534fa0) at
../winpthreads-svn-r5792/src/rwlock.c:107
#8 0x64943b5e in pthread_rwlock_wrlock
(rwlock_=rwlock_@entry=0x6494f08c) at
../winpthreads-svn-r5792/src/rwlock.c:430
#9 0x64944f26 in pthread_key_delete (key=0) at
../winpthreads-svn-r5792/src/thread.c:739
#10 0x6360da61 in team_destructor () from
f:\s31\mingw\bin\libgomp-1.dll
#11 0x in ?? ()
I'm using an svn-r5792 version of winpthreads + libgomp patches from
ktietz.
Where is the libgomp patches?
He pastebinned that patch at 2013-04-22 15:24:19 (that pastebin is
no longer alive, so i've attached the copy that i've got back then).
And what's your gettext configure option?
I don't know whether gettext has one option which can only use
pthread lib but not use openmp.
- --prefix=${prefix} \
- --enable-shared --enable-static --enable-silent-rules \
- --enable-threads=win32 \
- --with-included-gettext --with-included-glib --with-included-libcroco
\
- --with-included-unistring --with-included-libxml \
- --disable-rpath \
- --without-emacs --disable-native-java --disable-curses \
and i've added --disable-openmp for now, to work around this problem.
Now that you've mentioned it, maybe i should use --enable-threads=posix
with openmp?
Maybe using posix thread is right.
And I use my built gettext, but can't reproduce the issue (when running
msgmerge.exe --update -q nul nul)
I use static winpthread and static posix gcc 4.7.3.
My gettext configure option is :
./configure --prefix=/mingw/gettext \
--disable-shared --enable-static \
--enable-threads=posix \
--with-included-gettext --with-included-glib --with-included-libcroco
\
--with-included-unistring --with-included-libxml \
--disable-rpath --disable-nls \
--without-emacs --disable-native-java --disable-curses \
--enable-relocate
My winpthread configure option is :
./configure --prefix=/mingw --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-mingw32 --enable-static
--disable-shared
My gcc configure option is :
../gcc-4.7.3/configure --prefix=/mingw \
--with-arch=pentium4 --with-tune=core-avx-i \
--build=i686-w64-mingw32 --host=i686-w64-mingw32
--target=i686-w64-mingw32 \
--with-lto-plugin --with-host-libstdcxx=-lstdc++
--disable-bootstrap --disable-werror \
--enable-languages=c,c++,fortran --enable-libgomp
--enable-threads=posix --enable-libstdcxx-threads
--enable-libstdcxx-time --enable-lto --with-system-zlib --with-libiconv \
--enable-version-specific-runtime-libs
--enable-fully-dynamic-string --disable-libstdcxx-pch
--disable-libstdcxx-debug --enable-graphite \
--disable-sjlj-exceptions --with-dwarf2 --disable-symvers
--enable-checking=release --enable-cxx-flags='-fno-function-sections
-fno-data-sections' \
--enable-cloog-backend=isl --disable-shared --enable-static
--disable-win32-registry --disable-rpath --enable-plugins \
--enable-libquadmath-support --enable-libquadmath
--disable-multilib --disable-ppl-version-check
--disable-cloog-version-check --with-gnu-as --with-gnu-ld \
--disable-nls
Re: [Mingw-w64-public] OpenMP-related hangup with winpthreads
And what's your gettext configure option? I don't know whether gettext has one option which can only use pthread lib but not use openmp. On Wed, May 1, 2013 at 3:13 AM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30.04.2013 19:18, xunxun wrote: 于 2013/4/24 星期三 19:12, LRN 写道: msgmerge.exe (from gettext, i guess) hangs up, consuming 100% of a CPU core, this is the backtrace: #0 0x74d53b64 in SleepEx () from C:\Windows\syswow64\KernelBase.dll #1 0x74d54498 in Sleep () from C:\Windows\syswow64\KernelBase.dll #2 0x6494406b in _spin_lite_lock (l=0x64943003 mutex_ref+19) at ../winpthreads-svn-r5792/src/spinlock.c:256 #3 0x0001 in ?? () #4 0x64943003 in mutex_ref (m=0x11, m@entry=0x534fb4) at ../winpthreads-svn-r5792/src/mutex.c:60 #5 0x6494317f in pthread_mutex_lock_intern (timeout=4294967295, m=0x534fb4) at ../winpthreads-svn-r5792/src/mutex.c:236 #6 pthread_mutex_lock (m=m@entry=0x534fb4) at ../winpthreads-svn-r5792/src/mutex.c:223 #7 0x64943482 in rwlock_gain_both_locks (rwlock=rwlock@entry=0x534fa0) at ../winpthreads-svn-r5792/src/rwlock.c:107 #8 0x64943b5e in pthread_rwlock_wrlock (rwlock_=rwlock_@entry=0x6494f08c) at ../winpthreads-svn-r5792/src/rwlock.c:430 #9 0x64944f26 in pthread_key_delete (key=0) at ../winpthreads-svn-r5792/src/thread.c:739 #10 0x6360da61 in team_destructor () from f:\s31\mingw\bin\libgomp-1.dll #11 0x in ?? () I'm using an svn-r5792 version of winpthreads + libgomp patches from ktietz. Where is the libgomp patches? He pastebinned that patch at 2013-04-22 15:24:19 (that pastebin is no longer alive, so i've attached the copy that i've got back then). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRgBe8AAoJEOs4Jb6SI2Cw5JkH/iXMAh3sNF/xo5em8WcnjAMz Ew+ABAu53BBnw4Bxwvmyt/5tm7f6REhtxMPqwO8JcWDYtO05cWx7lV7VV+aTeldi BNvbQMqwrvdr17VKVrTPkq1sTGTDpnB+rPs8eUfPy+B4bACvbj20x9cZMqbJY1ih LZEeKWTvBgQ9DLb63BmKejem5XD34iITBmi5Vqh5+d8X/Knhnrb/Tk5XY2L0znI0 oMUL6ACblH2EI5uuCGNrL71oO9E2ysBJwtYYAa7UnNoma+2FZWdDdDH8Vf46Ed4g HJc70GGp09sMi+vabVwUAI2/09J7a8NAF/WXTQ8NIJkpvhGvINIwpg9hrVUlze8= =g7W6 -END PGP SIGNATURE- -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Best Regards, xunxun -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] OpenMP-related hangup with winpthreads
于 2013/5/1 星期三 21:15, LRN 写道:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01.05.2013 10:32, xunxun wrote:
On Wed, May 1, 2013 at 3:13 AM, LRN lrn1...@gmail.com wrote:
On 30.04.2013 19:18, xunxun wrote:
于 2013/4/24 星期三 19:12, LRN 写道:
msgmerge.exe (from gettext, i guess) hangs up, consuming 100% of a CPU
core, this is the backtrace:
#0 0x74d53b64 in SleepEx () from C:\Windows\syswow64\KernelBase.dll
#1 0x74d54498 in Sleep () from C:\Windows\syswow64\KernelBase.dll
#2 0x6494406b in _spin_lite_lock (l=0x64943003 mutex_ref+19) at
../winpthreads-svn-r5792/src/spinlock.c:256
#3 0x0001 in ?? ()
#4 0x64943003 in mutex_ref (m=0x11, m@entry=0x534fb4) at
../winpthreads-svn-r5792/src/mutex.c:60
#5 0x6494317f in pthread_mutex_lock_intern (timeout=4294967295,
m=0x534fb4) at ../winpthreads-svn-r5792/src/mutex.c:236
#6 pthread_mutex_lock (m=m@entry=0x534fb4) at
../winpthreads-svn-r5792/src/mutex.c:223
#7 0x64943482 in rwlock_gain_both_locks
(rwlock=rwlock@entry=0x534fa0) at
../winpthreads-svn-r5792/src/rwlock.c:107
#8 0x64943b5e in pthread_rwlock_wrlock
(rwlock_=rwlock_@entry=0x6494f08c) at
../winpthreads-svn-r5792/src/rwlock.c:430
#9 0x64944f26 in pthread_key_delete (key=0) at
../winpthreads-svn-r5792/src/thread.c:739
#10 0x6360da61 in team_destructor () from f:\s31\mingw\bin\libgomp-1.dll
#11 0x in ?? ()
I'm using an svn-r5792 version of winpthreads + libgomp patches from
ktietz.
Where is the libgomp patches?
He pastebinned that patch at 2013-04-22 15:24:19 (that pastebin is
no longer alive, so i've attached the copy that i've got back then).
And what's your gettext configure option?
I don't know whether gettext has one option which can only use
pthread lib but not use openmp.
- --prefix=${prefix} \
- --enable-shared --enable-static --enable-silent-rules \
- --enable-threads=win32 \
- --with-included-gettext --with-included-glib --with-included-libcroco \
- --with-included-unistring --with-included-libxml \
- --disable-rpath \
- --without-emacs --disable-native-java --disable-curses \
and i've added --disable-openmp for now, to work around this problem.
Now that you've mentioned it, maybe i should use --enable-threads=posix
with openmp?
Maybe using posix thread is right.
And I use my built gettext, but can't reproduce the issue (when running
msgmerge.exe --update -q nul nul)
I use static winpthread and static posix gcc 4.7.3.
My gettext configure option is :
./configure --prefix=/mingw/gettext \
--disable-shared --enable-static \
--enable-threads=posix \
--with-included-gettext --with-included-glib --with-included-libcroco \
--with-included-unistring --with-included-libxml \
--disable-rpath --disable-nls \
--without-emacs --disable-native-java --disable-curses \
--enable-relocate
My winpthread configure option is :
./configure --prefix=/mingw --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-mingw32 --enable-static
--disable-shared
My gcc configure option is :
../gcc-4.7.3/configure --prefix=/mingw \
--with-arch=pentium4 --with-tune=core-avx-i \
--build=i686-w64-mingw32 --host=i686-w64-mingw32
--target=i686-w64-mingw32 \
--with-lto-plugin --with-host-libstdcxx=-lstdc++
--disable-bootstrap --disable-werror \
--enable-languages=c,c++,fortran --enable-libgomp
--enable-threads=posix --enable-libstdcxx-threads
--enable-libstdcxx-time --enable-lto --with-system-zlib --with-libiconv \
--enable-version-specific-runtime-libs
--enable-fully-dynamic-string --disable-libstdcxx-pch
--disable-libstdcxx-debug --enable-graphite \
--disable-sjlj-exceptions --with-dwarf2 --disable-symvers
--enable-checking=release --enable-cxx-flags='-fno-function-sections
-fno-data-sections' \
--enable-cloog-backend=isl --disable-shared --enable-static
--disable-win32-registry --disable-rpath --enable-plugins \
--enable-libquadmath-support --enable-libquadmath
--disable-multilib --disable-ppl-version-check
--disable-cloog-version-check --with-gnu-as --with-gnu-ld \
--disable-nls --with-pkgversion=pcx32
I don't know where is your problem, but you can try
--enable-threads=posix to build gettext first. ( Maybe static winpthread
is better? )
- --
O ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJRgRV9AAoJEOs4Jb6SI2CwZUMIAJHXbx5pZMjmwXZsJD4Z1V4R
h/tbQd/Ihd/NsT9/1syt5o/PwrtfX72oIPx1vPQvbnNTG2chOJL77QbtjcmatBUE
pWqxIJJeq18WydCvtONz/o+VBdrZ1zdWNosaGlygw7PZmLWcLNV+sDwJQhxqRrcs
szgnyODBP/VVn9ADuZydfsBz0VfnvS3E/LyIEloLV43Xnzr5hgIXLVFGMVKQXr0E
maRZaLygplLbuj2A4EBgcb/xMWKNtEWX2hoUHIk0KAL8pxOe1NI6bSOils4PidIK
itYFHTcx24Zrg4Jw8IxMExqf9N4YfEgb6Ggm7yS2OCkXNCbL7MB5eWIs1+hEPkE=
=9NRU
-END PGP SIGNATURE-
--
Introducing AppDynamics Lite
Re: [Mingw-w64-public] OpenMP-related hangup with winpthreads
于 2013/4/24 星期三 19:12, LRN 写道: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 msgmerge.exe (from gettext, i guess) hangs up, consuming 100% of a CPU core, this is the backtrace: #0 0x74d53b64 in SleepEx () from C:\Windows\syswow64\KernelBase.dll #1 0x74d54498 in Sleep () from C:\Windows\syswow64\KernelBase.dll #2 0x6494406b in _spin_lite_lock (l=0x64943003 mutex_ref+19) at ../winpthreads-svn-r5792/src/spinlock.c:256 #3 0x0001 in ?? () #4 0x64943003 in mutex_ref (m=0x11, m@entry=0x534fb4) at ../winpthreads-svn-r5792/src/mutex.c:60 #5 0x6494317f in pthread_mutex_lock_intern (timeout=4294967295, m=0x534fb4) at ../winpthreads-svn-r5792/src/mutex.c:236 #6 pthread_mutex_lock (m=m@entry=0x534fb4) at ../winpthreads-svn-r5792/src/mutex.c:223 #7 0x64943482 in rwlock_gain_both_locks (rwlock=rwlock@entry=0x534fa0) at ../winpthreads-svn-r5792/src/rwlock.c:107 #8 0x64943b5e in pthread_rwlock_wrlock (rwlock_=rwlock_@entry=0x6494f08c) at ../winpthreads-svn-r5792/src/rwlock.c:430 #9 0x64944f26 in pthread_key_delete (key=0) at ../winpthreads-svn-r5792/src/thread.c:739 #10 0x6360da61 in team_destructor () from f:\s31\mingw\bin\libgomp-1.dll #11 0x in ?? () I'm using an svn-r5792 version of winpthreads + libgomp patches from ktietz. Where is the libgomp patches? This hangup happened twice already. Once when i was building gdb (at configure time, when it was creating po/Makefile), another - when i was building gstreamer-1.0-1.0.6 (at configure time, while checking for msgmerge...). Command line in both cases was msgmerge.exe --update -q nul nul or something similar. The code that spins is: while (tmp l-cur) Sleep (0); tmp is a small integer (9 and 37 in two cases i observed), l-cur is a large integer (all 4 bytes are non-zero). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRd740AAoJEOs4Jb6SI2Cw22EIANMAaktyUjq9EjYysmFX7R6Q Dir0haQ1BivbOsRQnR493ciJWRhbZCVynl3zze06N5oSB1Rb2FT95wOvzfHwvGeN 9/FBCDABOhHgATlA6Xkfj+UCL+g9Wfi6AGbXb69Vwz8FUz4JPPFcysDVNLclg/Vq lACg0XgUZ3JoC8NXKBECPhGZcbLJI8iecS63pN7q9Vg9B4y9aSr6789i/6eslppV gP0iYbwTa4cmyWM6U82iOKkK9lThjzlzV0FeMfHIsqTa9jP+T3SwD5TiyBmpbB0q mpePhFy3VhSJh2gKHWeQWM9Ya2SG+o9UNpBlwqDBgKjmBSjRov8fulPi7cOlffY= =nYi+ -END PGP SIGNATURE- -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Best Regards, xunxun -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] OpenMP-related hangup with winpthreads
于 2013/4/30 星期二 23:18, xunxun 写道: I'm using an svn-r5792 version of winpthreads + libgomp patches from ktietz. Where is the libgomp patches? And I remembered Kai recommended to change libgomp team.c team = gomp_malloc (size) to team = gomp_malloc_cleared (size) ago. -- Best Regards, xunxun -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Building a 64-bit Python-enabled GDB
于 2012/9/15 23:44, Ray Donnelly 写道: In the Google NDK git repo: https://android-review.googlesource.com/#/c/39651/ build/tools/toolchain-patches/gdb/0007-find-python.patch Now that I re-read it, it's all about setting PYTHONHOME env var; the dll is of course found by being in the same folder as gdb.exe (and differently named from CPython's one). For determining PYTHONHOME it expects a certain relative layout but also does some searching (I wanted to be a bit defensive in case the install prefix got modified). Did you try to build Python yet using https://dl.dropbox.com/u/17108768/crucifixion-freedom.7z ? Cheers, Ray. I use another patch to make python built by mingw two years ago : http://bugs.python.org/file19587/python-2.7-20101112-MINGW.patch But why not to use official python dll? There is no problem. On Sat, Sep 15, 2012 at 4:29 PM, niXman i.nix...@gmail.com wrote: 2012/9/15 Ray Donnelly: I explicitly set my path at the top of main in my gdb so that it finds my Python every time. It's never failed. I also renamed python27.dll to python2.7.dll to make sure that dll hell doesn't bite me. Hi, Where can I find this patch? ;) Thank tou! -- Regards, niXman -- Best Regards, xunxun -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] rubenvb 4.7.1-2-release build
于 2012/8/23 23:55, Ruben Van Boxem 写道: 2012/8/23 xunxun xunxun1...@gmail.com mailto:xunxun1...@gmail.com 于 2012/8/23 16:43, Ruben Van Boxem 写道: 2012/8/23 Loaden loa...@gmail.com mailto:loa...@gmail.com *mingw32-make.exe problem after 4.7.0 ~ 4.7.1-2 and 4.6.3-1* When I build Qt5 using x86_64-w64-mingw32-gcc-4.6.3-release-win64_rubenvb.7z on Windows, It's works well! But the configure failed with *4.7.0 ~ 4.7.1-2 and 4.6.3-1* *Failed Message:* g++ -Wl,-subsystem,console -mthreads -o ../../configure.exe main.o configureapp.o environment.o tools.o qarraydata.o qbytearray.o qbytearraymatcher.o qhash.o qlist.o qlocale.o qlocale_win.o qlocale_tools.o qvector.o qutfcodec.o qtextcodec.o qglobal.o qnumeric.o qbuffer.o qdatastream.o qdir.o qdiriterator.o qfiledevice.o qfile.o qfileinfo.o qabstractfileengine.o qfilesystementry.o qfilesystemengine.o qfilesystemengine_win.o qfilesystemiterator_win.o qfsfileengine.o qfsfileengine_win.o qfsfileengine_iterator.o qiodevice.o qtextstream.o qlogging.o qtemporaryfile.o qsystemlibrary.o qbitarray.o qdatetime.o qmap.o qregexp.o qstring.o qstringlist.o qvsnprintf.o qvariant.o qsystemerror.o qmetatype.o qmalloc.o qxmlstream.o qxmlutils.o quuid.o qcryptographichash.o registry.o -lole32 -ladvapi32 -luuid g++: error: main.o: No such file or directory g++: error: configureapp.o: No such file or directory g++: error: environment.o: No such file or directory g++: error: tools.o: No such file or directory g++: error: qarraydata.o: No such file or directory g++: error: qbytearray.o: No such file or directory g++: error: qbytearraymatcher.o: No such file or directory g++: error: qhash.o: No such file or directory g++: error: qlist.o: No such file or directory g++: error: qlocale.o: No such file or directory g++: error: qlocale_win.o: No such file or directory g++: error: qlocale_tools.o: No such file or directory g++: error: qvector.o: No such file or directory g++: error: qutfcodec.o: No such file or directory g++: error: qtextcodec.o: No such file or directory g++: error: qglobal.o: No such file or directory g++: error: qnumeric.o: No such file or directory g++: error: qbuffer.o: No such file or directory g++: error: qdatastream.o: No such file or directory g++: error: qdir.o: No such file or directory g++: error: qdiriterator.o: No such file or directory g++: error: qfiledevice.o: No such file or directory g++: error: qfile.o: No such file or directory g++: error: qfileinfo.o: No such file or directory g++: error: qabstractfileengine.o: No such file or directory g++: error: qfilesystementry.o: No such file or directory g++: error: qfilesystemengine.o: No such file or directory g++: error: qfilesystemengine_win.o: No such file or directory g++: error: qfilesystemiterator_win.o: No such file or directory g++: error: qfsfileengine.o: No such file or directory g++: error: qfsfileengine_win.o: No such file or directory g++: error: qfsfileengine_iterator.o: No such file or directory g++: error: qiodevice.o: No such file or directory g++: error: qtextstream.o: No such file or directory g++: error: qlogging.o: No such file or directory g++: error: qtemporaryfile.o: No such file or directory g++: error: qbitarray.o: No such file or directory g++: error: qdatetime.o: No such file or directory g++: error: qmap.o: No such file or directory g++: error: qregexp.o: No such file or directory g++: error: qstring.o: No such file or directory g++: error: qstringlist.o: No such file or directory g++: error: qvsnprintf.o: No such file or directory g++: error: qvariant.o: No such file or directory g++: error: qsystemerror.o: No such file or directory g++: error: qmetatype.o: No such file or directory g++: error: qmalloc.o: No such file or directory g++: error: qxmlstream.o: No such file or directory g++: error: qxmlutils.o: No such file or directory g++: error: qcryptographichash.o: No such file or directory g++: error: registry.o: No such file or directory mingw32-make: *** [../../configure.exe] Error 1 *** qtbase/configure exited with non-zero status. If I copy the mingw32-make.exe from
Re: [Mingw-w64-public] [Mingw-users] x86_64-w64-mingw32-gcc: error: unrecognized option '-pthread'
于 2012/8/16 17:25, wangfeng wangfeng 写道: Hi, I used x86_64-w64-mingw32-mingw32 to build spice. Then I see the error: /x86_64-w64-mingw32-gcc: error: unrecognized option '-pthread'/ / / How can I resolve the problem? Thanks. Which version do you use? Only 4.7.x or newer can support -pthread now. Or you can replace it with -lpthread ps: x86_64 compiler is not supported by MinGW, and you should mail it to MinGW64 Email list -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] apparent hang using the experimental pthread library
Hi, Kai 于 2012/7/23 4:14, Kai Tietz 写道: Hello Roger, 2012/7/22 Roger Pack rogerdpa...@gmail.com: Greetings fellow program(mers). A situation occurred the other day where, using (cross compiled) ffmpeg+libx264 with mingw-w64, --enable-pthreads and the mingw-w64 pthread library, some oddness would result, like the app would hang eating up 100% cpu, seemingly doing nothing useful. I was told to bring it up here, as well. Well, the issue seems to be that a mutex, which is already up to be destroyed, is still waited to return. I allowed for this that a mutex can be destroyed even if another thread waits for lock for it. You may want to test revision 5250. I attempted to capture stack traces during the time that it was hung (though who knows how accurate they are): https://gist.github.com/3125847 well, there isn't that much of information. Maybe you get more information by enabling WINPTHREAD_DBG define. Anybody have any clue/idea as to what is going on? See above. Regards, Kai svn 5250 commited by you can fix the issue? -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] apparent hang using the experimental pthread library
于 2012/7/22 13:12, Roger Pack 写道: Greetings fellow program(mers). A situation occurred the other day where, using (cross compiled) ffmpeg+libx264 with mingw-w64, --enable-pthreads and the mingw-w64 pthread library, some oddness would result, like the app would hang eating up 100% cpu, seemingly doing nothing useful. I was told to bring it up here, as well. I attempted to capture stack traces during the time that it was hung (though who knows how accurate they are): https://gist.github.com/3125847 Anybody have any clue/idea as to what is going on? It is reproducible using ffmpeg.exe from here: http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-20120706-git-8293a21-win32-static.7z then download this file: http://rogerdpack.t28.net/incoming/sintel.mpg then run like this: $ ffmpeg -y -i sintel.mpg -pass 1 -t 75 -c:v libx264 -an nul.mp4 Hangs/pauses on the console occur sporadically. When compiled using ffmpeg's win32threads option instead of pthreads, it never has hangs. Any help appreciated. Original thread: http://ffmpeg.org/pipermail/ffmpeg-user/2012-July/007861.html -roger- Which edition MinGW64 GCC Compiler did you use? Can you give us the link? Is it win32 thread or posix thread? -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANNOUNCEMENT] mingw-w64-headers build behavior changes in trunk (v3)
Hello JonY and NightStrike, 于 2012/7/9 8:54, Kai Tietz 写道: Hello JonY and NightStrike, Thanks for the information. Just one question I have: Does the crt-configure have the same change? If not so, please do so for crt, too. Thanks, Kai Ping ? -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] cross compiling with static Qt libraries
于 2012/7/4 17:41, jan van katwijk 写道: Dear list I have an SDR application with Qt developed under Linux (Fedora/ubuntu). It does run under windows (vista/w7) using mingw/Qt. I am preparing a windows distribution with - as much as possible - statically bound libraries I installed Fedora 17 and the - excellent - cross compilation tools for mingw64. It was surprisingly simple to generate an executable using dynamically bound libs, however, when trying to create an executable with static binding for the most important (i.e. QtGui etc) libs, there are linking problems: apparently the references from the Qt libs to some windows libs cannot be resolved. It seems I have to specify some additional libs to be used in the linking process, but I am completely lost. This is the result of the linkage step: x86_64-w64-mingw32-g++ -static -Wl,-s -Wl,-subsystem,console -mthreads -o release/spectrum-viewer.exe object_script.spectrum-viewer.Release -L'/usr/x86_64-w64-mingw32/sys-root/mingw/lib' /home/jan/cross-compiling/dll_64/libfftw3-3.lib /home/jan/cross-compiling/qwt-5.2.2/lib/libqwt.a -lole32 -lwinmm -lstdc++ -lusb-1.0 -lQtGui4 -lQtCore4 /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libQtGui4.a(qapplication.o):(.text+0x1824): undefined reference to `__imp_CoCreateGuid' /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libQtGui4.a(qapplication.o):(.text+0x1849): undefined reference to `__imp_StringFromGUID2'\ You should add -lole32 /usr/lib64/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libQtGui4.a(qapplication.o): bad reloc address 0x0 in section `.data' /usr/lib64/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-mingw32/bin/ld: final link failed: Invalid operation collect2: error: ld returned 1 exit status make[1]: *** [release/spectrum-viewer.exe] Error 1 When I add in the makefile -lole32 at the end of the link command line, these specific references disappear and some new ones do appear: make -f Makefile.Release make[1]: Entering directory `/home/jan/cross-compiling/jsdr-3.04/spectrum-viewer' x86_64-w64-mingw32-g++ -static -Wl,-s -Wl,-subsystem,console -mthreads -o release/spectrum-viewer.exe object_script.spectrum-viewer.Release -L'/usr/x86_64-w64-mingw32/sys-root/mingw/lib' /home/jan/cross-compiling/dll_64/libfftw3-3.lib /home/jan/cross-compiling/qwt-5.2.2/lib/libqwt.a -lole32 -lwinmm -lstdc++ -lusb-1.0 -lQtGui4 -lQtCore4 -lole32 /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libQtGui4.a(qfont.o):(.text+0xc1b): undefined reference to `__imp_GetDeviceCaps' /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libQtGui4.a(qfont.o):(.text+0xc5b): undefined reference to `__imp_GetDeviceCaps' You should add -lgdi32 /usr/lib64/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libQtGui4.a(qfont.o): bad reloc address 0x0 in section `.data' /usr/lib64/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-mingw32/bin/ld: final link failed: Invalid operation collect2: error: ld returned 1 exit status make[1]: *** [release/spectrum-viewer.exe] Error 1 make[1]: Leaving directory `/home/jan/cross-compiling/jsdr-3.04/spectrum-viewer' make: *** [release] Error 2 No idea where to find GetDeviceCaps, and no idea how to specify the .pro file for Qt such that it includes the libraries needed in the right order Try LIBS += -lole32 -lgdi32 any help is greatly appreciated best -- Jan van Katwijk +31 (0)15 3698980 +31 (0) 628260355 -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: cross compiling with static Qt libraries
于 2012/7/4 18:12, jan van katwijk 写道: Thanx so far. It seems that the qmake does not generate a right order for the libs to be linked. When adding LIBS += -lole32 -lgdi32 to the .pro file, the -lole32 -lgdi32 appears in front of the Qtlibs and they will not find the symbols. When manually adding the libs to the line, these symbols are found, but a whole lot of others is not. It seems to me that I am doing something wrong in the .pro specification, but no clue what See the result Well, you may only change the related qmake.conf I don't know the other method. -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: cross compiling with static Qt libraries
And, Kai Should we add -lole32 and -lgdi32 to gcc's internal specs? This may avoid the issue. -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: cross compiling with static Qt libraries
于 2012/7/4 18:35, jan van katwijk 写道: May be this is the wrong list, do not know, but it seems to me that QtCore and QtGui need a lot of windows-related libs, such as ole32 and gdi32, and a lot more, but I cannot find which ones. The second issue is indeed the way the makefile is generated and the order in which the libraries appear in the command line of the linker. Once I know what the windows related libs are (or how to find these), I can build - by adapting the generated makefiles - my application. Not nice, but for the time being workable. So, if there is any pointer to how finding the appropriate libraries for missing symbols, that would already be a great help. best jan I don't know that. I built qt4.7.1 static lib on Win7 ago, but I have no your problem. Maybe your build process has some problems? -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange behavior of snwprintf() function
于 2012/7/4 23:46, niXman 写道:
The following code gives the right result when compiled without
defined __USE_MINGW_ANSI_STDIO macro.
But, if __USE_MINGW_ANSI_STDIO macro is defined - the result is 6.
Why?
code:
#include stdio.h
int main() {
wchar_t buf[2];
int len = snwprintf(buf, sizeof(buf) / 2, Lworld!);
printf(%d\n, len);
}
Thanks.
Without the macro, it will hit the code
#if !defined (__USE_MINGW_ANSI_STDIO) || __USE_MINGW_ANSI_STDIO == 0
#pragma push_macro(snwprintf)
#pragma push_macro(vsnwprintf)
# undef snwprintf
# undef vsnwprintf
int __cdecl __ms_snwprintf (wchar_t * __restrict__ s, size_t n, const
wchar_t * __restrict__ format, ...);
int __cdecl __ms_vsnwprintf (wchar_t * __restrict__ , size_t, const
wchar_t * __restrict__ , va_list);
__mingw_ovr
int snwprintf (wchar_t * __restrict__ s, size_t n, const wchar_t *
__restrict__ format, ...)
{
int r;
va_list argp;
__builtin_va_start (argp, format);
r = _vsnwprintf (s, n, format, argp);
__builtin_va_end (argp);
return r;
}
It will call ms's _vsnwprintf
With the macro, it will hit the code
#ifndef __NO_ISOCEXT /* externs in libmingwex.a */
__mingw_ovr
/* __attribute__((__format__ (gnu_wprintf, 3, 4))) */
__MINGW_ATTRIB_NONNULL(3)
int snwprintf (wchar_t *__stream, size_t __n, const wchar_t *__format, ...)
{
register int __retval;
__builtin_va_list __local_argv; __builtin_va_start( __local_argv,
__format );
__retval = __mingw_vsnwprintf( __stream, __n, __format, __local_argv );
__builtin_va_end( __local_argv );
return __retval;
}
It will call __mingw_vsnwprintf
Maybe someone can explain it here.
--
Best Regards,
xunxun
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] c99
于 2012/6/7 17:08, Baruch Burstein 写道: I am trying to compile a program with mingw-w64, but the instructions they supply only target regular mingw. They say to compile with the `-lmingwex` flag. By Googling I found that this is a compatibility layer for c99 functionality. Does this apply to mingw-w64 too, or is c99 functionality built-in? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı What's your instruction? mingw-w64 also link -lmingwex by default. -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] msys ./configure gives error 77, compiler doesn't generate exe's
于 2012/6/7 15:36, Jim Michaels 写道: I am using auto build 2027 since it is the only latest one I know of that works. Jim Michaels@jim-13l5nom9i4u /jp/bristol-0.60.10 $ ./configure checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/jp/bristol-0.60.10': configure: error: C compiler cannot create executables See `config.log' for more details. Jim Michaels@jim-13l5nom9i4u /jp/bristol-0.60.10 Jim Michaels@jim-13l5nom9i4u /jp/bristol-0.60.10 $ ./configure ; cat .profile checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/jp/bristol-0.60.10': configure: error: C compiler cannot create executables See `config.log' for more details. CC=/mingw/bin/i686-w64-mingw32-mingw32-gcc CXX=/mingw/bin/i686-w64-mingw32-g++ Jim Michaels@jim-13l5nom9i4u /jp/bristol-0.60.10 $ tail -1 config.log configure: exit 77 Jim Michaels@jim-13l5nom9i4u /jp/bristol-0.60.10 not sure what to do at this point. I am not a unix developer yet.I am trying to build Jack audio server plugins. this is sort of like a cry for help, I am no expert at fixing configure scripts if they are broken. MSYS seems to have nothing to make autoconf run properly if that is supposed to be my first step to fix the configure script. I have never run autoconf before, so I don't know what to do with it. maybe I should be taking this to a linux newsgroup instead? I brought it here first because its mingw-w64+msys I am compiling this on. I noticed some configure scripts work and some don't, for whatever reason (date compiled?). It's hard to say. At least, you should provide the related config.log -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] specs file location
Hi John An off-list question GCC4.7.1 will be released soon. Will you build it for your new edition? -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] specs file location
于 2012/5/30 21:10, Ruben Van Boxem 写道: 2012/5/30 xunxun xunxun1...@gmail.com mailto:xunxun1...@gmail.com 于 2012/5/30 20:55, Ruben Van Boxem 写道: Hmm... it seems like it's looking in my --prefix or --sysroot directory. The MinGW;org version would only work if you installed it in C:\MinGW or are using MSYS. I unfortunately do not know where this search path is hardcoded in GCC. JonY or ktietz or anyone else: do you know where I could make this path relative in GCC? I think it's related with the --sysroot, which can hardcode the path. When I don't use --sysroot, specs will be in default path. But if using cross compiling, --sysroot should be a prerequisite option. OK, so a native compiler might do without. I still think this should be changed to respect sysroot. I hope someone knows where to look :) Ruben Forward to MinGW64 mail list :) -- Best Regards, xunxun -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] changing defaults
于 2012/5/24 2:04, Kai Tietz 写道: Well you can dump current default spec by option '-dumpspecs'. But I use gcc -dumpspecs specs1 g++ -dumpspecs specs2 gfortran -dumpspecs specs3 specs1, specs2 and specs3's content is the same... -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] std::this_thread::sleep_for not working
于 2012/5/14 7:40, K. Frank 写道: Hello All! I am finding that std::this_thread::sleep_for is not fully/properly implemented. I am using Ruben's 64-bit mingw-w64 4.7.0thread-enabled build. When I try compiling: g++ -std=c++0x -static -o test_sleep test_sleep.cpp the line: std::this_thread::sleep_for (std::chrono::milliseconds(500)); I get the error: error: 'sleep_for' is not a member of 'std::this_thread' When I try compiling with the following magic incantation: g++ -D_GLIBCXX_USE_NANOSLEEP -std=c++0x -static -o test_sleep test_sleep.cpp I get the error: In file included from test_sleep.cpp: c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/4.7.0/thread: In function 'void std::this_thread::sleep_for(const std::chrono::duration_Rep, _Period)': c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/4.7.0/thread:277:2: error: '::nanosleep' has not been declared Some background: Going back over my notes I see that when I was building mythread implementation I came across this same issue, but I never came back to sort it out or implement it properly. (At the time I was focused on using sleep_for as part of a test for some of the otherthread stuff I had implemented, rather than on implementing sleep_for itself. So I just moved forward by using the native windows sleep for my testing and overlooked coming back to get sleep_for working.) This looks like a semi-know issue in the gcc / linux world. Here are a couple of semi-random references: http://markmail.org/message/ufyrfwq6qjphewbm#query:+page:1+mid:4mui756gcycjvjnx+state:results https://bugs.archlinux.org/task/27751 (Hence my attempt to us -D_GLIBCXX_USE_NANOSLEEP.) Best. K. Frank I think it need to rebuild gcc using --enable-libstdcxx-time=yes -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] std::this_thread::sleep_for not working
于 2012/5/14 15:15, Ruben Van Boxem 写道: I'll add that in my next build. The question becomes then why is this not detected by configure automatically? Maybe Kai knows. This happened in gcc4.6.x first, so I use --enable-libstdcxx-time=yes from then. -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regarding usage of latest Mingw for MAME
I think Ruben's gdb was built using --with-sysroot= If you rebuild gdb when not using --with-sysroot=, the warnings will be gone. I remembered this only exists in x86 gdb. On Sun, May 6, 2012 at 10:58 PM, JonY jo...@users.sourceforge.net wrote: On 5/6/2012 22:28, Miodrag Milanovic wrote: Hi, I generate 32 bit executable and load it with 32bit GDB, and got those warnings. When I generate 64bit executable and load it with 64bit GDB no warnings. Micko I see, at which case, I'm not sure what's going on. Somebody should test if it happens on a 32bit system. Unfortunately, I don't have any at the moment. PS, top posting while using inline quoting makes your messages hard to read. Top posting only goes well for Outlook style quoting. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Best Regards, xunxun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Question about warning: ISO C does not support the 'I64' ms_printf length modifier
It seems that some code may be built using -pedantic ... which can imply `__STRICT_ANSI__'. On Thu, Apr 12, 2012 at 7:04 PM, niXman i.nix...@gmail.com wrote: I.e. these warnings is reported when building gcc. example: x86_64-w64-mingw32-gcc -c -O2 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -I/./mingw-libs-x64/include -D__USE_MINGW_ACCESS -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I../../../mingw-src/gcc-trunk/gcc -I../../../mingw-src/gcc-trunk/gcc/. -I../../../mingw-src/gcc-trunk/gcc/../include -I../../../mingw-src/gcc-trunk/gcc/../libcpp/include -I/./mingw-libs-x64/include -I/./mingw-libs-x64/include -I/./mingw-libs-x64/include -I../../../mingw-src/gcc-trunk/gcc/../libdecnumber -I../../../mingw-src/gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -I/./mingw-libs-x64/include -I/./mingw-libs-x64/include -DCLOOG_INT_GMP -DCLOOG_ORG -I/./mingw-libs-x64/include ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c -o lto-streamer.o ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c: In function 'lto_get_section_name': ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:173:5: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:175:5: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c: In function 'print_lto_report': ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:190:5: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:194:5: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:198:5: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:207:9: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:215:9: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:215:9: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:229:9: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:233:9: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:237:9: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:243:9: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:243:9: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:256:7: warning: ISO C does not support the 'I64' ms_printf length modifier [-Wformat] -- Regards, niXman -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Best Regards, xunxun -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Maybe of interrest.
Hi, reckless Yea, I forgot you had emailed me some days ago. Can you make your package more small? I will check some issues I had found in my dragonegg plugin. And I want to port the dragonegg plugin (c/c++/fortran) to gcc4.7.x on windows, but it may have another questions. After jens make codeblocks can be built using gcc4.7, I will investigate it. On Sun, Apr 1, 2012 at 11:13 PM, ralph engels ralpheng...@gmail.com wrote: Hello. Im the maintainer of C::B advanced and also an old member of inside3d where i stumbled upon sezero which i remembered maintained some ports of MinGW64. We had a little chat and he said you might be interrested in some of my work on the mingw64 compiler. My build is strictly 32 or 64 bit but i managed to get ada and the dragonegg plugin working (used some prework from other users as a base). Ada compiles fine besides one little bug it cannot find the crt libraries when doing the final link when bootstrapping unless you copy the crt libraries to the gcc source gcc folder. Using sysroot also fails so it seems to be something with gcc itself on windows. If you want my patches or sources (gcc-4.6.2 currently) let me know. Also feel free to use whatever you might find usefull on my site. the dragonegg plugins work like a charm but are a bit different than the linux ones as the plugins are specific for each compiler. Example if your source is pure C you use -fplugin=dragonegg-cc1 if its C++ you use -fplugin=dragonegg-cc1plus and so on. Revelator -- Best Regards, xunxun -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
于 2012/3/16 23:22, Ruben Van Boxem 写道: I think it is. These seem to be related to GCC plugins, and do not appear in my 4.6.4 build for example. When I try to run them, I get an error about the program not being built with plugins (probably cause I didn't enable them explicitely in binutils or gcc or something). The original binutils binaries were never prefixed, so I'd say just ignore them and use the prefixless versions. You should build binutils using --enable-plugin x86_64-w64-mingw32-gcc-ar.exe is a ar plugin wrapper -- Best Regards, xunxun -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: host/build/target for multilib cross compiler
于 2012/3/8 22:43, niXman 写道: 2012/3/7 niXmani.nix...@gmail.com: I have two thoughts: 1. Incorrectly configured binutils. 2. For the GCC configure to be able to specify the path to the 32/64 bit libraries. Ping? I found a blog post about the same problem: http://pete.akeo.ie/search/label/MinGW-w64 and on mingw-w64 forum: https://sourceforge.net/projects/mingw-w64/forums/ forum/723797/topic/3966835 This problem has been known for over a year ago, and it is still not fixed ... I asked the question about how to specify the path to the 32/64 bit libraries when configuring GCC: http://gcc.gnu.org/ml/gcc-help/2012-03/msg00080.html In the file gcc/config/i386/t-mingw-w32 paths are correct: MULTILIB_OSDIRNAMES = ../lib64 ../lib What should I do? Try to use LDFLAGS=-L/yourpath/lib64 ./configure ... -- Best Regards, xunxun -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: host/build/target for multilib cross compiler
On Wed, Mar 7, 2012 at 7:27 PM, niXman i.nix...@gmail.com wrote: 1. host compiler (dwarf) installed in /e/mingw: Using built-in specs. COLLECT_GCC=e:\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=e:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.3/lto-wrapper.exe Target: i686-pc-mingw32 Configured with: ../../mingw-src/gcc-4.6.3/configure \ --host=i686-pc-mingw32 --build=i686-pc-mingw32 \ --target=i686-pc-mingw32 --prefix=/mingw-dwarf-x86 \ --with-arch=i686 --with-tune=generic \ --enable-languages=c,c++,lto,fortran \ --enable-libstdcxx-time=yes --with-host-libstdcxx=-lstdc++ \ --enable-shared --enable-static --enable-libgomp \ --enable-lto --enable-graphite --enable-cloog-backend=isl \ --enable-checking=release --enable-fully-dynamic-string \ --enable-threads=posix --disable-libstdcxx-pch \ --enable-libstdcxx-debug --disable-sjlj-exceptions \ --with-dwarf2 --disable-debug --disable-bootstrap \ --disable-multilib --disable-rpath --disable-win32-registry \ --disable-nls --disable-werror --disable-symvers \ --with-gmp=/mingw-libs --with-mpfr=/mingw-libs \ --with-mpc=/mingw-libs --with-ppl=/mingw-libs \ --with-cloog=/mingw-libs --with-libiconv-prefix=/mingw-libs 2. building binutils: --target=i686-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --enable-multilib --enable-64-bit-bfd --prefix=$PREFIX --with-sysroot=$PREFIX --disable-nls --enable-lto --with-libiconv-prefix=$LIBS_DIR 3. building mingw-w64-headers: --host=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=$PREFIX --with-sysroot=$PREFIX --enable-sdk=all --enable-secure-api 4. building gcc-c: --target=i686-w64-mingw32 --enable-targets=all --enable-multilib --prefix=$PREFIX --with-sysroot=$PREFIX --enable-languages=c,c++,lto 5. building mingw-w64-crt: --host=i686-w64-mingw32 --prefix=$PREFIX --with-sysroot=$PREFIX --enable-lib32 --enable-lib64 --enable-wildcard 6. building gcc-all: make all make log attached. In log file you can see that libgcc_s_sjlj.dll - 32bit is built successfully(in first line), but libgcc_s_sjlj.dll 64 bit - error. (in second line) Hmm, this may be your ld search path has some problems. You can use /home/niXman/mingw-build/gcc-4.6.3/./gcc/xgcc -v -x c++ /dev/null And locate LIBRARY_PATH, it seems that your ld didn't search 64 libs. Ideas? Thanks. -- Best Regards, xunxun -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: host/build/target for multilib cross compiler
于 2012/3/7 20:04, niXman 写道: 2012/3/7 xunxunxunxun1...@gmail.com: /home/niXman/mingw-build/gcc-4.6.3/./gcc/xgcc -v -x c++ /dev/null Using built-in specs. COLLECT_GCC=E:\msys\home\niXman\mingw-build\gcc-4.6.3\gcc\xgcc.exe Target: i686-w64-mingw32 Configured with: ../../mingw-src/gcc-4.6.3/configure --target=i686-w64-mingw32 --enable-targets=all --enable-multilib --prefix=/home/niXman/mb-0.8/../mingw-x32 --with-sysroot=/home/niXman/mb-0.8/../mingw-x32 --with-tune=generic --enable-languages=c,c++,lto --enable-libstdcxx-time=yes --with-host-libstdcxx='-static -lstdc++' --enable-shared --enable-static --enable-libgomp --enable-lto --enable-graphite --enable-cloog-backend=isl --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-threads --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-sjlj-exceptions --disable-debug --disable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gmp=/home/niXman/mb-0.8/../mingw-libs --with-mpfr=/home/niXman/mb-0.8/../mingw-libs --with-mpc=/home/niXman/mb-0.8/../mingw-libs --with-ppl=/home/niXman/mb-0.8/../mingw-libs --with-cloog=/home/niXman/mb-0.8/../mingw-libs --with-libiconv-prefix=/home/niXman/mb-0.8/../mingw-libs --with-pkgversion='niXman build' --with-bugurl=http://code.google.com/p/mingw-builds/issues/list CFLAGS='-O3 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -I/home/niXman/mb-0.8/../mingw-libs/include' CXXFLAGS='-O3 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -I/home/niXman/mb-0.8/../mingw-libs/include -O3 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer' CPPFLAGS= LDFLAGS='-pipe -s -L/home/niXman/mb-0.8/../mingw-libs/lib' Thread model: single gcc version 4.6.3 (niXman build) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=pentiumpro' cc1plus -quiet -v -iprefix e:\msys\home\nixman\mingw-build\gcc-4.6.3\gcc\../lib/gcc/i686-w64-mingw32/4.6.3/ -U_REENTRANCE nul -quiet -dumpbase nul -mtune=generic -march=pentiumpro -auxbase nul -version -o C:\Users\niXman\AppData\Local\Temp\ccpNGHI5.s xgcc.exe: error: CreateProcess: No such file or directory Last line. %) And locate LIBRARY_PATH, it seems that your ld didn't search 64 libs. Ideas? Thanks. -- Best Regards, xunxun Try cd /home/niXman/mingw-build/gcc-4.6.3/./gcc/ xgcc -v -x c++ /dev/null And your building binutils: --target=i686-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --enable-multilib --enable-64-bit-bfd --prefix=$PREFIX --with-sysroot=$PREFIX --disable-nls --enable-lto --with-libiconv-prefix=$LIBS_DIR I think you should take out --target=i686-w64-mingw32 -- Best Regards, xunxun -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] host/build/target for multilib cross compiler
Try gcc: --build=x86_64-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32,x86_64-w64-mingw32 --enable-targets=all On Mon, Mar 5, 2012 at 10:34 PM, niXman i.nix...@gmail.com wrote: 2012/3/5 niXman i.nix...@gmail.com: 2012/3/5 JonY jo...@users.sourceforge.net: On 3/5/2012 13:22, niXman wrote: 2012/3/5 JonY jo...@users.sourceforge.net: On 3/5/2012 12:59, niXman wrote: Hi, I try to build multilib cross compiler for host=x86 and targets x86/x86_64 (is it possible?) and get the errors on build crt/lib64 what say that 64 bit is not compiled in. Tell me please which host/build/target I need to set for binutils/gcc-c/gcc-c++/crt? Thanks. You should always post your build details, information such as host/build system triplet, binutils, gcc headers, and crt configure command. Even config.log postings will help. Its otherwise a bit hard to guess what you did wrongly. I have only one error: '64 bit not compiled in' when build crt/lib64. So I ask, what host/build/target I have to set for the binutils/gcc-c/crt? Thanks. You haven't posted any information regarding the GCC/binutils you built, or the configure options you used for the CRT. For gcc and binutils, use --target=x86_64-w64-mingw32 --host=triplet you want to use the toolchain on. For CRT, use --build=whatever you put in GCC --host --host=whatever you put in GCC --target. It's building right now... Did you understand me properly? I want to build MinGW for x86-host and x86/x86_64 targets. binutils: --host=i686-pc-mingw32 --target=x86_64-w64-mingw32 gcc: --host=i686-pc-mingw32 --target=x86_64-w64-mingw32 --enable-targets=all CRT: --build=i686-pc-mingw32 --host=x86_64-w64-mingw32 Is it right? Error on configure gcc: configure: WARNING: you should use --build, --host, --target checking build system type... Invalid configuration `build': machine `build' not recognized configure: error: /bin/sh ../../mingw-src/gcc-4.6.3/config.sub build failed I would really encourage you to use the prebuilt Makefiles, or at least take a look at it instead of stumbling about blindly. Didn't understand what did you talk about. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Regards, niXman -- Regards, niXman -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Best Regards, xunxun -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] host/build/target for multilib cross compiler
于 2012/3/5 22:58, niXman 写道: JonY, xunxun, so what kind of flags should I use? That depends on which compiler you want to use now, and what OS you are on now. -- Best Regards, xunxun -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] host/build/target for multilib cross compiler
于 2012/3/5 23:05, niXman 写道: 2012/3/5 xunxunxunxun1...@gmail.com: 于 2012/3/5 22:58, niXman 写道: JonY, xunxun, so what kind of flags should I use? That depends on which compiler you want to use now, and what OS you are on now. compiler - i686-pc-mingw32 os - win7 x64 I think the process is: 1) binutils --host=i686-pc-mingw32 --build=i686-pc-mingw32 --enable-targets=x86_64-w64-mingw32,i686-pc-mingw32 --enable-multilib make install 2) build gcc but no libs --host=i686-pc-mingw32 --build=i686-pc-mingw32 --enable-targets=all --enable-multilib make all-gcc make install-gcc 3) build crt --enable-lib32 --enable-lib64 4) build gcc make -- Best Regards, xunxun -- Best Regards, xunxun -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] host/build/target for multilib cross compiler
于 2012/3/5 23:52, niXman 写道: 2012/3/5 xunxunxunxun1...@gmail.com: 于 2012/3/5 23:05, niXman 写道: 2012/3/5 xunxunxunxun1...@gmail.com: 于 2012/3/5 22:58, niXman 写道: JonY, xunxun, so what kind of flags should I use? That depends on which compiler you want to use now, and what OS you are on now. compiler - i686-pc-mingw32 os - win7 x64 I think the process is: 1) binutils --host=i686-pc-mingw32 --build=i686-pc-mingw32 --enable-targets=x86_64-w64-mingw32,i686-pc-mingw32 --enable-multilib make install 2) build gcc but no libs --host=i686-pc-mingw32 --build=i686-pc-mingw32 --enable-targets=all --enable-multilib make all-gcc make install-gcc 3) build crt --enable-lib32 --enable-lib64 4) build gcc make Thanks a lot for your reply. Tell me please, what kind of flags should I use for building mingw-w64-headers and which symlinks create for them? The headers are not the problem, because X86 and X64 use the same headers. You can use --host=i696-pc-mingw32 Usally I don't use symlink on Windows, it can be very annoyed and may have some bugs on Windows and it may depend on your sysroot set. Assume your predix is /mingw You can copy your headers and libs to /mingw, /mingw/mingw, /mingw/targets. They may be redundant, and you can try to make it sure when building ( if not finding some headers and libs, you can see relational config.log ). Good luck! Thanks. -- Best Regards, xunxun -- Best Regards, xunxun -- Best Regards, xunxun -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: host/build/target for multilib cross compiler
于 2012/3/6 2:47, niXman 写道: The same error on building crt: _libm_dummy.c:1:0: sorry, unimplemented: 64-bit mode not compiled in That`s how I do it : 1. binutils: --host=i686-pc-mingw32 --build=i686-pc-mingw32 --enable-targets=x86_64-w64-mingw32,i686-pc-mingw32 --enable-multilib --prefix=$PREFIX --with-sysroot=$PREFIX 3. set PATH: export PATH=$PREFIX/bin:$PATH 4. gcc-c: --host=i686-pc-mingw32 --build=i686-pc-mingw32 --target=i686-pc-mingw32 --enable-targets=all --enable-multilib --prefix=$PREFIX --with-sysroot=$PREFIX I think here don't need --target=i686-pc-mingw32 And after building it, using the built gcc to overwrite your present gcc, please make sure that gcc -m64 can work. 5. crt: --enable-lib32 --enable-lib64 --prefix=$PREFIX --with-sysroot=$PREFIX What am I doing wrongly? Thanks. -- Best Regards, xunxun -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] New rubenvb GCC 4.6 personal build: std::thread fixed!
于 2012/3/6 10:12, K. Frank 写道: Hello Ruben! On Mon, Mar 5, 2012 at 2:57 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Hi guys, niXman has pointed me to a workaround which is as good as a fix for the shared libstdc++ std::thread problem. It's been fixed in this build. Great news! Thank you. Do you have any plans to build a 4.7 version with this fix? I think he will when the 4.7.0 release after these days. ... Enjoy, Ruben Happy Hacking! K. Frank -- Best Regards, xunxun -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] New rubenvb GCC 4.6 personal build: std::thread fixed!
于 2012/3/6 3:57, Ruben Van Boxem 写道:
Hi guys,
niXman has pointed me to a workaround which is as good as a fix for
the shared libstdc++ std::thread problem. It's been fixed in this build.
I have used for this build:
- GCC 4.6 (currently 4.6.4 prerelease, so it's 4.6.3 with a few minor
patches from upstream)
- binutils/gdb trunk
- mingw-w64 trunk: it's stable enough and has some cool stuff added.
- LLVM/Clang trunk.
If the person having trouble with OpenMP crashes please retest (and if
the problem is still present, please give a testcase, as simple as
possible!), I'd appreciate it.
I've left out Mac and Cygwin builds, as I've switched to Arch Linux
for these and all future builds. This also means you might need a
newer glibc than your Linux distro installs, as Arch is on 2.15. I
can't help this. If you really need my toolchain on your linux, it's
quite easy to build yourself from source, albeit time-consuming.
Enjoy,
Ruben
Downloads in their usual places:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/4.6.4/
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/4.6.4/
http://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources%20Win64/Personal%20Builds/rubenvb/
And I recall some binutils patch from Kai, the patch can solve the bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=12762
Because of some reasons, the sections are not approved by binutils
maintainers.
--
Best Regards,
xunxun
diff -ruNa binutils-2.22.51/bfd/coffgen.c binutils-new/bfd/coffgen.c
--- binutils-2.22.51/bfd/coffgen.c 2011-10-06 16:59:36 +0800
+++ binutils-new/bfd/coffgen.c 2011-10-31 21:19:14 +0800
@@ -921,6 +921,9 @@
void * buf;
bfd_size_type symesz;
+ if ((bfd_get_section_flags (abfd, symbol-section) SEC_LINK_ONCE) != 0
+ symbol-section-output_section == bfd_abs_section_ptr)
+return TRUE;
if (native-u.syment.n_sclass == C_FILE)
symbol-flags |= BSF_DEBUGGING;
diff -ruNa binutils-2.22.51/bfd/cofflink.c binutils-new/bfd/cofflink.c
--- binutils-2.22.51/bfd/cofflink.c 2011-08-17 08:39:38 +0800
+++ binutils-new/bfd/cofflink.c 2011-10-31 21:19:36 +0800
@@ -392,7 +392,10 @@
section = coff_section_from_bfd_index (abfd, sym.n_scnum);
if (! obj_pe (abfd))
value -= section-vma;
- break;
+ if (bfd_is_abs_section (section)
+ || section-output_section != bfd_abs_section_ptr)
+ break;
+ /* Fall through */
case COFF_SYMBOL_UNDEFINED:
flags = 0;
@@ -410,6 +413,12 @@
break;
}
+ /*if (obj_pe (abfd) _bfd_coff_section_already_linked (abfd,
section, info))
+ {
+ flags = 0;
+ section = bfd_und_section_ptr;
+ }*/
+
if (IS_WEAK_EXTERNAL (abfd, sym))
flags = BSF_WEAK;
@@ -2318,7 +2327,9 @@
if ((o-flags SEC_LINKER_CREATED) != 0)
continue;
-
+ if (!bfd_is_abs_section (o)
+ o-output_section == bfd_abs_section_ptr)
+ continue;
if ((o-flags SEC_HAS_CONTENTS) == 0
|| (o-size == 0 (o-flags SEC_RELOC) == 0))
{
@@ -2386,7 +2397,10 @@
if (ps == NULL)
continue;
/* Complain if definition comes from an excluded section. */
- if (ps-flags SEC_EXCLUDE)
+ if ((ps-flags SEC_EXCLUDE) != 0
+ (ps-owner-flags BFD_PLUGIN) == 0
+ !bfd_is_abs_section (ps)
+ bfd_is_abs_section ((ps)-output_section))
(*finfo-info-callbacks-einfo)
(_(%X`%s' referenced in section `%A' of %B:
defined in discarded section `%A' of %B\n),
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gcc-4.6.3 released!
于 2012/3/4 5:42, Kai Tietz 写道: Btw I noticed in you recent .7z release an issue. Your gcc seems to have an issue. It doesn't work for me. It searchs for non-existing symbol __gxx_personality_v0 in libstdc++-6.dll. But the export should be '__gxx_personality_sj0'. Regards, Kai I think he built gcc using dw2 -- Best Regards, xunxun -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] New rubenvb Personal build with GCC 4.7 and mingw-w64 trunk
于 2012/2/18 3:08, niXman 写道: Hi Ruben! Thanks for your work. For dynamically linking C++11 std::thread, replace this line: #if SUPPORTS_WEAK GTHREAD_USE_WEAK with this one: #if SUPPORTS_WEAK GTHREAD_USE_WEAK !defined(__MINGW32__) In my builds dynamic linking is used for a long time. Possibly, anyone could tell me why this bug isn`t fixed yet? This bug should be related with ld. I remember libgcj.dll also has this issue. -- Best Regards, xunxun -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] New rubenvb Personal build with GCC 4.7 and mingw-w64 trunk
于 2012/2/18 3:20, Kai Tietz 写道: Hmm, interesting. What kind of issue happens here on cygwin. As my recent builds of binutils on cygwin were working fine. But well, I didn't built native cygwin ones. I didn't try it on cygwin and it seems that I missed the small testcase. But about weak function, there were some threads: http://old.nabble.com/Patch-to-enable-libgcj.dll-for-MinGW-td781670i20.html http://mingw-users.1079350.n2.nabble.com/weak-functions-td6911993.html And the related bug: http://sourceware.org/bugzilla/show_bug.cgi?id=9687 -- Best Regards, xunxun -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw64 svn 4809 can't build ctags
于 2012/2/10 17:04, JonY 写道:
On 2/10/2012 08:15, xunxun wrote:
Hi, all
I update to svn 4809 and found that I can't build ctags.
The error log is in the enclosure.
It seems stdio.h has something wrong
stdio.h:382:3 locate here:
__mingw_ovr // here
__MINGW_ATTRIB_NONNULL(2)
int vfscanf (FILE *__stream, const char *__format, __builtin_va_list
__local_argv)
{
return __ms_vfscanf (__stream, __format, __local_argv);
}
I revert stdio.h to svn4593 can solve the issue.
It seems that's caused by svn 4662 by Kai:
2011-12-14 Kai Tietzkti...@redhat.com
* stdio.h, wchar.h: Reorganize crt-overrides ... part 1
Hi,
What error messages are your seeing?
Sorry, it's related with ctags code, which redefined __unused__
So, the report is invalid.
--
Best Regards,
xunxun
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] MinGW/MinGW64 Gfortran program io dead lock issue
Hi, all My friend found a MinGW/MinGW64 Gfortran program io dead lock issue. I found that the problem is gone on Cygwin GFortran or Linux GFortran, I don't know it's related with MinGW/MinGW64 CRT or Gfortran source code. I test 4.5-4.6 series gfortran, all have this question. The test code : !main.f90 program main integer :: ret integer :: fun1 integer :: myfun1 ret=fun1() write(*,*) ret ! ok:) write(*,*) fun1() ! death! end program function fun1() integer fun1 write(*,*)1.0 fun1=1 write(*,*) fun1 end! end function When I use Cygwin GFortran to build it i686-pc-cygwin-gfortran main.f90 a.exe will output - 1.000 fun1 end! 1 1.000 fun1 end! 1 - it works well i686-w64-mingw32-gfortran main.f90 - 1.000 fun1 end! 1 --- Dead here - i686-pc-mingw32-gfortran is the same. May anyone look through the problem? Thanks. -- Best Regards, xunxun -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW/MinGW64 Gfortran program io dead lock issue
于 2012/1/7 3:39, Kai Tietz 写道: this program is btw invalid, you know? You aren't allowed to access in fun1 the same I/O unit (unit=* is OUTPUT_UNIT). An input/output statement that is executed while another input/output statement is being executed is a recursive input/output statement. A recursive input/output statement shall not identify an external unit that is identified by another input/output statement being executed except that a child data transfer statement may identify its parent data transfer statement external unit. (F2008,9.12 Restrictions on input/output statements) Thanks. I will tell my friend. I am not familiar with F2008. Is this an undefined behavior or not allowed, because linux and cygwin accept this approach. -- Best Regards, xunxun -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Application crashes with access violation on use std::this_thread::yield()
于 2011/12/2 5:03, niXman 写道: Hi guys! When I use std::this_thread::yield(), application crashes with access violation. If I repace __gthread_yield() in this function with sched_yield() everything works fine. Any ideas? Regards. It's very strange. Before I change it, it also crashes. After I modify gthr-default.h, replace return __gthrw_(sched_yield) (); with return sched_yield(); save it. The crash is gone ... But I think __gthrw_(sched_yield) is the same as sched_yield -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] DragonEgg 3.0 for win32
Hi, all Based on my gcc plugin port to windows (see http://sourceforge.net/mailarchive/forum.php?thread_name=4E9E5897.8030001%40gmail.comforum_name=mingw-users http://sourceforge.net/mailarchive/forum.php?thread_name=4E9E5897.8030001%40gmail.comforum_name=mingw-users and http://sourceforge.net/mailarchive/forum.php?thread_name=4E9E5C88.70506%40gmail.comforum_name=mingw-w64-public http://sourceforge.net/mailarchive/forum.php?thread_name=4E9E5C88.70506%40gmail.comforum_name=mingw-w64-public ), I port LLVM-Clang DragonEgg 3.0 plugin to win32. You can download it from : http://code.google.com/p/pcxllvm/downloads/list Because of some problems, you should follow the ways to use the plugin --- If you use GCC, you should use dragonegg-cc1.dll: gcc -fplugin=dragonegg-cc1.dll test.c If you use G++, you should use dragonegg-cc1plus.dll: g++ -fplugin=dragonegg-cc1plus.dll test.cpp If you use GFortran, you should use dragonegg-f951.dll: gfortran -fplugin=dragonegg-f951.dll test.f90 I haven't built other languages except C/C++/Fortran -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] difference betwen host=x86 - target=x86_64 and host=x86_64 - target=x86_64
于 2011/12/1 1:41, niXman 写道: Hi all. Please tell me, is there any point to build MinGW for x86_64 host? You should at first build binutils host=x86 target=x86_64 What advantages does it offer in comparison with the MinGW built with host=x86 - target=x86_64 and running on x86_64? The only advantage is that you can build x86_64 programs on X86 host such as WinXP 32bit OS. Regards. -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] difference betwen host=x86 - target=x86_64 and host=x86_64 - target=x86_64
于 2011/12/1 3:23, niXman 写道: I suppose to build such variants: 1)host=x86 - target=x86/x86_64, 2)host=x86_64 - target=x86_64. This should cover all the needs of users. missing host=x86_64 target=x86 ;-) But I only enjoy host and target is the same except linux to windows cross compile. :-) -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] winpthreads svn 4642 issue
winpthreads svn 4642 add a header file called pthread_compat.h, but is missing in makefile.in when installing. -- Best Regards, xunxun Index: Makefile.am === --- Makefile.am (revision 4645) +++ Makefile.am (working copy) @@ -19,7 +19,7 @@ src/barrier.c src/cond.c src/misc.c src/mutex.c src/rwlock.c src/spinlock.c src/thread.c src/ref.c src/sem.c src/sched.c \ src/winpthread_internal.h src/clock.c src/nanosleep.c src/version.rc -include_HEADERS = include/pthread.h include/sched.h include/semaphore.h include/pthread_unistd.h include/pthread_time.h +include_HEADERS = include/pthread.h include/sched.h include/semaphore.h include/pthread_unistd.h include/pthread_time.h include/pthread_compat.h DISTCHECK_CONFIGURE_FLAGS = --host=$(host_triplet) Index: Makefile.in === --- Makefile.in (revision 4645) +++ Makefile.in (working copy) @@ -274,7 +274,7 @@ src/barrier.c src/cond.c src/misc.c src/mutex.c src/rwlock.c src/spinlock.c src/thread.c src/ref.c src/sem.c src/sched.c \ src/winpthread_internal.h src/clock.c src/nanosleep.c src/version.rc -include_HEADERS = include/pthread.h include/sched.h include/semaphore.h include/pthread_unistd.h include/pthread_time.h +include_HEADERS = include/pthread.h include/sched.h include/semaphore.h include/pthread_unistd.h include/pthread_time.h include/pthread_compat.h DISTCHECK_CONFIGURE_FLAGS = --host=$(host_triplet) noinst_LTLIBRARIES = libdummy.la libwinpthread_la_LIBADD = libdummy.la -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] iconv() in mingw-w64
于 2011/11/25 20:13, JonY 写道: Looks like there is a problem with binutils ld for mingw32 win32, weak symbols don't get fixed up, strangely, win64 weak linking works perfectly. Can you file the bug to binutils bugzilla/mail list? -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libstdc++ built for and by cross-compiler has no symbols
于 2011/11/23 5:51, Ruben Van Boxem 写道: I'm attempting to make Arch user packages for MinGW-w64, but it seems I'm failing miserably. Although I'm using the exact same (more or less) steps as in my Personal build scripts, the cross-compiler's libstdc++ (and probably all other runtime libs) contain no symbols, which makes linking to them useless, i.e. undefined references all over the place. Specifically, linking a C++ iostream Hello world! program produces undefined references to ios_base stuff *and* ___chkstk_ms (which should be in libgcc?) ___chkstk_ms is a part of Microsoft Windows CRT I am using binutils 2.21.1a (latest official release) and GCC 4.6.2 and MinGW-w64 2.0.1 (although this last one should be unrelated). I'll try an unreleased version of binutils next, see if that automagically makes all my troubles go away :/ You can use nm to see the size and symbols of libstdc++.dll.a, I think it's the dlltool's issue. BTW, you can try binutils 2.22 release. -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cross compiler don't link with stdc++
于 2011/11/19 3:43, Zygmunt Ptak 写道: Hi! I created cross compiler for triplet i686-w32-mingw32 (and for test i686-w64-mingw32) based on mingw-w64-v2.0, gcc-4.6.2, binutils 2.21.1. And when i compile simple c++ code, i get error like this: // i686-w32-mingw32-g++ test.cpp /tmp/ccIOD3tF.o:test.cpp:(.text+0x16): undefined reference to `operator new[](unsigned int)' /tmp/ccIOD3tF.o:test.cpp:(.text+0x44): undefined reference to `std::cout' /tmp/ccIOD3tF.o:test.cpp:(.text+0x49): undefined reference to `std::basic_ostreamchar, std::char_traitscharstd::operator std::char_traitschar (std::basic_ostreamchar, std::char_traitschar , char const*)' /tmp/ccIOD3tF.o:test.cpp:(.text+0x59): undefined reference to `std::basic_ostreamchar, std::char_traitscharstd::operator std::char_traitschar (std::basic_ostreamchar, std::char_traitschar , char)' /tmp/ccIOD3tF.o:test.cpp:(.text+0x72): undefined reference to `std::ios_base::Init::~Init()' /tmp/ccIOD3tF.o:test.cpp:(.text+0x95): undefined reference to `std::ios_base::Init::Init()' collect2: ld returned 1 exit status I was trying to add option -L/path/to/tool/lib and -lstdc++. But this not work... PS: i want use dynamic libraries Your gcc configure option? Or your libstdc++.dll.a exist? -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cross compiler don't link with stdc++
于 2011/11/19 18:10, Zygmunt Ptak 写道: Dlls in /opt/cross-compilers/i686-w32-mingw32/i686-w32-mingw32/lib: libgcc_s_sjlj-1.dll libquadmath-0.dll libssp-0.dll libstdc++-6.dll PS: 1) i trying compile with -lstdc++, or with -lstdc++-6, but nothing... 2) and i tried link with libstdc++-6.dll without -l option, and i get the same error You must make sure that libstdc++.dll.a exists, not libstdc++-6.dll. -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cross compiler don't link with stdc++
于 2011/11/20 0:26, Zygmunt Ptak 写道: On 19.11.2011 16:05, xunxun wrote: 于 2011/11/19 18:10, Zygmunt Ptak 写道: Dlls in /opt/cross-compilers/i686-w32-mingw32/i686-w32-mingw32/lib: libgcc_s_sjlj-1.dll libquadmath-0.dll libssp-0.dll libstdc++-6.dll PS: 1) i trying compile with -lstdc++, or with -lstdc++-6, but nothing... 2) and i tried link with libstdc++-6.dll without -l option, and i get the same error You must make sure that libstdc++.dll.a exists, not libstdc++-6.dll. libstdc++-6.dll libstdc++.a libstdc++.dll.a libstdc++.dll.a-gdb.py libstdc++.la Maybe you want check packages? For ArchLinux, but shuld work on any linux distro... http://czlug.icis.pcz.pl/~zygmunt/packages PS: i have added bin path in PATH Your directory is strange. Can you type g++ test.cpp -v to output your library search path? Or copy your all files of opt\cross-compilers\i686-w32-mingw32\i686-w32-mingw32\lib\ to opt\cross-compilers\i686-w32-mingw32\lib\gcc\i686-w32-mingw32\4.6.2\ -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cross compiler don't link with stdc++
So this issue is related to your dll.a build, your dll.a some symbols were missing and your libstdc++.dll.a 's size is only 3KB. You should provide your libstdc++ build log. -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Latest mingw64 trunk failed to build gcc4.6.2's libgfortran
Hi, all I found that latest mingw64 trunk failed to build gcc4.6's libgfortran, and the error is : libtool: compile: i686-w64-mingw32-gcc -L/mingw/i686-w64-mingw32/lib -L/mingw/mingw/lib -isystem /mingw/i686-w64-mingw32/include -isystem /mingw/mingw/include -DHAVE_CONFIG_H -I. -I../.././libgfortran -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../.././libgfortran/../libquadmath -I../../host-i686-w64-mingw32/gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -pipe -g0 -O2 -MT main.lo -MD -MP -MF .deps/main.Tpo -c ../.././libgfortran/runtime/main.c -o main.o ../.././libgfortran/runtime/main.c: In function 'sprintf': /mingw/i686-w64-mingw32/include/stdio.h:277:5: sorry, unimplemented: function 'sprintf' can never be inlined because it uses variable argument lists removing sprintf's __forceinline in stdio.h will build successfully. -- Best Regards, xunxun -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] 4.7.0-stdthread version of gdb fails with python (?) error: ImportError: No module named site
于 2011/10/29 0:18, K. Frank 写道: I'd like to float this by you all again... Is there some way I can fix my gdb problem? Now, I never need to debug my code (Just trust me on this. Okay? Just trust me...), but sometimes I need to debug other people's code. But right now I'm dead in the water, because I can't even get gdb (from Ruben's 4.7.0 build) to start up. I assume that there are some compatibility requirements between gdb and gcc / g++. At the very least, I expect that I would need a 64-bit gdb to debug 64-bit applications. But if there's no fix for the problem with the gdb that came with Ruben's build, would it be possible for me to use a different version of gdb to debug applications compiled with Ruben's build? (If so, which version, and where would I get it?) Thanks. How about Ruben's 4.6.2 64bit? Or sizero's 64bit? TDM's 64bit? -- Best Regards, xunxun -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] liblto_plugin-0.dll not found
于 2011/10/28 22:18, Alexandre Gouraud 写道: Hi, Thank you for the answer Kai. My comments below 2011/10/28 Kai Tietz ktiet...@googlemail.com mailto:ktiet...@googlemail.com The issue is that you are setting PATH to wrong bin directory. You should use here 'c:\s2e\s2e-toolchain\mingw64\bin' instead. The folder 'c:\s2e\s2e-toolchain\mingw64\x86_64-w64-mingw32\bin' is for internal use only and has not to be used by user directly. Indeed, it apparently do something. But I think my set up is not correct. since I built gcc 4.7.0 with gcc 4.6.1, I have both installed on my machine. And of course the default one is 4.6.1 whereas I want the other one. with the PATH you told me to set up, I have what is reported below. Where can I learn about the internal of the directory structure so that I can configure my gcc appropriately. In the user manual, this is not that clear actually? Alexandre. -8- $ which gcc /mingw64/bin/gcc.exe $ gcc -v Using built-in specs. COLLECT_GCC=C:\s2e\s2e-toolchain\mingw64\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/s2e/s2e-toolchain/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.1/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: /home/drangon/work/mingw-w64-dgn/source/gcc/configure --host=x86_64-w64-mingw32 --target=x86_64-w6 4-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++ --with-gmp=/home/drangon/work/mingw-w64-dgn/build/for _target --enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry --prefix=/home/drangon/work/mingw-w64- dgn/target --with-sysroot=/home/drangon/work/mingw-w64-dgn/target Thread model: win32 gcc version 4.6.1 20110417 (prerelease) (GCC) $ which x86_64-w64-mingw32-gcc.exe /mingw64/bin/x86_64-w64-mingw32-gcc.exe $ x86_64-w64-mingw32-gcc.exe -v - pop up saying libintl-8.dll is missing, but actually it is not missing, it is just the set up which is messed up. $ x86_64-w64-mingw32-gcc-4.7.0.exe -v - pop up saying libintl-8.dll is missing, but actually it is not missing, it is just the set up which is messed up. $ x86_64-w64-mingw32-gcc-4.6.1.exe -v Using built-in specs. COLLECT_GCC=C:\s2e\s2e-toolchain\mingw64\bin\x86_64-w64-mingw32-gcc-4.6.1.exe COLLECT_LTO_WRAPPER=c:/s2e/s2e-toolchain/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.1/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: /home/drangon/work/mingw-w64-dgn/source/gcc/configure --host=x86_64-w64-mingw32 --target=x86_64-w6 4-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++ --with-gmp=/home/drangon/work/mingw-w64-dgn/build/for _target --enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry --prefix=/home/drangon/work/mingw-w64- dgn/target --with-sysroot=/home/drangon/work/mingw-w64-dgn/target Thread model: win32 gcc version 4.6.1 20110417 (prerelease) (GCC) $ which x86_64-w64-mingw32-gcc-4.7.0.exe /mingw64/bin/x86_64-w64-mingw32-gcc-4.7.0.exe -- Alexandre Maybe you can use gcc -flto -fuse-linker-plugin conftest.c -Wl,-v to output more link information. -- Best Regards, xunxun -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Qt-interest] Memory exhausted ld error when building Qt 4.8.0-rc1 with mingw-w64 4.7.0
于 2011/10/19 22:32, K. Frank 写道: Hello Lists! I get the following error: ./tmp\obj\debug_shared\moc_qgraphicsanchorlayout.o: file not recognized: Memory exhausted in the build step that links QtGuid4.dll when trying to build Qt 4.8.0-rc1 with mingw-w64 4.7.0 Would anyone have some suggestions about how I might fix this? (Task manager reported over 2 GB of available memory after the failed build process exited. I don't know how much memory was in use during the build.) Would it be possible to configure the Qt build process slightly differently? Would there be some way to run the offending link command manually, maybe tweaking it a little, and then continuing with the build process? I am trying to build Qt 4.8.0-rc1: qt-everywhere-opensource-src-4.8.0-rc1.zip with the mighty Ruben's std::thread-enabled 4.7.0 mingw-w64 build: x86_64-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z I am running on 64-bit windows 7. I ran the configure step for Qt thus: configure -opensource -platform win32-g++ -debug-and-release Note, I did have to patch the typo in pthread.h (tm -- ___tmp_tm) to get past an earlier build error, as described in an earlier thread on this list: http://sourceforge.net/mailarchive/message.php?msg_id=28124842 Here's the background on what I'm trying to accomplish: I want to upgrade various parts of my development environment. I am hoping to use a late-model g++ (hence the 4.7.0) to get as much support for the new c++11 as I can. I specifically want support for std::thread (hence Ruben's std::thread-enabled build). I decided to give Qt 4.8.0 a try (rather than upgrading, for example, to Qt 4.7.4) for no compelling reason, but I figured why not. I can dial back on either the compiler or the Qt version, or downgrade to 32 bits from 64 bits, for that matter, to fix the problem, but my general goal in the upgrade is to push forward as much as possible, A little more detail: The specific link command (from running mingw32-make) that fails is: g++ -mthreads -shared -Wl,--out-implib,c:\qt\4.8.0-rc1\lib\libQtGuid4.a -o ..\..\lib\QtGuid4.dll object_script.QtGuid.Debug -Lc:\qt\4.8.0-rc1\lib -Lc:\qt\4.8.0-rc1\lib -lgdi32 -lcomdlg32 -loleaut32 -limm32 -lwinmm -lwinspool -lws2_32 -lole32 -l uuid -luser32 -ladvapi32 tmp\obj\debug_shared\QtGuid_resource_res.o -lmsimg32 -lshell32 -lQtCored4 The resulting error message is: ./tmp\obj\debug_shared\moc_qgraphicsanchorlayout.o: file not recognized: Memory exhausted collect2.exe: error: ld returned 1 exit status mingw32-make[2]: *** [..\..\lib\QtGuid4.dll] Error 1 For what it's worth (I doubt it matters), this failed link command occurs immediately after the windres command for compiling QtGuid_resource_res.o: windres -i QtGuid_resource.rc -o tmp\obj\debug_shared\QtGuid_resource_res.o --include-dir=. -DQT_SHARED -DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -D_USE_MATH_DEFINES -DQT_NO_DIRECTDRAW -DQT_USE_BUNDLED_LIBPNG -DPNG_NO_ASSEMBLER_CODE -DQT_NO_CUPS -DQT_NO_LPR -DQT_NO_OPENTYPE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_GTK -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_S60 -DQT_NO_EGL -DQ_INTERNAL_QAPP_SRC -DQT_NO_DIRECTWRITE -DQT_DLL -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 Thanks for everyone's thoughts and advice. K. Frank Try to add -fno-keep-inline-dllexport to your compiler option. -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Qt-interest] Memory exhausted ld error when building Qt 4.8.0-rc1 with mingw-w64 4.7.0
于 2011/10/19 23:18, Ruben Van Boxem 写道: reduce DLL size reduce DLL obj size -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Qt-interest] Memory exhausted ld error when building Qt 4.8.0-rc1 with mingw-w64 4.7.0
于 2011/10/19 23:38, Morcego Vermelho 写道: this answer is enigmatic I dont know how to reduce it If you refer to Qt build, you can modify mkspecs/win32-g++/qmake.conf (similar it is, I forgot that) QMAKE_CFLAGS_RELEASE = -O2 -fno-keep-inline-dllexport -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Qt-interest] Memory exhausted ld error when building Qt 4.8.0-rc1 with mingw-w64 4.7.0
Hi, K. Frank On Thu, Oct 20, 2011 at 1:54 AM, K. Frank kfrank2...@gmail.com wrote: Hello xunxun! On Wed, Oct 19, 2011 at 11:43 AM, xunxun xunxun1...@gmail.com wrote: 于 2011/10/19 23:38, Morcego Vermelho 写道: ... If you refer to Qt build, you can modify mkspecs/win32-g++/qmake.conf (similar it is, I forgot that) QMAKE_CFLAGS_RELEASE = -O2 -fno-keep-inline-dllexport Thank you. I will give this a try. In my case I am trying to build both the debug and release versions. Is there a corresponding flag I should set for the debug version. (It appears that my Memory exhausted error is occurs during the debug part of the build process.) This is very similar. You can also modify the qmake.conf QMAKE_CFLAGS_DEBUG= -g -fno-keep-inline-dllexport (should be QMAKE_CFLAGS_DEBUG? I forgot it, too...) Am I right that to do this I edit qmake.conf by hand? Would anyone know offhand whether I should be doing this before or after I run the initial configure step? ... Best Regards, xunxun Thanks. I appreciate your advice. K. Frank -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Best Regards, xunxun -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] gcc --enable-plugin experimental built on windows
Hi, all
I built gcc with --enable-plugin on windows.
download link:
https://pcxprj.googlecode.com/files/MinGW_GCC4.6.1_enable_plugin_experimental.7z
There is an example in the package, and this is in the example directory.
Makefile.gcc is linked with cc1
Makefile.g++ is linked with cc1plus
So the gcc has some problems, when you use gcc to call plugin, you
should link plugin with libcc1.a, and if you use g++ to call plugin,
you should link plugin with libcc1plus.a. You can't mix linking, or
you will get segment fault.
Here is the patches and build process. (I only use C/C++/Fortran, so only
modify them)
Before building it, you should have dlopen/dlsym, here we can use
dlfcn-win32 temporarily.
1. Make binutils export exe's symbols.
Patch binutils using export-symbols.diff
And using the newer binutils to build gcc.
2. Modify gcc source code to support plugin
Patch gcc using gcc-plugin.patch
3. Build gcc using --enable-plugin
4. After installing, you should copy libcc1.a, libcc1plus.a and
libf951.a to your install directory's lib.
Then you can use gcc plugin.
Note: when you use gcc to call plugin, you should link plugin with
libcc1.a, and if you use g++ to call plugin, you should link plugin
with libcc1plus.a. You can't mix linking, or you will get segment
fault.
In the end, I use the built editon to run the gcc testsuite plugin section
successfully.
So, at some time, we can port llvm-dragonegg to windows?
Any ideas?
Thanks.
--
Best Regards,
xunxun
diff -ruNa gcc4.6.1/gcc/configure build/gcc/configure
--- gcc4.6.1/gcc/configure 2011-02-28 23:36:37.0 +0800
+++ build/gcc/configure 2011-10-16 20:57:13.0 +0800
@@ -26270,10 +26270,11 @@
${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest /dev/null
21
if $export_sym_check conftest | grep foobar /dev/null; then
plugin_rdynamic=yes
-pluginlibs=-rdynamic
+pluginlibs=-Wl,--export-all-symbols
else
-plugin_rdynamic=no
-enable_plugin=no
+plugin_rdynamic=yes
+enable_plugin=yes
+pluginlibs=-Wl,--export-all-symbols
fi
{ $as_echo $as_me:${as_lineno-$LINENO}: result: $plugin_rdynamic 5
$as_echo $plugin_rdynamic 6; }
@@ -26364,7 +26365,7 @@
$as_echo_n checking for -fPIC -shared... 6; }
cat confdefs.h - _ACEOF conftest.$ac_ext
/* end confdefs.h. */
-extern int X;
+int X;
int
main ()
{
diff -ruNa gcc4.6.1/gcc/cp/Make-lang.in build/gcc/cp/Make-lang.in
--- gcc4.6.1/gcc/cp/Make-lang.in2011-05-19 16:00:50.0 +0800
+++ build/gcc/cp/Make-lang.in 2011-10-18 13:42:58.0 +0800
@@ -102,7 +102,7 @@
cc1plus$(exeext): $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(LIBDEPS)
+$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
- $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS)
+ $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS)
-Wl,--output-def,cc1plus.def,--out-implib,libcc1plus.a
# Special build rules.
$(srcdir)/cp/cfns.h: $(srcdir)/cp/cfns.gperf
diff -ruNa gcc4.6.1/gcc/fortran/Make-lang.in build/gcc/fortran/Make-lang.in
--- gcc4.6.1/gcc/fortran/Make-lang.in 2010-11-13 07:26:56.0 +0800
+++ build/gcc/fortran/Make-lang.in 2011-10-18 13:42:09.0 +0800
@@ -98,7 +98,7 @@
f951$(exeext): $(F95_OBJS) \
$(BACKEND) $(LIBDEPS) attribs.o
+$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
- $(F95_OBJS) $(BACKEND) $(LIBS) attribs.o $(BACKENDLIBS)
+ $(F95_OBJS) $(BACKEND) $(LIBS) attribs.o $(BACKENDLIBS)
-Wl,--output-def,f951.def,--out-implib,libf951.a
gt-fortran-trans.h: s-gtype; @true
#
diff -ruNa gcc4.6.1/gcc/Makefile.in build/gcc/Makefile.in
--- gcc4.6.1/gcc/Makefile.in2011-05-24 02:12:34.0 +0800
+++ build/gcc/Makefile.in 2011-10-18 13:35:17.0 +0800
@@ -1852,7 +1852,7 @@
cc1$(exeext): $(C_OBJS) cc1-checksum.o $(BACKEND) $(LIBDEPS)
+$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) \
- cc1-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS)
+ cc1-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS)
-Wl,--output-def,cc1.def,--out-implib,libcc1.a
#
# Build libgcc.a.
diff -ruNa cvs/binutils/dlltool.c build/binutils/dlltool.c
--- cvs/binutils/dlltool.c 2011-10-14 21:02:59.722042474 +0800
+++ build/binutils/dlltool.c2011-10-15 08:39:30.244664033 +0800
@@ -412,7 +412,7 @@
/* TRUE if we should export all symbols. Otherwise, we only export
symbols listed in .drectve sections or in the def file. */
-static bfd_boolean export_all_symbols;
+static bfd_boolean export_all_symbols = TRUE;
/* TRUE if we should exclude the symbols in DEFAULT_EXCLUDES when
exporting all symbols. */
diff -ruNa cvs/ld/emultempl/pe.em build/ld/emultempl/pe.em
--- cvs/ld/emultempl/pe.em 2011-06-13 08:59:43.0 +0800
+++ build/ld/emultempl/pe.em2011-10-15 08:17:53.350233079 +0800
@@ -297,6 +297,9
Re: [Mingw-w64-public] Building the cross win32 win64 compiler
于 2011/10/14 16:59, Alexandre Gouraud 写道: Hello, Thank you very much for your prompt response. This is much appreciated. 2011/10/14 Kai Tietz ktiet...@googlemail.com mailto:ktiet...@googlemail.com Well, in case for cross-compilers this doesn't matter, as cross-compilers are prefixed with their target-triplet. Means to call cross-compiler from 32-bit - 64-bit means, that toolchain is prefix by x86_64-w64-mingw32-tools-name I am building a cross compiler, and I have this issue. Maybe because I am building a cross compiler ... using the same cross compiler (which might be stupid but this is what I do for the time being). I switched the path order, and it solved my problem. In my /mingw64/bin I have both gcc.exe and x86_64-w64-mingw32-gcc.exe which conflicts with the one I have in my --prefix directory... You need to specify on configure for crt the option --host=x86_64-w64-mingw32. This indicates to autotools, that you want to build for this host. Otherwise it assumes you want to build native, which would then mean you are building for 32-bit in your case. Of course you need to specify same prefix and sysroot. You just missed to specify --host argument on configure. I did specify --host in the confirgure script of crt: $ cat ./build/mingw64/crt/config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by mingw-w64-runtime configure 1.0b, which was generated by GNU Autoconf 2.67. Invocation command line was $ ../../../src/mingw-w64-trunk-20110723/mingw-w64-crt/configure --host=x86_64-w64-mingw32 --prefix=/usr/home/aceg7283/toolchain_gcc_4.6/build/mingw64/target --with-sysroot=/usr/home/aceg7283/toolchain_gcc_4.6/build/mingw64/target -- Alexandre Before cross building gcc, you should rebuild mingw64 headers and install to your prefix. -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Building the cross win32 win64 compiler
于 2011/10/14 17:27, Alexandre Gouraud 写道: Hi xunxun, 2011/10/14 xunxun xunxun1...@gmail.com mailto:xunxun1...@gmail.com Before cross building gcc, you should rebuild mingw64 headers and install to your prefix. -- Best Regards, xunxun I have followed all the steps mentioned in the guide, including this one of course. So the problem does not come from not having installed mingw64 headers, but rather from the fact that the new headers are not picked up. In the search dir of my cross compiler, you would have noticed that I have: . ../../../../src/mingw-w64-trunk-20110723/mingw-w64-crt C:\s2e\s2e-toolchain\mingw64\x86_64-w64-mingw32\include c:\s2e\s2e-toolchain\home\aceg7283\toolchain_gcc_4.6\build\mingw64\target\lib/gcc/x86_64-w64-mingw32/4.7.0/include c:\s2e\s2e-toolchain\home\aceg7283\toolchain_gcc_4.6\build\mingw64\target\lib/gcc/x86_64-w64-mingw32/4.7.0/include-fixed C:/s2e/s2e-toolchain/home/aceg7283/toolchain_gcc_4.6/build/mingw64/target/x86_64-w64-mingw32/include c:\s2e\s2e-toolchain\home\aceg7283\toolchain_gcc_4.6\build\mingw64\target\mingw/include Why do I have the second one, which is the one messing up everything I think. -- Alexandre You want to build linux-windows cross compiler or windows native compiler? -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Building the cross win32 win64 compiler
Hi, Kai 于 2011/10/14 18:31, Kai Tietz 写道: Candian-cross compiler By the way, what is Candian-cross compiler ? This is the first time I heared it. -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Building the cross win32 win64 compiler
It's my mistake. I thought this was built by you, but I don't think the edition's maintainer is TDM. On Fri, Oct 14, 2011 at 8:40 PM, JonY jo...@users.sourceforge.net wrote: On 10/14/2011 20:01, xunxun wrote: 于 2011/10/14 19:37, Alexandre Gouraud 写道: see below. I am not sure I do (or want) canadian-cross compilation. I just need a win64 native compiler, and in the manual it is said I would need to start creating a cross compiler first. No, you don't need cross compiler, because you have had a x86_64-w64-mingw32 native compiler. $ gcc -v Using built-in specs. COLLECT_GCC=C:\s2e\s2e-toolchain\mingw64\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/s2e/s2e-toolchain/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.1/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: /home/drangon/work/mingw-w64-dgn/source/gcc/configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++ --with-gmp=/home/drangon/work/mingw-w64-dgn/build/for_target --enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry --prefix=/home/drangon/work/mingw-w64-dgn/target --with-sysroot=/home/drangon/work/mingw-w64-dgn/target Thread model: win32 gcc version 4.6.1 20110417 (prerelease) (GCC) If you native build the gcc, you can use --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 ps: drangon mingw64 gcc is built by jon_y. I thought they were built by tdm, which jon_y do you refer to? -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] _FILE_OFFSET_BITS
On Wed, Oct 12, 2011 at 7:30 AM, Pau Garcia i Quiles pgqui...@elpauer.orgwrote: On Wed, Oct 12, 2011 at 12:53 AM, JonY jo...@users.sourceforge.netwrote: [...] Am I doing something wrong? Is this a bug in MinGW-W64's implementation of _FILE_OFFSET_BITS? Yes, looks like I forgot the part about stat. Try this patch: Index: trunk/mingw-w64-headers/crt/_mingw_stat64.h === --- trunk/mingw-w64-headers/crt/_mingw_stat64.h (revision 4539) +++ trunk/mingw-w64-headers/crt/_mingw_stat64.h (working copy) @@ -92,5 +92,10 @@ #define stat64 _stat64 /* for POSIX */ #define fstat64 _fstat64 /* for POSIX */ + +#if defined(_FILE_OFFSET_BITS) (_FILE_OFFSET_BITS == 64) +#define stat _stat64 +#endif + #define _STAT_DEFINED #endif /* _STAT_DEFINED */ This seems to fix it, thank you. I've also noticed the mingw-w64 builds I tried have some other problem which makes my application uncompilable, You can point out what the compile problem is. but I have not isolated the problem yet. Meanwhile, I've gone back to slightly older builds. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Weird crash when using Ruben's gcc4.6 stdthread package rebuilt gdb with -Os debug some program
I cross build the windows gcc4.6.2 on linux, the issue also existed. I don't know whether the issue is only targeted windows? I report it to gcc bugzilla : http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50664 On Fri, Sep 30, 2011 at 7:50 PM, xunxun xunxun1...@gmail.com wrote: On 2011/9/30 7:02, xunxun wrote: Ruben, can you try to build gdb with -Os using your edition, test it debugging? Kai, what changes gcc's -Os from gcc4.6.1 to now, because I use gcc4.6.1 release to build well. Thanks. -- Best Regards, xunxun -- Best Regards, xunxun -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS problem building anything with configure scripts
You can see install-dir/lib/gcc/your target
I think there are two different editon directories.
You can copy the content of the other edition directory to the right edition
directory.
On Sun, Oct 2, 2011 at 2:50 PM, JonY jo...@users.sourceforge.net wrote:
On 10/2/2011 13:42, Jim Michaels wrote:
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
Jim Michaels@jim-13l5nom9i4u /c/wxWidgets-2.9.2
$
log says:
gcc version 3.4.5 (mingw special)
You are using the old and ancient 3.x series from mingw.org (not
mingw-w64). If you do actually want to use the 3.x GCC, there is no
guarantee that it'll work with mingw-w64.
configure:15135: $? = 0
configure:15142: gcc -V 5
gcc.exe: `-V' option must have argument
configure:15145: $? = 1
configure:15168: checking for C compiler default output file name
configure:15195: gccconftest.c 5
\mingw\lib\gcc\mingw32\..\..\..\mingw32\bin\ld.exe: cannot find
crtbegin.o: No such file or directory
\mingw\lib\gcc\mingw32\..\..\..\mingw32\bin\ld.exe: cannot find -lgcc
\mingw\lib\gcc\mingw32\..\..\..\mingw32\bin\ld.exe: cannot find -lgcc
\mingw\lib\gcc\mingw32\..\..\..\mingw32\bin\ld.exe: cannot find crtend.o:
No such file or directory
This means your installation is broken. It is not normal to have these
errors, libgcc is part of gcc.
configure:15198: $? = 1
configure:15236: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME wxWidgets
| #define PACKAGE_TARNAME wxwidgets
| #define PACKAGE_VERSION 2.9.2
| #define PACKAGE_STRING wxWidgets 2.9.2
| #define PACKAGE_BUGREPORT wx-...@lists.wxwidgets.org
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:15243: error: C compiler cannot create executables
tried this with fltk 3.0 as well, got the same error.
Likely the same issue with broken install.
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Best Regards,
xunxun
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Weird crash when using Ruben's gcc4.6 stdthread package rebuilt gdb with -Os debug some program
Hi, all I found a weird problem when I rebuilt gdb using Ruben's gcc4.6 stdthread package. Reproduce process: 1. Download Ruben's gcc4.6 stdthread 32bit package. 2. Configure gdb --with-python --with-expat 3. make script : make -j2 BOOT_CFLAGS=-pipe -g3 -Os\ CFLAGS=-pipe -g3 -Os\ CXXFLAGS=-pipe -g3 -Os -mthreads \ CFLAGS_FOR_TARGET=-pipe -g3 -Os\ CXXFLAGS_FOR_TARGET=-pipe -g3 -Os -mthreads \ BOOT_CXXFLAGS=-pipe -g3 -Os -mthreads \ CFLAGS_FOR_BUILD=-pipe -g3 -Os\ CXXFLAGS_FOR_BUILD=-pipe -g3 -Os -mthreads \ LDFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,--large-address-aware \ LDFLAGS_FOR_BUILD=-Wl,-O1 -Wl,--as-needed -Wl,--large-address-aware \ BOOT_LDFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,--large-address-aware \ LDFLAGS_FOR_TARGET=-Wl,-O1 -Wl,--as-needed -Wl,--large-address-aware -static Then I use the new rebuilt gdb to debug other programs, and it can't list source code, and if you input list twice, gdb will crash. The debug log: -- GNU gdb (GDB) 7.3.1.20110921-cvs Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-w64-mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from E:\MyPack\MinGW\bin/gdb-1.exe...done. (gdb) run Starting program: E:\MyPack\MinGW\bin/gdb-1.exe [New Thread 2212.0x1ba8] GNU gdb (pcx32) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-w64-mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. (gdb) file a.exe Reading symbols from e:\t\temp\a.exe...done. (gdb) l (gdb) No source file named main. l [New Thread 2212.0xe34] [New Thread 2212.0x654] Program received signal SIGSEGV, Segmentation fault. 0x0041ad8b in exceptions_state_mc (action=CATCH_THROWING) at exceptions.c:126 126 switch (current_catcher-state) (gdb) warning: Could not load shared library symbols for 20 libraries, e.g. C:\Windows\system32\ntdll.dll. Use the info sharedlibrary command to see the complete listing. Do you need set solib-search-path or set sysroot? warning: Could not load shared library symbols for C:\Windows\SysWOW64\imm32.dll. Do you need set solib-search-path or set sysroot? warning: Could not load shared library symbols for C:\Windows\syswow64\msctf.dll. Do you need set solib-search-path or set sysroot? warning: Could not load shared library symbols for C:\Windows\syswow64\psapi.dll. Do you need set solib-search-path or set sysroot? bt #0 0x0041ad8b in exceptions_state_mc (action=CATCH_THROWING) at exceptions.c:126 #1 0x0041ad0d in throw_exception (exception=...) at exceptions.c:240 #2 0x0041ae68 in exceptions_state_mc (action=optimized out) at exceptions.c:191 #3 0x0041b1d4 in catch_errors (func=0x40181e captured_main, func_args=0x28fe90, errstring=0x614070 , mask=6) at exceptions.c:519 #4 0x0040262c in gdb_main (args=0x28fe90) at ./main.c:949 #5 0x00608ef0 in main (argc=1, argv=0x3f2fc0) at gdb.c:35 (gdb) bt 30 #0 0x0041ad8b in exceptions_state_mc (action=CATCH_THROWING) at exceptions.c:126 #1 0x0041ad0d in throw_exception (exception=...) at exceptions.c:240 #2 0x0041ae68 in exceptions_state_mc (action=optimized out) at exceptions.c:191 #3 0x0041b1d4 in catch_errors (func=0x40181e captured_main, func_args=0x28fe90, errstring=0x614070 , mask=6) at exceptions.c:519 #4 0x0040262c in gdb_main (args=0x28fe90) at ./main.c:949 #5 0x00608ef0 in main (argc=1, argv=0x3f2fc0) at gdb.c:35 (gdb) q A debugging session is active. Inferior 1 [process 2212] will be killed. Quit anyway? (y or n) And if I replace -Os with -O2 to rebuild again, gdb will work ok. In the same, my built posix thread with stdthread gcc 4.6 static edition also has the issue, but my old built win32 thread gcc4.6 has not the problem. I don't know why. Any ideas? Thanks. -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk
Re: [Mingw-w64-public] SEH
On 2011/9/26 3:15, niXman wrote: All greetings! Tell me please, is there any information about the plans on implementation SEH of exceptions? Where it is possible to learn about the plans on its implementation? Thanks! niXman. I don't know. At present you can see : http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Great success with Ruben's std::thread build!
Hi, Ruben 于 2011/9/21 18:43, Ruben Van Boxem 写道: ps: may you follow the binutils bug issue PR 12762 ( http://sourceware.org/bugzilla/show_bug.cgi?id=12762 )? I can't find the smallest testcase. Sorry, I don't understand what you're trying to say here. Ruben I mean can you debug the ld using my testcase in binutils bug PR 12762 ( http://sourceware.org/bugzilla/show_bug.cgi?id=12762 ). I don't know why I can't debug ld when break some breakpoint , because I encounted some memory excess error. At present, I think the code in the cofflink.c is something wrong: if (ps-flags SEC_EXCLUDE) (*finfo-info-callbacks-einfo) (_(%X`%s' referenced in section `%A' of %B: defined in discarded section `%A' of %B\n), h-root.root.string, o, input_bfd, ps, ps-owner); This can cause ld return value FALSE. But I don't know where its return value is. This issue can cause some code can't be built with -flto -fuse-linker-plugin. Thanks. -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Great success with Ruben's std::thread build!
Hi, Ruben
If you back port the std::thread to gcc4.6, you can use the patch.
ps: may you follow the binutils bug issue PR 12762 (
http://sourceware.org/bugzilla/show_bug.cgi?id=12762 )?
I can't find the smallest testcase.
Thanks.
--
Best Regards,
xunxun
diff -ruNa old/gcc/config/i386/mingw32.h build/gcc/config/i386/mingw32.h
--- old/gcc/config/i386/mingw32.h 2010-09-30 02:55:44 +0800
+++ build/gcc/config/i386/mingw32.h 2011-09-03 23:15:08 +0800
@@ -114,7 +114,7 @@
#define REAL_LIBGCC_SPEC \
%{mthreads:-lmingwthrd} -lmingw32 \
SHARED_LIBGCC_SPEC \
- -lgcc \
+ -lgcc -lpthread \
-lmoldname -lmingwex -lmsvcrt
#undef STARTFILE_SPEC
@@ -169,7 +169,8 @@
/* mingw32 uses the -mthreads option to enable thread support. */
#undef GOMP_SELF_SPECS
-#define GOMP_SELF_SPECS %{fopenmp: -mthreads}
+#define GOMP_SELF_SPECS %{fopenmp|ftree-parallelize-loops=*: \
+-mthreads -lpthread}
/* mingw32 atexit function is safe to use in shared libraries. Use it
to register C++ static destructors. */
diff -ruNa old/libstdc++-v3/acinclude.m4 build/libstdc++-v3/acinclude.m4
--- old/libstdc++-v3/acinclude.m4 2011-03-08 08:04:06 +0800
+++ build/libstdc++-v3/acinclude.m4 2011-09-03 23:28:45 +0800
@@ -1697,7 +1697,9 @@
m4_pushdef([n_syserr], [1])dnl
m4_foreach([syserr], [EOWNERDEAD, ENOTRECOVERABLE, ENOLINK, EPROTO, ENODATA,
ENOSR, ENOSTR, ETIME, EBADMSG, ECANCELED,
- EOVERFLOW, ENOTSUP, EIDRM, ETXTBSY],
+ EOVERFLOW, ENOTSUP, EIDRM, ETXTBSY,
+ ECHILD, ENOSPC, EPERM,
+ ETIMEDOUT, EWOULDBLOCK],
[m4_pushdef([SYSERR], m4_toupper(syserr))dnl
AC_MSG_CHECKING([for syserr])
AC_CACHE_VAL([glibcxx_cv_system_error[]n_syserr], [
diff -ruNa old/libstdc++-v3/config/os/mingw32/error_constants.h
build/libstdc++-v3/config/os/mingw32/error_constants.h
--- old/libstdc++-v3/config/os/mingw32/error_constants.h2011-01-31
06:39:36 +0800
+++ build/libstdc++-v3/config/os/mingw32/error_constants.h 2011-09-04
00:38:25 +0800
@@ -79,13 +79,17 @@
//network_reset = ENETRESET,
//network_unreachable =ENETUNREACH,
//no_buffer_space =ENOBUFS,
-//no_child_process = ECHILD,
+#ifdef _GLIBCXX_HAVE_ECHILD
+ no_child_process = ECHILD,
+#endif
//no_link =ENOLINK,
no_lock_available = ENOLCK,
//no_message_available = ENODATA,
//no_message = ENOMSG,
//no_protocol_option = ENOPROTOOPT,
-//no_space_on_device = ENOSPC,
+#ifdef _GLIBCXX_HAVE_ENOSPC
+ no_space_on_device = ENOSPC,
+#endif
//no_stream_resources =ENOSR,
no_such_device_or_address = ENXIO,
no_such_device = ENODEV,
@@ -96,12 +100,18 @@
//not_a_stream = ENOSTR,
//not_connected = ENOTCONN,
not_enough_memory = ENOMEM,
-//not_supported = ENOTSUP,
+#ifdef _GLIBCXX_HAVE_ENOTSUP
+ not_supported = ENOTSUP,
+#endif
//operation_canceled = ECANCELED,
//operation_in_progress = EINPROGRESS,
-//operation_not_permitted =EPERM,
+#ifdef _GLIBCXX_HAVE_EPERM
+ operation_not_permitted =EPERM,
+#endif
//operation_not_supported =EOPNOTSUPP,
-//operation_would_block = EWOULDBLOCK,
+#ifdef _GLIBCXX_HAVE_EWOULDBLOCK
+ operation_would_block = EWOULDBLOCK,
+#endif
//owner_dead = EOWNERDEAD,
permission_denied = EACCES,
//protocol_error = EPROTO,
@@ -113,12 +123,16 @@
//state_not_recoverable = ENOTRECOVERABLE,
//stream_timeout = ETIME,
//text_file_busy = ETXTBSY,
-//timed_out = ETIMEDOUT,
+#ifdef _GLIBCXX_HAVE_ETIMEDOUT
+ timed_out = ETIMEDOUT,
+#endif
too_many_files_open_in_system = ENFILE,
too_many_files_open =EMFILE,
- too_many_links = EMLINK
+ too_many_links = EMLINK,
// too_many_symbolic_link_levels = ELOOP,
- // value_too_large =EOVERFLOW,
+#ifdef _GLIBCXX_HAVE_EOVERFLOW
+ value_too_large =EOVERFLOW,
+#endif
// wrong_protocol_type =EPROTOTYPE
};
diff -ruNa old
