mingw September 2011

mingw@lists.fedoraproject.org

13 participants
28 discussions

[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

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

[mingw32-glib2/f16] Update to 2.30.0
by Kalev Lember 30 Sep '11

30 Sep '11

Summary of changes: a8afec9... Update to 2.30.0 (*) (*) This commit already existed in another branch; no separate mail sent

1 0

[mingw32-glib2] Update to 2.30.0
by Kalev Lember 30 Sep '11

30 Sep '11

commit a8afec944bd7f1d167d2160c3c3bab49661abc96 Author: Kalev Lember <kalevlember(a)gmail.com> Date: Fri Sep 30 18:52:26 2011 +0300 Update to 2.30.0 .gitignore | 1 + mingw32-glib2.spec | 5 ++++- sources | 2 +- 3 files changed, 6 insertions(+), 2 deletions(-) --- diff --git a/.gitignore b/.gitignore index 75caaf1..6ccbc88 100644 --- a/.gitignore +++ b/.gitignore @@ -9,3 +9,4 @@ 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 diff --git a/mingw32-glib2.spec b/mingw32-glib2.spec index 7b1e39b..6e1e787 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.29.18 +Version: 2.30.0 Release: 1%{?dist} Summary: MinGW Windows GLib2 library @@ -193,6 +193,9 @@ rm -rf $RPM_BUILD_ROOT%{_mingw32_libdir}/gdbus-2.0 %changelog +* Fri Sep 30 2011 Kalev Lember <kalevlember(a)gmail.com> - 2.30.0-1 +- Update to 2.30.0 + * Tue Aug 30 2011 Kalev Lember <kalevlember(a)gmail.com> - 2.29.18-1 - Update to 2.29.18 diff --git a/sources b/sources index 2a3ef1a..2f558bf 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -2ac3df9236116d40ec23b28a44635e65 glib-2.29.18.tar.xz +68ac9516233044f27e76577d4f4e6de9 glib-2.30.0.tar.xz

1 0

File glib-2.30.0.tar.xz uploaded to lookaside cache by kalev
by Kalev Lember 30 Sep '11

30 Sep '11

A file has been added to the lookaside cache for mingw32-glib2: 68ac9516233044f27e76577d4f4e6de9 glib-2.30.0.tar.xz

1 0

Broken dependencies in EPEL - 2011-09-25
by Fedora Koji Build System 24 Sep '11

24 Sep '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

mingw-pcap
by Simson Garfinkel 22 Sep '11

22 Sep '11

Hi there. I see that there is a mingw32-wpcap but not mingw64-wpcap. I need to do the 64-bit version. Is there instructions anywhere on how I can take the w32 version and make a w64 version?

1 0

Broken dependencies in EPEL - 2011-09-18
by Fedora Koji Build System 17 Sep '11

17 Sep '11

1 0

snprintf warning about long long
by Michael Cronenworth 17 Sep '11

17 Sep '11

Hi all, I am getting a warning out of gcc that it doesn't know about %lli in snprintf(). If I use sprintf() I don't see a warning. If I use snprintf() and ignore the warning the resulting binary seems to work just fine. Known bug or am I doing something wrong? Example code: snprintf( sixtyFourByteStr, 63, "%lli", sixtyFourBitInt ); Gcc output: CFLAGS = -mms-bitfields -g -Wall -pedantic -std=c99 -D _WIN32_WINNT=0x0501 foo.c:1:35: warning: unknown conversion type character 'l' in format foo.c:1:35: warning: too many arguments for format

3 4

Re: -mthreads
by Simson Garfinkel 16 Sep '11

16 Sep '11

> > Simson Garfinkel schreef op do 15-09-2011 om 17:06 [+0100]: >> I am having a problem creating multi-threaded executables that are statically linked. Even though I am using the -static flag, the resulting executable has a dependency for pthreadGC2.dll. Unfortunately, for my application we do not wish to have ANY DLL dependencies. >> >> Here is my linkage line: >> >> x86_64-w64-mingw32-g++ -D_FORTIFY_SOURCE=2 -Wall -g -Wno-format --static -mthreads -o tigerdeep.exe md5.o sha1.o sha256.o whirlpool.o tiger.o main.o hashlist.o multihash.o display.o hash.o dig.o helpers.o xml.o files.o threadpool.o -lws2_32 -lgdi32 -liberty -lpthread >> >> The problem seems to be that all of the libraries have been built for dynamic linking. > > Hi, > > This is expected behaviour. The mingw{32,64}-pthreads package only > contain shared libraries at the moment so even if you specify the > '-static' compiler flag it will still create a dependency on the > pthreads dll. > > You might want to look into the possibility of adding support for a > static pthreads library to the mingw-pthreads package and creating a > mingw{32,64}-pthreads-static subpackages. > > Kind regards, > > Erik van Pienbroek Hi, Erik. Thanks for the email. I'm not really sure how to create a package. Is there a reason why the single package can't have both static and dynamic options? I would think that the --static flag would be used to determine which of the two libraries would be used. In any event, I have been able to compile a static version and am using it locally. Yes, I'd like to make a package, if you can point me to directions. Regards, Simson

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw September 2011