December 2011 - mingw - Fedora mailing-lists

[Bug 599567] New: mingw32-gcc should not drag in mingw32-pthreads
by Red Hat Bugzilla 18 Feb '15

18 Feb '15

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: mingw32-gcc should not drag in mingw32-pthreads https://bugzilla.redhat.com/show_bug.cgi?id=599567 Summary: mingw32-gcc should not drag in mingw32-pthreads Product: Fedora Version: 13 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mingw32-gcc AssignedTo: rjones(a)redhat.com ReportedBy: eblake(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: berrange(a)redhat.com, rjones(a)redhat.com, kalev(a)smartlink.ee, fedora-mingw(a)lists.fedoraproject.org Classification: Fedora Target Release: --- Description of problem: mingw32-gcc currently drags in a dependency on mingw32-pthreads, which in turn forces some namespace pollution due to its buggy <pthread.h> header. It would be much nicer if the mingw32-pthreads package remained optional, since it can interfere with cross-compilation efforts to mingw. Version-Release number of selected component (if applicable): mingw32-gcc-4.4.2-2.fc13.x86_64 mingw32-pthreads-2.8.0-10.fc13.noarch How reproducible: Always Steps to Reproduce: 1. Install mingw32-gcc Actual results: mingw32-pthreads gets sucked in as a required dependency to the cross-compiler. Expected results: Mere presence of the cross-compiler shouldn't force the existence of a broken <pthread.h>. Either the compiler needs to be built without mingw32-pthreads, or mingw32-pthreads needs to be split into two packages (runtime dependency of the compiler, vs. development library that installs <pthread.h> for situations that actually want to use this library in spite of its current upstream flaws). Additional info: -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 15

[Bug 641423] New: mingw32-gcc installs files both inside and outside the sysroot
by Red Hat Bugzilla 18 Feb '15

18 Feb '15

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: mingw32-gcc installs files both inside and outside the sysroot https://bugzilla.redhat.com/show_bug.cgi?id=641423 Summary: mingw32-gcc installs files both inside and outside the sysroot Product: Fedora Version: 13 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mingw32-gcc AssignedTo: rjones(a)redhat.com ReportedBy: pbonzini(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: rjones(a)redhat.com, kalev(a)smartlink.ee, fedora-mingw(a)lists.fedoraproject.org Classification: Fedora Target Release: --- Description of problem: mingw32-gcc is a strange hybrid package that installs files both inside and outside the sysroot. The files in the sysroot should be separated in mingw32-libgcc. Version-Release number of selected component (if applicable): mingw32-gcc-4.4.2-2.fc13.x86_64 Additional info: This makes the following packages depend incorrectly on mingw32-gcc: * mingw32-gettext (directly) * mingw32-pthreads (directly) * mingw32-atk (indirectly) * mingw32-glib2 (indirectly) * mingw32-gtk2 (indirectly) * mingw32-pango (indirectly) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 11

[Bug 623338] New: mingw32-glib2 may need to be rebuilt against Python 2.7 in F14 and rawhide
by Red Hat Bugzilla 18 Feb '15

18 Feb '15

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: mingw32-glib2 may need to be rebuilt against Python 2.7 in F14 and rawhide https://bugzilla.redhat.com/show_bug.cgi?id=623338 Summary: mingw32-glib2 may need to be rebuilt against Python 2.7 in F14 and rawhide Product: Fedora Version: 14 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mingw32-glib2 AssignedTo: rjones(a)redhat.com ReportedBy: dmalcolm(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, t.sailer(a)alumni.ethz.ch, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Depends on: 623233 Blocks: 619913 Classification: Fedora Target Release: --- This is an automatically-filed bug. mingw32-glib2-2.24.1-1.fc14 contains one or more .pyc files, but has not been rebuilt since Python 2.7 was built for Fedora, and thus the .pyc files presumably are for Python 2.6. Python 2.7 changed the bytecode format, so usage of those files will typically fail (see e.g. bug 621726). The package needs to be rebuilt against python 2.7 in both F14 and devel. Information on the new "dist-git" system can be seen here: http://fedoraproject.org/wiki/Using_Fedora_GIT Information on common difficulties with Python 2.7 rebuilds can be seen here: https://fedoraproject.org/wiki/Features/Python_2.7 Once it's been successfully rebuilt for F14, an update needs to be filed to get the rebuild into F14: https://admin.fedoraproject.org/updates/new/ Please add this bug to the update, to make it easy to track what's been done, and what's left to do. I'm sorry that this component was not handled by the mass rebuild. (This may be due to bug 623233) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 8

[Bug 721312] New: CVE-2011-2690 libpng: buffer overwrite in png_rgb_to_gray [epel-5]
by Red Hat Bugzilla 01 Sep '14

