October 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 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 14 Feb '13

14 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 05 May '12

05 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 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

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 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

Fwd: Gtk+ win32 fixes, please test
by Kalev Lember 14 Nov '11

14 Nov '11

Hello, Forwarding a message from gtk-devel-list. The rest of the thread is archived at https://mail.gnome.org/archives/gtk-devel-list/2011-October/msg00055.html -------- Original Message -------- Subject: Gtk+ win32 fixes, please test Date: Wed, 19 Oct 2011 22:53:49 +0200 From: Alexander Larsson <alexl(a)redhat.com> To: gtk-devel-list(a)gnome.org <gtk-devel-list(a)gnome.org> I just pushed a bunch of changes to how grabs and crossing events work in the win32 backend to the gtk-2-24-win32 branch, and I want to fix any other leftover bugs from the client side windows conversion. Can any people interested in the win32 code please try this out and report any issues, regressions against gtk-2-24 or just things that are broken on windows related to windows and events. I'm doing this work on the 2.24 branch because gtk2 is what most apps are still using on win32. When this seems to work well I want to forward port it to 3.2. _______________________________________________ gtk-devel-list mailing list gtk-devel-list(a)gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

2 1

Broken dependencies in EPEL - 2011-10-30
by Fedora Koji Build System 30 Oct '11

30 Oct '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 652435] New: Define CMAKE_RC_COMPILER
by Red Hat Bugzilla 28 Oct '11

28 Oct '11

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Define CMAKE_RC_COMPILER https://bugzilla.redhat.com/show_bug.cgi?id=652435 Summary: Define CMAKE_RC_COMPILER Product: Fedora Version: 14 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: low Component: mingw32-filesystem AssignedTo: rjones(a)redhat.com ReportedBy: orion(a)cora.nwra.com 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: Please add: SET(CMAKE_RC_COMPILER /usr/bin/i686-pc-mingw32-windres) to /usr/share/mingw32/Toolchain-mingw32.cmake Version-Release number of selected component (if applicable): mingw32-filesystem-62-2.fc14.noarch -- 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 10

[mingw32-gcc] rebuild with new gmp without compat lib
by Marcela Mašláňová 26 Oct '11

26 Oct '11

commit a2b05cb715092cdab45271346d482bf99fee1f72 Author: Marcela Mašláňová <mmaslano(a)redhat.com> Date: Wed Oct 26 11:58:41 2011 +0200 rebuild with new gmp without compat lib mingw32-gcc.spec | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) --- diff --git a/mingw32-gcc.spec b/mingw32-gcc.spec index 3af2e67..f95c675 100644 --- a/mingw32-gcc.spec +++ b/mingw32-gcc.spec @@ -2,7 +2,7 @@ Name: mingw32-gcc Version: 4.6.1 -Release: 3%{?dist}.1 +Release: 3%{?dist}.2 Summary: MinGW Windows cross-compiler (GCC) for C License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions @@ -251,6 +251,9 @@ popd %changelog +* Wed Oct 26 2011 Marcela Mašláňová <mmaslano(a)redhat.com> - 4.6.1-3.2 +- rebuild with new gmp without compat lib + * Wed Oct 12 2011 Peter Schiffer <pschiffe(a)redhat.com> - 4.6.1-3.1 - rebuild with new gmp

1 0

how do I declare something printf like in a portable manner?
by Simson Garfinkel 26 Oct '11

26 Oct '11

I have code that trips the warning: warning: function might be possible candidate for ‘printf’ format attribute Unfortunately, mingw uses a different declaration for saying something is printf like than gcc does running on MacOS and Linux. Is there a way to do the declaration in a portable manner?

3 4

how do I declare something printf like in a portable manner?
by Simson Garfinkel 26 Oct '11

26 Oct '11

I have code that trips the warning: warning: function might be possible candidate for ‘printf’ format attribute Unfortunately, mingw uses a different declaration for saying something is printf like than gcc does running on MacOS and Linux. Is there a way to do the declaration in a portable manner?

1 0

Mingw32 packages for CentOS 6 are available!
by Erik van Pienbroek 25 Oct '11

25 Oct '11

