[Bug 652435] New: Define CMAKE_RC_COMPILER
by Red Hat Bugzilla
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.
12 years, 6 months
gnutls 2.12.x building fun
by Michael Cronenworth
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.
12 years, 6 months
[mingw32-glib2] Update to 2.30.0
by Kalev Lember
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
12 years, 7 months
Broken dependencies in EPEL - 2011-09-25
by Fedora Koji Build System
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
12 years, 7 months
mingw-pcap
by Simson Garfinkel
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?
12 years, 7 months
Broken dependencies in EPEL - 2011-09-18
by Fedora Koji Build System
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
12 years, 7 months
snprintf warning about long long
by Michael Cronenworth
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
12 years, 7 months
Re: -mthreads
by Simson Garfinkel
>
> 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
12 years, 7 months