Re: [Mingw-w64-public] Mingw toolchains and Clang
Long time ago we add possibility to build Clang into mingw-builds scripts. Now we want to provide Clang builds for mingw-w64 toolchains. There are two possibilities that we can do: *1. *Include clang builds into toolchain archive *2.* Provide separate builds of GCC+Clang I have a question to users what use our toolchains. I want you to vote for the best variant of doing that. I know that some users don't want to have bigger toolchains but I think that in modern time it is not a problem because all drives has big volume. Regards, Alexey. I would like to see a separate build for GCC + Clang, I would also like to know 1) if it is now possible to have 64 bit clang with SEH ? 2) If clang can work with a more recent libstdc++ (say 4.7.2 or 4.8 ? ) 3) most importantly, can we now debug clang compiled code with gdb ? (That was not possible with Ruben's build) I would also like to see 1) some clang tools along with the compiler. like clang-analyzer/ format/modernizer etc ( and include what you want, if possible) 2) debug release libraries for clang llvm, so that one can also use it like Clang C++ SDK to build new tools. Also in long term i like to see ( I hope it is sorter than i think! ) libc++ lldb working on windows, along with some other clang tools like Address Sanitizer, Memory Sanitizer etc Thanks abir -- 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
[Mingw-w64-public] (no subject)
ntstatus.h:#define STATUS_INVALID_IMAGE_FORMAT ((NTSTATUS)0xC07B) when I run my 64-bit exe, I get this windows error dialog box with the above error number saying the application cannot start in windows 64-bit. in 32-bit, it refuses to link due to 2 library coding error2 in the compiler (the 2nd error I don't know what it means): d:/i686-4.8.2-release-win32-sjlj-rt_v3-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-merr.o):merr.c:(.text+0x60): multiple definition of `_matherr' d:/i686-4.8.2-release-win32-sjlj-rt_v3-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/libcrtdll.a(dqkfs00177.o):(.text+0x0): first defined here df.o:df.cpp:(.text+0x2a01): undefined reference to `_imp__SHValidateUNC@12' collect2.exe: error: ld returned 1 exit status the compilers I am using, personal build of experimental posix 4.9.0: i686-4.8.2-release-posix-sjlj-rt_v3-rev0 x86_64-4.8.2-release-posix-sjlj-rt_v3-rev0 the crtdll.dll gave me an error on start saying it was missing because it's ONLY in %SystemRoot%\SysWOW64 on 64-bit (maybe win7 and up?) and this is not in the default PATH you get with a windows install. so a lot of people think they have a virus (there are pages to this effect) or they need to do a system restore due to an about.com web page that makes assumptions... - Jim Michaels jmich...@yahoo.com j...@renewalcomputerservices.com http://RenewalComputerServices.com http://JesusnJim.com (my personal site, has software) --- IEC Units: Computer RAM SSD measurements, microsoft disk size measurements (note: they will say GB or MB or KB or TB when it is IEC Units!): [KiB] [MiB] [GiB] [TiB] [2^10B=1,024^1B=1KiB] [2^20B=1,024^2B=1,048,576B=1MiB] [2^30B=1,024^3B=1,073,741,824B=1GiB] [2^40B=1,024^4B=1,099,511,627,776B=1TiB] [2^50B=1,024^5B=1,125,899,906,842,624B=1PiB] SI Units: Hard disk industry disk size measurements: [kB] [MB] [GB] [TB] [10^3B=1,000B=1kB] [10^6B=1,000,000B=1MB] [10^9B=1,000,000,000B=1GB] [10^12B=1,000,000,000,000B=1TB] [10^15B=1,000,000,000,000,000B=1PB]-- 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] Macro 'WIN32' not defined when specify -std=c++11
Hi, by default _WIN32 gets defined by compiler. So don't rely on WIN32, which only gets defined in certain context (eg -std=gnu). Actually that WIN32 gets defined is unintended, and caused by a stupid hidden feature of gcc/g++. Regards, Kai -- 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] Newest Win-Builds Package Mingw64 Dev
On Thu, Jan 16, 2014, wynfi...@gmail.com wrote:
When you say specify the bin/directory, I suppose you mean
/opt/windows_32/bin
because if you cp wget.exe to cygwin's /bin you'd overwrite the
cygwin compatible wget.exe.
Yes, that's definitely an issue. However, copying to /opt/windows_*/bin
could cause some overwriting too; actually then I wouldn't overwrite but
rely on the ones being installed, which mean I have to make sure they
are always installed. Slight annoyance though.
I'm more leaning towards having only one file with everything in it.
This means using an HTTP client library rather than wget.exe, using
libarchive directly without going through bsdtar.exe and linking
everything statically. I've opened this bug report to track the issue:
http://win-builds.org/bugs/index.php?do=detailstask_id=47
There is also something I don't understand, at least on msys: running
. win-builds-switch.sh 32 followed by sherpa -update openssl fails
because it can't find wget.exe in msys' /bin; it doesn't seem to check
in /opt/windows_32. I need to spend more time on that issue.
Adrien Nader wrote:
... snipped part
Hmm, I'm sorry if I didn't make it clear: all the fixes for installation
under cygwin and XP have been merged. If you download
http://win-builds.org/stable/win-builds-bundle-1.3.0.zip and use its
files, you should have nothing to do besides running
msys-cygwin-install.sh.
Now installing is easy, smooth, and less error prone. Thanks
Everthing appears to install successfully.
Here is an output from install on my system: I don't think the Fatal
Errors are really fatal as the tests I ran (see the bottom of this message)
run successfully. The Sys_error(Invalid argument) rings a bell, but I
forgot what it was about.
Tail of installation process output:
.
.
Installing zlib-1.2.8-1-i686-w64-mingw32.txz... DONE
-- Fatal error: exception Sys_error(Invalid argument)
Called from file pervasives.ml, line 444, characters 30-33
Called from file std_exit.ml, line 16, characters 8-20
Updating fontconfig's cache (takes lot of time and memory on Windows =
7).
-- Fatal error: exception Sys_error(Invalid argument)
Called from file pervasives.ml, line 444, characters 30-33
Called from file std_exit.ml, line 16, characters 8-20
Updating pango's module cache.
-- Fatal error: exception Sys_error(Invalid argument)
Called from file pervasives.ml, line 444, characters 30-33
Called from file std_exit.ml, line 16, characters 8-20
Updating gdk's pixbuf cache..; IMPOSSIBLE on Cygwin on XP/2k3!
Please run 'gdk-pixbuf-query-loaders --update-cache' from a new cmd.exe.
Updating gtk's immodules cache.
Win-builds has been installed for i686.
However no setting has been changed on the computer.
Remember to select a environment as described at
http://win-builds.org/1.3.0/msys-cygwin.html .
** Manually ran: C:\cygwin\opt\windows_32\bingdk-pixbuf-query-loaders
--update-cache
I have absolutely no idea why you get these invalid argument errors.
They are clearly from yypkg.exe or sherpa.exe but these tools are not
being run when Updating pango's module cache. Is your cygwin
up-to-date? If not it might be something with XP, your Service Pack
level, your locale; I've never gotten these on 2k3 but maybe it fixed
something form XP (they're basically the same kernel though).
TESTING:
PATH=/opt/windows_32/bin
cd${PATH%%:*} # assume 1st PATH component
gtk-demo
Successfull.
fc-cache -v
Successfull.
pango-querymodules
Successfull.
gtk-query-immodules-2.0
Successfull.
gdk-pixbuf-query-loaders
Error# Thie must be ran from a cmd.exe console:
cmd.exe then enter -- /opt/windows_32/bin/gdk-pixbuf-query-loaders
Then runs successfully. I suspect an enironment value might cause this.
:)
For gdk-pixbuf-query-loader, I've been unable to find the difference.
I've also suspected a difference in environment (variables) but haven't
found an obvious culprit (cygwin translates some env vars for native
windows programs).
Regards,
Adrien Nader
--
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] (no subject)
2014/1/16 Jim Michaels jmich...@yahoo.com ntstatus.h:#define STATUS_INVALID_IMAGE_FORMAT ((NTSTATUS)0xC07B) when I run my 64-bit exe, I get this windows error dialog box with the above error number saying the application cannot start in windows 64-bit. in 32-bit, it refuses to link due to 2 library coding error2 in the compiler (the 2nd error I don't know what it means): d:/i686-4.8.2-release-win32-sjlj-rt_v3-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-merr.o):merr.c:(.text+0x60): multiple definition of `_matherr' d:/i686-4.8.2-release-win32-sjlj-rt_v3-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/libcrtdll.a(dqkfs00177.o):(.text+0x0): first defined here df.o:df.cpp:(.text+0x2a01): undefined reference to `_imp__SHValidateUNC@12 ' collect2.exe: error: ld returned 1 exit status _SHValidateUNC is defined in libshell32: http://msdn.microsoft.com/en-us/library/windows/desktop/bb762259%28v=vs.85%29.aspx The other error might be a bug in MinGW-w64, or it might be a bug in your compilation options. Do you have a SSCCE http://sscce.org/? the compilers I am using, personal build of experimental posix 4.9.0: i686-4.8.2-release-posix-sjlj-rt_v3-rev0 x86_64-4.8.2-release-posix-sjlj-rt_v3-rev0 This looks like GCC 4.8.2, not 4.9. the crtdll.dll gave me an error on start saying it was missing because it's ONLY in %SystemRoot%\SysWOW64 on 64-bit (maybe win7 and up?) and this is not in the default PATH you get with a windows install. so a lot of people think they have a virus (there are pages to this effect) or they need to do a system restore due to an about.com web page that makes assumptions... In general, Windows has very complicated system DLL search stuff. This includes winsxs, which is so complicated you should never muck with any of it yourself, and let Windows handle it. Anyways, on Windows 7 x64 Pro SP1, I've got a 32-bit crtdll.dll in some winsxs directory, and one in SysWOW64. This last directory is definitely searched for system DLLs in 32-bit applications (just check with Dependency Walker). I don't know where you get the information this is not the case. Ruben -- 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 toolchains and Clang
2014/1/16 Abir Basak abirba...@gmail.com Long time ago we add possibility to build Clang into mingw-builds scripts. Now we want to provide Clang builds for mingw-w64 toolchains. There are two possibilities that we can do: *1. *Include clang builds into toolchain archive *2.* Provide separate builds of GCC+Clang I have a question to users what use our toolchains. I want you to vote for the best variant of doing that. I know that some users don't want to have bigger toolchains but I think that in modern time it is not a problem because all drives has big volume. Regards, Alexey. I would like to see a separate build for GCC + Clang, I would also like to know 1) if it is now possible to have 64 bit clang with SEH ? No. 2) If clang can work with a more recent libstdc++ (say 4.7.2 or 4.8 ? ) I believe there is a simple fix for that. I'm planning on taking a look at this. 3) most importantly, can we now debug clang compiled code with gdb ? (That was not possible with Ruben's build) I haven't checked, but I think something is going wrong on the Clang side wrt debug info. No idea what or how to check. Ideas welcome. I would also like to see 1) some clang tools along with the compiler. like clang-analyzer/ format/modernizer etc ( and include what you want, if possible) 2) debug release libraries for clang llvm, so that one can also use it like Clang C++ SDK to build new tools. Good idea, although this needs to be seperate from the compiler. I believe Clang now has an option to only install the compiler. Also in long term i like to see ( I hope it is sorter than i think! ) libc++ lldb working on windows, along with some other clang tools like Address Sanitizer, Memory Sanitizer etc I would guess the Sanitizers should work, but I haven't tested. libc++ is on my todo list (still needs quite some work, but it passed most tests at one point, with a very hackish setup, which I am now trying to improve quite a bit), and lldb will probably not be for this year, if history is any indication. Cheers, Ruben Thanks abir -- 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 -- 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
[Mingw-w64-public] Problem to build libgomp
Hello everyone, I try to build Mingw w64 on Linux (ubuntu 12.04 64bits) with GCC 4.8.1 and pthread library. I follow the instruction of the documentation but I have a problem when I build libgomp: make[1]: entrant dans le répertoire « /mypath/build/gcc/x86_64-w64-mingw32/libgomp » Makefile:456: .deps/affinity.Plo: No such file or directory Makefile:457: .deps/alloc.Plo: Aucun fichier ou dossier de ce type Makefile:458: .deps/bar.Plo: Aucun fichier ou dossier de ce type Makefile:459: .deps/barrier.Plo: Aucun fichier ou dossier de ce type Makefile:460: .deps/critical.Plo: Aucun fichier ou dossier de ce type Makefile:461: .deps/env.Plo: Aucun fichier ou dossier de ce type Makefile:462: .deps/error.Plo: Aucun fichier ou dossier de ce type Makefile:463: .deps/fortran.Plo: Aucun fichier ou dossier de ce type Makefile:464: .deps/iter.Plo: Aucun fichier ou dossier de ce type Makefile:465: .deps/iter_ull.Plo: Aucun fichier ou dossier de ce type Makefile:466: .deps/lock.Plo: Aucun fichier ou dossier de ce type Makefile:467: .deps/loop.Plo: Aucun fichier ou dossier de ce type Makefile:468: .deps/loop_ull.Plo: Aucun fichier ou dossier de ce type Makefile:469: .deps/mutex.Plo: Aucun fichier ou dossier de ce type Makefile:470: .deps/ordered.Plo: Aucun fichier ou dossier de ce type Makefile:471: .deps/parallel.Plo: Aucun fichier ou dossier de ce type Makefile:472: .deps/proc.Plo: Aucun fichier ou dossier de ce type Makefile:473: .deps/ptrlock.Plo: Aucun fichier ou dossier de ce type Makefile:474: .deps/sections.Plo: Aucun fichier ou dossier de ce type Makefile:475: .deps/sem.Plo: Aucun fichier ou dossier de ce type Makefile:476: .deps/single.Plo: Aucun fichier ou dossier de ce type Makefile:477: .deps/task.Plo: Aucun fichier ou dossier de ce type Makefile:478: .deps/team.Plo: Aucun fichier ou dossier de ce type Makefile:479: .deps/time.Plo: Aucun fichier ou dossier de ce type Makefile:480: .deps/work.Plo: Aucun fichier ou dossier de ce type make[1]: *** Pas de règle pour fabriquer la cible « .deps/work.Plo ». Arrêt. make[1]: quittant le répertoire « /mypath/build/gcc/x86_64-w64-mingw32/libgomp » I follow those steps inside one build directory per step (except for gcc): *Binutils*: ../../sources/binutils-2.24/configure --prefix=$PREFIX --with-sysroot=$PREFIX --target=x86_64-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 make make install //OK export PATH=$PATH:$PREFIX/bin *Mingw-w64 header*: ../../sources/mingw-w64-v3.1.0/mingw-w64-headers/configure --host=x86_64-w64-mingw32 --prefix=$PREFIX/x86_64-w64-mingw32 make install //OK mkdir $PREFIX/x86_64-w64-mingw32/lib32 cd $PREFIX ln -s x86_64-w64-mingw32 mingw cd $PREFIX/x86_64-w64-mingw32 ln -s lib lib64 *GCC Core*: ../../sources/gcc-4.8.1/configure --prefix=$PREFIX --with-sysroot=$PREFIX --target=x86_64-w64-mingw32 --enable-targets=all --enable-multilib --enable-64bit --enable-version-specific-runtime-libs --enable-shared --enable-fully-dynamic-string --enable-languages=c,c++ --enable-libgomp --enable-libssp --enable-lto --with-system-zlib make all-gcc make install-gcc //OK Mingw-w64 crt: ../../sources/mingw-w64-v3.1.0/mingw-w64-crt/configure --prefix=$PREFIX/x86_64-w64-mingw32 --with-sysroot=$PREFIX/x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-lib32 make make install //OK *GCC libgcc*: make all-target-libgcc //OK mv $PREFIX/lib/gcc/x86_64-w64-mingw32/lib32/libgcc_s.a $PREFIX/lib/gcc/x86_64-w64-mingw32/4.8.1/32/ mv $PREFIX/lib/gcc/x86_64-w64-mingw32/lib/libgcc_s.a $PREFIX/lib/gcc/x86_64-w64-mingw32/4.8.1/64/ //NOTE: In mingw-w64-howto-build-adv.txt, it says lib64 instead of lib * **Pthread-win32 v 2.9.1*: For 64 bits version, inside the source directory: make clean GC CROSS=x86_64-w64-mingw32- mv libpthreadGC2.a libpthread.a cp pthread.def pthreadGC2.dll libpthread.a $PREFIX/x86_64-w64-mingw32/lib cp pthread.h sched.h semaphore.h $PREFIX/x86_64-w64-mingw32/include/ cp config.h $PREFIX/x86_64-w64-mingw32/include/pconfig.h I edit $PREFIX/x86_64-w64-mingw32/include/pthread.h and replace: #if defined(HAVE_PTW32_CONFIG_H) #include config.h #endif /* HAVE_PTW32_CONFIG_H */ by #include pconfig.h Fox 32 bits version, inside the same source directory: I edit GNUmakefile and make the changes (-m i386 for dlltool, -m32 etc...). make clean GC CROSS=x86_64-w64-mingw32-
Re: [Mingw-w64-public] Ruben's Clang builds
As a side question, what does Clang development have to do with MinGW64? Aren't these actually competing projects? Only if you take a narrow or literal view of what MinGW-w64 is. I guess the name dates back to when the only open source toolchain worth using was GCC. Good technology is worth playing with; LLVM fits into that category and Clang is getting there on Windows too. For me MinGW-w64 is about being able to compile and run as much open source software on Windows as possible, preferably avoiding closed source at every turn. IMHO the only bad toolchain is a closed source toolchain - like the one you built Clang with ;-) On Tue, Jan 14, 2014 at 6:23 PM, Baruch Burstein bmburst...@gmail.com wrote: On Tue, Jan 14, 2014 at 3:46 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2014/1/14 Baruch Burstein bmburst...@gmail.com I am trying to use the Win64 toolchain. I assume I need to unpack the Clang into the same directory as one of your GCC builds? I tried it with the 4.8.0 release (regular, not seh or std::thread, from here http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/ ), but when I ran `clang` I got a crash message that it can't start because libgcc_s_sjlj-1.dll is missing. Ruben? Oh, in that case, know that C++ support is nonexistent (at least as far as exceptions or the standard library go). That is fine. I only need C support. After playing with this for a while, I found that the process to build Clang+LLVM from source on windows is much easier then it used to be (grab a couple of SVN repos, run CMake, Open in VS, compile. Easy) so that is what I ended up doing, and it works fine for me. Thanks anyway. As a side question, what does Clang development have to do with MinGW64? Aren't these actually competing projects? -- 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 -- 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/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 toolchains and Clang
2014/1/16 Ruben Van Boxem vanboxem.ru...@gmail.com 2014/1/16 Abir Basak abirba...@gmail.com Long time ago we add possibility to build Clang into mingw-builds scripts. Now we want to provide Clang builds for mingw-w64 toolchains. There are two possibilities that we can do: *1. *Include clang builds into toolchain archive *2.* Provide separate builds of GCC+Clang I have a question to users what use our toolchains. I want you to vote for the best variant of doing that. I know that some users don't want to have bigger toolchains but I think that in modern time it is not a problem because all drives has big volume. Regards, Alexey. I would like to see a separate build for GCC + Clang, I would also like to know 1) if it is now possible to have 64 bit clang with SEH ? No. 2) If clang can work with a more recent libstdc++ (say 4.7.2 or 4.8 ? ) I believe there is a simple fix for that. I'm planning on taking a look at this. Due to some ABI incompatibilities, Clang 3.4 will only work with older versions, like 4.6. Clang from svn works with recent versions. Check this bug http://llvm.org/bugs/show_bug.cgi?id=18034report. It says it support enough of the ABI to bootstrap and run all the tests. 3) most importantly, can we now debug clang compiled code with gdb ? (That was not possible with Ruben's build) I haven't checked, but I think something is going wrong on the Clang side wrt debug info. No idea what or how to check. Ideas welcome. I'm able to debug Clang programs on gdb. Though i've only tested with trivial programs. I would also like to see 1) some clang tools along with the compiler. like clang-analyzer/ format/modernizer etc ( and include what you want, if possible) 2) debug release libraries for clang llvm, so that one can also use it like Clang C++ SDK to build new tools. Good idea, although this needs to be seperate from the compiler. I believe Clang now has an option to only install the compiler. Also in long term i like to see ( I hope it is sorter than i think! ) libc++ lldb working on windows, along with some other clang tools like Address Sanitizer, Memory Sanitizer etc I would guess the Sanitizers should work, but I haven't tested. libc++ is on my todo list (still needs quite some work, but it passed most tests at one point, with a very hackish setup, which I am now trying to improve quite a bit), and lldb will probably not be for this year, if history is any indication. Cheers, Ruben Thanks abir -- 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 -- 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 -- 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
[Mingw-w64-public] Potential memory leaks in exception handling?
Hi guys: I got memory leaks in this code. Hope someone would help. Minimal sample code attached. Compiled with g++ test.cpp -std=c++11 -static, then attached with OllyDbg, bp malloc, calloc, realloc, free. There were 2 or 3 blocks of memory that were not freed upon termination. gcc -v: Thread model: win32 gcc version 4.9.0 20131119 (experimental) (Built by MinGW-W64 project) Best regards. 2014-01-17 lh_mouse test.cpp Description: Binary data -- 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] Potential memory leaks in exception handling?
Hello lh_mouse lh_mo...@126.com schrieb am 18:38 Donnerstag, 16.Januar 2014: I got memory leaks in this code. Hope someone would help. Minimal sample code attached. Compiled with g++ test.cpp -std=c++11 -static, then attached with OllyDbg, bp malloc, calloc, realloc, free. There were 2 or 3 blocks of memory that were not freed upon termination. Are you sure it's because of exceptions? I think the argv[]-strings in main() are copied and never freed. Regards Domani Hannes -- 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] Linker crash
2014/1/16 Jan Blok jan.b...@gmail.com Hi, I'm trying to crosscompile robovm library (from robovm.org) on Linux to a windows dll. All small dlls and test work/run great on windows, but compiling basically LLVM to a dll seems too much for the linker. The linker crashes immediately with core dump, as seen below. Steps I took are explained at: https://groups.google.com/forum/#!topic/robovm/-ysEgS_8J54 Any suggestions? What version of ld is crashing? If it's not 2.24, I'd try with this version. How much memory is it using at the moment of the crash (roughly)? If it is a lot, is it a 32-bit or 64-bit executable? It sounds like an out-of-memory issue. If x86_64-w64-mingw32-ld is a 32-bit executable and ld is using almost 2GB of memory, I'd suggest trying with a 64-bit linker. Ruben Regards Jan --- Linking CXX shared library librobovm-llvm.dll *** Error in `/usr/bin/x86_64-w64-mingw32-ld': free(): invalid pointer: 0x01219888 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x73baf)[0x2ab75b41fbaf] /lib/x86_64-linux-gnu/libc.so.6(+0x8067a)[0x2ab75b42c67a] /usr/bin/x86_64-w64-mingw32-ld[0x43ad15] /usr/bin/x86_64-w64-mingw32-ld[0x4573ea] /usr/bin/x86_64-w64-mingw32-ld[0x443997] /usr/bin/x86_64-w64-mingw32-ld[0x410f42] /usr/bin/x86_64-w64-mingw32-ld[0x411a4f] /usr/bin/x86_64-w64-mingw32-ld[0x413cb2] /usr/bin/x86_64-w64-mingw32-ld[0x4038a0] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2ab75b3cded5] /usr/bin/x86_64-w64-mingw32-ld[0x403de5] === Memory map: 0040-0053 r-xp ca:01 10325 /usr/bin/x86_64-w64-mingw32-ld 0072f000-0073 r--p 0012f000 ca:01 10325 /usr/bin/x86_64-w64-mingw32-ld 0073-00736000 rw-p 0013 ca:01 10325 /usr/bin/x86_64-w64-mingw32-ld 00736000-0073b000 rw-p 00:00 0 00edc000-00efd000 rw-p 00:00 0 [heap] 00efd000-00f2 rw-p 00:00 0 [heap] 00f2-00f5 rw-p 00:00 0 [heap] 00f5-00f71000 rw-p 00:00 0 [heap] 00f71000-00f92000 rw-p 00:00 0 [heap] 00f92000-00fb3000 rw-p 00:00 0 [heap] 00fb3000-00fd4000 rw-p 00:00 0 [heap] 00fd4000-00ff5000 rw-p 00:00 0 [heap] 00ff5000-01016000 rw-p 00:00 0 [heap] 01016000-01037000 rw-p 00:00 0 [heap] 01037000-01058000 rw-p 00:00 0 [heap] 01058000-01079000 rw-p 00:00 0 [heap] 01079000-0109a000 rw-p 00:00 0 [heap] 0109a000-010bb000 rw-p 00:00 0 [heap] 010bb000-010dc000 rw-p 00:00 0 [heap] 010dc000-010fe000 rw-p 00:00 0 [heap] 010fe000-0111f000 rw-p 00:00 0 [heap] 0111f000-0114 rw-p 00:00 0 [heap] 0114-01161000 rw-p 00:00 0 [heap] 01161000-01182000 rw-p 00:00 0 [heap] 01182000-011b4000 rw-p 00:00 0 [heap] 011b4000-011d5000 rw-p 00:00 0 [heap] 011d5000-011f6000 rw-p 00:00 0 [heap] 011f6000-01217000 rw-p 00:00 0 [heap] 01217000-01238000 rw-p 00:00 0 [heap] 2ab75ad6a000-2ab75ad8c000 r-xp ca:01 147895 /lib/x86_64-linux-gnu/ld-2.18.so 2ab75ad8c000-2ab75ad8e000 rw-p 00:00 0 2ab75ad8e000-2ab75ad95000 r--s ca:01 7959 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache 2ab75ad95000-2ab75ad96000 rw-p 00:00 0 2ab75ad96000-2ab75ad97000 rw-p 00:00 0 2ab75ad97000-2ab75ad98000 rw-p 00:00 0 2ab75ad98000-2ab75ad99000 rw-p 00:00 0 2ab75ad99000-2ab75ad9a000 rw-p 00:00 0 2ab75ad9a000-2ab75ad9b000 rw-p 00:00 0 2ab75ad9b000-2ab75ad9d000 rw-p 00:00 0 2ab75ad9d000-2ab75af26000 r--p ca:01 317 /usr/lib/locale/locale-archive 2ab75af26000-2ab75af73000 rw-p 00:00 0 2ab75af73000-2ab75af74000 rw-p 00:00 0 2ab75af8c000-2ab75af8d000 r--p 00022000 ca:01 147895 /lib/x86_64-linux-gnu/ld-2.18.so 2ab75af8d000-2ab75af8f000 rw-p 00023000 ca:01 147895 /lib/x86_64-linux-gnu/ld-2.18.so 2ab75af8f000-2ab75afa7000 r-xp ca:01 132943 /lib/x86_64-linux-gnu/libz.so.1.2.8 2ab75afa7000-2ab75b1a6000 ---p 00018000 ca:01 132943 /lib/x86_64-linux-gnu/libz.so.1.2.8 2ab75b1a6000-2ab75b1a7000 r--p 00017000 ca:01 132943 /lib/x86_64-linux-gnu/libz.so.1.2.8 2ab75b1a7000-2ab75b1a8000 rw-p 00018000 ca:01 132943 /lib/x86_64-linux-gnu/libz.so.1.2.8 2ab75b1a8000-2ab75b1ab000 r-xp ca:01 147903 /lib/x86_64-linux-gnu/libdl-2.18.so 2ab75b1ab000-2ab75b3aa000 ---p 3000 ca:01 147903 /lib/x86_64-linux-gnu/libdl-2.18.so 2ab75b3aa000-2ab75b3ab000 r--p 2000 ca:01 147903 /lib/x86_64-linux-gnu/libdl-2.18.so 2ab75b3ab000-2ab75b3ac000 rw-p 3000 ca:01 147903 /lib/x86_64-linux-gnu/libdl-2.18.so 2ab75b3ac000-2ab75b568000 r-xp ca:01 147896 /lib/x86_64-linux-gnu/libc-2.18.so 2ab75b568000-2ab75b768000 ---p 001bc000 ca:01 147896 /lib/x86_64-linux-gnu/libc-2.18.so 2ab75b768000-2ab75b76c000 r--p 001bc000 ca:01 147896
Re: [Mingw-w64-public] mingw-w64 and gcc plugins
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. 2014/1/16 xunxun xunxun1...@gmail.com 于 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 -- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute -- 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] Potential memory leaks in exception handling?
I'm quite sure it is due to exceptions. Memory leaks did not occure if those two try...catch'es were in the same thread or no rethrow_exception() was used. Best regards. 2014-01-17 lh_mouse - 发件人：Hannes Domani ssb...@yahoo.de 发送时间：2014-01-17 05:34 主题：Re: [Mingw-w64-public] Potential memory leaks in exception handling? 收件人：mingw-w64-public@lists.sourceforge.netmingw-w64-public@lists.sourceforge.net 抄送： Hello lh_mouse lh_mo...@126.com schrieb am 18:38 Donnerstag, 16.Januar 2014: I got memory leaks in this code. Hope someone would help. Minimal sample code attached. Compiled with g++ test.cpp -std=c++11 -static, then attached with OllyDbg, bp malloc, calloc, realloc, free. There were 2 or 3 blocks of memory that were not freed upon termination. Are you sure it's because of exceptions? I think the argv[]-strings in main() are copied and never freed. Regards Domani Hannes -- 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] Potential memory leaks in exception handling?
Additional information: Another example attached. On line #54 there is an #if directive. If I put an #if 0 there, the function ThreadProc() would get directly called - hence would run in the same thread with main() - and I got the following result: E:\Desktopg++ test2.cpp -static -std=c++11 E:\Desktopa ctor : global cnt = 0 exception caught, e = 12345 dtor : global cnt = 5 On the other hand, if I left it #if 1 there, the program would throw an exception in another thread, catch it and rethrow it in the main thread, and I got the following result: E:\Desktopg++ test2.cpp -static -std=c++11 E:\Desktopa ctor : global cnt = 0 exception caught, e = 12345 dtor : global cnt = 6 AFAIK mingw-w64 uses callbacks to reclaim TLS memory. In the first case, upon destruction of the static object there were 5 blocks of memory unfreed; and in the second case there were 6. If we say there was no memory leak in case 1, then there must be in case 2, IMO. 2014-01-17 lh_mouse test2.cpp Description: Binary data -- 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] Potential memory leaks in exception handling?
AFAIK mingw-w64 uses callbacks to reclaim TLS memory. In the first case, upon destruction of the static object there were 5 blocks of memory unfreed; and in the second case there were 6. If we say there was no memory leak in case 1, then there must be in case 2, IMO. I've tried this myself, and I think I'm seeing what you are seeing. It looks to me like the problem comes from ___w64_mingwthr_add_key_dtor in tlsthrd.c. In this routine, calloc is called to create a __mingwthr_key_t. However, I don't believe that memory ever gets freed. In theory it could get freed in ___w64_mingwthr_remove_key_dtor (at least there is a free for it there), but apparently that routine never gets called. Maybe it was supposed to be freed in __mingwthr_run_key_dtors when it gets called? dw -- 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