Hi all, As mentioned in the 'broken dependencies in EPEL' mailing list posting which I sent yesterday [1] I helped out the CentOS developers with getting the mingw32 toolchain bootstrapped using the RHEL 6.1 srpms [2]. I just received word from the CentOS developers that they managed to get the mingw32 toolchain bootstrapped and all mingw32 packages (as provided by Red Hat) have just been built successfully! They are now asking whether people can help out with testing these built packages. I'm sure there are CentOS 6 users reading along this mailing list so here's a call to test these packages. The packages will be published in the CentOS 6 CR repository (which contains packages which are part of Red Hat 6.1 and will become part of CentOS 6.1 once its released). This repository is not enabled by default on a clean CentOS 6.0 installation, so if you want to test out you'd have to 'yum install centos-release-cr' first. Once the CR repo is enabled, you can do a 'yum search mingw32' and install any packages which may be of interest to you. If the 'yum search mingw32' only returns two results (mingw32-filesystem and mingw32-binutils) then your mirror isn't up2date yet. In that case you can try again later. Test results (either good or bad) can be sent to either this mailing list (I'll forward them to the CentOS devs) or directly in the CentOS trac ticket [2]. Kind regards, Erik van Pienbroek [1]: http://lists.fedoraproject.org/pipermail/mingw/2011-October/004182.html [2]: http://bugs.centos.org/view.php?id=5180

1 0

Broken dependencies in EPEL - 2011-10-23
by Fedora Koji Build System 23 Oct '11

23 Oct '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

2 1

gnutls 2.12.x building fun
by Michael Cronenworth 22 Oct '11

22 Oct '11

To test a possible bug I needed to have 2.12.6.1 built. Using the mingw32-2.10.5 spec file I found the following differences: - libnettle has been chosen as the default crypto lib, but I gave configure "--with-libgcrypt" to use gcrypt. - openssl compat dll has an soname bump from 26 to 27 The .def file is still named 26, though. I will report upstream. - libgnutlsxx has an soname bump from 26 to 27 - p11tool, a new binary Just an FYI as I see 2.12 is in rawhide.

3 5

GnuTLS 2.12 fun (continued)
by Michael Cronenworth 22 Oct '11

22 Oct '11

So, I get around to building the latest GnuTLS only to find out there's a new dependency since I last built it: p11-kit Is Rawhide ready for the new package guidelines (to me it looks like it isn't)? Or should I follow the current (F15) guidelines?

2 2

[mingw32-glib2/f16] (3 commits) ...Update to 2.30.1
by Kalev Lember 18 Oct '11

18 Oct '11

Summary of changes: b7695a6... Use wildcards in .gitignore (*) 4eb215e... Clean up old BuildRequires / Requires (*) ff8b72f... Update to 2.30.1 (*) (*) This commit already existed in another branch; no separate mail sent

1 0

[mingw32-glib2] Update to 2.30.1
by Kalev Lember 18 Oct '11

18 Oct '11

commit ff8b72f5596e89cb4432387d3fa24d39b39c7b14 Author: Kalev Lember <kalevlember(a)gmail.com> Date: Tue Oct 18 19:11:21 2011 +0300 Update to 2.30.1 mingw32-glib2.spec | 5 ++++- sources | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-) --- diff --git a/mingw32-glib2.spec b/mingw32-glib2.spec index 1a00cc1..e54cc9e 100644 --- a/mingw32-glib2.spec +++ b/mingw32-glib2.spec @@ -3,7 +3,7 @@ %define __debug_install_post %{_mingw32_debug_install_post} Name: mingw32-glib2 -Version: 2.30.0 +Version: 2.30.1 Release: 1%{?dist} Summary: MinGW Windows GLib2 library @@ -184,6 +184,9 @@ rm -rf $RPM_BUILD_ROOT%{_mingw32_libdir}/gdbus-2.0 %changelog +* Tue Oct 18 2011 Kalev Lember <kalevlember(a)gmail.com> - 2.30.1-1 +- Update to 2.30.1 + * Fri Sep 30 2011 Kalev Lember <kalevlember(a)gmail.com> - 2.30.0-1 - Update to 2.30.0 diff --git a/sources b/sources index 2f558bf..790152c 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -68ac9516233044f27e76577d4f4e6de9 glib-2.30.0.tar.xz +1954dca69994fb8f60280341da3fe2ae glib-2.30.1.tar.xz

1 0

[mingw32-glib2] Clean up old BuildRequires / Requires
by Kalev Lember 18 Oct '11

18 Oct '11

