I am planning to orphan mingw-qt.
Reasons:
- it fails to build on F28, presumably due to the __debug_install_post
hook not generating the debugsource lists properly
- releng/Till complains that the build log is now 3Gbytes long (due to
more elaborate compiler diagnostics)
Fixing this is more
On 01/19/2014 04:58 PM, Ed Beroset wrote:
I've developed software that uses the boost asio (asynchronous serial
I/O) library and would like to use mingw to create a Windows port of it.
There doesn't currently seem to be support for it. Am I overlooking
it? If it matters, I'm using Fedora 20.
I've fixed mingw32-glibmm24 and mingw32-boost.
> The only package which I've found (to date) that doesn't build anymore
> with gcc 4.7 is mingw32-boost. It seems to bail out because of a lack of
> thread support but I haven't been able to pinpoint the exact cause yet.
If you're interested why, se
https://bugzilla.redhat.com/show_bug.cgi?id=661312
I need this to compile newer versions of mingw32-gtkmm24
Thanks,
Tom
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
Hi Kai,
> I am not sure if 3.15.2-5 already has support for v2
Apparently not.
> pseudo-relocations, but binutils 2.20.51 has it. So maybe try to
> specify the additional linker option
> '--enable-runtime-pseudo-reloc-v1' on dll generation. By this you can
> enforce that ld generates the old rel
Hi Kai,
thanks for you answer!
I first used a fully uptodate Fedora14 system:
mingw32-binutils-2.20.1-1.fc14.x86_64
mingw32-runtime-3.15.2-5.fc13.noarch
Then I manually upgraded binutils:
mingw32-binutils-2.20.51.0.10-1.fc14.x86_64
Both configurations resulted in segfaulting boost regex dlls.
Hi,
can anybody tell me what __pei386_runtime_relocator does/is supposed to
do?
The boost regex dll segfaults on process attach within DllMain, or
__pei386_runtime_relocator+0x1f to be exact. I'm running out of clues...
https://bugzilla.redhat.com/show_bug.cgi?id=654424
NB: I've privately built
On Sat, 2010-10-09 at 21:39 +0200, Erik van Pienbroek wrote:
> try to rewrite the Qt .spec file. In the end I managed to get Qt
> compiled without the hacks which were originally used. As a bonus
Great! Thanks for your work!
> around this limitation, but I think we should discuss changing it to
