[Bug 499987] New: Review Request: mingw32-curl - MinGW Windows port of curl and libcurl
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: Review Request: mingw32-curl - MinGW Windows port of curl and libcurl
https://bugzilla.redhat.com/show_bug.cgi?id=499987
Summary: Review Request: mingw32-curl - MinGW Windows port of
curl and libcurl
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: Package Review
AssignedTo: nobody(a)fedoraproject.org
ReportedBy: erik-fedora(a)vanpienbroek.nl
QAContact: extras-qa(a)fedoraproject.org
CC: notting(a)redhat.com, fedora-package-review(a)redhat.com,
fedora-mingw(a)lists.fedoraproject.org
Depends on: 499979,499986
Classification: Fedora
Spec URL: http://www.ftd4linux.nl/contrib/mingw32-curl.spec
SRPM URL: http://www.ftd4linux.nl/contrib/mingw32-curl-7.19.4-1.fc11.src.rpm
Description:
cURL is a tool for getting files from HTTP, FTP, FILE, LDAP, LDAPS,
DICT, TELNET and TFTP servers, using any of the supported protocols.
cURL is designed to work without user interaction or any kind of
interactivity. cURL offers many useful capabilities, like proxy
support, user authentication, FTP upload, HTTP post, and file transfer
resume.
This is the MinGW cross-compiled Windows library.
Koji scratch build: none for now because mingw32-libidn and mingw32-libssh2
aren't in Fedora yet
Approved MinGW packaging guidelines are here:
http://fedoraproject.org/wiki/Packaging/MinGW
--
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.
13 years, 10 months
[Bug 513824] New: glib cannot be found while cross compiling
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: glib cannot be found while cross compiling
https://bugzilla.redhat.com/show_bug.cgi?id=513824
Summary: glib cannot be found while cross compiling
Product: Fedora
Version: 11
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: mingw32-glib2
AssignedTo: rjones(a)redhat.com
ReportedBy: pbonzini(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: lfarkas(a)lfarkas.org, t.sailer(a)alumni.ethz.ch,
berrange(a)redhat.com, rjones(a)redhat.com,
fedora-mingw(a)lists.fedoraproject.org
Depends on: 513819
Classification: Fedora
Target Release: ---
Description of problem:
The glib configure macros will not detect glib correctly. Part of the problem
is that the \mingw paths are not available inside Wine.
The part this bug is concerned about, is that the glib macros require a working
touch binary.
This can be as simple as:
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <errno.h>
#include <utime.h>
int main(int argc, char **argv)
{
int i;
struct utimbuf u;
u.actime = time (NULL);
u.modtime = time (NULL);
for (i = 1; i < argc; i++)
{
int fd = open (argv[i], O_WRONLY | O_EXCL | O_CREAT, 0600);
if (fd == -1)
{
if ((errno == EACCES || errno == EISDIR)
&& utime (argv[i], &u) == -1)
perror ("touch");
}
else
close (fd);
}
}
and (if bug 513819 is fixed, which is a prerequisite anyway) it should be
placed in c:\windows so that a more complete mingw installation including GNU
touch would override it.
--
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.
13 years, 10 months
[Bug 497492] New: mingw32-libjpeg crash on windows, typedef
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: mingw32-libjpeg crash on windows, typedef
https://bugzilla.redhat.com/show_bug.cgi?id=497492
Summary: mingw32-libjpeg crash on windows, typedef
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: mingw32-libjpeg
AssignedTo: rjones(a)redhat.com
ReportedBy: mikkel(a)linet.dk
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
Mikkel Kruse Johnsen <mikkel(a)linet.dk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flag| |fedora-review?
Created an attachment (id=341131)
--> (https://bugzilla.redhat.com/attachment.cgi?id=341131)
Patch for SPEC file, to include jpeg-6b-typedefs.patch
Description of problem:
Testing with webkitgtk and loading pages containing jpeg images courses a crash
How reproducible:
Always
Steps to Reproduce:
1. Load ex http://arabic.cnn.com in webkitgtk
Actual results:
Crash
Expected results:
Should load
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.
13 years, 10 months
rpms/mingw32-filesystem/F-13 Toolchain-mingw32.cmake, 1.1, 1.2 mingw32-filesystem.spec, 1.30, 1.31
by Kalev Lember
Author: kalev
Update of /cvs/pkgs/rpms/mingw32-filesystem/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv4233
Modified Files:
Toolchain-mingw32.cmake mingw32-filesystem.spec
Log Message:
Work around cmake's Qt detection in the toolchain file
Index: Toolchain-mingw32.cmake
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-filesystem/F-13/Toolchain-mingw32.cmake,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- Toolchain-mingw32.cmake 9 Jun 2009 08:44:18 -0000 1.1
+++ Toolchain-mingw32.cmake 24 May 2010 09:48:26 -0000 1.2
@@ -12,3 +12,8 @@ SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NE
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+
+# FindQt4.cmake queries qmake to get information,
+# which doesn't work when crosscompiling
+SET(QT_HEADERS_DIR ${CMAKE_FIND_ROOT_PATH}/include)
+SET(QT_LIBRARY_DIR ${CMAKE_FIND_ROOT_PATH}/lib)
Index: mingw32-filesystem.spec
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-filesystem/F-13/mingw32-filesystem.spec,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -p -r1.30 -r1.31
--- mingw32-filesystem.spec 18 Sep 2009 21:34:17 -0000 1.30
+++ mingw32-filesystem.spec 24 May 2010 09:48:26 -0000 1.31
@@ -2,7 +2,7 @@
Name: mingw32-filesystem
Version: 56
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: MinGW base filesystem and environment
Group: Development/Libraries
@@ -166,6 +166,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon May 24 2010 Kalev Lember <kalev(a)smartlink.ee> - 56-2
+- Work around cmake's Qt detection in the toolchain file
+
* Fri Sep 18 2009 Erik van Pienbroek <epienbro(a)fedoraproject.org. - 56-1
- Prevented a circular dependency which caused the i686-pc-mingw32-pkg-config
script to be broken. Thanks to Kalev Lember for spotting this bug
13 years, 11 months
rpms/mingw32-filesystem/devel Toolchain-mingw32.cmake, 1.1, 1.2 mingw32-filesystem.spec, 1.30, 1.31
by Kalev Lember
Author: kalev
Update of /cvs/pkgs/rpms/mingw32-filesystem/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv3286
Modified Files:
Toolchain-mingw32.cmake mingw32-filesystem.spec
Log Message:
Work around cmake's Qt detection in the toolchain file
Index: Toolchain-mingw32.cmake
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-filesystem/devel/Toolchain-mingw32.cmake,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- Toolchain-mingw32.cmake 9 Jun 2009 08:44:18 -0000 1.1
+++ Toolchain-mingw32.cmake 24 May 2010 09:39:19 -0000 1.2
@@ -12,3 +12,8 @@ SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NE
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+
+# FindQt4.cmake queries qmake to get information,
+# which doesn't work when crosscompiling
+SET(QT_HEADERS_DIR ${CMAKE_FIND_ROOT_PATH}/include)
+SET(QT_LIBRARY_DIR ${CMAKE_FIND_ROOT_PATH}/lib)
Index: mingw32-filesystem.spec
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-filesystem/devel/mingw32-filesystem.spec,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -p -r1.30 -r1.31
--- mingw32-filesystem.spec 18 Sep 2009 21:34:17 -0000 1.30
+++ mingw32-filesystem.spec 24 May 2010 09:39:19 -0000 1.31
@@ -2,7 +2,7 @@
Name: mingw32-filesystem
Version: 56
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: MinGW base filesystem and environment
Group: Development/Libraries
@@ -166,6 +166,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon May 24 2010 Kalev Lember <kalev(a)smartlink.ee> - 56-2
+- Work around cmake's Qt detection in the toolchain file
+
* Fri Sep 18 2009 Erik van Pienbroek <epienbro(a)fedoraproject.org. - 56-1
- Prevented a circular dependency which caused the i686-pc-mingw32-pkg-config
script to be broken. Thanks to Kalev Lember for spotting this bug
13 years, 11 months
The Fedora mingw-w64 cross-compiler stack has arrived!
by Erik van Pienbroek
Hi everybody,
The last few months have been very silent for the Fedora MinGW SIG.
To get things up and running again, I decided to spend some of my very
limited spare time to package the mingw-w64 cross-compiler for Fedora.
Thanks to the initial work done by Richard W.M. Jones, I managed to get
mingw-w64 fully packaged as RPM's. A large number of mingw32 RPM's have
been ported to this new stack. The resulting source and binary RPM's are
now published at http://build1.openftd.org/mingw-w64 and a yum
configuration file can be found at
http://build1.openftd.org/mingw-w64/mingw-w64.repo (save this file
to /etc/yum.repos.d).
Bootstrapping
=============
Most cross-compilers need to be bootstrapped before they can be used.
This is also the case with the mingw-w64 cross-compiler. To get things
bootstrapped, one needs to perform these actions:
1. Build and install mingw64-filesystem
2. Build and install mingw64-binutils
3. Build and install mingw64-headers
4. Edit the .spec file of mingw64-gcc and change the bootstrap variable
(line 2) to '1'
5. Build and install mingw64-gcc
6. Build and install mingw64-runtime
7. Edit the .spec file of mingw64-gcc and change the bootstrap variable
(line 2) to '0' and bump the release tag
8. Build and install mingw64-gcc
9. That's all!
As you can see there are no pre-compiled binaries involved so that's a
good thing for Fedora.
>From here on regular packages can be built against this stack.
Libtool and DLL's
=================
A lot of open source libraries/applications use libtool to generate
DLL's. While this works perfectly for mingw32, there's a catch with
mingw-w64. Due to a bug in libtool, building DLL's can result in strange
error messages like this one:
*** Warning: linker path does not have real file for library -lws2_32.
*** I have the capability to make that library automatically link in
when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libws2_32 and none of the candidates passed a file format test
*** using a file magic. Last file
checked: /usr/x86_64-pc-mingw32/sys-root/mingw/lib//libws2_32.a
Luckily enough the bug is already fixed upstream
(http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=7efdc248...) so it will get resolved automatically in time. For now I backported this patch and created a new RPM for it (the new RPM also is placed in the mingw-w64 repository). The scratch build for this new RPM can be found at http://koji.fedoraproject.org/koji/taskinfo?taskID=2190267
However, almost every libtool-based project bundles it's own copy of
libtool. To work around this one must call 'libtoolize --copy --force'
in the %prep phase of the RPM build. This is also done in various
mingw-w64 packages which is published in the repository. After updating
libtool, building DLL's work just fine.
Porting mingw32 packages
========================
Porting mingw32 packages to mingw-w64 is quite easy. All that needs to
be done is changing the '32' in various macros to '64'. For example,
%{_mingw32_strip} will need to become %{_mingw64_strip}. For a complete
list of macro's see the file /etc/rpm/macros.mingw64. Wrapper scripts
like mingw32-configure have also been ported. These are named
mingw64-configure, etc
List of packages
================
These mingw32 packages are currently ported to mingw-w64:
mingw64-atk
mingw64-cairo
mingw64-enchant
mingw64-gettext
mingw64-glib2
mingw64-gtk2
mingw64-gtkhtml3
mingw64-hunspell
mingw64-iconv
mingw64-jasper
mingw64-libgnurx
mingw64-libjpeg
mingw64-libpng
mingw64-libproxy
mingw64-libsoup
mingw64-libtiff
mingw64-libxml2
mingw64-openssl
mingw64-pango
mingw64-pixman
mingw64-qt
mingw64-qt-qmake
mingw64-sqlite
mingw64-zlib
What's next?
============
Ideally, all these packages should end up in the official Fedora
repositories. However, due to my $DAYJOB I don't have the time to get
everything through the Fedora packaging process. Help would be greatly
appreciated to get things rolling! Also note that I haven't done a legal
audit of any kind, so I don't know if there are still legal issues
pending.
Best regards,
Erik van Pienbroek
13 years, 11 months
[Bug 510949] New: upgrade to gcc 4.4.0 proper and mingw upstream
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: upgrade to gcc 4.4.0 proper and mingw upstream
https://bugzilla.redhat.com/show_bug.cgi?id=510949
Summary: upgrade to gcc 4.4.0 proper and mingw upstream
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: mingw32-gcc
AssignedTo: rjones(a)redhat.com
ReportedBy: htl10(a)users.sourceforge.net
QAContact: extras-qa(a)fedoraproject.org
CC: berrange(a)redhat.com, rjones(a)redhat.com,
fedora-mingw(a)lists.fedoraproject.org
Classification: Fedora
Description of problem:
gcc 4.4 was released on 21st April, a little later than feature fedora 11
freeze; and the mingw people has also released a mingw patch set, with some
mingw specific changes a few weeks ago... wouldn't it be nice to upgrade and
synchronization with upstream (gcc or mingw)?
I also noted that the fedora shipped compiler uses sjlj exception, apparently
dwarf2 is the supported model...
--
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.
13 years, 11 months
mingw32-ocaml, missing symbols in libthreadsnat.a
by Paul Steckler
When I compile a multithreaded program using ocamlopt from the mingw32-ocaml package for
Fedora 11, the linker complains about these missing symbols from threads.a:
_caml_thread_exit
_caml_thread_sigmask
_caml_wait_signal
On my Fedora 12 box, those symbols are defined in libthreadsnat.a for the non-MinGW
ocaml package, and the same OCaml code compiles and links OK.
Could it be that libthreadsnat.a was not built correctly in the Fedora 11 mingw32-ocaml
package?
-- Paul
--
Paul Steckler
National ICT Australia
paul DOT steckler AT nicta.com.au
The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.
13 years, 11 months