commit 4eb215e8cebc238cb3d0a6dcd131ac0b213b2c9b Author: Kalev Lember <kalevlember(a)gmail.com> Date: Tue Oct 18 19:10:48 2011 +0300 Clean up old BuildRequires / Requires mingw32-glib2.spec | 9 --------- 1 files changed, 0 insertions(+), 9 deletions(-) --- diff --git a/mingw32-glib2.spec b/mingw32-glib2.spec index 6e1e787..1a00cc1 100644 --- a/mingw32-glib2.spec +++ b/mingw32-glib2.spec @@ -25,20 +25,11 @@ BuildRequires: mingw32-gettext BuildRequires: mingw32-libffi BuildRequires: mingw32-zlib -BuildRequires: pkgconfig # Native version required for msgfmt use in build BuildRequires: gettext # Native version required for glib-genmarshal BuildRequires: glib2-devel -Requires: pkgconfig - -# As we're using libproxy-intl the libintl-8.dll dependency is a soft one -# To compile applications against glib2 we need to have gettext installed -# for it's headers -Requires: mingw32-gettext - - %description MinGW Windows Glib2 library.

1 0

[mingw32-glib2] Use wildcards in .gitignore
by Kalev Lember 18 Oct '11

18 Oct '11

commit b7695a6b6357dfc7fe0ef39e18d423b6c80752a5 Author: Kalev Lember <kalevlember(a)gmail.com> Date: Tue Oct 18 19:08:10 2011 +0300 Use wildcards in .gitignore .gitignore | 13 +------------ 1 files changed, 1 insertions(+), 12 deletions(-) --- diff --git a/.gitignore b/.gitignore index 6ccbc88..590a15d 100644 --- a/.gitignore +++ b/.gitignore @@ -1,12 +1 @@ -glib-2.24.1.tar.bz2 -glib-2.25.12.tar.bz2 -glib-2.27.4.tar.bz2 -glib-2.25.15.tar.bz2 -glib-2.25.17.tar.bz2 -glib-2.26.0.tar.bz2 -glib-2.28.0.tar.bz2 -glib-2.27.93.tar.bz2 -/glib-2.28.6.tar.bz2 -/glib-2.29.10.tar.xz -/glib-2.29.18.tar.xz -/glib-2.30.0.tar.xz +/glib-*.tar.xz

1 0

File glib-2.30.1.tar.xz uploaded to lookaside cache by kalev
by Kalev Lember 18 Oct '11

18 Oct '11

A file has been added to the lookaside cache for mingw32-glib2: 1954dca69994fb8f60280341da3fe2ae glib-2.30.1.tar.xz

1 0

Broken dependencies in EPEL - 2011-10-16
by Fedora Koji Build System 16 Oct '11

16 Oct '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-gcc] rebuild with new gmp
by Marcela Mašláňová 12 Oct '11

12 Oct '11

commit e0c1ca9ce23fc2f1b2774bad014aad802ff0684b Author: Marcela Mašláňová <mmaslano(a)redhat.com> Date: Wed Oct 12 03:58:50 2011 +0200 rebuild with new gmp mingw32-gcc.spec | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) --- diff --git a/mingw32-gcc.spec b/mingw32-gcc.spec index 29f514f..3af2e67 100644 --- a/mingw32-gcc.spec +++ b/mingw32-gcc.spec @@ -2,7 +2,7 @@ Name: mingw32-gcc Version: 4.6.1 -Release: 3%{?dist} +Release: 3%{?dist}.1 Summary: MinGW Windows cross-compiler (GCC) for C License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions @@ -251,6 +251,9 @@ popd %changelog +* Wed Oct 12 2011 Peter Schiffer <pschiffe(a)redhat.com> - 4.6.1-3.1 +- rebuild with new gmp + * Fri Aug 26 2011 Kalev Lember <kalevlember(a)gmail.com> - 4.6.1-3 - Fix float.h inclusion when gcc's headers precede mingrt in include path

1 0

Broken dependencies in EPEL - 2011-10-09
by Fedora Koji Build System 09 Oct '11

09 Oct '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: configuration for compiling libraries
by Simson Garfinkel 03 Oct '11

03 Oct '11

