I committed the patch with additional __MINGW_INTRIN_INLINE check so we
can move on (to another problem on x64).
I committed the additional updates I had sent privately to Erik.
As for the __MINGW_INTRIN_INLINE thing, I guess I still don't quite
understand the value. If it isn't defined, is
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
:
using an old mingw-w64 snapshot (20121016): success!
using a recent mingw-w64 snapshot (20130713, r5949): success!
using a bleeding edge mingw-w64 snapshot (20130721, r5969): success!
The qpid-cpp build failure is also resolved with this patch as well.
Unless somebody objects I think this patch
On Sun, Jul 21, 2013, JonY wrote:
On 7/21/2013 02:00, niXman wrote:
After the discussion of the details, it was decided to merge the
MinGW-builds and MinGW-w64 projects.
Since then, the MinGW-builds project and all its achievements, are
moving into the MinGW-w64 project and, thus, the
2013/7/21 JonY:
Please revert the move now, move things back, it is breaking a lot of
old links. I don't mind the merge but please do not break things because
of new developments.
What is wrong with the old structure? You can put your builds under
Toolchains targetting Win64/Official
Hi
as far as I remember we discussed that we shouldn't touch first hand old
structure. First building up new tree and then move *unnecessary* parts
away, or/and at least announce changes in front with community to avoid
such fallouts. It is worse to have some changes/temporary fallouts.
2013/7/21 Kai Tietz:
Hi
as far as I remember we discussed that we shouldn't touch first hand old
structure. First building up new tree and then move *unnecessary* parts
away, or/and at least announce changes in front with community to avoid such
fallouts. It is worse to have some
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
2013/7/21 Kai Tietz:
Hi
as far as I remember we discussed that we shouldn't touch first hand old
structure. First building up new tree and then move *unnecessary* parts
away, or/and at least announce changes in front with community to avoid such
fallouts. It is worse to have some
On 7/22/2013 03:46, niXman wrote:
2013/7/21 Kai Tietz:
Hi
as far as I remember we discussed that we shouldn't touch first hand old
structure. First building up new tree and then move *unnecessary* parts
away, or/and at least announce changes in front with community to avoid such
fallouts.
On 7/22/2013 06:19, JonY wrote:
On 7/22/2013 03:46, niXman wrote:
2013/7/21 Kai Tietz:
Hi
as far as I remember we discussed that we shouldn't touch first hand old
structure. First building up new tree and then move *unnecessary* parts
away, or/and at least announce changes in front with
This patch has nothing to do with boost, and makes no changes to inline
asm. Just some simple header changes.
This patch:
- Allows winbase.h to use inline intrinsics whether winnt.h is also
included or not.
- Brings x86 versions of InterlockedAnd64 et al into alignment with MS.
- Adds the
16 matches
Mail list logo