01 Sep '14

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: CVE-2011-2690 libpng: buffer overwrite in png_rgb_to_gray [epel-5] https://bugzilla.redhat.com/show_bug.cgi?id=721312 Summary: CVE-2011-2690 libpng: buffer overwrite in png_rgb_to_gray [epel-5] Product: Fedora EPEL Version: el5 Platform: All OS/Version: Linux Status: NEW Keywords: Security, SecurityTracking Severity: medium Priority: medium Component: mingw32-libpng AssignedTo: rjones(a)redhat.com ReportedBy: huzaifas(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Blocks: 720607 Classification: Fedora Story Points: --- epel-5 tracking bug for mingw32-libpng: see blocks bug list for full details of the security issue(s). This bug is never intended to be made public, please put any public notes in the 'blocks' bugs. [bug automatically created by: add-tracking-bugs] -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 4

[Bug 755814] New: CVE-2011-0216 libxml2: Off-by-one error leading to heap-based buffer overflow in encoding [fedora-all]
by Red Hat Bugzilla 13 Feb '13

13 Feb '13

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: CVE-2011-0216 libxml2: Off-by-one error leading to heap-based buffer overflow in encoding [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=755814 Summary: CVE-2011-0216 libxml2: Off-by-one error leading to heap-based buffer overflow in encoding [fedora-all] Product: Fedora Version: 15 Platform: All OS/Version: Linux Status: NEW Keywords: Security, SecurityTracking Severity: low Priority: low Component: mingw32-libxml2 AssignedTo: rjones(a)redhat.com ReportedBy: huzaifas(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, veillard(a)redhat.com, rjones(a)redhat.com, erik-fedora(a)vanpienbroek.nl, fedora-mingw(a)lists.fedoraproject.org, drizt(a)land.ru Blocks: 724906 Classification: Fedora Story Points: --- Type: --- This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected Fedora versions. For comments that are specific to the vulnerability please use bugs filed against "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please include this bug ID and the bug IDs of this bug's parent bugs filed against the "Security Response" product (the top-level CVE bugs). Please mention the CVE IDs being fixed in the RPM changelog when available. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=security&bugs=724906 Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please ensure that it is only closed when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 11

[Bug 749175] New: CVE-2011-3256 FreeType FT_Bitmap_New integer overflow to buffer overflow, FreeType TT_Vary_Get_Glyph_Deltas improper input validation [fedora-all]
by Red Hat Bugzilla 13 Feb '13

13 Feb '13

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: CVE-2011-3256 FreeType FT_Bitmap_New integer overflow to buffer overflow, FreeType TT_Vary_Get_Glyph_Deltas improper input validation [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=749175 Summary: CVE-2011-3256 FreeType FT_Bitmap_New integer overflow to buffer overflow, FreeType TT_Vary_Get_Glyph_Deltas improper input validation [fedora-all] Product: Fedora Version: 15 Platform: All OS/Version: Linux Status: NEW Keywords: Security, SecurityTracking Severity: high Priority: high Component: mingw32-freetype AssignedTo: rjones(a)redhat.com ReportedBy: rcvalle(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Blocks: 746226 Classification: Fedora Story Points: --- Type: --- This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected Fedora versions. For comments that are specific to the vulnerability please use bugs filed against "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please include the bug IDs of the respective parent bugs filed against the "Security Response" product. Please mention CVE ids in the RPM changelog when available. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=security&bugs=746226 Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please only close it when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 8

[Bug 657478] New: Invalid declare statement in macros.mingw32 with some packages
by Red Hat Bugzilla 20 Jun '12

20 Jun '12

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Invalid declare statement in macros.mingw32 with some packages https://bugzilla.redhat.com/show_bug.cgi?id=657478 Summary: Invalid declare statement in macros.mingw32 with some packages Product: Fedora Version: 14 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mingw32-filesystem AssignedTo: rjones(a)redhat.com ReportedBy: waananen(a)nbi.dk QAContact: extras-qa(a)fedoraproject.org CC: rjones(a)redhat.com, kalev(a)smartlink.ee, erik-fedora(a)vanpienbroek.nl, fedora-mingw(a)lists.fedoraproject.org, drizt(a)land.ru Classification: Fedora Description of problem: I'm using a custom build of mingw32-python in order to build Python bindings for a software package. For this packages the code in macros.mingw32 breaks: ... for i in `ls %{_mingw32_bindir}/*|grep -- "-config\$"` ; do \ x=`basename $i|tr "a-z+-" "A-ZX_"`; \ declare -x $x="$i" ; export $x; \ done; \ ... The variable name $x contains a ('.') when it finds the python2.x-config script in %{_mingw32_bindir}. One could imagine that this problem could be triggered on other *-config scripts. The fix is easy: filter away dots ('.') from the filename when generating the variable name (eg. |cut -d '.'). Version-Release number of selected component (if applicable): I found this in Fedora 12, but it seems applicable to Fedora 14. How reproducible: Build a package which requires mingw32-python. The mingw32-python does not yet exist in Fedora (unfortunately). Steps to Reproduce: 1. 2. 3. Actual results: Package build fails Expected results: Package should build Additional info: Cheers Anders -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 21

[Bug 665539] New: mingw32-bzip2 is missing a static package
by Red Hat Bugzilla 04 May '12

04 May '12

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: mingw32-bzip2 is missing a static package https://bugzilla.redhat.com/show_bug.cgi?id=665539 Summary: mingw32-bzip2 is missing a static package Product: Fedora Version: 14 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: low Component: mingw32-bzip2 AssignedTo: rjones(a)redhat.com ReportedBy: amorilia(a)users.sourceforge.net QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Classification: Fedora Description of problem: Currently, it is not possible to cross compile against bzip2 statically. Version-Release number of selected component (if applicable): 1.0.5-8 How reproducible: cat > test.c <<EOF void main() {}; EOF i686-pc-mingw32-gcc -Wl,-Bstatic -lbz2 test.c Steps to Reproduce: 1. 2. 3. Actual results: /usr/lib64/gcc/i686-pc-mingw32/4.5.0/../../../../i686-pc-mingw32/bin/ld: cannot find -lbz2 collect2: ld returned 1 exit status Expected results: The test program compiles successfully. Additional info: Patch attached. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 9

[Bug 758911] New: libgio-2.0-0.dll does not work on Windows 2000
by Red Hat Bugzilla 01 Mar '12

01 Mar '12

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: libgio-2.0-0.dll does not work on Windows 2000 https://bugzilla.redhat.com/show_bug.cgi?id=758911 Summary: libgio-2.0-0.dll does not work on Windows 2000 Product: Fedora Version: 16 Platform: i386 OS/Version: Windows Status: NEW Severity: unspecified Priority: unspecified Component: mingw32-glib2 AssignedTo: rjones(a)redhat.com ReportedBy: t.sailer(a)alumni.ethz.ch QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, t.sailer(a)alumni.ethz.ch, rjones(a)redhat.com, kalevlember(a)gmail.com, erik-fedora(a)vanpienbroek.nl, fedora-mingw(a)lists.fedoraproject.org Classification: Fedora Story Points: --- Type: --- Description of problem: libgio-2.0-0.dll is not usable on Windows 2000. Version-Release number of selected component (if applicable): mingw32-glib2-2.30.1-1.fc16.noarch How reproducible: always Steps to Reproduce: 1.try to run a program that uses libgio-2.0-0.dll on Windows 2000 Actual results: a dialog box pops up stating that freeaddrinfo was not defined. Expected results: program runs Additional info: the reason for this is that freeaddrinfo is not present in the Windows 2000 version of ws2_32.dll. MS has a work around provided in wspiapi.h; wspiapi.h uses freeaddrinfo from ws2_32.dll if available, otherwise provides its own implementation. But mingw32 (unlike mingw w64) does not provide wspiapi.h. Therefore, gio...dll directly links to freeaddrinfo from ws2_32.dll, which does not work on Windows 2000. I created a quick&dirty workaround by just including wspiapi from mingw w64: http://sailer.fedorapeople.org/mingw32-glib2-2.30.1-2.fc16.src.rpm A better fix might be to add wspiapi from w64 to mingw32, and then recompile mingw32-glib2 (glib2 should autodetect the presence of wspiapi.h). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 7

[Bug 604702] New: Custom Fedora patch to mingw32-libjpeg breaks API
by Red Hat Bugzilla 28 Feb '12

28 Feb '12

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Custom Fedora patch to mingw32-libjpeg breaks API https://bugzilla.redhat.com/show_bug.cgi?id=604702 Summary: Custom Fedora patch to mingw32-libjpeg breaks API Product: Fedora Version: 13 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mingw32-libjpeg AssignedTo: rjones(a)redhat.com ReportedBy: adam(a)spicenitz.org QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, berrange(a)redhat.com, rjones(a)redhat.com, erik-fedora(a)vanpienbroek.nl, fedora-mingw(a)lists.fedoraproject.org Classification: Fedora Description of problem: The resolution of bug #497492 creates a source incompatible fork of libjpeg that is not even compatible with the native libjpeg! Version-Release number of selected component (if applicable): mingw32-libjpeg-7-2.fc12.noarch Steps to Reproduce: 1. Try to compile libtiff with standard Fedora configure, make. 2. Now try to compile libtiff with mingw32-configure, mingw32-make. Actual results: tif_jpeg.c:289: error: expected declaration specifiers or '...' before 'boolean' etc. I don't think we should fork libjpeg in Fedora. Bug #497492 should be reopened and the programs that crash should be fixed. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 13

jmorecfg.h INT32
by Nerijus Baliunas 16 Feb '12

16 Feb '12

Hello, I am trying to compile poppler-0.16.7 on Fedora 15. mingw32-configure fails to link libopenjpeg: checking for opj_cio_open in -lopenjpeg... no checking openjpeg.h usability... yes checking openjpeg.h presence... yes checking for openjpeg.h... yes Why? But running mingw32-cmake instead of mingw32-configure enables libopenjpeg support. Later it fails: In file included from /usr/i686-pc-mingw32/sys-root/mingw/include/winnt.h:192:0, from /usr/i686-pc-mingw32/sys-root/mingw/include/windef.h:253, from /home/nerijus/rpmbuild/BUILD/poppler-0.16.7/poppler/poppler-config.h:83, from /home/nerijus/rpmbuild/BUILD/poppler-0.16.7/poppler/Error.h:33, from /home/nerijus/rpmbuild/BUILD/poppler-0.16.7/goo/JpegWriter.cc:17: /usr/i686-pc-mingw32/sys-root/mingw/include/basetsd.h:52:13: error: conflicting declaration 'typedef int INT32' /usr/i686-pc-mingw32/sys-root/mingw/include/jmorecfg.h:164:14: error: 'INT32' has a previous declaration as 'typedef long int INT32' It is a known problem, I know wxWidgets have workaround for it. Which one should I use? Regards, Nerijus

3 6

Request to add gendef to packages
by The Source 30 Jan '12

30 Jan '12

Please, add gendef utility mingw32/64 packages

2 1

Broken vsprintf
by The Source 30 Jan '12

30 Jan '12

While trying to build one of my apps using mingw from fedora-cross mingw repository (compiler version mingw32-gcc-c++-4.6.2-0.4.20110908.fc16_cross.x86_64) I have found that _GLIBCXX_HAVE_BROKEN_VSWPRINTF is defined and for that reason I can't use std::to_string

2 2

Fwd: Goocanvas for Mingw32
by Richard W.M. Jones 28 Jan '12

28 Jan '12

Thanks Egil, I am forwarding your message and the spec file to the fedora-mingw mailing list. I looked quickly over the spec file and it looks good. Rich. ----- Forwarded message from Egil Kvaleberg <egil(a)kvaleberg.com> ----- Subject: Goocanvas for Mingw32 Date: Mon, 27 Apr 2009 13:54:27 +0200 From: Egil Kvaleberg <egil(a)kvaleberg.com> To: rjones(a)redhat.com I have played around with the Mingw32 for Fedora, and it absolutely seems like a very cool thing. For my purposes, I am using GTK2, which is supported, but I also need a canvas. I have been using Goocanvas (not sure what really is *the* canvas for GTK2, but I have been happy with Goocanvas). However, a Goocanvas package does not seem to be available, so I built one. Goocanvas may be of interest to others, so if you think it is suitable then please use the attached spec-file or tell me how to get involved. The spec-file for Fedora 11 is attached. Sincerely, Egil Kvaleberg -- Company: Kvaleberg AS Office: +47 22 44 31 75 Mobile: +47 920 22 780 Fax: +47 22 44 46 77 Web: http://www.kvaleberg.com/ ----- End forwarded message ----- -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v

3 4

[Bug 770203] New: No libpng.a
by Red Hat Bugzilla 01 Jan '12

01 Jan '12

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: No libpng.a https://bugzilla.redhat.com/show_bug.cgi?id=770203 Summary: No libpng.a Product: Fedora Version: 15 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: mingw32-libpng AssignedTo: rjones(a)redhat.com ReportedBy: drizt(a)land.ru QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, rjones(a)redhat.com, erik-fedora(a)vanpienbroek.nl, fedora-mingw(a)lists.fedoraproject.org, ktietz(a)redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Description of problem: I built static version of mingw32-qt. But I can't build test project with static. i686-pc-mingw32-g++ -static -static-libgcc -Wl,-s -Wl,-subsystem,windows -o release/standarddialogs.exe release/dialog.o release/main.o release/moc_dialog.o -L'/home/taurus/qt/mingw32/lib' -lmingw32 -lqtmain -lQtGui -lgdi32 -lcomdlg32 -loleaut32 -limm32 -lwinmm -lwinspool -ljpeg -ltiff -lmsimg32 -lQtCore -lpng -lole32 -luuid -lws2_32 -ladvapi32 -lshell32 -luser32 -lkernel32 -lz /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld: cannot find -lpng I had a look at mingw32-libpng package. It has libpng14.dll.a, it has libpng.dll.a, it has libpng14.a but it hasn't libpng.a Can you make symbolic link to? libpng.a -> libpng14.a . -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 6

[Bug 770204] New: No static library
by Red Hat Bugzilla 01 Jan '12

01 Jan '12

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: No static library https://bugzilla.redhat.com/show_bug.cgi?id=770204 Summary: No static library Product: Fedora Version: 15 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: mingw32-sqlite AssignedTo: rjones(a)redhat.com ReportedBy: drizt(a)land.ru QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, t.sailer(a)alumni.ethz.ch, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- I tried to build static qt. But I couldn't do it. Static qt require static libsqlite3.a. I rebuild mingw32-sqlite with static for myself. It works. Does it possible to add static subpackage to Fedora repo? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 6

No cross-DLL exceptions in mingw32 compilers
by Simson Garfinkel 30 Dec '11

30 Dec '11

We have certainly seen problems on production code because of the inability of sending exceptions cross-DLLs. If this problem was fixed, it was not fixed in the current release. > > I believe this bug was fixed in an upstream: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34684, so let me change the flag > as:CLOSED/ERRATA , feel free to reopen this bug if u still experiencing this > problem. >

1 0

[Bug 489100] New: No cross-DLL exceptions in mingw32 compilers
by Red Hat Bugzilla 29 Dec '11

29 Dec '11

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: No cross-DLL exceptions in mingw32 compilers https://bugzilla.redhat.com/show_bug.cgi?id=489100 Summary: No cross-DLL exceptions in mingw32 compilers Product: Fedora EPEL Version: el5 Platform: All OS/Version: Linux Status: NEW Severity: high Priority: low Component: mingw32-gcc AssignedTo: rjones(a)redhat.com ReportedBy: wolfgang.glas(a)ev-i.at QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, berrange(a)redhat.com, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Classification: Fedora Version 4.3.2-12 of EPEL's version of the moingw32 cross-compiler do not support cross-DLL exceptions. I've attached the gcc bug report below. This make running a non-trivial C++ program impossible an renders the mingw32 toolchain unusable for real-world C++ programs. The mingw-w64 toolchain has solved this problem by supplying a shared libgcc, hopefully the mingw32 toolchain will follow this approach in the near future. Please keep on your tremendous work on providing the ming32 toolchain in the EPEL. TIA, Wolfgang -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 15

Broken dependencies in EPEL - 2011-12-25
by Fedora Koji Build System 24 Dec '11

24 Dec '11

Your following packages in the repository suffer from broken dependencies: ====================================================================== The results in this summary consider Test Updates! ====================================================================== package: mingw32-libpng-1.2.37-3.el6.noarch from fedora-epel-6-ppc64 unresolved deps: mingw32(msvcrt.dll) mingw32(zlib1.dll) mingw32(kernel32.dll) mingw32-filesystem >= 0:63 mingw32-runtime

1 0

[mingw32-libpng] static subpackage
by ivanromanov 24 Dec '11

24 Dec '11

Summary of changes: a8457f8... static subpackage (*) (*) This commit already existed in another branch; no separate mail sent

1 0

[mingw32-libpng/f16] static subpackage
by ivanromanov 24 Dec '11

24 Dec '11

commit a8457f822035baa38cca3dec8a530934f3afd955 Author: Ivan Romanov <drizt(a)land.ru> Date: Sat Dec 24 20:51:56 2011 +0600 static subpackage mingw32-libpng.spec | 21 +++++++++++++++++++-- 1 files changed, 19 insertions(+), 2 deletions(-) --- diff --git a/mingw32-libpng.spec b/mingw32-libpng.spec index 4ec429d..9cbd88e 100644 --- a/mingw32-libpng.spec +++ b/mingw32-libpng.spec @@ -4,7 +4,7 @@ Name: mingw32-libpng Version: 1.4.8 -Release: 1%{?dist} +Release: 2%{?dist} Summary: MinGW Windows Libpng library License: zlib @@ -26,6 +26,16 @@ Requires: pkgconfig MinGW Windows Libpng library. +%package static +Summary: Static version of MinGW Windows Libpng library +Requires: %{name} = %{version}-%{release} +Group: Development/Libraries + +%description static +MinGW Windows Libpng library. + +This package contains static cross-compiled libraries. + %{?_mingw32_debug_package} @@ -34,7 +44,7 @@ MinGW Windows Libpng library. %build -%{_mingw32_configure} --disable-static +%{_mingw32_configure} make %{?_smp_mflags} @@ -61,8 +71,15 @@ rm -rf $RPM_BUILD_ROOT%{_mingw32_mandir} %{_mingw32_libdir}/pkgconfig/libpng.pc %{_mingw32_libdir}/pkgconfig/libpng14.pc +%files static +%defattr(-,root,root,-) +%{_mingw32_libdir}/libpng.a +%{_mingw32_libdir}/libpng14.a %changelog +* Sat Dec 24 2011 Ivan Romanov <drizt(a)land.ru> - 1.4.8-2 +- New static subpackage + * Fri Jul 22 2011 Kalev Lember <kalevlember(a)gmail.com> - 1.4.8-1 - Update to 1.4.8 (CVE-2011-2690, CVE-2011-2692) - Generate debuginfo subpackage

1 0

[mingw32-libpng/f15] static subpackage
by ivanromanov 24 Dec '11

24 Dec '11

commit a87e23eca174758c6d231b3dc7688f6e784b50b0 Author: Ivan Romanov <drizt(a)land.ru> Date: Sat Dec 24 20:44:24 2011 +0600 static subpackage mingw32-libpng.spec | 25 +++++++++++++++++++++---- 1 files changed, 21 insertions(+), 4 deletions(-) --- diff --git a/mingw32-libpng.spec b/mingw32-libpng.spec index 4b8b12e..407c831 100644 --- a/mingw32-libpng.spec +++ b/mingw32-libpng.spec @@ -6,7 +6,7 @@ Name: mingw32-libpng Version: 1.4.8 -Release: 1%{?dist} +Release: 2%{?dist} Summary: MinGW Windows Libpng library License: zlib @@ -29,6 +29,17 @@ Requires: pkgconfig %description MinGW Windows Libpng library. +%package static +Summary: Static version of MinGW Windows Libpng library +Requires: %{name} = %{version}-%{release} +Group: Development/Libraries + + +%description static +MinGW Windows Libpng library. + +This package contains static cross-compiled libraries. + %prep %setup -q -n libpng-%{version} @@ -52,8 +63,6 @@ rm -rf $RPM_BUILD_ROOT make DESTDIR=$RPM_BUILD_ROOT install -rm $RPM_BUILD_ROOT%{_mingw32_libdir}/libpng.a - # No need to distribute manpages which appear in the Fedora # native packages already. rm -rf $RPM_BUILD_ROOT%{_mingw32_mandir} @@ -74,14 +83,22 @@ rm -rf $RPM_BUILD_ROOT %{_mingw32_includedir}/pngconf.h %{_mingw32_libdir}/libpng.dll.a %{_mingw32_libdir}/libpng.la -%{_mingw32_libdir}/libpng14.a %{_mingw32_libdir}/libpng14.dll.a %{_mingw32_libdir}/libpng14.la %{_mingw32_libdir}/pkgconfig/libpng.pc %{_mingw32_libdir}/pkgconfig/libpng14.pc +%files static +%defattr(-,root,root,-) +%{_mingw32_libdir}/libpng.a +%{_mingw32_libdir}/libpng14.a + + %changelog +* Sat Dec 24 2011 Ivan Romanov <drizt(a)land.ru> - 1.4.8-2 +- New static subpackage + * Fri Jul 22 2011 Kalev Lember <kalevlember(a)gmail.com> - 1.4.8-1 - Update to 1.4.8 (CVE-2011-2690, CVE-2011-2692)

1 0

[mingw32-sqlite/f15] static subpackage
by ivanromanov 24 Dec '11

24 Dec '11

Summary of changes: 602064f... static subpackage (*) (*) This commit already existed in another branch; no separate mail sent

1 0

[mingw32-sqlite/f16] static subpackage
by ivanromanov 24 Dec '11

24 Dec '11

Summary of changes: 602064f... static subpackage (*) (*) This commit already existed in another branch; no separate mail sent

1 0

[mingw32-sqlite] static subpackage
by ivanromanov 24 Dec '11

24 Dec '11

commit 602064f2fa9aaade642fe95759c6badf4b55ff5d Author: Ivan Romanov <drizt(a)land.ru> Date: Sat Dec 24 20:24:05 2011 +0600 static subpackage mingw32-sqlite.spec | 29 +++++++++++++++++++++++++---- 1 files changed, 25 insertions(+), 4 deletions(-) --- diff --git a/mingw32-sqlite.spec b/mingw32-sqlite.spec index 663454f..aa8afca 100644 --- a/mingw32-sqlite.spec +++ b/mingw32-sqlite.spec @@ -16,7 +16,7 @@ Name: mingw32-%{name1} Version: %{rpmver} -Release: 1%{?dist} +Release: 2%{?dist} Summary: MinGW Windows port of sqlite embeddable SQL database engine License: Public Domain @@ -70,6 +70,23 @@ This package contains cross-compiled libraries and development tools for Windows. +%package static +Summary: Static version of MinGW Windows port of sqlite library +Requires: %{name} = %{version}-%{release} +Group: Development/Libraries + +%description static +SQLite is a C library that implements an SQL database engine. A large +subset of SQL92 is supported. A complete database is stored in a +single disk file. The API is designed for convenience and ease of use. +Applications that link against SQLite can enjoy the power and +flexibility of an SQL database without the administrative hassles of +supporting a separate database server. Version 2 and version 3 binaries +are named to permit each to be installed on a single host + +This package contains static cross-compiled library + + %{_mingw32_debug_package} @@ -116,9 +133,6 @@ make rm -rf $RPM_BUILD_ROOT make DESTDIR=$RPM_BUILD_ROOT install -# Remove static libraries but DON'T remove *.dll.a files. -rm $RPM_BUILD_ROOT%{_mingw32_libdir}/libsqlite3.a - chmod 0644 $RPM_BUILD_ROOT%{_mingw32_libdir}/libsqlite3.dll.a mv $RPM_BUILD_ROOT%{_mingw32_libdir}/libsqlite3-0.dll $RPM_BUILD_ROOT%{_mingw32_bindir}/ @@ -148,7 +162,14 @@ rm -rf $RPM_BUILD_ROOT %{_mingw32_datadir}/tcl%{tclversion}/sqlite3/pkgIndex.tcl %endif +%files static +%defattr(-,root,root,-) +%{_mingw32_libdir}/libsqlite3.a + %changelog +* Sat Dec 24 2011 Ivan Romanov <drizt(a)land.ru> - 3.7.5-2 +- static subpackage + * Sun Feb 13 2011 Thomas Sailer <t.sailer(a)alumni.ethz.ch> - 3.7.5-1 - update to 3.7.5

1 0

GD package for MinGW64/32
by Boszormenyi Zoltan 21 Dec '11

21 Dec '11

Hi, I was trying to cross-compile the RLIB reporting library: http://rlib.sicompos.com/ http://newrlib.sicom.com/~rlib/index.php/Main_Page and it prefers GD to be present. So, I tried to compile GD (version 2.0.35-13 SRPM as in Fedora 16) using the fedora-cross repos for MinGW32-w64. There were some problems with it as the configure.ac in GD only expected Cygwin, not MinGW without Cygwin. The patch against configure.ac and the RPM specfile to package for fedora-cross are attached. Best regards, Zoltán Böszörményi

2 5

Broken dependencies in EPEL - 2011-12-18
by Fedora Koji Build System 17 Dec '11

17 Dec '11

Your following packages in the repository suffer from broken dependencies: ====================================================================== The results in this summary consider Test Updates! ====================================================================== package: mingw32-libpng-1.2.37-3.el6.noarch from fedora-epel-6-ppc64 unresolved deps: mingw32(msvcrt.dll) mingw32(zlib1.dll) mingw32(kernel32.dll) mingw32-filesystem >= 0:63 mingw32-runtime

1 0

Question about the MinGW-packaged Webkit
by Boszormenyi Zoltan 13 Dec '11

13 Dec '11

Hi, I am trying to use the webkit_web_view widget in my GTK2 application. 1st problem: I am trying to display an report (the engine can output HTML) this way: webkit_web_view_load_string(WEBKIT_WEB_VIEW(report_web_view), buf, "text/html", "ISO-8859-2", url); char *buf contains the HTML content of course, char *url contains "file:///C:\Program Files\myapp" as the base url so the content should also find an external logo image in that directory. The problem is that the logo isn't displayed, neither under Wine, nor under native Windows. What should be set as the "base url" to get it displayed? 2nd problem: The content's HTML header looks like this: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <style type="text/css"> pre { margin:0; padding:0; margin-top:0; margin-bottom:0; font-size:9pt;} body { background-color: #ffffff;} div { position: absolute; left: 0; } TABLE { border: 0; border-spacing: 0; padding: 0; width:100%; } </style> <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-2"><title>RLIB Report</title></head> The report contents (besides the logo) is displayed perfectly under Wine. But in Windows it swallows a some lines, maybe during conversion. Interestingly, all the lines that contain accented hungarian characters are visible, but ones that only contains plain ASCII are not. I would expect the reverse: iconv bails out with error in case of inconvertible characters. All the lines are present in the html string, I verified it by writing it to a disk file. My application is packaged with NSIS and libwebkitgtk-1.0-0.dll and all the required DLLs are included. Is there anything else I should also package to make webkit display everything? Thanks in advance, Zoltán Böszörményi

2 1

Broken dependencies in EPEL - 2011-12-11
by Fedora Koji Build System 10 Dec '11

10 Dec '11

Your following packages in the repository suffer from broken dependencies: ====================================================================== The results in this summary consider Test Updates! ====================================================================== package: mingw32-libpng-1.2.37-3.el6.noarch from fedora-epel-6-ppc64 unresolved deps: mingw32(msvcrt.dll) mingw32(zlib1.dll) mingw32(kernel32.dll) mingw32-filesystem >= 0:63 mingw32-runtime

1 0

Re: Package for mingw64-pdcurses
by Erik van Pienbroek 10 Dec '11

10 Dec '11

Christophe GRENIER schreef op di 06-12-2011 om 14:02 [+0100]: > Hello > > Using the spec file for mingw32-pdcurses, I have tried to > create a mingw64 version. It compiles but the generated binaries > crashes... Do you have any experience with it ? > > Thanks, > Christophe > Hi Christophe, Please send any questions regarding the Fedora MinGW toolchain (and the mingw-w64 testing repo) to the mailing list mingw(a)lists.fedoraproject.org. That way other people can also help you with these kind of questions. I've CC'ed this message to the mailing list for now. The general method to debug crashes in binaries is by using gdb. For win64 we've got the mingw64-gdb package available in the mingw-w64 testing repo. You can copy the gdb.exe from that package to a win64 environment (some additional dll's may be required) and try to reproduce the crash inside of gdb. I won't fully explain how you can use gdb as there's already enough info available online about that subject. It's quite possible that these kind of crashes (where the win32 version works fine and the win64 version crashes) are caused by the assumption that sizeof(long) == 8 bytes on 64bit platforms while in reality it is only 4 bytes on win64. To be able to find out if this is also the case for the crash you're seeing you'd have to catch the crash using gdb first and look at the code involved. Kind regards, Erik van Pienbroek

1 0

bluetooth help
by Michael Cronenworth 09 Dec '11

09 Dec '11

Has anyone used Bluetooth devices with MinGW compiled programs? I can perform a bluetooth scan and I can see devices, but calling connect() fails with a bad port/address message. I have a valid bluetooth address that I have verified exists in the address structure with a hex dump. I also know the bluetooth device is reachable in Windows as I can use PuTTY to connect to the COM port and talk to the device just fine. It seems like the connect doesn't even try to reach the device as I have tried to connect when the device is not paired in windows and I never receive a pair prompt. Pairing the device manually doesn't help connect work though. I have run out of ideas to what the cause of the failure is and Windows documentation is very lacking. Thanks for any help, Michael

1 0

CRYPT package for MinGW64/32
by Boszormenyi Zoltan 04 Dec '11

04 Dec '11

Hi, I created a package for cryptographic functions as found in http://gnuwin32.sourceforge.net/packages/crypt.htm . You can get it from http://www.kortancegyesulet.hu/private/zoltan/mingw-crypt-2.14-1.fc16.src.r… Implementation details: - The main crypt-2.14.tar.gz source is only a skeleton that contains configure.ac, Makefile.am, etc. - The secondary source file (crypt.tar.gz) is the crypt directory from glibc-2.14.90-19 SRPM as in Fedora 16, you can compare them. GNUWin32's crypt.dll is a modified source from GLIBC 2.2.5. - crypt-mingw.patch contains - 3 necessary private headers from glibc: sysdeps/i386/bits/byteswap.h sysdeps/x86_64/bits/byteswap.h sysdeps/x86_64/bits/wordsize.h - a naive implementation for stpncpy(3) as the algorithm is described in the man page and modifies the crypt source itself in a minimalistic was so it can compile standalone (e.g. there is no weak_alias(), and __THROW) and without warnings on both mingw32 and mingw64. The result is libcrypt-1.dll (NOT crypt.dll as in GNUWin32), so when GLIBC adds more crypthographic functions, the library version can increase. All test programs (md5test.exe, md5c-test.exe, sha256test.exe, sha256c-test.exe, sha512test.exe, sha512c-test.exe, ufc.exe) report success with 0 return code. Best regards, Zoltán Böszörményi

1 1

Broken dependencies in EPEL - 2011-12-04
by Fedora Koji Build System 03 Dec '11

03 Dec '11

Your following packages in the repository suffer from broken dependencies: ====================================================================== The results in this summary consider Test Updates! ====================================================================== package: mingw32-libpng-1.2.37-3.el6.noarch from fedora-epel-6-ppc64 unresolved deps: mingw32(msvcrt.dll) mingw32(zlib1.dll) mingw32(kernel32.dll) mingw32-filesystem >= 0:63 mingw32-runtime

1 0

[Bug 756448] Review Request: mingw-ftplib - MinGW package for ftplib
by Red Hat Bugzilla 02 Dec '11

02 Dec '11

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=756448 --- Comment #2 from Michael Cronenworth <mike(a)cchtml.com> 2011-12-03 00:56:58 EST --- Ah, yes. It shows you how long I've waited to put this up in Fedora. ;) New spec: http://michael.cronenworth.com/RPMS/mingw-ftplib.spec new srpm: http://michael.cronenworth.com/RPMS/mingw-ftplib-3.1-2.fc16.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

Re: Lazarus is lacking crosscompiling ability(?)
by Erik van Pienbroek 02 Dec '11

02 Dec '11

Heiko Adams schreef op vr 02-12-2011 om 01:40 [+0100]: > Hi, > I'm not very experienced in crosscompiling applications but as far as > I understand lazarus wiki page for that topic[1], lazarus is able to > compile i.e. windows binaries on linux. > > I'm currently in a situation where this feature would be very helpful > because it gets boring and costs some time for me to start my windows > vm just for a new build of my applications. I've allready filed a > bug[2] for making feodra's lazarus package able to compile windows > binaries but there isn't any reaction so far. > > So can anyone give me a hint how I can compile my lazarus applications > for windows on my linux box without using a windows vm and why the > lazarus package seems to miss the neccessary files for doing this out > of the box? > > [1] > http://wiki.lazarus.freepascal.org/Cross_compiling_for_Win32_under_Linux > [2] https://bugzilla.redhat.com/show_bug.cgi?id=756486 Forwarding your mail to the Fedora MinGW mailing list. The Fedora MinGW SIG currently has an infrastructure ready which allows easy cross compilation of packages for the win32 target using the mingw.org toolchain. I'm not really familiar with lazarus, but I'm willing to help out wherever I can. I just took a quick look at the wiki page you mentioned. As I see it now there are 3 steps involved in builder a lazarus cross compiler for the win32 target: 1. build binutils for the win32 target 2. build the lazarus fpc compiler for the win32 target 3. configure the lazarus fpc.cfg Step 1 is already provided by the Fedora MinGW SIG. We've got the mingw32-binutils package which contains the various binutils tools for the win32 target. The only real differences I've found so quick are the name of the build target and the installation location. In the fpc buildcrossbinutils script the build target 'i686-mingw32' is used while all Fedora MinGW packages use 'i686-pc-mingw32' (and once the mingw-w64 toolchain is approved for inclusion in Fedora this will be changed to 'i686-w64-mingw32' and 'x86_64-w64-mingw32', see [1] for more details about that). The mingw32-binutils binaries are all placed in %{_bindir}. For step 2 I think you need to extract the interesting instructions from the lazarus buildcrosssnaphot script and merge them in a .spec file. I think it should be pretty straightforward to do so. Step 3 doesn't tell me much, but I guess the current lazarus package ships a fpc.cfg and this file needs to be changed to be aware of the win32 fpc target. If you need any help with the above steps you can always join our IRC channel at #fedora-mingw on FreeNode and we'll try to help you as much as possible. Kind regards, Erik van Pienbroek Fedora MinGW SIG [1]: https://fedoraproject.org/wiki/Features/Mingw-w64_cross_compiler

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw December 2011