; code.) In searching the web, I came across this mailing list and the
> good work done by Erik van Pienbroek and others in this regard. As a
> first pass, I tried to install Erik's FC11 RPMs as a quick test to see
> if the cross-compiler works.
Great to hear that people are still intere
lled 'dsymutil' to merge debug symbols in
binaries. However, the source code of this tool isn't available (or
better said: I couldn't find it anywhere yet) so adding debug symbols to
binaries is broken right now.
Regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
y be built for the three different arch's: ppc, i386
and x86_64:
$ file /usr/darwinx/lib/libglib-2.0.0.dylib
/usr/darwinx/lib/libglib-2.0.0.dylib: Mach-O fat file with 3
architectures
A further rebuild is going on right now so new packages should be added
soon.
Regards,
Er
Op donderdag 28-01-2010 om 08:51 uur [tijdzone +], schreef Richard
W.M. Jones:
> On Wed, Jan 27, 2010 at 09:42:08PM +0100, Erik van Pienbroek wrote:
> > The biggest issue so far is the license.. The SDK from Apple
> contains
> > several headers which contain a forbidden li
on.
That strange BuildRequires is needed to get a 32bit compiler installed
in the buildroot (a 64bit version of the odcctools produces corrupt
binaries..perhaps this area has been improved recently). I originally
took it from somewhere else (don't know anym
include/stdarg.h:4:25: error:
> stdarg.h: No such file or directory
Ah yes, it's something I forgot to copy/paste for the x86_64 compiler. A
new version of the darwinx-gcc package has just been published which
should solve both issues (a patch has also
.
> Also on snow leopard it looks like the compiler is called
> i686-apple-darwin10. What is the distinction between 9 and 10?
The original work on this toolchain was done last summer. At that moment
Snow Leopard wasn't released yet so I used the 10.5 SDK (Leopard) as
starting p
Hi,
Several new packages have just been published. Here are the relevant
changelogs:
--
darwinx-filesystem:
* Thu Feb 4 2010 Erik van Pienbroek - 13-1
- Compile binaries with stabs debug symbols instead of dwarf (because
dwarf debug symbols require the closed source tool 'dsymutil
ow why the packages didn't make it to the
repository in the first place, but I just published them again.
Regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
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
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
x27;t know if the Windows opengl32 library contains all the OpenGL
functions you want to use, but there's also a mingw32-freeglut package
in the Fedora repositories which offers additional OpenGL functions.
If you've got any more questions, feel free to drop them on this list
xml2 build succeeds with
it.
Speaking of which, why are you building libxml2? We've already got a
mingw32-libxml2 package in Fedora which works fine. If you want to help
with maintaining the package, feel free to apply for it in pkgdb.
Regards,
Erik van Pienbroek
1.
ersion is better
because of certain fixes and you're confident enough that the package is
stable enough for regular users I don't see any problem.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
t have any dependencies on these external
libraries as they're all bundled inside the Qt DLL's. So the question is
whether we should confirm to the way upstream wants it or the way Fedora
wants it. Comments are welcome.
As soon as we've agreed on these two questions I'
Hi Tom,
> > libraries as they're all bundled inside the Qt DLL's. So the question is
> > whether we should confirm to the way upstream wants it or the way Fedora
> > wants it. Comments are welcome.
>
> I would prefer the fedora way if it's doable without excessive packager
> workload...
The path
ing internal copies.
The new package is expected to land in F14's updates-testing tomorrow
Regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
I just put up a review request for
mingw32-win-iconv at [4]. Could somebody please review that package?
Does everybody agree to these changes?
Kind regards,
Erik van Pienbroek
[1]: http://www.gtk.org/download-windows.html
[2]: http://svn.openftd.org/svn/fedora_cross
[3]: http:
Erik van Pienbroek schreef op di 12-10-2010 om 12:58 [+0200]:
> Does everybody agree to these changes?
No objections? Then I guess it's okay to apply the changes to rawhide.
Regards,
Erik
___
mingw mailing list
mingw@lists.fedoraproject.o
tegrated in Fedora 15.
After the Mac OS X integration has been completed successfully I'll
publish more details about it to this list. For those who are interested
in testing this new framework already, see [5]. Note that when you use
the testing repository all original mingw32 packages will g
Michael Cronenworth schreef op wo 10-11-2010 om 16:12 [-0600]:
> Erik van Pienbroek wrote:
> [snip]
> > My goal is to get this framework integrated in Fedora 15.
>
> Wow, looks great!
>
> I am definitely looking forward to this. Nice work.
>
> Is there anything tha
fkoo...@tuxed.net schreef op ma 15-11-2010 om 11:36 [+0100]:
> On Wed, Nov 10, 2010 at 10:50 PM, Erik van Pienbroek
> wrote:
> > The old mingw.org project does not bundle headers like winscard.h. The
> > new mingw-w64 project looks much more promising. See [1] for the
> >
H. Peter Anvin schreef op ma 15-11-2010 om 16:07 [-0800]:
> On 11/07/2010 07:37 AM, epienbro wrote:
> > commit 2e2670266f9eaf91b9da305164df64af24a7fd7e
> > Author: Erik van Pienbroek
> > Date: Sun Nov 7 16:37:21 2010 +0100
> >
> > Dropped the mingw64 macr
t; mingw32-libxml2-2.7.6-1.fc13.noarch.rpm
> > mingw32-readline-5.2-7.fc12.noarch.rpm
> > mingw32-termcap-1.3.1-8.fc12.noarch.rpm
> >
> > Matthias
Hi Matthias,
There are currently some known issues with the mingw32 toolchain in
Fedora 15. See https://bugzilla.redhat.co
Richard W.M. Jones schreef op wo 17-11-2010 om 09:18 [+]:
> According to some virus scanning (using clamav) that I'm surprised we
> are doing on Fedora packages, the mingw32-nsis package is identified
> thus:
>
> /usr/share/nsis/Stubs/zlib - Trojan.Buzus-7623
>
> Upstream NSIS keep a list of
rent?
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,
E
Panu Matilainen schreef op di 30-11-2010 om 22:10 [+0200]:
> On Tue, 30 Nov 2010, Erik van Pienbroek wrote:
> > If I understand your blog entry correctly then we (the Fedora MinGW SIG)
> > are recommended to use something like this:
> >
> > %__mingw32_provi
Thomas Sailer schreef op wo 08-12-2010 om 15:16 [+0100]:
> https://bugzilla.redhat.com/show_bug.cgi?id=661312
> I need this to compile newer versions of mingw32-gtkmm24
Hi Thomas,
I'll take it for review.
Could you please review mingw32-win-iconv in return?
https://bugzilla.redhat.com/show_bug.cg
ks from now).
Feel free to test the testing repositories and report back any issues
you might find. Other feedback about the cross compiler framework is
welcome too. Help with the reviews is very much appreciated as well!
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
is without introducing a lot
of duplicate instructions in the .spec files?
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
Kevin Kofler schreef op vr 07-01-2011 om 04:13 [+0100]:
> Erik van Pienbroek wrote:
> > I agree with your point that placing all targets in a single binary RPM
> > isn't an ideal solution. While working on this framework I thought about
> > the possibility to split ever
rt:
If you're still running on a Fedora 14 environment you
need to un-comment the 'exclude=..' line in the
/etc/yum.repos.d/fedora-cross.repo file. Otherwise
you'll get a dependency resolving conflict.
If you've still got dependency errors feel free to me
Erik van Pienbroek schreef op zo 09-01-2011 om 13:47 [+0100]:
> Kevin Kofler schreef op vr 07-01-2011 om 04:13 [+0100]:
> > Erik van Pienbroek wrote:
> > > I agree with your point that placing all targets in a single binary RPM
> > > isn't an ideal solution. W
oss_darwinx set to be updated
> --> Processing Dependency: libmpfr.so.4()(64bit) for package:
> cross-cpp-4.5.2-2.fc15_cross_darwinx.x86_64
Apparently there was a typo in the fedora-cross-darwinx.repo file. Could
you please re-download that file again?
Regards,
Erik van Pien
Gilboa Davara schreef op di 25-01-2011 om 11:11 [+0200]:
> Where do I report bugs (if/when I hit them)?
Bug reports can be posted to this mailing list
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
n the
'i686-pc' vs 'i686-w64' prefix). The only changes I applied in the
package are [2] and [3].
Regards,
Erik van Pienbroek
[1]: https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework
[2]: http://svn.openftd.org/viewvc/Fedora%20Cross%20Compiler%
20Framework/mingw32-wpc
Erik van Pienbroek schreef op di 25-01-2011 om 15:56 [+0100]:
> The porting guide
> isn't entirely up to date anymore, but I'll try to update it later
> tonight.
The documentation at
https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework has just
been updated to reflec
Erik van Pienbroek schreef op wo 26-01-2011 om 00:30 [+0100]:
> Erik van Pienbroek schreef op di 25-01-2011 om 15:56 [+0100]:
> > The porting guide
> > isn't entirely up to date anymore, but I'll try to update it later
> > tonight.
>
> The documentation at
&
Michael Cronenworth schreef op di 25-01-2011 om 17:49 [-0600]:
> On 01/25/2011 05:42 PM, Erik van Pienbroek wrote:
> > Oh yeah, another thing: The Fedora 15 feature freeze is already less
> > than two weeks away. Unfortunately this gives us too little time to get
> > the most
es approved in time for Fedora 15. My fear is that the main issue
will be the legal aspect. If that can't be cleared soon enough then
we'll most likely be too late for Fedora 15. We're actually already past
the feature submission deadline (which was 5 days ago) as well so I
guess we
le?
As far as I know there is no gfortran support in the Mac OS X SDK. I've
seen some messages about users installing gcc manually in order to get
gfortran support, but I have to look into the possibilities before I can
add a darwinx-gfortran packa
Archambault Fabien schreef op di 01-02-2011 om 09:03 [+0100]:
> thanks for correcting the first issue but now I have (this morning after
> clean all):
Earlier today, updated packages were published. Does it work now?
Regards,
Erik van Pie
ss/ and
http://svn.openftd.org/viewvc/Fedora%20Cross%20Compiler%20Framework/
Regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
uld try running: rpm -Va --nofiles --nodigest
Does it work by now?
If you still get the libmpfr errors, then you need to verify that you
removed the '#' from the exclude=... line
in /etc/yum.repos.d/fedora-cross.repo (or fedora-cross-darwinx.repo)
Regards,
Erik van Pienbroek
gt; gpgkey=http://build1.openftd.org/fedora-cross/RPM-GPG-KEY-Erik-van-Pienbroek
> exclude=cross-gcc*.fc15_cross cross-cpp*.fc15_cross
>
> And the /etc/yum.repos.d/fedora-cross-darwinx.repo
> [fedora-cross-darwinx]
> name=fedora-cross-darwinx
> baseurl=http://build1.openftd.org/f
++-4.6.0-0.4.20110122.fc15_cross.x86_64
> (fedora-cross)
>Requires: libmpfr.so.4()(64bit)
Did you remove the '#' from the exclude line mentioned
in /etc/yum.repos/fedora-cross.repo ?
Regards,
Erik van Pienbroek
___
mingw maili
Kevin Kofler schreef op wo 09-02-2011 om 09:39 [+0100]:
> Erik van Pienbroek wrote:
> > and have a Fedora Feature approved by FESCO (which I still have to
> > create).
>
> Unfortunately, the feature submission deadline is already past (it's 2 weeks
> before featu
Archambault Fabien schreef op do 10-02-2011 om 11:16 [+0100]:
> > But I still cannot install gfortran:
I just pushed new gcc packages (updated to the latest gcc snapshot).
Could you check whether gfortran works now?
Kind regards,
Erik van Pie
ng everything (to keep the package
versions in sync with the F15 mass rebuild) so new packages will appear
soon.
Regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
ime' works for you?
(It should downgrade to version 3.15). You might have to wait for the
new daily push for this to work..
Kind regards,
Erik van Pienbroek
1: https://fedorahosted.org/rel-eng/ticket/4448
2: https://bugzilla.redhat.com/show_bug.cgi?id=629209
___
#x27;t be part of Fedora for now due to
legal issues with the Mac OS X pieces
It's now recommended to use the fedora-cross repository as it is planned
for inclusion in Fedora 16. More details about the fedora-cross
repository can be found at
https://fedoraproject.org/wi
hear about it.
Otherwise I think that we should drop dlfcn.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
-0-0.8.r11.fc15.src.rpm
This SRPM is compatible with the testing repository, but not with the
new packaging guidelines which are currently under review at
https://fedorahosted.org/fpc/ticket/71 (as there are some small changes
in the naming)
Kind regards,
Erik van Pienbroek
R P Herrold schreef op do 07-04-2011 om 13:20 [-0400]:
> On Mon, 3 Jan 2011, Erik van Pienbroek wrote:
>
> > My plan is to get all the packages belonging to the cross compiler
> > framework in Fedora 15, rebuild all current mingw32 packages and
> > rename/port various p
n't know how stable
the trunk branch is at the moment and whether compatibility-breaking
changes are expected in the coming months. Perhaps the mingw-w64
maintainers (who are also joined on the fedora-mingw mailing list) can
respond to that?
Kind regards,
Erik van Pienbroek
_
Kai Tietz schreef op zo 10-04-2011 om 16:35 [+0200]:
> 2011/4/10 Erik van Pienbroek :
> > I'm okay with switching to the trunk branch, but I don't know how stable
> > the trunk branch is at the moment and whether compatibility-breaking
> > changes are expected in
> in more detail so I can try to figure out the error?
>
> -Jay Higley
Looks like there was a still typo. New version at
http://www.ftd4linux.nl/contrib/cross-dlfcn-0-0.9.r11.fc15.src.rpm
Kind regards,
Erik van Pienbroek
___
mingw mailing li
>
> I'm am not sure it pays off diverging from upstream gettext like that.
Hi Kalev,
I agree with you. Using proxy-libintl turned out to be worse than
expected. Especially with the mingw32-webkitgtk issues we're discussing
right now in #fedora-mingw. I'm okay with droppi
API (as was
requested for wine-gecko support) is also enabled.
Kind regards,
Erik van Pienbroek
[1]:
http://meetbot.fedoraproject.org/fedora-meeting/2011-04-13/fpc.2011-04-13-15.59.html
[2]: https://fedoraproject.org/wiki/Packaging:MinGW
[3]:
https:
Erik van Pienbroek schreef op di 26-04-2011 om 16:32 [+0200]:
> I agree with you. Using proxy-libintl turned out to be worse than
> expected. Especially with the mingw32-webkitgtk issues we're discussing
> right now in #fedora-mingw. I'm okay with dropping it from the F-15
library to
link against is named '-lgfortran' (which doesn't exist), hence you get
the error that a library named '-lgfortran' could not be found.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
uses two underscores while the linker
tries to locate a function which just one underscore. I don't know if
the program you're trying to compile also expects this '__cpuid'
function, but I think you can better ask this question to the upstream
developers.
Regards,
Erik van Pienbroek
kages
without having to get everything through the review proces again.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
PM and is available in all current Fedora
releases.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
Kalev Lember schreef op za 28-05-2011 om 16:07 [+0300]:
> Any comments?
Hi Kalev,
I'm +1 to your proposed change to use mingw32-xxx debuginfo subpackages.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.o
tricks yet, so these packages should also work on RHEL-6 (I don't have
access to an RHEL-6/CentOS-6 environment so I can't test this yet). You
might have to rebuild the gcc and binutils packages for RHEL-6, but
other than that the packages should work just fine.
Kind regards,
Erik
are now part of RHEL (be it as a technology preview)
we aren't allowed to bundle them in EPEL anymore... Only packages which
aren't part of RHEL (yet) may be added to EPEL.
See http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies for more
details about this subject
Ki
libpthreadGC2.a
However, there's another catch here. There is no
mingw32/64-pthreads-static package available at the moment..so the above
command won't work. If you want to run your application you need to
bundle the pthread dll for now.
Kind regards,
Erik van Pienbroek
ok really
hard you can see that there's a %{cross_files} macro which spans all the
way until the last file. The use of \'s at the end of each line also
make this error prone.
Another thing that may be an interesting read for you is the ticket we
filed at the Fedora Packaging Committee to get the mingw-w64 based
guidelines approved: https://fedorahosted.org/fpc/ticket/71
The discussion in the mingw-filesystem review ticket may also be
interesting to you: https://bugzilla.redhat.com/show_bug.cgi?id=673784
Please don't let this all discourage you. If you (or anybody else) can
come up with methods to making the example spec file at
http://fedoraproject.org/wiki/Packaging:MinGW_Future more readable and
smaller I would be glad to hear about it so we can use it for future
mingw packages!
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
fkoo...@tuxed.net schreef op vr 03-06-2011 om 17:03 [+0200]:
> On Fri, Jun 3, 2011 at 4:39 PM, Erik van Pienbroek
> wrote:
> > Please don't let this all discourage you. If you (or anybody else) can
> > come up with methods to making the example spec file at
> >
7;s
so, we could return it.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
ora-cross/src/mingw-pango-1.29.3-1.fc15_cross.src.rpm
Could you try if you can get that package build on EL-6? (I don't have
access to an EL-6 environment yet so I can't test it myself..)
Kind regards,
Erik van Pienbroek
___
mingw mail
ue yourself :)
I also noticed you changed the release number for the mingw-crt and
mingw-headers packages. By doing this you've broken the upgrade path (as
version 1.0-0.1.20110620 is older than 1.0-0.5.20110609). Please revert
this change and stick with the original versioning.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
we can pull in
a recent enough snapshot.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
r=matroska --disable-demuxer=matroska'"
%mingw_configure "--enable-shared" "--disable-static"
It's not really that much more readable but it's just another method to
achieve the same goal. It's strange anyway that you have to supply ext
tart - %* - end
%define macro2() %{macro1}
%macro2 test
'
This returns 'start - test - end', but has the side-effect that it
breaks calling %macro1 as can be seen in the next example:
$ rpm --eval '
%define macro1 start - %*
oot/mingw/include" -I"../src" -I"release"
> -I"/usr/lib/qt4/mkspecs/win32-g++-cross" -o release/qtlockedfile_unix.o
> ../src/qtlockedfile_unix.cpp
Are you sure that you've used the mkspecs name 'win32-g++-cross'? It
looks like it was trying to
Farkas Levente schreef op zo 26-06-2011 om 15:00 [+0200]:
> hi,
> after i find the Erik already checkin the update to newer crt and header
> and able to fix the d3d patch now (for me) everything build on rhel-6.
> so Erik svn contains spec which is working on both fedora and rhel-6.
> i'm just rena
e, both the mingw32 and the mingw64
pieces will be pulled in. I've just applied a change so that all RPM
macros which depend on both mingw32-filesystem and mingw64-filesystem
will be bundled with this package (this wasn't the case before
ovides: mingw64(gdi32.dll)
> Provides: mingw64(gdiplus.dll)
> Provides: mingw64(glut32.dll)
> @@ -310,6 +314,9 @@
>
>
> %changelog
> +* Wed Jul 6 2011 Levente Farkas - 75-1
> +- Add Provides: ddraw.dll and dsound.dll
> +
> * Fri Jul 1 2011 Erik
Farkas Levente schreef op za 02-07-2011 om 18:21 [+0200]:
> On 07/01/2011 06:26 PM, Erik van Pienbroek wrote:
> > Farkas Levente schreef op di 28-06-2011 om 10:56 [+0200]:
> >> hi,
> >> why there is a mingw-filesystem-scripts package and not move everything
> >>
Farkas Levente schreef op wo 06-07-2011 om 14:09 [+0200]:
> On 07/06/2011 01:57 PM, Erik van Pienbroek wrote:
> > After thinking some more about this I decided to drop the
> > mingw-filesystem package and rename the -scripts package to -base. So
> > now we've got the m
ant to help, feel free to do so. The new
packaging guidelines (for win32 and win64 support) can be found at
https://fedoraproject.org/wiki/Packaging:MinGW_Future
If you've got any questions feel free to ask them here or on IRC,
irc.freenode.net, #fedora-mingw.
Kind regards,
Er
only static
libraries being built. Instead of manually running libtoolize in most
mingw-* packages (to get a recent enough libtool in place) I added a
global libtool export which is set during the build for all win64
packages.
Kind regards,
Erik van Pienbroek
_
are affected too).
In Fedora Rawhide this problem is already solved in a more proper way.
Recently, the package mingw32-libjpeg was replaced by
mingw32-libjpeg-turbo. Several (upstreamed!) changes have been done to
prevent these kind of conflicts. If it's possible, I wou
architectures x86_64 and i686. The architectures i586/i686
are 32bit targets and the architectures amd64/x86_64 are 64bit targets.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
e
You could replace 'mingw64-%{mingw_pkg_name}' with '%{mingw64_pkg_name}' here.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
Farkas Levente schreef op do 07-07-2011 om 00:10 [+0200]:
> hi,
> i rewrite all mingw-find- scripts since the build targets was hardcoded
> into these.
> the mingw-find-requires already has a bug since the *ddl_found if never
> be true since the win32/64_dll_found=true was inside a pipe which cause
able for Win32 and Win64. Perhaps you could create some kind
of exception-list inside the mingwtool which contains a list of all such
special-case packages.
Could you also send the mingwtool script to this mailing list once your
okay with it so we can take a look at it?
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
Farkas Levente schreef op ma 11-07-2011 om 11:58 [+0200]:
> to answer to myself again and again...
> i'm just thinking that may be we can create a mingwtool and a
> mingwtool-real. the mingwtool can include mingwtool-real if found it
> otherwise not. in this case mingwtool only handle the BuildRequ
information mentioned there should mostly still apply on today's
state of the mingw32 toolchain. Unfortunately the annexia links
(Richard's personal domain) seem to be broken now, but perhaps Richard
still has access to the files mentioned on that wiki page.
Kind regards,
Erik van Pienb
gtk3 and not the gtk2
libraries anymore? If that's the case then it'll be a change in behavior
which several people (who are depending on nsiswrapper to bundle the
gtk2 libraries) probably won't like. I think a better solution would be
to change the script so that it supports
Michael Cronenworth schreef op wo 13-07-2011 om 16:14 [-0500]:
> Is GTK3 even ready for Win32/64? Everything I've seen says no even
> though I see we have MinGW packages of it in the repos.
> ___
> mingw mailing list
> mingw@lists.fedoraproject.org
> htt
cific
function. The file poppler/CairoFontEngine.cc contains two calls to the
cairo-ft function cairo_ft_font_face_create_for_ft_face. Perhaps you
could ask upstream to implement a method to make these 2 calls optional
(so that poppler still remains to work even if cairo-ft is missing) ?
Kind rega
and
mingw32-gdb packages which can be found in my mingw-w64 testing repo:
==
C:\Users\Erik van Pienbroek\Desktop\gstreamer>dir
Het volume in station C heeft geen naam.
Het volumenummer is 06D4-9680
Map van C:\Users\Erik van Pienbroek\Desktop\gstreamer
07-08-2011 14:49 .
07-08
On Wed, 2011-08-10 at 11:07 +0300, Kalev Lember wrote:
> > On Tue, Aug 9, 2011 at 11:05 AM, Farkas Levente wrote:
> >> ps. anyway i'm just like to update it to the 2.0 rc1.
>
> Talk to epienbro on IRC, I belive he already started work on this.
The mingw-w64 2.0rc1 packages have already been buil
On Wed, 2011-08-10 at 14:09 +0200, Farkas Levente wrote:
> first of all which binutils to use? imho always the latest release
> (currently binutils-2.21.53.0.2), but in fedora rpms there are many
> patches. should we use them too? imho yes. these packages made by many
> those people who really know
Ruben Van Boxem schreef op di 16-08-2011 om 13:43 [+0200]:
> Hi,
>
> I have recently been put on the trail of your effort to provide a Mac
> OS X cross-compiler from Linux to Mac OS X. Although I'm running Arch,
> with the necessary symlinks(for openssl libs and /usr/darwinx) I can
> run your extr
may need to perform
a 'yum clean all' first.
Kind regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
s, feel free
to let us know about it so we can help to resolve these issues.
Kind regards,
Erik van Pienbroek
[1]:
https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework#Development_and_testing_repository
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
file to the SVN repo. If you happen to stumble
across any other missing files, just let me know and I'll add them to
the repo.
Regards,
Erik van Pienbroek
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
1 - 100 of 504 matches
Mail list logo