> Message: 3 > Date: Sun, 02 Oct 2011 19:43:09 +0200 > From: Erik van Pienbroek <erik(a)vanpienbroek.nl> > Subject: Re: configuration for compiling libraries > To: "Fedora MinGW (Windows cross-compiler) project" > <mingw(a)lists.fedoraproject.org> > Message-ID: <1317577389.29302.21.camel(a)alguno.terneuzen.openftd.org> > Content-Type: text/plain; charset="UTF-8" > > Simson Garfinkel schreef op zo 02-10-2011 om 12:56 [-0400]: >> All, >> >> This is the line that I'm currently using for configuring an auto-tools generated configure script for libraries with mingw64: >> >>> $ ./configure --host=x86_64-w64-mingw32 --prefix=/usr/x86_64-w64-mingw32/sys-root/mingw/ >> >> This seems to work with most libraries but not all. My questions: >> >> 1 - Why is the --prefix needed? Shouldn't the configure scripts automatically figure out where the include and libraries go? >> >> 2 - Is this correct? > > Hi, > > The --prefix shouldn't be needed. The correct path for the mingw{32,64} > sysroot should already be built into {i686,x86_64}-w64-mingw32-gcc so > gcc will always know where to search for headers and libraries. > > When using the --prefix argument you are telling the build system that > you want to install the binaries belonging to that project in a > non-default directory (the default is /usr/local). Hi, Erik, I think that it's incorrect for the default to be /usr/local for a cross-compiler. /usr/local is for stuff that's running on the local machine, not on the target machine. > > If you wish to install the project you're trying to build in the system > wide mingw sysroot you can use > --prefix=/usr/x86_64-w64-mingw32/sys-root/mingw/ although for those > situations we recommend to use the mingw32-configure and > mingw64-configure helper scripts. If you wish to install the project in > your homedir, you could use something like --prefix=/home/simson/mingw. > The value given here shouldn't affect the build itself, so no build > failures are expected when you use a custom --prefix. Thanks. Can you tell me how to use the mingw32-configure and mingw64-configure helper scripts?

2 1

Re: weird linking errors with exiv2
by Simson Garfinkel 03 Oct '11

03 Oct '11

> > Well, you could Use also on command line simply -Wc,lexiv2.dll option. > By this you are choosing always the shared variant (which is used in > scan_exif.cpp source via dllimport). By this the link-failures should > be gone. > Not sure about it, but for testing you might want to remove the > libexiv2.la file. > > Another way to solve this, so that you are able to use static version > here, is to make sure that in scan_exif.cpp for imported libexiv2 API > no dllimport attribute gets specified. Thanks, Kai. I did delete the libexiv2.la file and am seeing the same behavior. Can you tell me how to specify the "no dllimport attribute?" Thanks again. Simson

2 1

Heads up: mingw builds of GNOME 3.2 libraries in F16
by Kalev Lember 02 Oct '11

02 Oct '11

Hello, I have updated various MinGW cross-compiled libraries to GNOME 3.2 versions in F16. They are currently in updates-testing queue; would be great if anyone could give the new builds a try: https://admin.fedoraproject.org/updates/FEDORA-2011-13605 Most of our mingw-specific patches are now upstream and it's mostly just vanilla tarball builds. mingw32-atk-2.2.0 mingw32-cairomm-1.10.0 mingw32-glib2-2.30.0 mingw32-glibmm24-2.30.0 mingw32-glib-networking-2.30.0 mingw32-gtk3-3.2.0 mingw32-gtkmm30-3.2.0 mingw32-gtksourceview3-3.2.0 mingw32-libsigc++20-2.2.10 mingw32-libsoup-2.36.0 mingw32-libxml++-2.34.2 mingw32-pango-1.29.4 mingw32-pangomm-2.28.3 mingw32-webkitgtk-1.6.1 -- Best regards, Kalev

1 0

configuration for compiling libraries
by Simson Garfinkel 02 Oct '11

02 Oct '11

All, This is the line that I'm currently using for configuring an auto-tools generated configure script for libraries with mingw64: > $ ./configure --host=x86_64-w64-mingw32 --prefix=/usr/x86_64-w64-mingw32/sys-root/mingw/ This seems to work with most libraries but not all. My questions: 1 - Why is the --prefix needed? Shouldn't the configure scripts automatically figure out where the include and libraries go? 2 - Is this correct? Thanks, Simson

2 1

Re: weird linking errors with exiv2
by Simson Garfinkel 02 Oct '11

02 Oct '11

