On Tue, Oct 8, 2013 at 7:38 AM, Incongruous wrote:
> Humm... JonY, Right now I don't have the time to migrate to any other Mail
> Reader; I think Microsoft finally did something extremely good when it came
> to created Outlook.
> Thanks for the info kids, I will keep double-clicking on the text at
On Sun, Sep 29, 2013 at 7:58 AM, Ruben Van Boxem wrote:
> It's MinGW:
> Minimalistic GNU for/on Windows
>
> Personally, I think it's a crappy name, as it fails to describe what it
> really is :-) "Open Windows Runtime" or something would be a lot more
> descriptive.
> - Have you installed OWR yet?
On Tue, Sep 24, 2013 at 2:15 PM, Kai Tietz wrote:
>
> The binary-mode is default behavior for mingw-w64. So of course there
> is no difference in using binmode.o object. That we install this
> object-file at all is IMHO a bug, or better said useless.
>
Why was this decision made? It seems a bi
On Thu, Sep 19, 2013 at 9:06 AM, Incongruous wrote:
> I would assume that Win32 and posix refers to the threading technology used,
> but what does the part after the hyphen mean?
The exception handling technology; especially as it relates to unwinding.
--
Earnie
-- https://sites.google.com/site/
On Mon, Sep 16, 2013 at 3:53 AM, niXman wrote:
> 2013/9/14 Jon:
>> On Sat, Sep 14, 2013 at 9:44 AM, Ruben Van Boxem
>>> I think you guys are missing the main problem: the fact that for the last
>>> half year, trunk was necessary to build the latest GCC version. I'm
>>> confident the whole trunk sta
On Fri, Sep 13, 2013 at 8:49 AM, John E. / TDM wrote:
> On 9/13/2013 1:28 AM, Adrien Nader wrote:
>> On Thu, Sep 12, 2013, John E. / TDM wrote:
>>> This is absolutely the case. The pthreads-win32 library is LGPL, forcing
>>> the distribution of its source code along with all binary distributions
>
On Wed, Jul 31, 2013 at 3:47 PM, Kai Tietz wrote:
> 2013/7/31 Baruch Burstein :
>> On Wed, Jul 31, 2013 at 9:49 PM, Kai Tietz wrote:
>>>
>>> 2013/7/31 Earnie Boyd :
>>> > On Wed, Jul 31, 2013 at 8:21 AM, Kai Tietz wrote:
>>> >>
>>> &
On Wed, Jul 31, 2013 at 8:21 AM, Kai Tietz wrote:
>
> As there never was, and won't be in next future a target with ending
> ...mingw64 in triplet.
>
That statement maybe here but not at MinGW.org. The x86_64-pc-mingw64
triplet is contained in the config master repository.
--
Earnie
-- https://
On Wed, Jul 31, 2013 at 5:52 AM, JonY wrote:
> On 7/31/2013 17:21, Baruch Burstein wrote:
>> The latest version of config.guess, when run on MSYS2 64bit (posted
>> elsewhere on this list) with ruben's 64bit native compilers reports:
>> x86_64-pc-mingw32
>>
>> I recall somewhere that the correct tri
On Sat, Jul 20, 2013 at 10:15 AM, Ozkan Sezer wrote:
> On Sat, Jul 20, 2013 at 4:58 PM, Ruben Van Boxem
> wrote:
>> Hi,
>>
>> Although I am not strictly against it, it seems the MinGW-w64 files tree has
>> dramatically changed, invalidating any old links to files.
>>
>> I'd appreciate if something
On Mon, Jul 15, 2013 at 2:09 PM, Alexey Pavlov wrote:
> 2013/7/15 Jon :
>> On Mon, 15 Jul 2013 11:02:20 +0400
>> niXman wrote:
>>
>>> 2013/7/15 Jon:
>>> > When I build C apps with mingwbuilds 4.8.1-win32-sjlj, the built
>>> > artifacts have a runtime dependency on
>>> > `libgcc_s_sjlj-1.dll`. This
On Wed, Jul 3, 2013 at 12:28 PM, Dongsheng Song wrote:
> On Thu, Jul 4, 2013 at 12:09 AM, Kai Tietz wrote:
>> That is a known issue of ld for pe-coff. If at least one symbol is
>> exported by dllexport, only those symbols are. If there is none, then
>> all symbols getting exported.
>>
>
> Just f
On Thu, Jun 27, 2013 at 12:11 PM, Rafaël Carré wrote:
> Le 27/06/2013 17:17, Earnie Boyd a écrit :
>> On Thu, Jun 27, 2013 at 10:21 AM, Rafaël Carré wrote:
>>> However ___lc_codepage_func seems to be also present in msvcrt.dll so
>>> why do we need emul?
>>
On Thu, Jun 27, 2013 at 10:21 AM, Rafaël Carré wrote:
> However ___lc_codepage_func seems to be also present in msvcrt.dll so
> why do we need emul?
That depends on the version of MSVCRT.DLL on the users system. It is
emulated to avoid conflicts at runtime.
--
Earnie
-- https://sites.google.com
On Sun, Jun 23, 2013 at 3:07 PM, Alexey Pavlov wrote:
> 2013/6/23 Baruch Burstein
>>
>> And of course, as expected. I just went to try the mingw-builds, and
>> downloaded their recommended installer (the download button on the front
>> page), and when tried to run it, it didn't work (couldn't downl
On Thu, Jun 20, 2013 at 9:06 AM, Dongsheng Song wrote:
>
> I want to build gcc 4.8 with isl and cloog, can I put isl and cloog
> to gcc/branches/gcc-4_8-branch/ like gmp/mpfr/mpc ?
>
You should be able to determine that by looking at the top level
configure script. IIRC, it will look for other c
On Thu, Jun 6, 2013 at 1:20 PM, Kai Tietz wrote:
> Hello everybody,
>
> Please be aware. Project update happend by SourceForge recently. It
> wasn't wished by us. Nevertheless we have to live by that.
>
Since I've lived through this nightmare already I have one word of
advice; be cautious of yo
On Sun, Jun 2, 2013 at 11:22 AM, John E. / TDM wrote:
> On 6/2/2013 6:08 AM, Ruben Van Boxem wrote:
>> I also could not find any GNU make related build or patch stuff in the
>> TDM source packages, although mingw32-make is part of the binary package.
>
> For the TDM toolchain, the installer just pu
On Sat, May 4, 2013 at 3:19 AM, NightStrike wrote:
>
>
> On Friday, May 3, 2013, Earnie Boyd wrote:
>> On Thu, May 2, 2013 at 10:05 PM, Jim Michaels wrote:
>>>
>>> sorry, my yahoo mail can only top-post, so don't email me about that.
>>> still
>&
On Thu, May 2, 2013 at 10:05 PM, Jim Michaels wrote:
>
> sorry, my yahoo mail can only top-post, so don't email me about that. still
> investigating this problem.
Yahoo mail has nothing to do with TOP posting. You have to configure
and maneuver the cursor in the mail but it works just the same.
On Thu, Apr 11, 2013 at 6:08 AM, Corinna Vinschen wrote:
> On Apr 11 09:38, Ruben Van Boxem wrote:
>> 2013/4/11 G M
>>
>> > Hi Ruben
>> >
>> > Thanks for replying. :)
>> >
>> > That's because from the pasted code shows the file and the line and an
>> > array access:
>> >
>> >
>> > c:/mingw/bin/../l
On Wed, Apr 3, 2013 at 6:08 AM, Ahso Aa wrote:
>> Are all dependencies compiled with the same toolchain?
>
> No I don't think so
>
Then this is the most likely candidate of issue. ABI differences can
and will cause you problems.
--
Earnie
-- https://sites.google.com/site/earnieboyd
On Mon, Apr 1, 2013 at 5:35 AM, G M wrote:
> It does work as long as the destination directory already exists.
> But I am thinking it might not work if a file (as opposed to a directory) is
> being copied and the destination directory doesn't exist, then I am
> concerned that what might happen is t
On Fri, Mar 29, 2013 at 9:42 AM, Jon wrote:
>> > I'm toying with lzo on Windows 7 32-bit (mingwbuilds 4.8.0 and rubenvb
>> > 4.7.2) and want to create a solid patch for configure.ac, but my autoconf
>> > fu hovers around the nano-fu level. While the failure is not a mingw-w64
>> > bug, you guys li
On Fri, Mar 29, 2013 at 9:13 AM, Earnie Boyd wrote:
>
> Caution: MSYSTEM=MINGW64 will be used for identifying
> i86_64-pc-mingw64 in config.guess; I submitted a patch for it to the
> maintainers of config.guess and config.sub last year.
Lacking the caffeine this morning s/i
On Fri, Mar 29, 2013 at 8:55 AM, LRN wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 29.03.2013 15:15, Алексей Павлов wrote:
Question #2: If MinGW64 'uname' will not be available any time
soon, is there any problem in using the --build option when
you configure?
>>> I
On Sat, Mar 23, 2013 at 3:52 AM, Ruben Van Boxem
wrote:
> 2013/3/23 Ruben Van Boxem
>>
>> Hi,
>>
>> I'm trying to get GCC 4.8 built, but I run into this error:
>> libtool: compile: /home/ruben/mingw-w64/linux64mingw32/gcc/./gcc/xgcc
>> -B/home/ruben/mingw-w64/linux64mingw32/gcc/./gcc/
>> -L/home
On Fri, Mar 15, 2013 at 12:28 AM, Mook wrote:
> On 3/14/2013 8:48 AM, Earnie Boyd wrote:
>> I've noticed some saying the SF archives search blows, here is an
>> alternative using Google:
>>
>> "mingw-w64-public"+SearchItem+SearchItemN
>> site:sourc
I've noticed some saying the SF archives search blows, here is an
alternative using Google:
"mingw-w64-public"+SearchItem+SearchItemN
site:sourceforge.net/mailarchive/forum.php
--
Earnie
-- https://sites.google.com/site/earnieboyd
On Mon, Mar 4, 2013 at 10:42 AM, Sebastian Wolff wrote:
> Although little off-topic, one questions remains to me: Is it allowed to
> distribute proprietary software which links against libgcc statically?
http://www.gnu.org/licenses/gcc-exception-faq.html
--
Earnie
-- https://sites.google.com/sit
On Mon, Mar 4, 2013 at 7:50 AM, Sebastian Wolff wrote:
> I also checked all DLLs in Dependency Walker. The following DLLs reference
> msvcrt.dll: advapi32.dll, comdlg32.dll, netapi32.dll, ole32.dll,
> oleaut32.dll, ws2_32.dll
> Comparing this with the VC++-built executable gives similar implicit
>
On Mon, Mar 4, 2013 at 5:01 AM, Sebastian Wolff wrote:
>
> I modified the specs according to the Jon's summary of your recommendations,
> i.e.:
> - use -lmsvcr90 instead of -lmsvcrt
> - use -static
> - avoid linking against -lmoldname
> - use the define -D__MSVCRT_VERSION__=0x0900 when compiling *.
On Sat, Mar 2, 2013 at 1:15 PM, Jon wrote:
>> > There is one problem: There is no liboldname90 in Mingw-w64, hence I kept
>> > liboldname.
>> Yes, for what purpose you need it?
>
> I'm updating my 32/64bit build systems to better automate how I use
> mingw/mingw-w64, and have three followup questi
On Thu, Feb 14, 2013 at 9:37 AM, Baruch Burstein wrote:
> I know nothing about this, I just wanted to comment that the error:
>
> error: 'long long long' is too long for GCC
>
> Had me laughing out loud.
LOL
Q: How many longs does it take to be too long?
A: Only one more long than not too long.
On Wed, Feb 6, 2013 at 8:32 AM, K. Frank wrote:
> I'm going to go with the working assumption that I can use two
> threads with a winsock socket, but I'll keep my eyes open, just
> in case.
You might want to be sure the streams are set to binary mode and be
careful of buffering.
--
Earnie
-- htt
On Tue, Feb 5, 2013 at 8:44 PM, K. Frank wrote:
> Hello List!
>
> Not really a pure mingw-w64 question, but maybe someone here knows
> the answers.
>
> Socket connections go two ways -- you can read from and write to them.
> With a standard windows socket, is it safe to use one thread for reading
>
On Thu, Jan 31, 2013 at 9:31 AM, niXman wrote:
> 2013/1/31 Koehne Kai:
>> the difference is actually in the debugging info: E.g. Qt5Guid.dll for MinGW
>> is a 131 MB big, while MSVC Qt5Guid.dll + Qt5Guid.pdb is just 24 MB.
> Wow оО
>
>> Don't know whether the size of debugging info can be reduced
On Wed, Jan 23, 2013 at 3:22 AM, Ruben Van Boxem wrote:
> 2013/1/23 Xiaofan Chen
>>
>> On Wed, Jan 23, 2013 at 2:58 PM, Jim Michaels wrote:
>> >
>> > and, alas, microsoft has made sp2 unavailable and xp next year is
>> > support
>> > EOL except for embedded. so SP1 users (like me) are out of luck
On Wed, Jan 16, 2013 at 8:35 AM, Ruben Van Boxem wrote:
> I was under the strong impression all MSYS tools were built with a special
> (ancient) MSYS toolchain, which links and compiles in a Cygwin-y way. Maybe
> "goal" was stating it a bit strongly, but in how the MSYS devs saw their
> world takin
On Wed, Jan 16, 2013 at 8:18 AM, Vasileios Anagnostopoulos wrote:
> UWIN anyone?
No thanks, there are better alternatives that aren't closed source.
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
Master Java S
On Wed, Jan 16, 2013 at 3:56 AM, Ruben Van Boxem
wrote:
> 2013/1/16 Ray Donnelly
>>
>> unixy utils built with Boost? Very cool. It'd be nice if an explicit
>> goal was cross compilation on many different OSes.
>>
>> ...but why not pitch in with MSYS2 instead? Your time, your choice, of
>> course;
On Mon, Jan 14, 2013 at 4:39 AM, Алексей Павлов wrote:
> Hey!
> Maybe fork new Cygwin to MSYS2 is the best solution? I am interesting in it
> because MSYS is very old and porting new software for it is very difficult.
> I can help you any way I can. I have Cygwin git repo on
> https://github.com/Al
On Mon, Jan 14, 2013 at 10:16 AM, JonY wrote:
>
> MSYS is pretty bad at path translation, it was what drove me to Cygwin
> in the first place. Perhaps some setting on how aggressive it scans and
> assumes a string as a path is a good idea.
>
> gcc -c abc.c -Dfoo="/bar1/bar2" <- is this a path to t
On Sun, Jan 6, 2013 at 11:35 AM, Ray Donnelly wrote:
> I've had a quick look at the source code and it's littered with stuff like:
>
> #ifdef _MSC_VER
Which is the wrong MACRO to detect Windows build. It is the right
MACRO to detect using MSVC.
> #include
> ...
>
> So the fact is that the code
On Sat, Dec 1, 2012 at 1:47 AM, Vincent Torri wrote:
> On Sat, Dec 1, 2012 at 6:49 AM, NightStrike wrote:
>>
>>
>> Really, I haven't seen any build system that I think is wonderful.
>> autotools works for us, but it's not great. I've used a lot... even
>> scons.
>
> just for curiosity : what do yo
On Thu, Nov 22, 2012 at 4:07 AM, JonY wrote:
>
> See gcc -print-search-dirs, usually in
> $prefix/[x86_64-w64-]mingw32/include and it's sibling lib or lib64 dirs.
>
Or it might be lib or lib32 directories. The TDM distribution puts
the 64bit in lib and 32bit in lib32.
--
Earnie
-- https://sites
On Tue, Nov 20, 2012 at 10:54 AM, Ruben Van Boxem
wrote:
> 2012/11/20 deneme.true
>
>> Thanks for responds.
>>
>> >How did you build your cross compiler? You need a compiler that runs
>> >on 32bit OS but targets 64bit OS.
>>
>> I am using Rubenv's x86_64-w64-mingw32 build:
>>
>> http://sourcefor
On Mon, Nov 19, 2012 at 8:37 AM, Ray Donnelly wrote:
> On Mon, Nov 19, 2012 at 1:32 PM, Earnie Boyd
>>
>> You may need to build it yourself using the GCC sources. I need to
>> create a document for doing this so I can just point to it.
>
> Even better, you could encode
On Sun, Nov 18, 2012 at 1:25 PM, Ruben Van Boxem
wrote:
> 2012/11/5 Yves
>>
>> Hi Ruben,
>>
>> All the while I tried all packages, since I`m still oscillating between 32
>> bit and 64 bit, TDM seemed to be the way to go, at least to compile to
>> compile on Windows for Windows.
>>
>> As far as I
On Sat, Nov 17, 2012 at 6:17 AM, deneme.true wrote:
> Hello,
>
> I am trying to cross-compile wxWidgets library on 32 bit machine for
> Win64. I haven't a 64 bit machine and 64 bit OS. I've seen that linker
> links the object files with 32 bit
How did you build your cross compiler? You need a com
On Tue, Nov 13, 2012 at 8:48 AM, Ruben Van Boxem
wrote:
>
> PS: the opinions expressed in this email do not necessarily coincide with
> the opinions of the MinGW-w64 developers, Microsoft, or any other person
> participating in this discussion ;-)
Ha Ha. Ditto that.
--
Earnie
-- https://sites.g
On Tue, Nov 13, 2012 at 8:01 AM, Ruben Van Boxem
wrote:
> 2012/11/13 Earnie Boyd
>>
>> That doesn't address the side-by-side issue where we need a 32bit
>> executable matching the 64bit executable. What do you propose for
>> 32bit executable path versus the 64bit
On Tue, Nov 13, 2012 at 8:23 AM, Ruben Van Boxem
wrote:
> 2012/11/13 Earnie Boyd
>>
>> On Tue, Nov 13, 2012 at 8:05 AM, Kai Tietz wrote:
>> > As I said before ... "you need to add the target-lib/ folder to you
>> > path".
>> >
>>
>>
On Tue, Nov 13, 2012 at 8:05 AM, Kai Tietz wrote:
> As I said before ... "you need to add the target-lib/ folder to you path".
>
That is unfriendly to the end-user. Note the discussion deals with
more than just GCC it is a deployment of the client code using GCC
that is in discussion. Businesses
On Tue, Nov 13, 2012 at 7:04 AM, Kai Tietz wrote:
> 2012/11/13 Václav Šmilauer :
>>
>>> This is a small question with much more impact as you might expect.
>>> Old style is to put Runtime-DLL files into bin/ directory. This had
>>> some advantages as long as you just have one target to support, bu
On Mon, Nov 12, 2012 at 8:01 AM, Václav Šmilauer wrote:
>
>> Common practice is to put the DLL in the $PREFIX/bin directory and to
>> put the import libraries in $PREFIX/lib. Since it is common practice
>> doing otherwise might upset your users.
> What do you mean by import libraries here? DLLs wh
On Mon, Nov 12, 2012 at 5:58 AM, Václav Šmilauer wrote:
> Hi there,
>
> I would like to ask what the best/recommended practice for installing
> shared libraries under Windows/mingw is. Qt4 for instance installs DLLs
> to both $PREFIX/bin and $PREFIX/lib. I prefer to install to $PREFIX/lib
> and add
On Fri, Nov 9, 2012 at 9:01 AM, Ruben Van Boxem
wrote:
> 2012/11/9 Earnie Boyd
>>
>> On Thu, Nov 8, 2012 at 5:05 PM, JonY wrote:
>> >
>> > There isn't an include directory specifically for win32 and another for
>> > win64. Installing to the same ar
On Thu, Nov 8, 2012 at 5:05 PM, JonY wrote:
>
> There isn't an include directory specifically for win32 and another for
> win64. Installing to the same area will clash as OP predicted.
>
There is only one set of mingw-w64 distributed headers and those
headers contain both Win32 and Win64 filtered
On Thu, Nov 8, 2012 at 10:03 AM, JonY wrote:
> On 11/8/2012 22:49, Václav Šmilauer wrote:
>> Greetings to experienced Mingw64-ers,
>>
>> I am currently compiling several 3rd-party libraries which I need for my
>> code. Among those are glib, VTK, Qt and perhaps several others. I have
>> the (32bit)
On Wed, Nov 7, 2012 at 6:33 AM, Václav Šmilauer wrote:
>
>>> Just for the heck of it, I changed
>>> Python27/lib/distutils/cygwincompiler.py to return "msvcrt" instead of
>>> "msvcr90". It works.
>>>
>>> My question is: do we really need to link our modules to msvcr*, if
>>> python.dll (which we l
On Tue, Nov 6, 2012 at 8:55 AM, K. Frank wrote:
> Hi Jim!
>
> A gentle suggestion ...
>
Oh, don't be too gentle. ;D
> On Tue, Nov 6, 2012 at 5:03 AM, Jim Michaels wrote:
>> somehow I think pointers are the way to go when modifying an iterator
>> function argument. but I am having problems. I hav
On Tue, Nov 6, 2012 at 5:04 AM, Václav Šmilauer wrote:
>
>> I'm hoping my load fail (and the OP's) turns out to be the issue of
>> modules linking against two different CRT versions. PeStudio tells me
>> my msvcrt.dll linked .pyd's try to use _errno, __dllonexit, fflush,
>> free, malloc, and strcm
On Tue, Nov 6, 2012 at 6:50 AM, Zouzou wrote:
>> With this in mind, which package should I use to compile on Windows
>> for Linux?
>> You probably see it coming… which package should I use to compile on
>> Windows for MacOSX?
>>
>> In another words, what solution is there to cr
On Fri, Nov 2, 2012 at 3:01 PM, Jon wrote:
>
> I settled for the "fix" of using mingw.org gcc 4.6.2 32bit but don't
> understand why it works since the 4.6.2 .pyd's still have deps on msvcr90.dll
> and msvcrt.dll...need to try again with a custom spec to force everything to
> msvcr90.dll and try
On Fri, Nov 2, 2012 at 9:42 AM, Ray Donnelly wrote:
>
> I intend my make.exe to (one day) be able to also work from MSYS (by
> hand parsing fstab), cmd.exe and whatever else I can throw it at.
>
Off-topic here but the code already exists, just use it. If you need
to discuss it use the mingw-us...
On Fri, Nov 2, 2012 at 8:51 AM, Ozkan Sezer wrote:
> On 11/2/12, Earnie Boyd wrote:
>> On Fri, Nov 2, 2012 at 4:55 AM, Ozkan Sezer wrote:
>>> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd wrote:
>>>> Browsing the SVN data, try including strings.h instead of string.h.
On Fri, Nov 2, 2012 at 9:19 AM, Ray Donnelly wrote:
> Yeah, that's usually down to the way MSYS bash implements fork-like
> behaviour... It's in intermittent thing, I usually wrap my calls to
> make up with a loop to retry a few times! Horrible I know...
>
> The other (better) fix is to use a make.
On Fri, Nov 2, 2012 at 4:55 AM, Ozkan Sezer wrote:
> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd wrote:
>> 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
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=509
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 i
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-secu
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,
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
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 comb
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 sou
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
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
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
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
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 g
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
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
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.
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
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 Dodg
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:/
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 gene
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(
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 wr
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.
>
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 Runti
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
--
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 dire
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 p
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 *s
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
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.
>>
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.go
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 binarie
1 - 100 of 169 matches
Mail list logo
