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.
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.
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.
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.
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.
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.
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
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.
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.
Panu Matilainen schreef op vr 26-11-2010 om 13:20 [+0200]:
> In particular, I'm interested in feedback on the new, pluggable and
> enhanced dependency extration system. Documentation is scarce at the
> moment but some background and examples can be found here:
> http://laiskiainen.org/blog/?p=35
All mingw32 packages in Fedora contain these set of instructions in
the .spec files:
%global _use_internal_dependency_generator 0
%global __find_requires %{_mingw32_findrequires}
%global __find_provides %{_mingw32_findprovides}
Does this new dependency extraction system make these kind of
instructions obsolete?
If I understand your blog entry correctly then we (the Fedora MinGW SIG)
are recommended to use something like this:
%__mingw32_provides %{_mingw32_findprovides}
%__mingw32_requires %{_mingw32_findrequires}
Is this correct or do you recommend something different?
The macros %{_mingw32_findrequires} and %{_mingw32_findprovides} are
mentioned in the file /etc/rpm/macros.mingw32 which is part of the
mingw32-filesystem package. Both refer to a small shell script which
uses the i686-pc-mingw32-objdump tool to extract dependency information.
Kind regards,
Erik van Pienbroek