Jacek Caban schreef op ma 22-07-2013 om 11:50 [+0200]:
On 07/21/13 23:24, dw wrote:
Attached is the patch I came up with to fix the build issue.
You are checking for defined(__MINGW64_VERSION_MAJOR). Would it make
sense to do (__MINGW64_VERSION_MAJOR = 3)?
IMO, if the change works with
On 7/23/13 10:53 PM, Erik van Pienbroek wrote:
Jacek Caban schreef op ma 22-07-2013 om 11:50 [+0200]:
On 07/21/13 23:24, dw wrote:
Attached is the patch I came up with to fix the build issue.
You are checking for defined(__MINGW64_VERSION_MAJOR). Would it make
sense to do
On 07/21/13 17:02, Erik van Pienbroek wrote:
Erik van Pienbroek schreef op zo 21-07-2013 om 14:49 [+0200]:
So now I think it's up to us to come up with the most proper fix which
we can then try to get upstreamed.
Attached is the patch I came up with to fix the build issue. It is
basically
On 07/21/13 23:24, dw wrote:
Attached is the patch I came up with to fix the build issue.
You are checking for defined(__MINGW64_VERSION_MAJOR). Would it make
sense to do (__MINGW64_VERSION_MAJOR = 3)?
IMO, if the change works with older mingw-w64 release, not checking
version is better. If
I vote for this. Boost can always be fixed, and it contains lots of
ugly hacks around various platform obscurities. I think MSVC
intrinsics combined with GCC are a valid obscurity.
Granted, if Boost is to change, you might as well give them the best
performance while we're at it :)
It's
With this specific define set the boost package can indeed be compiled
without issues (for both the x86 and x64 targets).
Yay!
However, there's a catch! The boost build system doesn't embed this
specific define in its installed headers. It expects that all
boost-using projects (like
Still, the question if we want those in our crt is a separated issue.
That's a question of being backward compatible, which is important IMO.
Too bad those were introduced in the first place...
To me, this is the key question. I agree that breaking backward
compatibility is a bad thing.
dw schreef op za 20-07-2013 om 23:48 [-0700]:
So, who decides? If it's me, I'm probably going to wimp out and add the
defs back to avoid the conflict.
I've just forwarded all our information to the Fedora maintainer of the
mingw-boost package - Thomas Sailer - and asked him if he could
Erik van Pienbroek schreef op zo 21-07-2013 om 12:22 [+0200]:
dw schreef op za 20-07-2013 om 23:48 [-0700]:
So, who decides? If it's me, I'm probably going to wimp out and add the
defs back to avoid the conflict.
I've just forwarded all our information to the Fedora maintainer of the
Erik van Pienbroek schreef op zo 21-07-2013 om 14:49 [+0200]:
So now I think it's up to us to come up with the most proper fix which
we can then try to get upstreamed.
Attached is the patch I came up with to fix the build issue. It is
basically method 2 in dw's original mail.
The header in
Attached is the patch I came up with to fix the build issue.
You are checking for defined(__MINGW64_VERSION_MAJOR). Would it make
sense to do (__MINGW64_VERSION_MAJOR = 3)?
dw
--
See everything from the browser to
So, Erik was kind enough to try re-running some of his builds with the
latest patches to winbase.h. With a bit of tweaking to the patch, x86
now builds. While I haven't checked it in yet, these DLLIMPORT things
are fixed.
Unfortunately, x64 does not build correctly. If you want to see the
dw schreef op za 20-07-2013 om 02:07 [-0700]:
An argument could be made that we have broken backward compatibility
and it's our responsibility to fix it. On the other hand, one could
say they are using our library incorrectly (by not including any of
our headers), and the fact that it
On 07/20/13 12:22, Erik van Pienbroek wrote:
dw schreef op za 20-07-2013 om 02:07 [-0700]:
An argument could be made that we have broken backward compatibility
and it's our responsibility to fix it. On the other hand, one could
say they are using our library incorrectly (by not including any
2013/7/20 dw limegreenso...@yahoo.com
So, Erik was kind enough to try re-running some of his builds with the
latest patches to winbase.h. With a bit of tweaking to the patch, x86 now
builds. While I haven't checked it in yet, these DLLIMPORT things are
fixed.
Unfortunately, x64 does not
dw schreef op za 20-07-2013 om 02:07 [-0700]:
Boost could:
1) Use winbase.h (via windows.h) like the MSDN docs say they should.
In fact, I wonder if defining BOOST_USE_WINDOWS_H would work.
I just did some more testing. According to
16 matches
Mail list logo
