From: Ruben V. B. <van...@gm...> - 2011-08-25 13:47:35
|
Hi everyone! After some hard work rewriting my scripts to work on Fedora (and now hopefully any Linux flavour), I can proudly announce a new release! The presents I bring you today: - Mac (32-bit) and Cygwin builds: these are untested, and cross-compiled from Fedora using the darwinx and cygwinx toolchains respectively. Thank you epienbro and Yaakov for the great work. You really outdid yourselves providing novel solutions for people like me :) - I switched from mingw-w64 to the stable/v2.x branch. All the features, and the stability of a release branch :) - Winpthreads has had a grand makeover by Kai, and it now does not hang with GCC's openmp support. Don't hesitate to try it out, there's no pthreads-win32 here anymore, and I'm quite sure it'll stay that way :) - I removed my custom optimizations (ie optimize for intel core 2 and compiling everything with graphite optimizations) because 1) my new build procedure breaks with this kind of thing due to GCC's in-tree build system not being quite as good as it was in ye olde days and because I think the result is minimal anyways (and maybe bad for people without a Core2 CPU) - I compiled/linked all 32-bit Windows and Cygwin binutils with --enable-large-address-aware, which should allow people using my 32-bit compiler to build QtGui4d.dll without ld crashing because it runs out of address space/memory - As always, there's a Clang addon package for the native compilers for those wanting to experiment with it. Remember it needs GCC to link, so install both packages. In this little challenging build by trial and mostly error, I now know what can go wrong with the different platform's builds. This should help enormously when working with NightStrike and jon_y for an official mingw-w64 toolchain build process. Enjoy! Ruben |
From: Ruben V. B. <van...@gm...> - 2011-08-25 13:49:48
|
2011/8/25 Ruben Van Boxem <van...@gm...>: > Hi everyone! > > After some hard work rewriting my scripts to work on Fedora (and now > hopefully any Linux flavour), I can proudly announce a new release! > > The presents I bring you today: > - Mac (32-bit) and Cygwin builds: these are untested, and > cross-compiled from Fedora using the darwinx and cygwinx toolchains > respectively. Thank you epienbro and Yaakov for the great work. You > really outdid yourselves providing novel solutions for people like me > :) > - I switched from mingw-w64 to the stable/v2.x branch. All the > features, and the stability of a release branch :) > - Winpthreads has had a grand makeover by Kai, and it now does not > hang with GCC's openmp support. Don't hesitate to try it out, there's > no pthreads-win32 here anymore, and I'm quite sure it'll stay that way > :) > - I removed my custom optimizations (ie optimize for intel core 2 and > compiling everything with graphite optimizations) because 1) my new > build procedure breaks with this kind of thing due to GCC's in-tree > build system not being quite as good as it was in ye olde days and > because I think the result is minimal anyways (and maybe bad for > people without a Core2 CPU) > - I compiled/linked all 32-bit Windows and Cygwin binutils with > --enable-large-address-aware, which should allow people using my > 32-bit compiler to build QtGui4d.dll without ld crashing because it > runs out of address space/memory > - As always, there's a Clang addon package for the native compilers > for those wanting to experiment with it. Remember it needs GCC to > link, so install both packages. > > In this little challenging build by trial and mostly error, I now know > what can go wrong with the different platform's builds. This should > help enormously when working with NightStrike and jon_y for an > official mingw-w64 toolchain build process. > > Enjoy! > > Ruben > Ah yes, and download links :) http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb http://sourceforge.net/projects/mingw-w64/files/Toolchain sources/Personal Builds/rubenvb/ Ruben |
From: Luis L. <lui...@gm...> - 2011-08-25 15:20:37
|
On Thu, Aug 25, 2011 at 10:49 AM, Ruben Van Boxem <van...@gm...> wrote: > > Ah yes, and download links :) > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb > http://sourceforge.net/projects/mingw-w64/files/Toolchain sources/Personal Builds/rubenvb/ > Thank you Ruben! But, didn't i686 and x86_64 get uploaded in inverse way? I see i686-w64-mingw32 in Targeting Win64 and x86_64-w64-mingw32 inside Targetting Win32 folders. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry |
From: Luis L. <lui...@gm...> - 2011-08-25 15:57:05
|
On Thu, Aug 25, 2011 at 12:20 PM, Luis Lavena <lui...@gm...> wrote: > On Thu, Aug 25, 2011 at 10:49 AM, Ruben Van Boxem > <van...@gm...> wrote: >> >> Ah yes, and download links :) >> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb >> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb >> http://sourceforge.net/projects/mingw-w64/files/Toolchain sources/Personal Builds/rubenvb/ >> > I'm receiving a data error trying to extract x86_64-w64-mingw32-gcc-4.6.2-2-mac_rubenvb.tar.lzma shasum reports b72bf4008da357de2666be82506f51be63f13ff1 for the file, the same SHA1 displayed on the downloads page, which might indicate a corrupted file. Cheers, -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry |
From: Ruben V. B. <van...@gm...> - 2011-08-25 18:39:51
|
2011/8/25 Luis Lavena <lui...@gm...>: > On Thu, Aug 25, 2011 at 12:20 PM, Luis Lavena <lui...@gm...> wrote: >> On Thu, Aug 25, 2011 at 10:49 AM, Ruben Van Boxem >> <van...@gm...> wrote: >>> >>> Ah yes, and download links :) >>> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb >>> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb >>> http://sourceforge.net/projects/mingw-w64/files/Toolchain sources/Personal Builds/rubenvb/ >>> >> > > I'm receiving a data error trying to extract > x86_64-w64-mingw32-gcc-4.6.2-2-mac_rubenvb.tar.lzma > > shasum reports b72bf4008da357de2666be82506f51be63f13ff1 for the file, > the same SHA1 displayed on the downloads page, which might indicate a > corrupted file. This is what I get from thinking I can copy 500 MB in 5 seconds to a USB flash drive... And by thinking KDE would not tell me it's finished before it's well, finished copying. The checksum does not match my local file. I re-uploaded everything directly from my build machine. Sorry for the inconvenience, and thanks for letting me know so soon! Be sure to complain if the mac builds don't work, I'm blindly relying on, well, no testing whatsoever :) Ruben |
From: Luis L. <lui...@gm...> - 2011-08-25 19:27:39
|
On Thu, Aug 25, 2011 at 3:39 PM, Ruben Van Boxem <van...@gm...> wrote: > > This is what I get from thinking I can copy 500 MB in 5 seconds to a > USB flash drive... And by thinking KDE would not tell me it's finished > before it's well, finished copying. > At least is not the dreaded 5 seconds left guesstimations of windows ;-) Re: x86_64 inside Win32 and i686 inside Win64 download folders. It was me or these are in the right place? > The checksum does not match my local file. I re-uploaded everything > directly from my build machine. Sorry for the inconvenience, and > thanks for letting me know so soon! Be sure to complain if the mac > builds don't work, I'm blindly relying on, well, no testing whatsoever > :) > i686-w64-mingw32-gcc-4.6.2-2-mac_rubenvb.tar.lzma: SHA1: 1a98ced51b5fd6b11b2f2094ecf5449650063bf9 Matches the download page, so it's ok. Even better: I've successfully built Ruby on my OSX 10.6 with it, haven't tested it yet, but I bet it works ;-) Will test the native builds along with the cross-compiled version later today and let you know. Cheers, -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry |
From: Ruben V. B. <van...@gm...> - 2011-08-25 19:33:04
|
Op 25 aug. 2011 21:28 schreef "Luis Lavena" <lui...@gm...> het volgende: > > On Thu, Aug 25, 2011 at 3:39 PM, Ruben Van Boxem > <van...@gm...> wrote: > > > > This is what I get from thinking I can copy 500 MB in 5 seconds to a > > USB flash drive... And by thinking KDE would not tell me it's finished > > before it's well, finished copying. > > > > At least is not the dreaded 5 seconds left guesstimations of windows ;-) > > Re: x86_64 inside Win32 and i686 inside Win64 download folders. > > It was me or these are in the right place? I fixed it by reuploading everything :-) > > > The checksum does not match my local file. I re-uploaded everything > > directly from my build machine. Sorry for the inconvenience, and > > thanks for letting me know so soon! Be sure to complain if the mac > > builds don't work, I'm blindly relying on, well, no testing whatsoever > > :) > > > > i686-w64-mingw32-gcc-4.6.2-2-mac_rubenvb.tar.lzma: > SHA1: 1a98ced51b5fd6b11b2f2094ecf5449650063bf9 > > Matches the download page, so it's ok. > > Even better: I've successfully built Ruby on my OSX 10.6 with it, > haven't tested it yet, but I bet it works ;-) Great to hear! > > Will test the native builds along with the cross-compiled version > later today and let you know. Thanks for that! > > Cheers, > -- > Luis Lavena > AREA 17 > - > Perfection in design is achieved not when there is nothing more to add, > but rather when there is nothing more to take away. > Antoine de Saint-Exupéry > > ------------------------------------------------------------------------------ > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public |
From: Luis L. <lui...@gm...> - 2011-08-25 22:31:16
|
On Thu, Aug 25, 2011 at 4:32 PM, Ruben Van Boxem <van...@gm...> wrote: > Op 25 aug. 2011 21:28 schreef "Luis Lavena" <lui...@gm...> het >> >> Re: x86_64 inside Win32 and i686 inside Win64 download folders. >> >> It was me or these are in the right place? > > I fixed it by reuploading everything :-) > Thank you :-) > >> >> Will test the native builds along with the cross-compiled version >> later today and let you know. > > Thanks for that! > I hope you will be happy to know that i686-w64-mingw32-gcc-4.6.2-2_rubenvb.7z package successfully compiled the following libraries: - libffi 3.0.9 - libyaml 0.1.4 - OpenSSL 1.0.0d And Ruby 1.9.3 codebase, all test pass. Thank you! -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry |
From: Jon <jon...@gm...> - 2011-08-25 19:49:02
|
Thanks, nice job Ruben! With i686-w64-mingw32-gcc-4.6.2-2_rubenvb.7z I've just built gvim (with dynamic lua and python support) on Win7 32bit and all looks great. I'm still seeing this SIGTRAP issue http://sourceforge.net/mailarchive/message.php?msg_id=27964784 Jon --- blog: http://jonforums.github.com/ twitter: @jonforums "Anyone who can only think of one way to spell a word obviously lacks imagination." - Mark Twain |
From: Ruben V. B. <van...@gm...> - 2011-08-26 15:06:29
|
2011/8/25 Jon <jon...@gm...>: > Thanks, nice job Ruben! > > With i686-w64-mingw32-gcc-4.6.2-2_rubenvb.7z I've just built gvim (with dynamic lua and python support) on Win7 32bit and all looks great. > > I'm still seeing this SIGTRAP issue http://sourceforge.net/mailarchive/message.php?msg_id=27964784 I have an idea: try removing the python27.dll file in mingw32/bin. I put it in there for gdb's python support, and it might interfere with the Python you're using to do your stuff. I'll see if I can't move the dll to mingw32/bin/lib and have gdb search for lib/python27.dll (import library magic?), if this solves your issue of course. Otherwise, you probably have the VC++ 2008 redistributable packages installed, right? (ie both the normal and SP1 one, both for x86 in this case) Ruben |
From: Jon <jon...@gm...> - 2011-08-26 16:09:56
|
> 2011/8/25 Jon <jon...@gm...>: > > Thanks, nice job Ruben! > > > > With i686-w64-mingw32-gcc-4.6.2-2_rubenvb.7z I've just built gvim (with dynamic lua and python support) on Win7 32bit and all looks great. > > > > I'm still seeing this SIGTRAP issue http://sourceforge.net/mailarchive/message.php?msg_id=27964784 > > I have an idea: try removing the python27.dll file in mingw32/bin. I > put it in there for gdb's python support, and it might interfere with > the Python you're using to do your stuff. I'll see if I can't move the > dll to mingw32/bin/lib and have gdb search for lib/python27.dll > (import library magic?), if this solves your issue of course. Good point, but while the move is a good idea, I don't think it's the problem. Originally I doh'd and left your bin/ on the beginning of PATH, but just rebuilt and tried again after cleaning PATH: C:\Users\Jon\Documents\vim-src>hg in comparing with https://vim.googlecode.com/hg/ abort: DLL load failed: Invalid access to memory location.! C:\Users\Jon\Documents\vim-src>echo %PATH% C:\Program Files\CollabNet\Subversion Client;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\Microsoft Windows Performance Toolkit\;C:\tools;C:\Python27\Scripts;C:\Python27;C:\ruby193\bin;c:\scala\bin;c:\lua\bin;c:\groovy\bin;C:\gnuwin32\curl\bin;C:\gnuwin32\diff\bin;C:\gnuwin32\grep\bin;C:\gnuwin32\findutils\bin;C:\gnuwin32\sed\bin;C:\gnuwin32\gawk\bin;C:\gnuwin32\less\bin;C:\gnuwin32\upx\bin;C:\gnuwin32\coreutils\bin;C:\Program Files\Wix;C:\git\cmd C:\Users\Jon\Documents\vim-src>hg in comparing with https://vim.googlecode.com/hg/ abort: DLL load failed: Invalid access to memory location.! I need to get back to gdb and manually `break *addr` walk back the frames to try to get something useful now that I've figured out how to abuse distutils into building the hg extensions with -ggdb3. Eventhough I'd like to blame this http://sourceforge.net/mailarchive/message.php?msg_id=27971417 I'm still holding out it's something with my system. I've also noticed that it's not a 100% failure in that if it ever "works" it seems to keep working. I've added the mercurial dirs to my AV (AVG) real-time exclusion list as these apps sometimes cause similar problems. Odd. FWIW, I get the following (in both working and failing cases) dependencies on the osutil.pyd so it doesn't seem relevant: http://www.mediafire.com/i/?9pjj5ampefpyti1 > Otherwise, you probably have the VC++ 2008 redistributable packages > installed, right? (ie both the normal and SP1 one, both for x86 in > this case) I have 9.0.21022 and x86 9.0.30729.4148 (both x86) installed, but sorry I've missed your (probably debugging) point :( Jon --- blog: http://jonforums.github.com/ twitter: @jonforums "Anyone who can only think of one way to spell a word obviously lacks imagination." - Mark Twain |
From: Earnie <ea...@us...> - 2011-08-29 13:55:12
|
Ruben Van Boxem wrote: > I have an idea: try removing the python27.dll file in mingw32/bin. I > put it in there for gdb's python support, and it might interfere > with the Python you're using to do your stuff. I'll see if I can't > move the dll to mingw32/bin/lib and have gdb search for > lib/python27.dll (import library magic?), if this solves your issue > of course. Ruben, you are aware of the .local directory method of dll side-by-side assemblies, correct? http://msdn.microsoft.com/en-us/library/dd408052(v=VS.85).aspx <http://msdn.microsoft.com/en-us/library/dd408052%28v=VS.85%29.aspx> So basically create a gdb.exe.local in the same location as gdb.exe and put the dll in it. Earnie |
From: Ruben V. B. <van...@gm...> - 2011-08-29 14:02:12
|
2011/8/29 Earnie <ea...@us...> > Ruben Van Boxem wrote: > > > I have an idea: try removing the python27.dll file in mingw32/bin. I > > put it in there for gdb's python support, and it might interfere > > with the Python you're using to do your stuff. I'll see if I can't > > move the dll to mingw32/bin/lib and have gdb search for > > lib/python27.dll (import library magic?), if this solves your issue > > of course. > > Ruben, you are aware of the .local directory method of dll side-by-side > assemblies, correct? > http://msdn.microsoft.com/en-us/library/dd408052(v=VS.85).aspx > <http://msdn.microsoft.com/en-us/library/dd408052%28v=VS.85%29.aspx> > > So basically create a gdb.exe.local in the same location as gdb.exe and > put the dll in it. > Does it work for preloaded (ie no LoadLibrary involved) DLLs? I gathered it didn't. I also figured that renaming the dll before I did the gendef+dlltool steps should work equally effictively. Ruben |
From: Earnie <ea...@us...> - 2011-08-29 14:30:53
|
Ruben Van Boxem wrote: > 2011/8/29 Earnie <ea...@us...> > >> Ruben Van Boxem wrote: >> >>> I have an idea: try removing the python27.dll file in >>> mingw32/bin. I put it in there for gdb's python support, and it >>> might interfere with the Python you're using to do your stuff. >>> I'll see if I can't move the dll to mingw32/bin/lib and have gdb >>> search for lib/python27.dll (import library magic?), if this >>> solves your issue of course. >> >> Ruben, you are aware of the .local directory method of dll >> side-by-side assemblies, correct? >> http://msdn.microsoft.com/en-us/library/dd408052(v=VS.85).aspx >> <http://msdn.microsoft.com/en-us/library/dd408052%28v=VS.85%29.aspx> >> >> >> So basically create a gdb.exe.local in the same location as gdb.exe and >> put the dll in it. >> > > Does it work for preloaded (ie no LoadLibrary involved) DLLs? I > gathered it didn't. I also figured that renaming the dll before I did > the gendef+dlltool steps should work equally effictively. > This statement, "The contents of a redirection file are ignored, but its presence causes Windows to check the application directory first whenever it loads a DLL," from http://msdn.microsoft.com/en-us/library/ms682600(v=vs.85).aspx <http://msdn.microsoft.com/en-us/library/ms682600%28v=vs.85%29.aspx> makes me believe so. But the page is LoadLibrary explicit. But see also http://msdn.microsoft.com/en-us/library/ms682586(v=vs.85).aspx <http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx> regarding DLL search order. Hmm, this is an interesting statement "An import library supplies the system with the information needed to load the DLL and locate the exported DLL functions when the application is loaded." from http://msdn.microsoft.com/en-us/library/ms681914(v=VS.85).aspx <http://msdn.microsoft.com/en-us/library/ms681914%28v=VS.85%29.aspx> is it possible to use a relative path to the DLL such that your idea of bin/lib/foo.dll works? You set the DLL name as lib/foo.dll in the import library and it works? If so, then having gdb.exe.local/python.dll would be just has effective and have another purpose for LoadLibrary should you need it later. Earnie |