> Date: Sat, 1 Oct 2011 20:30:46 +0200 > From: Kai Tietz <ktietz70(a)googlemail.com> > Subject: Re: weird linking errors with exiv2 > To: "Fedora MinGW (Windows cross-compiler) project" > <mingw(a)lists.fedoraproject.org> > Cc: ahuggel(a)gmx.net > Message-ID: > <CAEwic4aBk0arJYrxc-suedToUAE24cFtjeC4A_8sOL1Sna1U4g(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > So is libexiv2.a a static library or an DLL import library? > > As far as I can see are just __imp_ symbols undefined. If libexiv2.a > is an static library, then they are of course not present. Might it > be that there is also an libexiv2.dll.a import-library? > > Regards, > Kai Kai, Thanks for your email. In fact, I did have both the .dll and the static library: /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libexiv2.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libexiv2.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libexiv2.la As a reminder, my link command says "--static": > x86_64-w64-mingw32-g++ -g -D_FORTIFY_SOURCE=2 -Wall -D_FORTIFY_SOURCE=2 > -Wall -Wno-format --static -mthreads -o bulk_extractor.exe > bulk_extractor.o threadpool.o context_list.o histogram.o utils.o support.o > base64_forensic.o feature_recorder.o feature_recorder_set.o image_process.o > image_process_fts.o sbuf.o md5.o scan_ccns2.o scan_find.o scan_net.o > scan_wordlist.o scan_exif.o scan_base64.o xml.o scan_zip.o scan_gzip.o > scan_pdf.o scan_aes.o scan_json.o scan_winprefetch.o scan_hiberfile.o > pyxpress.o scan_email.o scan_accts.o scan_kml.o scan_gps.o -lewf -lz > -lpthreadGC2 -lws2_32 -lgdi32 -lexiv2 -lexpat I removed the library: $ sudo /bin/rm /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libexiv2.dll.a $ sudo /bin/rm /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libexiv2.la And got the same error: scan_exif.o: In function `scan_exif': /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:168: undefined reference to `__imp__ZN5Exiv212ImageFactory4openEPKhl' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:169: undefined reference to `__imp__ZNK5Exiv25Image4goodEv' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:202: undefined reference to `__imp__ZNK5Exiv25Value8toStringEv' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:204: undefined reference to `__imp__ZNK5Exiv25Value8toStringEv' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:214: undefined reference to `__imp__ZNK5Exiv25Value8toStringEv' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:217: undefined reference to `__imp__ZNK5Exiv25Value8toStringEv' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:220: undefined reference to `__imp__ZNK5Exiv25Value8toStringEv' scan_exif.o:/home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:223: more undefined references to `__imp__ZNK5Exiv25Value8toStringEv' follow This really has me stumped. My only recourse seems to be to find another exif library.

2 1

Broken dependencies in EPEL - 2011-10-02
by Fedora Koji Build System 02 Oct '11

02 Oct '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

weird linking errors with exiv2
by Simson Garfinkel 01 Oct '11

01 Oct '11

Hi. I'm using exiv2 with mingw32 and mingw64. For reasons that are not clear to me I get linking errors with mingw64 but not with mingw32. I'm building and installing the library the same way with both. Any idea what I should do? Below is the error that I'm getting: x86_64-w64-mingw32-g++ -g -D_FORTIFY_SOURCE=2 -Wall -D_FORTIFY_SOURCE=2 -Wall -Wno-format --static -mthreads -o bulk_extractor.exe bulk_extractor.o threadpool.o context_list.o histogram.o utils.o support.o base64_forensic.o feature_recorder.o feature_recorder_set.o image_process.o image_process_fts.o sbuf.o md5.o scan_ccns2.o scan_find.o scan_net.o scan_wordlist.o scan_exif.o scan_base64.o xml.o scan_zip.o scan_gzip.o scan_pdf.o scan_aes.o scan_json.o scan_winprefetch.o scan_hiberfile.o pyxpress.o scan_email.o scan_accts.o scan_kml.o scan_gps.o -lewf -lz -lpthreadGC2 -lws2_32 -lgdi32 -lexiv2 -lexpat scan_exif.o: In function `scan_exif': /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:168: undefined reference to `__imp__ZN5Exiv212ImageFactory4openEPKhl' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:169: undefined reference to `__imp__ZNK5Exiv25Image4goodEv' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:202: undefined reference to `__imp__ZNK5Exiv25Value8toStringEv' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:204: undefined reference to `__imp__ZNK5Exiv25Value8toStringEv' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:214: undefined reference to `__imp__ZNK5Exiv25Value8toStringEv' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:217: undefined reference to `__imp__ZNK5Exiv25Value8toStringEv' /home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:220: undefined reference to `__imp__ZNK5Exiv25Value8toStringEv' scan_exif.o:/home/simsong/domex/src/bulk_extractor/src/scan_exif.cpp:223: more undefined references to `__imp__ZNK5Exiv25Value8toStringEv' follow scan_exif.o: In function `Exiv2::LogMsg::setLevel(Exiv2::LogMsg::Level)': /usr/x86_64-w64-mingw32/sys-root/mingw/include/exiv2/error.hpp:116: undefined reference to `__imp__ZN5Exiv26LogMsg6level_E' collect2: ld returned 1 exit status make[2]: *** [bulk_extractor.exe] Error 1 make[2]: Leaving directory `/home/simsong/domex/src/bulk_extractor/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/simsong/domex/src/bulk_extractor' make: *** [all] Error 2 Here is the usage for the exiv2 configure: simsong@FC15:~/exiv2-0.22$ ./configure --help `configure' configures exiv2 0.22 to adapt to many kinds of systems. Usage: ./configure [OPTION]... [VAR=VALUE]... To assign environment variables (e.g., CC, CFLAGS...), specify them as VAR=VALUE. See below for descriptions of some of the useful variables. Defaults for the options are specified in brackets. Configuration: -h, --help display this help and exit --help=short display options specific to this package --help=recursive display the short help of all the included packages -V, --version display version information and exit -q, --quiet, --silent do not print `checking ...' messages --cache-file=FILE cache test results in FILE [disabled] -C, --config-cache alias for `--cache-file=config.cache' -n, --no-create do not create output files --srcdir=DIR find the sources in DIR [configure dir or `..'] Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] By default, `make install' will install all the files in `/usr/local/bin', `/usr/local/lib' etc. You can specify an installation prefix other than `/usr/local' using `--prefix', for instance `--prefix=$HOME'. For better control, use the options below. Fine tuning of the installation directories: --bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/exiv2] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR] System types: --build=BUILD configure for building on BUILD [guessed] --host=HOST cross-compile to build programs to run on HOST [BUILD] Optional Features: --disable-option-checking ignore unrecognized --enable/--with options --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] --disable-nls do not use Native Language Support --disable-rpath do not hardcode runtime library paths --enable-shared[=PKGS] build shared libraries [default=yes] --enable-static[=PKGS] build static libraries [default=yes] --enable-fast-install[=PKGS] optimize for fast installation [default=yes] --disable-libtool-lock avoid locking (might break parallel builds) --disable-dependency-tracking speeds up one-time build --disable-visibility do not use symbol visibility support --disable-lensdata do not use the lens database for Nikon lens names --enable-commercial compile with the EXV_COMMERCIAL_VERSION symbol set --disable-xmp do not compile XMP support and the XMP Toolkit Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --with-gnu-ld assume the C compiler uses GNU ld default=no --with-libiconv-prefix[=DIR] search for libiconv in DIR/include and DIR/lib --without-libiconv-prefix don't search for libiconv in includedir and libdir --with-libintl-prefix[=DIR] search for libintl in DIR/include and DIR/lib --without-libintl-prefix don't search for libintl in includedir and libdir --with-pic try to use only PIC/non-PIC objects [default=use both] --with-gnu-ld assume the C compiler uses GNU ld [default=no] --with-zlib=DIR root directory path of zlib installation defaults to /usr/local or /usr if not found in /usr/local --without-zlib to disable zlib usage completely --with-expat[=DIR] use libexpat in DIR Some influential environment variables: CXX C++ compiler command CXXFLAGS C++ compiler flags LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> LIBS libraries to pass to the linker, e.g. -l<library> CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if you have headers in a nonstandard directory <include dir> CXXCPP C++ preprocessor CC C compiler command CFLAGS C compiler flags CPP C preprocessor Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. Report bugs to <ahuggel(a)gmx.net>. simsong@FC15:~/exiv2-0.22$ simsong@FC15:~/domex/src/bulk_extractor$ And here is the command I'm using to create exiv2: ./configure --host=x86_64-w64-mingw32 --prefix=/usr/x86_64-w64-mingw32/sys-root/mingw --enable-static --without-libiconv-prefix Here is the usage for the exiv2 configure:

2 1

addendum
by Simson Garfinkel 01 Oct '11

01 Oct '11

As a follow-up to my own post, I want to tell those reading that I have looked in the .a file and the symbol is present: simsong@FC15:~/domex/src/bulk_extractor/src$ x86_64-w64-mingw32-nm /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libexiv2.a |grep Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv 00000000000067b0 T _ZNK5Exiv25Value8toStringEv U _ZNK5Exiv25Value8toStringEv simsong@FC15:~/domex/src/bulk_extractor/src$ I find this very confusing and welcome any help.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw October 2011