Re: [Mingw-w64-public] Problem with i686-w64-mingw32-gcc-4.6.2-2_rubenvb
On Thu, 15 Sep 2011 12:33:38 +0200 Ruben Van Boxem wrote: > Op 15 sep. 2011 12:16 schreef "Andrei Lapshin" het > volgende: > > > > Solved the problem by moving Z:\mingw32 to C:\mingw32. > > Wow, that's strange. I always place my mingw* folders at > m:/development/mingw*. Weird :s What I noticed earlier was that the compiler picked up libstdc++ from z:\mingw32\lib and not from the mingw-w64 folder. Earnie -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] clever toolchain dep mgmt examples?
> On 9/19/2011 22:38, Jon wrote: > > I'm working on an app (targeted to run on WinXP_SP2+) having DLLs > > with runtime dependencies on the particular MinGW-w64 > > `libgcc_s_sjlj-1.dll` and `libstdc++-6.dll` artifacts used to build > > the app. As such, these specific artifact versions will need to be > > placed on the end users PATH. > > > > I'm interested in hearing whether others have discovered > > particularly clever examples of automating a build process to > > ensure the build's install/archive step includes the correct > > versions of these MinGW-w64 toolchain artifacts. > > > > Thanks, > > Jon > > > > > > Why not just bundle the DLLs along side the user executable? See side-by-side assemblies in MSDN if you need to control differing versions of DLL libraries. Earnie P.S.: My mail client (Claws-Mail) refused to quote Jon's mail. I had to forward it to myself and then reply to the mail. -- 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] new ISO C Standard C1X
On Tue, Jan 3, 2012 at 3:18 PM, Jim Michaels wrote: > http://www.h-online.com/open/news/item/ISO-updates-C-standard-1400814.html > > new ISO C standard, C1X, more C++ features, including threads... > Jim, can you please put this link in some appropriate spot on the wiki? Thanks, -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] difference between your projects
On Wed, Jan 4, 2012 at 2:57 AM, Peter Meyer wrote: > History: > As far as i know. The MinGW64 Project was forked from the MinGW32 > Project because of foolery from the MinGW32 Project Staff. Some Members > of the MinGW32 > Teams wanted to have a 64-Bit 64-Bit 86_64 Version of the MinGW Project > but the effort was hampered by the MinGW32 Leaders.After a lot of > discussion and flaming, > the two teams are devided and the MinGW64 Project was created to go > ahead with the 32 and 64-Bit Plan. I do not believe you represent the history correctly. I will not say more except to say that the archives hold the truth about the history. -- Earnie -- 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] autotools
On Thu, Jan 5, 2012 at 5:09 PM, JonY wrote: > > iirc Perl 5.8 for MSYS is out, you could try to persuade the maintainers > to make it threaded. > That would be Chuck Wilson who IIRC monitors this list but discussion should happen at mingw-us...@lists.sourceforge.net. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] undefined reference to `wcslen'
On Fri, Jan 13, 2012 at 8:07 AM, Erik van Pienbroek
wrote:
> Kai Tietz schreef op do 12-01-2012 om 22:54 [+0100]:
>> 2012/1/12 Kyle :
>> > I'm getting:
>> > trunk/mingw-w64-crt/stdio/mingw_pformat.c:476: undefined reference to
>> > `wcslen'
>>
>> As wcslen is in libmsvcrt.a present, it seems to me like a broken
>> build of runtime. Or binutils is broken, but the link-order used - as
>> you have shown it - looks correct.
>>
>
> Hey,
>
> I've been bitten by this issue too while updating the base toolchain
> packages for Fedora. First I've updated to gcc 4.7 (20120106 snapshot),
> then binutils head (20120113 snapshot) and then mingw-w64 trunk
> (20120112 snapshot).
>
> Now when I try to compile a minimal .c file the following linker error
> occurs for the x86_64 target:
>
> $ cat test.c
> int main() { return 0; }
>
> $ x86_64-w64-mingw32-gcc test.c -o test.exe
> /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libmingwex.a(lib64_libmingwex_a-mingw_pformat.o):(.text+0x1e83):
> undefined reference to `wcslen'
>
> Building binaries for the i686 target work just fine.
>
> Is it also needed to rebuild gcc with the new crt in place?
Only if the ABI changed in the CRT which I doubt.
It appears to me to be a default library ordering problem. -lmsvcrt
needs to follow -lmingwex in the linker parameter order. Add -v to
your gcc options to see the order of default libraries being passed to
the linker.
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/4] Move IDL generation option from --enable-sdk=idl to --enable-idl
On Tue, Jan 31, 2012 at 9:12 PM, Rafaël Carré wrote: > Le 2012-01-31 01:57, JonY a écrit : >> On 1/31/2012 11:07, Rafaël Carré wrote: >>> --- >>> mingw-w64-headers/configure.ac | 19 +++ >>> 1 files changed, 11 insertions(+), 8 deletions(-) >>> >> >> What is the benefit of it being split up? > > Kai wanted to split up at list IDL to keep it disabled. > >> If possible keep the options >> as is, just enable them by default, eg --enable-sdks=all by default. > > I think --enable-sdks="ddk,directx" is a strange way to use configure. > No, it is acceptable as per your output below. > --disable-foo --enable-bar is the standard way to use autoconf, and this > makes the configure.ac code smaller. > > ./configure --help says: > > Optional Features: > > --disable-FEATURE do not include FEATURE (same as > --enable-FEATURE=no) > --enable-FEATURE[=ARG] include FEATURE [ARG=yes] > --enable-FEATURE[=ARG] and you're giving an ARG of "ddk,directx". Even GCC uses an ARG other than "yes". --enable-cloog-backend[=BACKEND] set the CLooG BACKEND used to either isl, ppl or ppl-legacy (default) --enable-stage1-languages[=all] choose additional languages to build during stage1. Mostly useful for compiler development -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] vsnprintf could not be located
On Wed, Feb 8, 2012 at 4:27 AM, Davidson, Josh wrote: > > > “The procedure entry point vsnprintf could not be located in the dynamic > link library msvcrt.dll” > > > > I know this error has been posted to the mailing list before, but I’m > wondering if there is any way of working around it in binary distributions. > I’m using the latest automated build (mingw-w32-bin_i686-mingw_20111219.zip > ) on 32-bit WinXP SP3. Sure enough has been left out of the system build, even though it is documented to be there. It needs to be _vsnprintf(). $ objdump -x /c/Windows/system32/msvcrt.dll | grep printf [ 216] _cprintf [ 224] _cwprintf [ 467] _scprintf [ 468] _scwprintf [ 482] _snprintf [ 484] _snwprintf [ 541] _vscprintf [ 542] _vscwprintf [ 543] _vsnprintf [ 544] _vsnwprintf [ 671] fprintf [ 684] fwprintf [ 741] printf [ 761] sprintf [ 786] swprintf [ 800] vfprintf [ 801] vfwprintf [ 802] vprintf [ 803] vsprintf [ 804] vswprintf [ 805] vwprintf [ 828] wprintf -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] unneeded directory?
On Sat, Feb 11, 2012 at 11:49 AM, Christer Solskogen wrote: > > Is it because gcc is braindead that we really need that symlink? I can't > quite understand why we need it in the first place. > No, it is because Windows isn't POSIX. If you desire you can use a utility called junction.exe to replace the copied directory with a junction point. Assuming we want a link pointing to real directory foo. junction bar foo -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] sizeof(size_t) on 64-bit systems with auto build?
On Thu, Feb 16, 2012 at 6:17 AM, Jim Michaels wrote: > > too bad the standard says that the definition in any particular compiler of > size_t should not be relied upon. > C99 defines SIZE_MAX which is (size_t)(-1). -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] error: 'long long long' is too long for GCC
On Sun, Feb 19, 2012 at 10:00 AM, Pau Garcia i Quiles wrote: > On Sun, Feb 19, 2012 at 11:59 AM, Ruben Van Boxem > wrote: > >> MSYS is a minimalistic and old Cygwin, which >> is a POSIX software layer on top of Windows. The MSYS Bash is also at >> version 3.2 or something. Cygwin has 4.2 if I'm not mistaken. MinGW != >> MSYS/Cygwin, it's native Win32, without any serious posix support. MinGW-w64 >> fills some gaps, but it's impossible to have decent POSIX support for native >> Win32. > > Earnie Boyd and others started MSYS 2.0 a few months ago (based on > bash 4.0 and cygwin 1.7). > I'm hoping to get back to it by summer. See https://sourceforge.net/u/earnie/msys2/home/Home/ and https://sourceforge.net/u/earnie/msys2/support/faq/thread/7a480221/ -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] mingw64 toolchain automatic installer.
On Wed, Feb 22, 2012 at 4:02 AM, Vincent Torri wrote: > On Tue, Feb 21, 2012 at 5:02 AM, Me Myself and I wrote: > >> Can someone here give me the url for the >> 64 bit equivalent of 32 bit >> >> mingw-get-inst-20110530.exe >> >> file? > > There is no such installer for the mingw-w64 project (at least, no > official one, maybe there are some somewhere). Usually, you just need > an archive of mingw-w64 toolchain, untar it, and add to PATH the > directory where the compilers are located. That's what I do. And no matter how many times you ask it you get the same answer. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] gcc-4.6.3 released!
On Fri, Mar 2, 2012 at 4:45 PM, Joshua Boyce wrote: > > On Sat, Mar 3, 2012 at 5:13 AM, Luis Lavena wrote: >> >> On Fri, Mar 2, 2012 at 1:09 PM, niXman wrote: >> > >> > I didn't upload sources and scripts cause nobody needs them. I didn't >> > want to hide them =) >> > >> > BTW, Why should I duplicate sources avalilable from official sites? >> >> That is where GPL becomes annoying, but you should comply :-( >> > > Yep, it can be quite frustrating sometimes. :( > > http://www.gnu.org/licenses/gpl-faq.html#DistributingSourceIsInconvenient So in a nut shell, it is *your* responsibility to provide the exact source for the binary distribution, including libraries, if someone asks for it. Not all licenses require source distribution when distributing the binary but it is a common practice to do so anyway. If you offer a binary on the internet you must provide the source on the internet from a location or locations you control. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] gcc-4.6.3 released!
On Fri, Mar 2, 2012 at 10:49 PM, Joshua Boyce > Personally I think it's all a little ridiculous, especially when it comes to > distributing the source of such massive and ubiquitous applications like > GCC... You need to take that up with Richard Stallman. ;-p -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] undefined reference to `__imp__fribidi_get_joining_types'
On Thu, Mar 8, 2012 at 4:26 AM, JonY wrote: >>> On 3/1/2012 11:06, Kyle wrote: The only __declspec(dllexport) I can find in fribidi is in lib/common.h: #if (defined(WIN32)) || (defined(_WIN32_WCE)) # define FRIBIDI_ENTRY __declspec(dllexport) #endif /* WIN32 */ If dllexport without an extern is being used to attempt to declare data or function then this is wrong as it ends up being a definition and not a declaration. See MSDN for more information. >>> >>> You need to link to fribidi DLL, not static lib. >> > > Go to your fribidi headers and remove the __declspec(dllimport) attributes. You can add an level of filtering such that you define FRIBIDI_ENTRY to empty. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Static Link libstdc++-6
On Tue, Mar 13, 2012 at 4:54 AM, Kai Tietz wrote: > 2012/3/13 Teemu Nätkinniemi : >> On 13.3.2012 10:26, Kyle wrote: >> >>> I have tried adding -static and -static-libstdc++ to both the LDFLAGS >>> and CFLAGS for FFmpeg. I have tried adding them to utvideo as well. >>> >>> I'm not sure how to force FFmpeg to compile statically, but if anyone >>> has any input I would greatly appreciate it! >> >> Rename libstdc++.dll.a so ld will use libstdc++.a instead. > > Better and not so hacky way to solve this is to specify option > '-static-libstdc++' on link for gcc's frontend. Not just hacky, the rename of .dll.a to just .a doesn't resolve anything and potentially removes the static library that already exists. Such advice should never be given. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] dbghelp: different behavior when compiling with mingw or vc++
On Tue, Mar 13, 2012 at 4:41 AM, Vincent Torri wrote: > Hey, > > I'm trying to get the callstack of programs, so I try to use dbghelp. > The code is here: > > http://codepad.org/wAhYYChY > > compilation is fine (see the first line to see how I compile it with > mingw). I use mingw-w64, Windows XP SP2 running in virtualbox. > > The binary compiled with Visual Studio 2008 express is working correctly > The binary compiled with mingw gives the following errors : > > SymGetSymFromAddr64() failed ( 487) Attempt to access invalid address. > SymGetLineFromAddr64() failed ( 487) Attempt to access invalid address. > MSDN says "Note This function is provided only for compatibility. Applications should use SymFromAddr." How would these work in a 32 bit platform? Examples on MSDN suggest that it wouldn't. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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 GCC 4.7 rubenvb Personal build
On Tue, Mar 13, 2012 at 4:24 PM, Luis Lavena wrote: > Compiled as: > > g++ hello.cc -o hello.exe > > Still depends on LIBSTDC++-6.DLL > > Adding -static-libstdc++ made it depend on LIBWINPTHREAD-1.DLL > It depended on both before. > Maybe I'm confusing how it is supposed to work? > Try -static -static-libstdc++ to see if you might be happier. IDK if it works. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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 GCC 4.7 rubenvb Personal build
On Tue, Mar 13, 2012 at 4:45 PM, Ruben Van Boxem wrote: > 2012/3/13 Earnie Boyd >> >> On Tue, Mar 13, 2012 at 4:24 PM, Luis Lavena wrote: >> > Compiled as: >> > >> > g++ hello.cc -o hello.exe >> > >> > Still depends on LIBSTDC++-6.DLL > > > Of course it does. > >> >> > >> > Adding -static-libstdc++ made it depend on LIBWINPTHREAD-1.DLL >> > >> >> It depended on both before. > > > Yup (see below) > >> >> > Maybe I'm confusing how it is supposed to work? >> > > > > This has always been the case. What got fixed is programs using std::thread > and a libstdc++ dll. They used to not work and throw a C++ exception when > they shouldn't. Now these programs work as they should with a libstdc++ dll, > as well as statically linked. If you never experienced a problem, nothing > changed. I repeat: only stuff using std::thread is affected. > >> >> >> Try -static -static-libstdc++ to see if you might be happier. IDK if it >> works. > > > see above, he already tried that... > I still don't see the -static with -static-libstdc++ above. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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 ver 3.20 source?
On Tue, Mar 20, 2012 at 4:21 PM, Colin S. Miller wrote: > On 20/03/12 10:25, JonY wrote: > > On 3/20/2012 17:54, postmas...@csmiller.demon.co.uk wrote: > >> JonY said: > >>> On 3/20/2012 00:57, mingw...@csmiller.demon.co.uk wrote: > >> > >>> I'm trying to build ffmpeg-0.5.5 for MS-Windows 64bit; it claims > it needs MinGW64 3.15 or later. > > > TIA, > Colin S. Miller > >>> Go ahead and bump it yourself, we don't normally increment those numbers. > >> > >> Jon, > >> It seems a bit strange that the ffmpeg team picked a version that MinGW64 > >> doesn't support by default (the version check is only for MinGW x86_64). > >> However, I bumped the version to 3.20, and the win32api version to 3.13 > >> (from 3.12), as ffmpeg checks that next. > >> > >> Their code then does (libavdevice\vfwcap.c) > >> #include "libavformat/avformat.h" > >> #include > >> #include > >> > >> which fails as vfw.h does not pull in a #define / typedef for DWORD etc. > >> This could be be fixed, (in several source files, or in vfw.h), but I > >> suspect that ffmpeg used a different version of MinGW64. > >> > >> Thanks for your time, but I think this is a question for the ffmpeg team. > >> > >> Colin. > >> > > > > I'm not familiar with the ffmpeg code base, so its best to ask the mingw > > maintainer for some explanation. I can't say for sure what the real > > problem is. > > > > As a quick fix, you could try moving windows.h above vfw.h. > > > > > > > Jon, > > I am a bit reluctant to do that, as the fact that it doesn't build means > that there is something wrong with my build environment. > However, if it comes to it, I will do that, or upgrade to a slightly > later ffmpeg. AFAIK all header files that are part of the Windows API should be included after Windows.h so that things like DWORD are defined. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] some warning when compiling with mingw-w64 (32 bits)
On Tue, Mar 20, 2012 at 1:50 PM, Vincent Torri wrote: > Hey > > with latest d-bus release (1.4.18) : > > In file included from dbus-sockets-win.h:36:0, > from dbus-sysdeps-win.c:49: > c:\mingw_efl\mingw-w64-x86_32\bin\../lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/include/winsock2.h:15:2 > : warning: #warning Please include winsock2.h before windows.h [-Wcpp] > I wonder why it matters? The mingw.org version of winsock2.h just includes windows.h as the first item of business. Let's ask mingw-64-public? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] some warning when compiling with mingw-w64 (32 bits)
On Tue, Mar 20, 2012 at 5:16 PM, Ruben Van Boxem wrote: > 2012/3/20 Earnie Boyd >> >> On Tue, Mar 20, 2012 at 1:50 PM, Vincent Torri >> wrote: >> > Hey >> > >> > with latest d-bus release (1.4.18) : >> > >> > In file included from dbus-sockets-win.h:36:0, >> > from dbus-sysdeps-win.c:49: >> > >> > c:\mingw_efl\mingw-w64-x86_32\bin\../lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/include/winsock2.h:15:2 >> > : warning: #warning Please include winsock2.h before windows.h [-Wcpp] >> > >> >> I wonder why it matters? The mingw.org version of winsock2.h just >> includes windows.h as the first item of business. Let's ask >> mingw-64-public? > > > This will cause problems with the fact that windows.h includes winsock.h > (check MSVC headers, you'll find it). Including winsock2.h after winsock.h > (through windows.h for example) will produce double definition errors. > > For reference, see the "note" here: > http://msdn.microsoft.com/en-us/library/ms737629%28VS.85%29.aspx > 'Historical reasons' Ah, thank-you Ruben. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
On Thu, Mar 22, 2012 at 3:35 PM, Kai Tietz wrote: > > Yes, this winsup thing was introduced by mingw.org and cygwin ... It > is indeed a pain in the ... Therefore in our Wiki there were the > description for multilib build that said to setup winsup link. I > checked and this information is lost ... > ( > https://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler > ) Don't blame mingw.org. :-o We inherited that mess and anytime we've tried to touch the configure elements we break something in Cygwin. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] need 32+64-bit target ubuntu compiler for 32-bit windows host
On Mon, Mar 26, 2012 at 5:38 PM, Whitequill Riclo wrote: > > On Sun, Mar 25, 2012 at 8:37 PM, NightStrike wrote: >> >> On Sun, Mar 25, 2012 at 2:18 PM, JonY wrote: >> > On 3/26/2012 07:17, Jim Michaels wrote: >> >> vityan provided a compiler set for 64-bit windows host for ubuntu and >> >> freebsd 32 and 64-bit targets. >> >> my problem is, I have a 32-bit windows. also, not everybody has a >> >> 64-bit system or can afford one. >> >> >> >> please provide a compiler set also for 32-bit. thank you. >> >> I would like the ability to start compiling code for linux platforms >> >> from my windows machine. >> >> I don't know how to make an RPM. I also don't know what kind of >> >> installer ubuntu uses. >> >> >> > >> > Compiling code for Linux from Windows is really off-topic here. Your >> > best bet is to build the compiler yourself, seeing that you already have >> > the libc parts from Vityan. >> >> Actually, this is very on topic. Jim, we'd love to support your >> efforts. We had a user here who tried to provide toolchains to do >> exactly that. I will find out what hte status is. > > > I've been working on a cross compiler to build Linux binaries on Windows. > So far I have a cross to build Windows executable, on Linux. > People have tried and failed with mingw.org as well. We have never understood why you would want to. Just get a VM with Linux in it to build on Windows in Linux. > 1) Linux >>builds>> Win64/32 > 2) Win64/32 >>builds>> Linux > 1) --host = Linux --target = Win64/32 --build = Linux 2a) --host = Win64/32 --target = Linux --build = Linux 2b) --host = Win64/32 --target = Linux --build = Win64/32 > I'm to the bootstrapping stage2 compiler to building the I have the Windows > binutils '.exe' files, and I'm having trouble with "how to's" of boot > strapping and building windows exe files with the compiler. > Then it needs to compile its self? on linux? or Windows? or WINE? > I found a --bootstrap-stage1-bubble command, and finally have got it to > build gmp with it, but it doesn't recognize MPFR. > Which did you use 2a or 2b? I would imagine 2a to be easier to get GCC to build but once built you still need all of the Linux libraries and headers on Win32/64. For 2b you need the Linux libraries and headers o Win32/64 before you begin the build of GCC. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Printing unicode characters with std::wcout or wprintf
On Wed, Mar 28, 2012 at 8:28 AM, Jim Michaels wrote: > > they tabled it for C++11. which I thought wasn't too bright. maybe it was > someone who used the windows cmd shell and never figured out he could switch > from raster font to"lucida console". > It has nothing to do with C++11, it is about Microsoft and their desires to want you using the Windows API instead of the C runtime. And Ruben's sample code was C and not C++ specific although he stated the C++ API exhibited the same results. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] need 32+64-bit target ubuntu compiler for 32-bit windows host
On Tue, Mar 27, 2012 at 12:25 PM, Whitequill Riclo wrote: > > I'm using 1, to try and build... here: > http://pastebin.me/c589420d23daa3d5ddbe15e58e03b0ab that is what I've been > doing. One thing I've noticed here is that you use sudo for most commands touching directories in /tools except for: case $(uname -m) in x86_64) mkdir -v /tools/lib && ln -sv lib /tools/lib64 ;;/ easc If sudo is required everywhere else it should be used here also. In the script I cannot see where you are changing to a build directory. I see a couple of places where you make a build directory but you've never changed to them. You should not build in the source directory and in fact GCC refuses to build in the source directory. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Printing unicode characters with std::wcout or wprintf
On Wed, Mar 28, 2012 at 10:06 AM, Ruben Van Boxem wrote: > 2012/3/28 Earnie Boyd >> >> On Wed, Mar 28, 2012 at 8:28 AM, Jim Michaels wrote: >> > >> > they tabled it for C++11. which I thought wasn't too bright. maybe it >> > was >> > someone who used the windows cmd shell and never figured out he could >> > switch >> > from raster font to"lucida console". >> > >> >> It has nothing to do with C++11, it is about Microsoft and their >> desires to want you using the Windows API instead of the C runtime. >> And Ruben's sample code was C and not C++ specific although he stated >> the C++ API exhibited the same results. > > > Although I share your sentiments wrt to a bad C runtime implementation on > Windows, this is strictly not forbidden by the Standard. It just happens > that the *nix wprintf family converts the wchar_t's to UTF-8, which is > supported by the regular char printf's. The Standards only state that an > implementation defined conversion happens, which happens to be a conversion > to the local ANSI codepage on Windows. Conclusion: it's the C/C++ wchar_t > output functionality that is broken, not the Windows implementation of it. > Programs relying on any "right" conversion to be happening there are relying > on implementation defined behavior and thus are not portable by design. > > I know, it sucks, and it surprised me too. > Yea, well, Microsoft has some peculiar extensions to the C runtime that aren't exactly ANSI compatible either. You might try the _wprintf_l() API to specify a locale but based on MSDN wprintf() should print the UTF-8 character. You should be able to use printf() with a %C format specifier to print the UTF-8 character and that doesn't work either. I was using 4.6.1 as delivered by mingw.org. And you stated that you used MSVC as well and couldn't get it to work correctly so my conclusion is that it is the runtime API that is broken. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] ddk headers missing
On Mon, Apr 2, 2012 at 6:28 AM, Christer Solskogen wrote: > diff -r 57225b741f27 mingw-w64/mingw-w64-headers/configure > --- a/mingw-w64/mingw-w64-headers/configure Mon Apr 02 08:55:41 2012 > +0200 > +++ b/mingw-w64/mingw-w64-headers/configure Mon Apr 02 12:28:19 2012 > +0200 Your change should be to configure.ac. The configure script itself is generated by autoconf. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Cross Compilation and using autoconf, automake
On Tue, Apr 3, 2012 at 1:59 AM, rajeshwari b wrote: > Hi all, > I followed "http://wiki.videolan.org/Win32CompileMSYSNew" and have installed > Msys 1.0.11 in "E:\Msys", TDM-GCC in "E:\MINGW32_64" (both 32 and 64 bit) > and Msys-git in "E:\msysgit\msysgit". I want to use autoconf and automake > for generating makefiles which i can get from Msys. Is there a way to access > the above linux tools from TDM-GCC? The collection of unix tools mentioned > in the "CrossQuickstart – mingw-w64.htm" are available in msysgit. So i may > need to access Msys-git also. Pl let me know the procedure. I would suggest that you use ``mingw-get install msys'' to install MSYS. The mingw-get application is the mingw.org installer. However, you already have it installed so... I would remove the msys-1.0.dll from the e:\msysgit\msysgit\bin directory, it might get in your way and it isn't the official MSYS runtime. Then just make sure e:\msysgit\msysgit\bin is in your directory after the MSYS /bin directory. You could even create an entry in your MSYS /etc/fstab file like ``e:/msysgit/msysgit /opt/msysgit'' and then create an entry in your ~/.profile file that modifies PATH like so export PATH=$PATH:/opt/msysgit/bin HTH, -- Earnie -- https://sites.google.com/site/earnieboyd -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-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] Cross Compilation and using autoconf, automake
On Tue, Apr 3, 2012 at 10:53 AM, rajeshwari b wrote: > Hi all, > Sorry, i didn't get it. There is no folder as mentioned i.e., " > e:/msysgit/msysgit > /opt/msysgit ". Instead of opt, there is a "libpopt" at > msysgit/msysgit/src. I am first timer, so pl let it be clear. You installed MSYS in E:\Msys You installed MSYSGIT in E:\msysgit\msysgit That means you have two versions of the MSYS runtime in two different directories. The runtime file is msys-1.0.dll and is located in the bin/ directory under each of the installed directories. I instructed you to remove the one from the MSYSGIT distribution to avoid address space collision. MSYS provides a means to map a Windows directory to a POSIX style directory by means of a file in /etc/fstab. Note that /etc is mapped to bin/msys-1.0.dll/../../etc automatically by MSYS. My reference to E:/msysgit/msysgit /opt/msysgit was adding a mapping of your installed E:/msysgit/msysgit to a POSIX variant /opt/msysgit. So add the following line to E:/Msys/etc/fstab: E:/msysgit/msysgit /opt/msysgit In POSIX ~ references the users HOME directory which you can find by echoing $HOME environment variable in the MSYS shell. echo $HOME My reference to adding /opt/msysgit/bit to PATH in the ~/.profile file means that the PATH environment variable would contain the path to the git executable every time you begin the MSYS instance. -- Earnie -- https://sites.google.com/site/earnieboyd -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-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] Cross Compilation and using autoconf, automake
On Wed, Apr 4, 2012 at 4:52 AM, rajeshwari b wrote: > Hi all, > As directed, have deleted the "msys-1.0.dll" from E:\msysgit\msysgit\bin > directory. > Have mounted the directory E:\msys\msys\ as /opt/msysgit You need to use E:/msysgit/msysgit Use the / and not the \ in /etc/fstab. > Have added the line "export PATH=$PATH:/opt/msysgit/bin" preceding the > following condition statement, > > if [ $MSYSTEM == MINGW32 ]; then > export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH" > else > export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH" > fi > > So, can still access the TDM-GCC from Msys shell. There is one more doubt You also need to add /e/MINGW32_64 to PATH. You probably want to replace /mingw/bin with /e/MINGW32_64/bin. -- Earnie -- https://sites.google.com/site/earnieboyd -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-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] Question about "warning: ISO C does not support the 'I64' ms_printf length modifier"
On Thu, Apr 12, 2012 at 7:04 AM, niXman wrote: > I.e. these warnings is reported when building gcc. > > ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:173:5: warning: ISO C > does not support the 'I64' ms_printf length modifier [-Wformat] Add -Wno-format after the -pedantic. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Question about "warning: ISO C does not support the 'I64' ms_printf length modifier"
On Thu, Apr 12, 2012 at 11:10 AM, niXman wrote: > 2012/4/12 Earnie Boyd : >> On Thu, Apr 12, 2012 at 7:04 AM, niXman wrote: >>> I.e. these warnings is reported when building gcc. >>> >>> ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:173:5: warning: ISO C >>> does not support the 'I64' ms_printf length modifier [-Wformat] >> >> Add -Wno-format after the -pedantic. > > No, I do not want to suppress all warnings for the format string. > Thanks. Then you'll need to live with the warnings because MS extensions are not ISO C, nor are they ANSI C for that matter. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Off-topic about Cygwin / MSVC
On Fri, Apr 20, 2012 at 7:49 AM, MARTIN Pierre wrote: > Dear MinGW-w64 readers, > > Is there anyone aware of some kind of wrapper so i could use the MSVC > compiler with either MSYS or cygwin? By that, i mean that i have bash scripts > which perform under either linux, macos and windows, and i would like to be > able to use them as well in cohesion with the MSVC compiler. Substitute GCC with the MSVC command line compiler. IIRC, that is cl. Substitute other commands with their appropriate counter part. NOTE: I don't know if it works and you may run into issues. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Thoughts on supporting the C++11 thread library on Windows
On Wed, May 9, 2012 at 11:58 AM, K. Frank wrote: > Again, I'm not all that big on backward compatibility, and, as noted > above, I don't understand what --enable-threads=win32 is for. But > my gut reaction is if that the gcc implementation (with > --enable-threads=win32) is sub-optimal, maybe it makes sense to > do it "right," even at the cost of backward compatibility. If you enable something new how does it affect backward compatibility? Perhaps with-in the coding itself, in that case the coding would need some method to know when it was different. If it is a run time or library compatibility issue my suggestion to all users using a new version of a compiler is to always rebuild the library with that compiler. It rarely gets done but it is the users detriment if they do not and then have issues; i.e. not a problem I worry about. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Thoughts on supporting the C++11 thread library on Windows
On Wed, May 9, 2012 at 12:04 PM, K. Frank wrote: > > Personally, as mentioned above, I am quite happy with the winpthreads > implementation of , as made available in Ruben's build. > > Please, let's have mingw-w64 (and mingw) users chime in. Do folks > prefer one approach (native vs. pthreads) to implementing > to the other? Is there enough interest in both approaches that it > makes sense to take away manpower from other issues to develop > and support both? > My druthers leans toward native. The Windows pthreads becomes a wrapper between POSIX and native so there is some loss of CPU resource by using it. > For those who haven't tried it yet, I heartily recommend Ruben's > -enabled build (that is based on winpthreads under the > hood). I have tested it and been using it some, and I haven't > found any problems with it yet. I have yet to give it a go myself so can't compare anything. Are there metrics using one versus another method? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Command Window
On Fri, May 11, 2012 at 2:20 AM, Ruben Van Boxem wrote: > Op 11 mei 2012 03:50 schreef "tomdean" het volgende: > > >> >> On 5/10/2012 6:00 PM, Luis Lavena wrote: >> > Use gcc -mwindows, by default it will create a console application. >> > See gcc --target-help >> I am using 'g++ -I. -lgdi32 -lcomctl32 -lcomdlg32 .cpp -o >> ' >> >> When I double click on .exe, a command window opens then >> whatever window I create opens. >> > > Use 'g++ -mwindows -lgdi32 -lcomctl32 -lcomdlg32 .cpp -o > ' instead. If you leave out -mwindows, GCC defaults to -mconsole > and you get a console window. The same applies to msvc with the /subsystem > commandline option. Isn't the library specification order incorrect and perhaps not needed? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] gcc does not find input file
On Thu, May 10, 2012 at 3:57 PM, David Froger wrote: >> Sure, you are using here within cygwin a native gcc. Of course it >> doesn't support cygwin's pathname. >> If you want to use cygwin, then please use the mingw-w64 package >> provided within cygwin's setup. > > Thanks for your reply! > > I understand, of course... My first steps with cygwin, sorry... This path name confusion is the reason I created MSYS. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] MinGW-w64 MSYS version questions.
On Tue, May 15, 2012 at 9:02 AM, MARTIN Pierre wrote: > i have a quick question about this MSYS environment. i primarily > use it because all my scripts are initially made on an unix system, > and are also being ran on my Debian machine. i didn't want to go > through the hassle of making windows bat scripts, and as i was > very happy with MSYS, i just adapted the scripts so they can run > on all systems under a POSIX environment. > At the time i did that, i was still using MinGW MSYS, and i had > access to the wonderful mingw-get command. i had 7zip, git > and some other pre-built packages installed. What file type are you trying to archive/unarchive? MSYS provides msys-zip and msys-unzip for .zip files. Also there is a msys-xz which will pack/unpack .lzma and .xz. So do you really need 7zip and if so why? But you should be able to use the windows command line version of 7zip within MSYS. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Debugging with gdb/QtCreator
On Mon, May 14, 2012 at 6:56 PM, Antony Riakiotakis wrote: > Ah, looks like the reason for the strange behaviour was my using > release with debug info build type for cmake. Optimizations play funky > with the debugger it seems. Now all is in order...phew. > If you're debugging code you should start by building without optimization then move to adding the individual items of optimization so you know which one is breaking the code. > So, summarizing again for reference: > > * Make sure python 2.7 is installed > * Make sure you don't enable any optimization in debug builds But you need to consider that optimization may cause a bug. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Hello, I'm new here and can't find Undefined symbols: __time32, __localtime32, and __gmtime32
On Tue, May 15, 2012 at 11:39 AM, Kai Tietz wrote: > Hello Anthony, > > those symbols are present in our libmingwex.a library. So I assume > that there might be a link-order issue. Or perhaps a link command issue? If you use GCC or G++ to link then these frontends should add the most common libraries. The mingwex library is one of those common libraries. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
On Wed, May 16, 2012 at 6:44 AM, Joshua Boyce wrote: > > I didn't mean that an additional import library was required, simply that > the correct import lib needs to be linked in as normal (just like you do > when using windows.h). For functions exported by kernel32 this > happens automatically, for other modules (user32, advapi32, etc) I believe > they must be specified manually. Is this not true? (I'm genuinely > interested, as I thought it was true last time I checked, but it may have > just been a configuration error on my end.) Assuming you use GCC/G++ for the linker command user32 and advapi32 are added as libraries. To see the list of libraries added use -v and you will see the full linker command parameters as passed to it by GCC. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Hello, I'm new here and can't find Undefined symbols: __time32, __localtime32, and __gmtime32
On Tue, May 15, 2012 at 8:24 PM, Anthony Walter wrote: > I fixed the problem. It was caused by out of order link lib statements. Link > order is important sometimes. s/sometimes/always -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] rubenvb GCC 4.7.0 release build
On Tue, May 22, 2012 at 10:13 AM, Antony Riakiotakis wrote: > Personally I don't mind using a toolchain with sse3 support > requirements but we have a policy towards backwards compatibility for > the program itself going back to 32 bit single core systems. For the > build systems I am not sure... You mean like Windows XP systems or do you mean something older? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] rubenvb GCC 4.7.0 release build
On Tue, May 22, 2012 at 9:06 AM, Ruben Van Boxem wrote: > > My new builds (along with the 4.5.3) will be built with > -march=nocona -mtune=core2 > Have you considered passing the options directly to the assembler. You can be specific with your refinements of the extensions added. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Building custom version
On Thu, May 24, 2012 at 7:46 AM, Baruch Burstein wrote:
> Specifically, I am looking to change the default mode of g++ to c++11. Where
> would I change that?
Well, you have several options for this. If you're set on building
the code you'll need to find the source for the internal specs file
and modify the %{std* string so that c++11 is used instead of ansi.
Note that there is more than one place to change.
On the other hand it will be easier to just add a specs file to the
/path/to/lib/gcc/TARGET/VERSION/ directory with the changed values.
You can get a specs file by simply doing g++ -dumpspecs > specs.
But all of this was said already.
If you're using a POSIX shell such as bash you could also assign an
alias as long as your make file isn't using an absolute PATH for the
compiler. If the make file is GNU standard then you should be able to
assign CXX variable as well.
alias g++='g++ -std=c++11'
export CXX='g++ -std=c++11'
You can also create a script file
#! /path/to/bin/sh
g++ -std=c++11 "$@"
https://sites.google.com/site/earnieboyd
--
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] Building custom version
On Thu, May 24, 2012 at 9:31 AM, Earnie Boyd wrote: > You can also create a script file > > > #! /path/to/bin/sh > > g++ -std=c++11 "$@" This should be g++.exe -std=c++11 "$@" > > > https://sites.google.com/site/earnieboyd -- 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
On Wed, May 30, 2012 at 9:06 AM, xunxun wrote: > 于 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. > I was coming to that conclusion based on http://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html but --prefix may play a role as well. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
On Tue, Jun 5, 2012 at 12:46 PM, niXman wrote: > Hello list! > > I would like to to understand this problem. > The fact is that, if MinGW is built on the disc 'D:', and is used on a > machine that does not have the disk 'D:' - then the windows shows the > dialog with the error of the access to the disk 'D:'. > Anybody can tell me in what GCC files this functionality is implemented? IIRC this has to do with the default search paths for headers and libraries and tends to be hardcoded based on the --prefix at configure time with a -D passed to the compiler. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
On Tue, Jun 5, 2012 at 10:21 PM, John E. / TDM wrote: > (2) MSYS' path > translation can get in the way, or at least has gotten in the way for me in > the past when building GCC. When I was maintaining MSYS I wouldn't release it if GCC would not build. Building the GCC package was my test of sanity for MSYS. I've not tried a GCC build in a while though so I don't know the state of issues with the current process. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
On Thu, Jun 7, 2012 at 5:08 AM, Baruch Burstein wrote: > 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? There is no reason to specify -lmingwex since the GCC and G++ front ends add it for you via the builtin specs. This is true for both mingw.org and mingw-w64. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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"
On Thu, Jun 7, 2012 at 3:36 AM, Jim Michaels wrote: > $ tail -1 config.log > configure: exit 77 You need more than just the tail end of the file. You need to find the section in config.log that failed. For some reason GCC aborted when trying to execute a program or aborted during the build of the program it was about to execute. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
On Wed, Jun 6, 2012 at 8:04 PM, John E. / TDM wrote: > On 6/6/2012 7:18 AM, Earnie Boyd wrote: >> On Tue, Jun 5, 2012 at 10:21 PM, John E. / TDM wrote: >>> (2) MSYS' path >>> translation can get in the way, or at least has gotten in the way for me in >>> the past when building GCC. >> When I was maintaining MSYS I wouldn't release it if GCC would not >> build. Building the GCC package was my test of sanity for MSYS. I've >> not tried a GCC build in a while though so I don't know the state of >> issues with the current process. > > What I mean is, MSYS' path translation can prevent the build-time > machinery from making all paths relocatable, or has in the past. The > build is still able to complete without any patches. I've created https://sourceforge.net/tracker/?func=detail&aid=3532790&group_id=2435&atid=102435 for it. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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"
On Fri, Jun 8, 2012 at 3:52 AM, Jim Michaels wrote: > it looks to be the fact that *this* gcc expects an argument on -V while the > one on linux does not (?). > interesting. there are a LOT of things I would like to compile, but I can't > because of this bug. > > --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 configure, which was > generated by GNU Autoconf 2.59. Invocation command line was > > $ ./configure > > ## - ## > ## Platform. ## > ## - ## > > hostname = jim-13l5nom9i4u > uname -m = i686 > uname -r = 1.0.17(0.48/3/2) > uname -s = MINGW32_NT-5.1 > uname -v = 2011-04-24 23:39 > > /usr/bin/uname -p = unknown > /bin/uname -X = unknown > > /bin/arch = unknown > /usr/bin/arch -k = unknown > /usr/convex/getsysinfo = unknown > hostinfo = unknown > /bin/machine = unknown > /usr/bin/oslevel = unknown > /bin/universe = unknown > > PATH: . > PATH: /usr/local/bin > PATH: /mingw/bin > PATH: /bin > PATH: /c/gnuwin32/GetGnuWin32/bin > PATH: /c/gnuwin32/GetGnuWin32/gnuwin32/sbin > PATH: /c/gnuwin32/GetGnuWin32/gnuwin32/bin > PATH: /c/Perl/site/bin > PATH: /c/Perl/bin > PATH: /c/WINDOWS/system32 > PATH: /c/WINDOWS > PATH: /c/WINDOWS/system32/WBEM > PATH: /c/PHP-5.4.0 > PATH: /c/u > PATH: /c/x > PATH: /c/program files/7-zip > PATH: /c/bin > PATH: /c/Program Files/Csound/bin > PATH: /c/Program Files/Common Files/Roxio Shared/9.0/DLLShared/ > PATH: /c/Program Files/CMake 2.8/bin > PATH: /c/Program Files/Common Files/HP/Digital Imaging/bin > PATH: /c/Program Files/HP/Digital Imaging/bin/ > PATH: /c/Program Files/HP/Digital Imaging/bin/Qt/Qt 4.3.3 > PATH: /c/Program Files/WinMerge > PATH: /c/Program Files/Java/jdk1.6.0_26/bin > PATH: /c/Program Files/Common Files/Ulead Systems/MPEG > PATH: /c/Program Files/Microsoft SQL Server/100/Tools/Binn/ > PATH: /c/Program Files/Microsoft SQL Server/100/DTS/Binn/ > PATH: /c/Program Files/Common Files/Intuit/QBPOSSDKRuntime > PATH: /c/Program Files/Microsoft Visual Studio 10.0/VC/bin > PATH: /c/Program Files/Microsoft Visual Studio 10.0/Common7/Tools/1033 > PATH: /c/Program Files/Microsoft Visual Studio 10.0/Common7/Tools > PATH: /c/Program Files/Microsoft Visual Studio 10.0/Common7/Tools/VDT > PATH: /c/Program Files/Microsoft Visual Studio 10.0/Common7/Tools/VDT/1033 > PATH: /c/Program Files/Microsoft Visual Studio > 10.0/Common7/Tools/ProjectComponents > PATH: /c/Program Files/Microsoft Visual Studio 10.0/Common7/IDE > PATH: /c/Program Files/Microsoft Visual Studio 10.0/Common7/IDE/1033 > PATH: /c/Program Files/Microsoft Visual Studio 10.0/Common7/Packages > PATH: /c/Program Files/Microsoft Visual Studio 10.0/Common7/Packages/1033 > PATH: /c/Program Files/Opera > PATH: /c/Program Files/QuickTime/QTSystem/ > PATH: /c/Program Files/OpenAxiom/bin > PATH: /c/Program Files/Notepad++/ > PATH: /c/tsepro You should think to trim your PATH to a minimal set by exporting what you need from ~/.profile file. > > > ## --- ## > ## Core tests. ## > ## --- ## > > configure:1340: checking for gcc > configure:1356: found /c/Program Files/OpenAxiom/bin/gcc What GCC is this? And paths with spaces is an issue that will cause you much grief. > configure:1366: result: gcc > configure:1610: checking for C compiler version > configure:1613: gcc --version &5 > gcc.exe (GCC) 3.4.5 (mingw special) Ah, I see, an old MinGW version. > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > configure:1616: $? = 0 > configure:1618: gcc -v &5 > Using built-in specs. > Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld > --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw > --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java > --disable-win32-registry --disable-shared --enable-sjlj-exceptions > --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm > --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization > --enable-libstdcxx-debug > Thread model: win32 > gcc version 3.4.5 (mingw special) > configure:1621: $? = 0 > configure:1623: gcc -V &5 > gcc.exe: `-V' option must have argument > configure:1626: $? = 1 > configure:1649: checking for C compiler default output file name > configure:1652: gcc conftest.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 As others have mentioned your installation is foul. Perhaps all you need to do is adjust you
Re: [Mingw-w64-public] msys ./configure gives error 77, "compiler doesn't generate exe's"
On Sat, Jun 9, 2012 at 4:08 AM, Jim Michaels wrote: > 2027 auto build 32-bit windows. > here is my fstab: > $ cat /etc/fstab > c:/ /c > e:/ /e > c:/prj /prj > c:/prj/fltk /fltk > c:/wxWidgets-2.9.3 /wx > c:/mingw-w32-bin_i686-mingw_2027 /mingw > c:/mingw-w64-bin_i686-mingw_2027 /mingw64 > c:/jackplugins /jp > > so as you can see, /mingw/ isn't the mingw you are thinking... It was your config.log file that told me. I didn't have to think about it. > > BASH manual says is supposed to use .bashrc on startup. does this shell use > instead .profile? hmm. that's different. > MSYS uses sh.exe which uses .profile. You have read the entire manual of bash. > so now I have this essentially for my .profile: > > $ cat ~/.profile > ADDR2LINE=`ls /mingw/bin/*mingw32-addr2line.exe` > CC=`ls /mingw/bin/*mingw32-gcc.exe` > CPP=`ls /mingw/bin/*mingw32-cpp.exe` > CXX=`ls /mingw/bin/*mingw32-g++.exe` > AR=`ls /mingw/bin/*mingw32-ar.exe` > AS=`ls /mingw/bin/*mingw32-as.exe` > DLLTOOL=`ls /mingw/bin/*mingw32-dlltool.exe` > DLLWRAP=`ls /mingw/bin/*mingw32-dllwrap.exe` > GPROF=`ls /mingw/bin/*mingw32-gprof.exe` > > export ADDR2LINE AR AS CC CPP CXX DLLTOOL DLLWRAP GPROF > > and most things compile (except mingw-w64). You mean the /mingw64 directory? Don't you need to change the variables to point to that? > I would really like to be able to compile it because I need the update. > difference I suppose between your builds and mine is I am trying to build on > a windows system - if that's possible. > > I always get an error during make. > Looks like you need to debug why. > other stuff now compiles just fine (well, except for the ones that are > unix-specific like jack audio, and apache modules). :-( > > looks like I am not going to be doing much with Jack audio server. > You'll need to figure out how to port these or turn on others ports of these packages. I know apache has Windows builds, I use it, but I use someone else's distribution. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: [PATCH v1] setup: allow building with i686-w64-mingw32
On Tue, Jun 12, 2012 at 5:11 AM, Jacek Caban wrote: > On 06/12/12 10:51, Jacek Caban wrote: >> On 06/12/12 07:06, Yaakov (Cygwin/X) wrote: >>> On 2012-06-04 04:04, Jacek Caban wrote: Where? I don't see any. There is one change to propkeydef.h, but and I believe incorrect. Generally, this patch makes REFIID and similar typedefs depend on CINTERFACE, which is not present in MSVC. >>> According to these, it is: >>> >>> http://msdn.microsoft.com/en-us/library/ak5wyby1(v=vs.71).aspx Isn't this specific to COM and an IDL compiler? Remarks By default, only COM-interfaces that are base classes of the coclass are added in the IDL coclass. implements lets you force other interfaces to be IDL coclass members. >>> http://social.msdn.microsoft.com/forums/en/vcgeneral/thread/80485378-3978-472b-ac76-a6a193cb9e47 >>> http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9e520505-5d05-4aad-83d9-a1b73042c531 >>> http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9b1b2189-c518-4cd8-80cc-2656b9c0d37f I didn't bother looking at social.msdn because it might influence me with code I don't want to see. >> If there is any source of informations more misleading than MSDN, that's >> MSDN forums:) Why do you need that change? That's not what mingw.org >> does nor MSVC, so why is it needed for your code? Can you please point >> me to the code that doesn't compile without this change? > > I double checked and mingw.org apparently has this bug. Anyway, that's > still a bug on their side that I don't think we want to duplicate. We (mingw.org) doesn't support COM and never has. A GCC supported IDL compiler would be great but whose going to pick up the support on that? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: [PATCH v1] setup: allow building with i686-w64-mingw32
On Tue, Jun 12, 2012 at 6:53 AM, Earnie Boyd wrote: > We (mingw.org) doesn't support COM and never has. A GCC supported IDL > compiler would be great but whose going to pick up the support on > that? Please excuse my improper English, s/doesn't/do not/ -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] MSVC Compatability in libmingwex - A Discussion on Design
On Sun, Jun 17, 2012 at 4:35 AM, Kai Tietz wrote: > Hi everybody, > > here come my 5-cent on that. First libmingw32.a and libmingwex.a are > two pretty different things. > I'll throw in 2 more cents worth. The mingwex was started by mingw.org and meant to contain code maintained by us that extended (the ex part) msvcrt to the extent that some of the functions provided by msvcrt could be overridden by libmingwex. Therefore by default it was never meant to be used by MSVC but you are more than welcome to create a differently named library that is more copacetic to MSVC. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Odd linking error
On Wed, Jun 20, 2012 at 7:17 AM, Ozkan Sezer wrote: > > If the MSVC *.lib that other project using is 32 bit, no problems with mingw. > Only 64 bit MSVC *.lib aren't supported. > Do you have a pointer to explain why? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
[Mingw-w64-public] Confirm for me please
I do not yet have a 64bit system to try this so please humor me a bit with this question. When compiling with 64bit version will __MINGW32__ be defined as well as __MINGW64__? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] linking error: "*x* referenced in section `.text' of [...]: defined in discarded section `.text' of [...]"
On Fri, Jul 6, 2012 at 1:25 AM, Ozkan Sezer wrote: > On 7/5/12, Rune K. Svendsen wrote: > >> -lwsock32 -lws2_32 -liberty-o streamer-ml-monl-chunkstream-static.exe > > You aren't supposed to link to both wsock32 and ws2_32: > only to one which you are supposed to be using. And you should be using ws2_32 (WinSOCK version 2) and not wsock32 (WinSOCK version 1). -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] linking error: "*x* referenced in section `.text' of [...]: defined in discarded section `.text' of [...]"
On Fri, Jul 6, 2012 at 9:07 AM, Ozkan Sezer wrote: -lwsock32 -lws2_32 -liberty-o streamer-ml-monl-chunkstream-static.exe >>> >>> You aren't supposed to link to both wsock32 and ws2_32: >>> only to one which you are supposed to be using. >> >> And you should be using ws2_32 (WinSOCK version 2) and not wsock32 >> (WinSOCK version 1). > > No, that depends on which header he is including, winsock.h or winsock2.h: > Not many, but there are a few constants that are different across the two > versions. If he is including winsock.h (or including it implicitly by just > including windows.h without WIN32_LEAN_AND_MEAN defined) then wsock32 is > needed. Otherwise if he is including winsock2.h (which needs to be included > before windows.h, BTW) then ws2_32 is needed. Correct but winsock2 is preferred. http://msdn.microsoft.com/en-us/library/windows/desktop/ms741412(v=vs.85).aspx -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] problem with static linking - libgcc_s_sjlj-1.dll - pthreadGC2.dll not statically linked
On Mon, Jul 9, 2012 at 11:52 AM, Zouzou wrote: > On 09/07/12 17:16, Simson Garfinkel wrote: >> x86_64-w64-mingw32-g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 >> -fexceptions --param=ssp-buffer-size=4 -Wno-format --static -static-libgcc >> -static-libstdc++ -Wall -MD -D_FORTIFY_SOURCE=2 -Wpointer-arith -Wshadow >> -Wwrite-strings -Wcast-align -Wredundant-decls -Wdisabled-optimization >> -Wfloat-equal -Wmultichar -Wmissing-noreturn -Wstrict-null-sentinel >> -Woverloaded-virtual -Wsign-promo -funit-at-a-time -mthreads >> -shared-libgcc -o tcpflow.exe datalink.o flow.o pcap_fake.o main.o tcpip.o >> xml.o util.o md5.o -lpthreadGC2 -lz -lws2_32 -lgdi32 > > the "-shared-libgcc" flag seems out of place. ;) And would cause the appearance of -static-libgcc to seem not to work when in essence it was told to ignore it. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Dev mails on mingw-w64-public
On Wed, Aug 1, 2012 at 3:51 PM, Ozkan Sezer wrote: > >> you look on http://sourceforge.net/projects/mingw-w64/, under the >> "Mailing Lists" link, there are three lists only, mingw-w64-documentation, >> mingw-w64-ironcrate and mingw-w64-public. No trace of a developers list. >> > > I think it is visible only when you are logged into sf.net. > No. Maybe if your one of the project members but only the three Corinna mentions is visible logged in or not. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
[Mingw-w64-public] genidl ??
List, I've been trying to find a proper use of the genidl tool. If you wish contact me off list for it. I've seen the documentation but how does one find proper enabled files? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] genidl ??
On Fri, Aug 3, 2012 at 2:54 PM, Kai Tietz wrote: > Hope this helps a bit about this tool, Yes, thank you. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
[Mingw-w64-public] strtod("NAN", &endp) not return QNAN
I need some math whiz help. So it seems to me that strtod("NAN",
NULL) should return the same as __builtin_nan(""). And G++ should
return the same result as GCC. For the GCC instance I believe that
the crt/gdtoa/strtodnrp.c code is wrong. For the G++ instance I
believe stdlib.h isn't correct. Can someone help me debug the
strtodnrp.c issue?
// -nan-test.c-
#include
#include
#include
int main()
{
char *endp;
printf("strtod(NAN) = %f, nan('') = %f\n", strtod("NAN", &endp),
__builtin_nan(""));
return 0;
}
-// --end nan-test.c---
$ gcc -o nan-test nan-test.c
$ ./nan-test
strtod(NAN) = -1.#IND00, nan('') = 1.#QNAN0
$ g++ -o nan-test nan-test.C
$ ./nan-test
strtod(NAN) = 0.00, nan('') = 1.#QNAN0
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
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] GCC 4.6.3-1-release and Clang 3.1 release by rubenvb
On Wed, Aug 8, 2012 at 5:56 AM, Ruben Van Boxem wrote: > PS: I investigated the implications of the -march=nocona option and it seems > this is unfortunately also passed to runtime libraries. It is not a general > cause for concern; only libgfortran contained 3 calls to an SSE3 > instruction, all the rest did not have any SSE3 instructions embedded. I am > doubly disappointed: there seems to be no option to pass optimizations only > for the compiler executables and not runtime libs (for both cross and native > compilers), and SSE3 seems to have little to no effect whatsoever. Only the > 32-bit fortran runtime dll might not work on non-SSE3-enabled CPUs. You could achieve this by tedious process of individually building the runtime libraries prior to building the compiler. I don't think it is worth the extra work and would rather let users of older computers compile their own or use older distributions from the period age of the users computer. However, there is always the ignorant who seem to want to use cutting edge software on over-the-hill computers and bite themselves in the process derriere. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] strtod("NAN", &endp) not return QNAN
On Wed, Aug 8, 2012 at 11:01 AM, Kai Tietz wrote:
> 2012/8/4 Earnie Boyd :
>> I need some math whiz help. So it seems to me that strtod("NAN",
>> NULL) should return the same as __builtin_nan(""). And G++ should
>> return the same result as GCC. For the GCC instance I believe that
>> the crt/gdtoa/strtodnrp.c code is wrong. For the G++ instance I
>> believe stdlib.h isn't correct. Can someone help me debug the
>> strtodnrp.c issue?
>
> Well, the issue here about strtod is, that mingw-w64 uses msvcrt's
> variant. So you would need to pass '1.#IND' or '1.#QNAN' (+/- NaN)
> for your test. If we teach gdtoa's __strtodg to handle also MS'
> Inf/Nan syntax, then we could indeed simply override in both cases
> msvcrt's strtod.
>
> So sorry, test shows expected behavior.
The expected behavior for __strtod from gdtoa is to return 1.#IND0 for
"NAN" input? That doesn't sound correct.
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
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] Position independent code (-fPIC) on x86_64 Windows dll specially for Cygwin
On Wed, Aug 8, 2012 at 1:33 PM, dashesy wrote: > BTW, this is the line in Wikipedia "64-bit Windows has switched to > using position-independent code for DLLs as well and has abandoned > relocation" > And it references here: http://msdn.microsoft.com/en-us/magazine/bb985017.aspx For 64 bit binaries. Not for 32 bit binaries running in the emulator. But does binutils support it for 64 bit binaries? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] strtod("NAN", &endp) not return QNAN
On Wed, Aug 8, 2012 at 1:52 PM, Kai Tietz wrote: > Found the cause for this. This was caused by dg_qnan.h header ... I > really should get rid of this gdtoa ... > > Revision 5361 fixes this problem. > > Thanks for reporting, The thanks belongs to you for fixing it. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] strtod("NAN", &endp) not return QNAN
On Wed, Aug 8, 2012 at 3:29 PM, Earnie Boyd wrote: > On Wed, Aug 8, 2012 at 1:52 PM, Kai Tietz wrote: >> Found the cause for this. This was caused by dg_qnan.h header ... I >> really should get rid of this gdtoa ... >> >> Revision 5361 fixes this problem. >> >> Thanks for reporting, > > The thanks belongs to you for fixing it. FYI, you have a typo in the ChangeLog. 2012-08-08 Kai Tietz * gdtoa/dg_qnan.h: Make Nan constants positive valued. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] #include causes formatting problems with PRId64
On Wed, Aug 8, 2012 at 3:49 PM, Ruben Van Boxem wrote:
>
> Further reduction to (removed unistd.h):
> #define __STDC_FORMAT_MACROS
> #include
> #include
> #include
> #include
> #include
> int main(int argc,char **argv)
> {
>uint64_t val=1234567890;
>printf("%"PRId64"\n",val);
>exit(0);
> }
>
> produces this warning with x86_64-w64-mingw32 clang 3.1:
> test.cpp:10:14: warning: invalid conversion specifier 'I'
> [-Wformat-invalid-specifier]
>printf("%"PRId64"\n",val);
>~~^
> M:/Development/mingw64/bin/../lib/clang/3.1/../../../x86_64-w64-mingw32/include\inttypes.h:42:17:
> note:
> expanded from macro 'PRId64'
> #define PRId64 "I64d"
> ^
> And also a (different) warning with GCC x86_64.
>
> Is this also a bug (in Clang)?
>
Maybe add -Wno-pedantic-ms-format for it?
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
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] experimental 4.7 std::thread enabled build by rubenvb
On Sat, Aug 11, 2012 at 8:20 AM, Martin Mitáš wrote: > > Dne 11.8.2012 12:26, Ruben Van Boxem napsal(a): >> Would you mind conjuring up a small test case (dll .c file, main.c >> file and compile options)? dllexport/dllimport of normal functions >> should work (dllexport of C++ classes is WIP). I *seem* to remember >> using a Clang-built GSL DLL once before, but I may be mistaken. > > The goal (corresponding to the uriginal case) is to output a DLL where > __stdcall > symbols are exported without the decoration as Windows system DLLs do. > __stdcall 32bit windows always decorates with @BYTES where @BYTES is the number of arguments times four bytes. __stdcall 64bit windows changed it so no @BYTES is in the exported symbols. If you don't want @BYTES in the exported symbol then you should use __cdecl instead. However, ld has an option --kill-at that will remove the @BYTES from the exported symbols but you may not be happy with it, don't know since I haven't used it. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Noob question about headers
On Tue, Aug 14, 2012 at 3:59 PM, Greg Dove wrote: > Hi, a recent starter with mingw64is it right or wrong to patch the > header files in mingw to get something to compile? > > I had to patch winsock2.h with some #defines from winsock.h to get ocaml to > compile under mingw64. Is that an ocaml problem or mingw64 problem? > > I had errors when building ocaml with undeclared SO_OPEN_TYPE and > SO_SYNCHRONOUS_NONALERT (iirc) > > anyhow I pasted (from winsock.h) into winsock2.h : > No, this isn't correct. Simply #include to get the definitions. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Conflicting declaration of getcwd in io.h
On Fri, Aug 17, 2012 at 6:12 AM, Jacek Caban wrote: > > That's a good question, it seems like MSVC has only one declaration in > direct.h. I don't know why do we have it duplicated in io.h. IMO we > should consider removing it from there, leaving only direct.h version. My guess is that the MS direction changed. MSDN states for getcwd "This POSIX function is deprecated. Use the ISO C++ conformant _getcwd instead." And both getcwd and _getcwd state "This API cannot be used in applications that execute in the Windows Runtime. For more information, see Windows Runtime Unsupported CRT Functions." How does one know when they are "in the Windows Runtime"? I.E. How can we guard against an application using the CRT functions that are not supported "in the Windows Runtime"? http://msdn.microsoft.com/en-us/library/hh674596.aspx -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] rubenvb 4.7.1-2-release build
On Fri, Aug 17, 2012 at 4:18 AM, Ruben Van Boxem wrote: > (I'm not entirely sure what the "c++" executable is > or does) It is a symlink or copy of g++. The same is true for gcc and cc. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Conflicting declaration of getcwd in io.h
On Fri, Aug 17, 2012 at 9:37 AM, Ozkan Sezer wrote: >> information, see Windows Runtime Unsupported CRT Functions." How does >> one know when they are "in the Windows Runtime"? I.E. How can we >> guard against an application using the CRT functions that are not >> supported "in the Windows Runtime"? >> > > Forgive my ignorance, but can someone point me to the > definition of being "in the Windows Runtime"? > I was trying to discover after my question. The best write up for it I've found thus far is http://en.wikipedia.org/wiki/Windows_Runtime. The MSDN reference is http://msdn.microsoft.com/en-us/library/windows/apps/br211377.aspx which doesn't give much. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] printf + long long on GCC 4.7.1
On Tue, Aug 21, 2012 at 2:35 PM, Greg Peele wrote: > > If this is a spurious warning, I can use -Wno-format to suppress it (this > inline method gets included a LOT of places in my code) but of course that > loses the ability of using that warning as a legitimate way to warn about > printf bugs. > IIRC, you want -Wno-pedantic-ms-format instead. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] printf + long long on GCC 4.7.1
On Tue, Aug 21, 2012 at 3:11 PM, Greg Peele wrote: > > >> Date: Tue, 21 Aug 2012 14:46:51 -0400 >> From: ear...@users.sourceforge.net >> To: mingw-w64-public@lists.sourceforge.net >> Subject: Re: [Mingw-w64-public] printf + long long on GCC 4.7.1 >> >> On Tue, Aug 21, 2012 at 2:35 PM, Greg Peele wrote: >> > >> > If this is a spurious warning, I can use -Wno-format to suppress it >> > (this >> > inline method gets included a LOT of places in my code) but of course >> > that >> > loses the ability of using that warning as a legitimate way to warn >> > about >> > printf bugs. >> > >> >> IIRC, you want -Wno-pedantic-ms-format instead. > > Tried that and no effect on the warning. Here's my actual GCC command line > so I can check I'm not accidentally re-enabling something: > > F:\mingw64-gcc471\bin\g++.exe -Wall -Werror=return-type -m64 > -fno-enforce-eh-specs -Wno-pedantic-ms-format -fexceptions -frtti -O3 > -fomit-frame-pointer -DNDEBUG http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html -Wno-pedantic-ms-format (MinGW targets only) Disables the warnings about non-ISO printf / scanf format width specifiers I32, I64, and I used on Windows targets depending on the MS runtime, when you are using the options -Wformat and -Wpedantic without gnu-extensions. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] mingw-w64 CRT is ABI compatible with CRT from the mingw.org project?
On Wed, Aug 29, 2012 at 6:17 PM, JonY wrote: > On 8/30/2012 05:58, niXman wrote: >> Hello, >> >> Can it be affirmed that mingw-w64 CRT built in 32 bit mode is ABI >> compatible with CRT from the mingw.org project? >> In other words, I am interested if there will appear problems when >> using boost(for example) built with the compiler from mingw.org in the >> project that uses the mingw-w64 CRT, and vice versa? >> Is there any difference how boost is built - dynamically or statically? >> >> > > No, it is not compatible. Do not mix compiled code between the 2. > Dynamic or static will not matter. You didn't say why; I assume it has to do with sjlj versus dwarf2, is that correct? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Add VS2012 CRT support
On Wed, Sep 12, 2012 at 9:02 AM, Dongsheng Song wrote: > > Oh, My automake is 1.11.6, mingw-w64 use 1.12.2. please re-generate > Makefile.in yourself. > My preference is to not store the auto generated files in the repository and have the configuration set to ignore the generated files so the generated diff file would not contain the changes to the generated files. Is there a reason for the generated files in the repository? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] 'strip.exe has stoped working'
On Thu, Sep 13, 2012 at 12:46 PM, CanisMajorWuff wrote: > strip -x lib/libglew32.a > make: *** [lib/libglew32.a] Error 5 Permission denied. > > And a window with text "strip.exe has stoped working". Does somebody know > what can be wrong? > I'm guessing antivirus software or other BLODA. http://cygwin.com/acronyms/#BLODA -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] 'strip.exe has stoped working'
On Thu, Sep 13, 2012 at 1:36 PM, CanisMajorWuff wrote: > I don't know what is BLODA, and I did not understand from the description > how it could influence to stip work. But I removed the cygwin binaries from > path. I did not give any effect. BLODA doesn't affect just Cygwin, the Big List Of Dodgy Apps is updated on their FAQ. Did you see the list from the link I gave you earlier? http://cygwin.com/faq/faq.using.html#faq.using.bloda > If this is antivirus why the previous invocation of strip worked fine: > strip -x lib/glew32.dll > You got lucky. I suspect it has to due with the fact that the antivirus has the file open and so strip cannot remove the file to replace it. As I state, it is a guess since I don't have any other information to go on. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] 'strip.exe has stoped working'
On Thu, Sep 13, 2012 at 2:34 PM, CanisMajorWuff wrote: > I don't any antivirus software on my Windows Home Premium. > If some Windows component scans newly created files, then I tried this > command 'strip -x lib/glew32.dll' by myself in several minutes after > creation. > Does something have the file open? You are receiving permission denied errors because the file cannot be removed. I don't know if the --verbose option will help you find it but you can try it. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] fgrep.exe (MSYS) - Trojan.Packed.140
On Sun, Sep 16, 2012 at 3:04 PM, CanisMajorWuff wrote: > Hi, > > My antivirus (Dr.Web) tells me that fgrep.exe in MSYS package is a > trojan ( Trojan.Packed.140). Are you aware of this issue? Either Dr. Web has a false positive or you have infected the file locally. File a support issue with Dr. Web. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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] Problem with mingw32-make and long commands (x86_64-w64-mingw32-gcc-4.7.2-release-win64_rubenvb)
On Fri, Sep 28, 2012 at 11:17 AM, Ruben Van Boxem wrote: > > That's interesting. I'll check out mingw-builds' patches. > --8<-- > > True, but at least all CMake generated Makefiles work great as well. Maybe > you could push for better MinGW support in jom ;-). > > I'll try to get a complete CVS GNU make checkout. Anyone on the list know > how to resurrect dead files from a CVS repo? Or if there is a good svn > mirror, or perhaps a near-complete GNU make clone other than jom? Here is an interesting thread http://lists.gnu.org/archive/html/make-w32/2012-05/msg0.html which is the patch niXman used for mingw-builds. -- Earnie -- https://sites.google.com/site/earnieboyd -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? 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
[Mingw-w64-public] SEH
Please forgive my laziness as not having enough time yet to download and format an environment with 4.8 GCC as yet. Is there a predefined macro to indicate when I have SEH support? -- Earnie -- https://sites.google.com/site/earnieboyd -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? 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] [Mingw-users] The difference between pe and pei ?
On Thu, Oct 11, 2012 at 11:51 PM, Dongsheng Song wrote: > Hi, > > What's the difference between pe and pei ? > > I see: > > ld: supported targets: pe-i386 pei-i386 pe-x86-64 pei-x86-64 ... > ld: supported emulations: i386pe i386pep > > When I use 'gcc.exe -m32 example.c', which target file format generated ? > i386pe, i386pep, pe-i386 or pei-i386 ? > > When I use 'gcc.exe -m64 example.c', which target file format generated ? > pe-x86-64 or pei-x86-64 ? > > For mingw-w64 tool chain, which format preferred ? You might want to ask the mingw-w64-public list. Though Kai can answer here if he chooses. -- Earnie -- https://sites.google.com/site/earnieboyd -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-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] Detect mingw
On Tue, Oct 16, 2012 at 5:24 AM, Ruben Van Boxem wrote: > __MINGW64__ only really signifies x64 Windows and MinGW. I bet that if > MinGW.org ever come with a 64-bit variant (not likely), they'd define this > for consistency (just as MinGW-w64 does). Since it is defined by the compiler, of course a MinGW.org provided 64-bit compiler would define it. The "(not likely)" is not likely true. ;p -- Earnie -- https://sites.google.com/site/earnieboyd -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-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] conflicting types?
On Fri, Oct 19, 2012 at 3:19 PM, Roger Pack wrote: >>> Who is defining const as an empty macro? That doesn't seem right. >> >> >> C++ only makes it undefined behavior, and the rules are fuzzy at best (seems >> that it's only undefined behavior when the translation unit includes a >> standard header): >> http://stackoverflow.com/questions/2726204/c-preprocessor-define-ing-a-keyword-is-it-standards-conforming >> >> In C, it seems that it is allowed. >> >> All this doesn't change the fact that #define const is incredibly stupid and >> should be removed from user code. > > Agree. > My confusion though is still why, with the same include (windows.h) in > 64 bit it also loads intrin.h, but not in 32 bit. odd... It is most likely because _WIN64 takes on different characteristics. I.E. The same path isn't followed in the header code when _WIN64 is defined. -- Earnie -- https://sites.google.com/site/earnieboyd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_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] RFC: How shall we plan releases of new major
On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote: > Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible > unless you stick strictly to C. Like Kai says, C++ support comes from > GCC libstdc++, fortran support from libgfortran etc. You should have no > legal problems distributing these DLLs with your programs in anyway. As long as the source of those DLL libraries is also distributed. Distributing binaries of GPL code (LGPL is GPL with an exception for binary use) requires you to also distribute the source for those binaries; there is never an exception for that. -- Earnie -- https://sites.google.com/site/earnieboyd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_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] RFC: How shall we plan releases of new major
On Fri, Oct 26, 2012 at 8:05 AM, Ruben Van Boxem wrote: > 2012/10/26 Earnie Boyd >> >> On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote: >> > Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible >> > unless you stick strictly to C. Like Kai says, C++ support comes from >> > GCC libstdc++, fortran support from libgfortran etc. You should have no >> > legal problems distributing these DLLs with your programs in anyway. >> >> As long as the source of those DLL libraries is also distributed. >> Distributing binaries of GPL code (LGPL is GPL with an exception for >> binary use) requires you to also distribute the source for those >> binaries; there is never an exception for that. > > > IANAL, but I can read. > > Stop spreading FUD. The GCC runtime libraries fall under a special exception > which is very liberal, as JonY intended to make unambiguously clear. Read up > on the subject here. The FAQ clearly states you can create proprietary > programs with these libraries as long as you don't use a non-GPL compatible > GCC plugin to do code generation. It even explicitly states that you can > combine code generated by the Intel compiler with GCC-generated code, and > still be able to use the exception to just redistribute the runtime > libraries alongside your binaries. This has nothing to do with the license > of the code actually being compiled and linked. IANAL either but I am not spreading FUD. The exception covers the use and not the distribution. If you don't believe me ask Richard Stallman. http://www.gnu.org/licenses/gcc-exception-3.1-faq.html";> I use a proprietary compiler toolchain without any parts of GCC to compile my program, and link it with libstdc++. My program itself does not include any runtime library code the same way that GCC-compiled programs include libgcc. Can I still take advantage of the exception? Yes. While combining libgcc with GCC-compiled object code is probably the most common way the exception is used, neither the GPL nor the GCC Runtime Library Exception distinguish between static linking, dynamic linking, and other methods for combining code in their conditions. The same permissions are available to you, under the same terms, no matter which method you use. Note that if you distribute libstdc++ as an independent library, you will need to follow the terms of the GPL when doing so. For example, if you distribute the library itself in object code form, you will need to provide source code to your recipients using one of the methods listed in section 6 of GPLv3. But as long as you are eligible to take advantage of the GCC Runtime Library Exception's permissions for your own program, the GPL's terms do not extend to it. -- Earnie -- https://sites.google.com/site/earnieboyd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_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] RFC: How shall we plan releases of new major
On Fri, Oct 26, 2012 at 9:04 AM, Ruben Van Boxem wrote: > > And that Section 6 clearly states you can point to e.g. the GCC website for > the source code: > http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites > > So absolutely no end-developer hassle in providing toolchain source code is > required. Well there is some hassle and you must take care to make sure that the source remains available for as long as you distribute the object code. The only way to do that for a guarantee is to have the sources handy to distribute in the event the sited source removes their files or goes away for any length of time. The question is also stated in such a manner that *you* are the one controlling both sites; i.e. the answer to the question doesn't eliminate your responsibility to provide the source. -- Earnie -- https://sites.google.com/site/earnieboyd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_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] RFC: How shall we plan releases of new major
On Fri, Oct 26, 2012 at 11:39 AM, Ruben Van Boxem wrote: > > I also don't think a static runtime link changes any of this, TDM. >From the > same FAQ as before: > "neither the GPL nor the GCC Runtime Library Exception distinguish between > static linking, dynamic linking, and other methods for combining code in > their conditions" > > So I doubt your forced static runtime linking affects any of this. The static linking reduces the need to distribute the shared library. It is the shared library whose source needs distributed when you distribute the shared library. -- Earnie -- https://sites.google.com/site/earnieboyd -- The Windows 8 Center In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFC: How shall we plan releases of new major
On Fri, Oct 26, 2012 at 11:54 AM, Ray Donnelly wrote: > On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen wrote: >> On Oct 26 16:10, Ray Donnelly wrote: >>> I've never seen any precedent of anyone ever doing this anywhere. >>> >>> Are you saying we are all in violation here? If so, 'we' includes a >>> huge amount of developers and applications (every Windows C++ >>> application built with GCC!) >> >> No, that's not the case. This is the kind of FUD which is spread >> way too often, unfortunately. There's an important difference here. >> >> Assuming you create a Linux application which is linked against glibc, >> then you can provide binaries of your application, as well as sources if >> it's an open source project, at your sole discretion. There's no reason >> to provide glibc together with your application since you can be pretty >> sure that glibc exists on any target computer. >> >> But what if you *do* provide glibc together with your application? In >> that case you provide a binary of a (L)GPLed product. Now that you >> provide this binary, you're also required to provide the sources for >> that binary since your user has the right to get the sources as well. >> >> Keep in mind that the GPL is a user-centric license. In a way, you as >> developer are not the beneficiary of this license, but the user of the >> product is, by making sure that the user retains the right to see the >> sources of the product, whoever distributes that product. >> >> Does that make the situation clearer? >> > > No, less clear, you've said that I've just spread some FUD, then > appear to repeat exactly what I said. > > In your response, s/glibc/libstdc++.dll/ to see what I mean! > > I build a Qt application (Necessitas Qt Creator) for Windows and we > distribute it with libstdc++-6.dll, so from what I'm gathering, we > should also be providing the sources for this? > > Many thanks for increasing the U factor in FUD! I understood Corinna to mean "This is the kind of FUD" relative to the "you don't need to distribute source, just point somewhere else" FUD and the reason I butted in. If you distribute libstc++-6.dll then yes you need to distribute the source that created it. -- Earnie -- https://sites.google.com/site/earnieboyd -- The Windows 8 Center In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFC: How shall we plan releases of new major
On Fri, Oct 26, 2012 at 12:27 PM, Ruben Van Boxem wrote: > > Also, can someone clarify that you only need to be able to provider the > source when asked for it vs providing it in some public place, which might > not even be reachable everywhere in the world? AIUI, at least for v2 of the license, you need to be able to provide the source for the exact version the user has in possession via the same media that the binary was delivered when asked for it. It is easier if you just deliver the source and the same time you deliver the binary since you can tell the user he already has the source. -- Earnie -- https://sites.google.com/site/earnieboyd -- The Windows 8 Center In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] strerror_s problem
On Thu, Nov 1, 2012 at 10:38 AM, Ruben Van Boxem
wrote:
> Dear list,
>
> Using MinGW-w64 v2.0.7 and my 4.7.2 toolchain, I get a build failure in LLVM
> related to strerror_s.
> It performs a CMake check to see if the function is declared, and finds it
> (I configured the headers with --enable-secure-api as always) so it defines
> the config.h guard macro.
>
> When the function is used in C++ code though, it is not found.
>
> I reduced this to
>
> #include
>
> void f()
> {
> strerror_s("bla",3,4);
> }
>
> which, when compiled as C++, gives the error of no strerror_s declared, but
> when compiled as C, works fine.
>
> This looks like a pure MinGW-w64 bug, what can I do to fix it?
Is it properly wrapped in the extern C { } when __cplusplus is
defined? Is __cplusplus defined correctly?
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_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] strerror_s problem
On Thu, Nov 1, 2012 at 11:02 AM, Ruben Van Boxem wrote: > > The first I don't know, the second is obviously yes; the compiler takes care > of that. Compilers are programs that can contain bugs. > I don't think declarations are influences by extern "C" though. Yes it matters. The name mangling is different. > Only linkage is affected, and I get a compile error. Because the C++ mangled name doesn't exist in the library. -- Earnie -- https://sites.google.com/site/earnieboyd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_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] strerror_s problem
On Thu, Nov 1, 2012 at 11:27 AM, Ruben Van Boxem wrote: > I get a compile-time error. Browsing the SVN data, try including strings.h instead of string.h. See http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-headers/crt/string.h?revision=1520&view=markup&sortby=rev&pathrev=5092 -- Earnie -- https://sites.google.com/site/earnieboyd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
