Re: Switching to DWARF2 exceptions
On 11/30/2009 01:03 PM, Richard W.M. Jones wrote: > On Mon, Nov 30, 2009 at 12:53:53PM +0200, Kalev Lember wrote: >> On 11/30/2009 12:19 PM, Richard W.M. Jones wrote: >>> On Mon, Nov 30, 2009 at 11:56:46AM +0200, Kalev Lember wrote: To work around that, upstream mingw has a patch to annotate functions which support unwinding with SEH with __attribute__((seh_aware)). I've tested that patch and it really does fix binary compatibility with binaries produced by Visual Studio. >>> >>> I'm not quite sure I understand this bit - which functions >>> need to be annotated? >> >> Lets say we have function a() in a.dll (compiled with mingw), b() in >> b.dll (compiled with Visual Studio) and main() in c.exe (compiled with >> mingw). c.exe is linked against b.dll, and b.dll is linked against >> a.dll. Now if an exception is thrown in a() and rethrown in b(), then >> b() prototype in header file has to be annotated like this to make it >> possible to catch it in main() in c.exe: >> >> void b() __attribute__((seh_aware)); >> >> MinGW unwinder supports unwinding either DWARF2 or SEH, but the runtime >> has no way of knowing whether a function supports unwinding with SEH. >> The patch is a workaround to add seh_aware attribute to foreign (SEH) >> function declarations. MinGW release notes [3] explain that it's only a >> temporary measure and future versions of w32api will have a way of doing >> it automatically. >> >> [3] http://sourceforge.net/project/shownotes.php?release_id=691876 > > It certainly sounds like a hack ... But I know even less about this > than anyone else on this thread, so I'll shut up. my question: what is the benefit of change? i can't see any:-( and until ms change his calling convention in visual studio imho it's safer to remain and their side... -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: mingw32-pthreads
On 11/16/2009 08:17 AM, Richard W.M. Jones wrote: > On Sun, Nov 15, 2009 at 01:15:17PM +0100, Farkas Levente wrote: >> On 11/15/2009 01:10 PM, Kalev Lember wrote: >>> On 11/15/2009 01:08 PM, Farkas Levente wrote: >>>> hi, >>>> after reading this page >>>> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/mingw/README.chromium?revision=25199&view=markup >>>> i think we should also include this patch, so i apply. >>> >>> Can you send the patch to pthreads-win32 mailing list [1] ? I took a >>> quick look at the archives and there is some talk about 2.9.0 release >>> with 64 bit Windows support. Would be nice if this patch was properly >>> merged upstream and included in the new release. >>> >>> [1] http://sourceware.org/ml/pthreads-win32/ >>> >> >> done. > > I'm unhappy about the way this patch was added. The message > (http://sourceware.org/ml/pthreads-win32/2009/msg00057.html) isn't > clear what patch we're talking about. The real patch URL is: there is only one patch at the given url:-) but i add the comment to the spec file now. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: mingw32-pthreads
On 11/15/2009 01:10 PM, Kalev Lember wrote: > On 11/15/2009 01:08 PM, Farkas Levente wrote: >> hi, >> after reading this page >> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/mingw/README.chromium?revision=25199&view=markup >> i think we should also include this patch, so i apply. > > Can you send the patch to pthreads-win32 mailing list [1] ? I took a > quick look at the archives and there is some talk about 2.9.0 release > with 64 bit Windows support. Would be nice if this patch was properly > merged upstream and included in the new release. > > [1] http://sourceware.org/ml/pthreads-win32/ > done. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
mingw32-pthreads
hi, after reading this page http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/mingw/README.chromium?revision=25199&view=markup i think we should also include this patch, so i apply. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
[Fwd: Re: %{_global_cflags}]
would be nice to rewrite %_mingw32_cflags to %__global_cflags
Original Message
Subject: Re: %{_global_cflags}
Date: Mon, 13 Jul 2009 17:17:00 +0200
From: Michael Schwendt
Reply-To: Development discussions related to Fedora
To: Development discussions related to Fedora
References:
On Mon, 13 Jul 2009 16:31:34 +0200, Marcus wrote:
> Hi all.
>
> In http://fedoraproject.org/wiki/Packaging:RPMMacros#Build_flags_macros
> %{_global_cflags} is set and %{_optflags} references
> %{__global_cflags} (double underscores). Is this correct or should it
> say %{_global_cflags}?
%{optflags} and %{__global_cflags}
$ rpm --eval %optflags
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586
-mtune=generic -fasynchronous-unwind-tables
$ rpm --eval %__global_cflags
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4
--
fedora-devel-list mailing list
fedora-devel-l...@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: How much to stick to the packaging layout of native packages
Kevin Kofler wrote: > Richard W.M. Jones wrote: >> They're OK as long as they are development tools, and in this case >> they look like mostly development tools, so I would say this is OK. > > But why would you need the EXE versions of those as opposed to the native > ones? let see a simpler example openssl ship the openssl.exe too since many tools used to generate/sign etc. certificate and if the result binary which use the openssl*dll would like to the openssl.exe how can be solve this issue? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: how to patch native pacakge
Richard W.M. Jones wrote: > On Wed, Jun 17, 2009 at 10:40:56PM +0200, Farkas Levente wrote: >> Richard W.M. Jones wrote: >>> On Wed, Jun 17, 2009 at 09:09:45PM +0200, Farkas Levente wrote: >>>> so what's our position now? >>>> it seems upstream wouldn't like to (and probably can't solve without >>>> break something). >>> Have you talked to upstream about this? Please point us to >>> the upstream discussion on their mailing lists. >> without any response: >> http://sourceforge.net/mailarchive/forum.php?thread_name=4A12C61E.9010701%40lfarkas.org&forum_name=libjpeg-devel-6x >> and we discuss many way that this not possible. > > There's a reason I keep going on about upstream libjpeg, not just > because I'm being difficult. It's because there's no way we, as mere > packagers, can fix this on our own. We can't even fix it if we have > the consent of SuSE, Debian and other packagers. > > libjpeg has a screwy, disfunctional upstream. There's not been a real > upstream release for 11 years. Now there is someone claiming to be > the official upstream for libjpeg who isn't ready to hold open > discussions with any of the interested groups. > > This can *only* be fixed by someone taking control, and making > a real upstream libjpeg which has an open, responsive governance. > > This is *not* a Fedora problem. > > Create a real upstream libjpeg (maybe you'll need to change the name). > Involve all the parties and packagers, make the right technical > decisions, release up to date, modern packages, and then, maybe, > mingw32-libjpeg can be a proper part of Fedora. in this case we've to remove mingw32-libjpeg from fedora since it's currently unusable and there is no usable upstream. which will result all of it's dependencies should have to be also removed (which is rather large number:-(). -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: how to patch native pacakge
Richard W.M. Jones wrote: > On Wed, Jun 17, 2009 at 09:09:45PM +0200, Farkas Levente wrote: >> so what's our position now? >> it seems upstream wouldn't like to (and probably can't solve without >> break something). > > Have you talked to upstream about this? Please point us to > the upstream discussion on their mailing lists. without any response: http://sourceforge.net/mailarchive/forum.php?thread_name=4A12C61E.9010701%40lfarkas.org&forum_name=libjpeg-devel-6x and we discuss many way that this not possible. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: how to patch native pacakge
Fridrich Strba wrote: > > Yeah, but it is what the upstream recommends and what virtually all > win32 jpeg packages distributed out there do. So, it is consistent with > the jpeg win32 ABI :) > > Cheers > > F. > > On Tue, 2009-05-19 at 21:04 +0200, Kevin Kofler wrote: >> Fridrich Strba wrote: >>> Just out of curiosity: this is what I do in my packages. >> And this one changes the ABI. >> >> Looks like there's really no good solution here. :-( so what's our position now? it seems upstream wouldn't like to (and probably can't solve without break something). but currently fedora's mingw32-libjpeg worse then any other precompiled windows mingw libjpeg, since other at least works and has a long history, but ours can't be used. imho if we switch to the tor lillqvist's version than it'd be much better then the current status. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Mac OS X cross-compiler coming soon to a Fedora near you (or maybe not?)
Kevin Kofler wrote: >> But we did come up with a coherent plan for how to do this: >> >> http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-February/000464.html >> >> (see also the following messages). > > That sounds like a bad plan. The targets don't have any more in common than > they do with the native version. It makes sense to keep them in separate SRPMs > for the same reason it makes sense to keep them separate from the native > package. > > I don't see a problem with building mingw64-* from mingw32-* SRPMs or the > opposite, as that's the same target OS, just on different hardware platforms, > but building darwinx-* from the same SRPM as mingw* sounds very artificial to > me. They're likely to need different patches, dependencies etc. why maintain 3 spec file for eg mingw32-zlib which are exactly identical on all platform or even a for cycle would be enough in the build section. it keeps simple clean and easier to maintain these even now too much packages. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Mac OS X cross-compiler coming soon to a Fedora near you (or maybe not?)
Erik van Pienbroek wrote: > Hi all, > > In the last two weeks I've been experimenting with getting a Mac OS X > cross-compiler operational on Fedora. This was done according to > documentation [1] which Richard W.M. Jones mentioned [2] on the mailing > list some weeks ago. just 2 quick questions: - wouldn't we like to merge all 3 platform (mingw32, mingw64, darwin) into a common name and package set as discussed earlier? - why not use the same gcc on all platform? ie. gcc-4.4. isn't it build on darwin? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: MinGW packages on S/390
Karsten Hopp wrote: > Am 24.05.2009 17:20, schrieb Richard W.M. Jones: >> Karsten, >> >> MinGW packages _should_ work on s/390. However you must bootstrap >> them correctly. >> >> http://fedoraproject.org/wiki/MinGW/Bootstrapping summarises some of >> the issues. >> >> Rich. >> >> > > There's more required than just those two noarch packages listed on > the mingw bootstrapping page. Some important headers are missing: > http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=67014 > > I'll take a look at that later... those two packages contains those headers:-) -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: how to patch native pacakge
Richard W.M. Jones wrote: > On Sat, May 23, 2009 at 12:36:49AM +0200, Farkas Levente wrote: >> ok. os what to do now? > > Go and ask upstream!!! i did and no one answer in the last 5 days:-( but anyway anything batter then the current state. we've got a packages which not usable. if we fix it in the same way as tor did it then we're at least better. and anyway this situation can't be solve even upstream, the most what we can expect from them that everybody use the same hack. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: how to patch native pacakge
Kevin Kofler wrote: > Farkas Levente wrote: >> ok we rtfm:-) so we fix it. > > This suffers from the "different ABI depending on which header is included > first" (i.e. "first included wins") issue. > > But I don't think there's a real solution as the ABI which is currently used > uses different type definitions than the rpcndr.h ones. ok. os what to do now? facts: - the current mingw32-libjpeg is unusable - there is no abi compatible solution with unix - try to be consistent ie. don't choose solution which depend on the include file order. - imho try to be compatible with previous windows libs (ie. Tor Lillqvist's libs) it use: --- #ifdef _WIN32 # include /* Define "boolean" as unsigned char, not int, per Windows custom */ # if !defined __RPCNDR_H__ || defined __MINGW32__/* don't conflict if rpcndr.h already read */ # ifndef boolean /* don't conflict if rpcndr.h already read */ typedef unsigned char boolean; # endif /* boolean */ # endif /* __RPCNDR_H__ */ # define HAVE_BOOLEAN /* prevent jmorecfg.h from redefining it */ # define USE_WINDOWS_MESSAGEBOX 1 #endif /* _WIN32 */ --- for INT32: --- /* INT32 must hold at least signed 32-bit values. */ #if !defined(XMD_H) && !defined(_WIN32) /* X11/xmd.h correctly defines INT32 */ typedef long INT32; #endif --- so how we patch? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Fedora MinGW
Richard W.M. Jones wrote: > On Fri, May 22, 2009 at 01:26:48PM +0200, Farkas Levente wrote: >> Richard W.M. Jones wrote: >>> On Fri, May 22, 2009 at 11:36:18AM +0200, Farkas Levente wrote: >>>> Richard W.M. Jones wrote: >>>>> On Fri, May 22, 2009 at 11:27:39AM +0200, Farkas Levente wrote: >>>>>> it'd be useful if this page still be updated daily:-) >>>>>> http://www.annexia.org/fedora_mingw >>>>> Yeah, I do need to update that. Also the mingw32-crossreport database >>>>> needs to be updated, since we've added a lot of new packages. >>>> it's not it automatically updated by cron? >>> No, neither one is automatically updated. >> may be i can write a small script for that... > > The script is here: > > http://hg.et.redhat.com/cgi-bin/hg-misc.cgi/fedora-mingw--devel/file/tip/status.pl > > It doesn't help to have the script though, because you also need > access to the site (out of the question) and it produces a strange > HTML variant format used by that site. i generate this page nightly: http://www.lfarkas.org/linux/mingw-status.html -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Fedora MinGW
Richard W.M. Jones wrote: > On Fri, May 22, 2009 at 11:36:18AM +0200, Farkas Levente wrote: >> Richard W.M. Jones wrote: >>> On Fri, May 22, 2009 at 11:27:39AM +0200, Farkas Levente wrote: >>>> it'd be useful if this page still be updated daily:-) >>>> http://www.annexia.org/fedora_mingw >>> Yeah, I do need to update that. Also the mingw32-crossreport database >>> needs to be updated, since we've added a lot of new packages. >> it's not it automatically updated by cron? > > No, neither one is automatically updated. may be i can write a small script for that... -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Fedora MinGW
Richard W.M. Jones wrote: > On Fri, May 22, 2009 at 11:27:39AM +0200, Farkas Levente wrote: >> it'd be useful if this page still be updated daily:-) >> http://www.annexia.org/fedora_mingw > > Yeah, I do need to update that. Also the mingw32-crossreport database > needs to be updated, since we've added a lot of new packages. it's not it automatically updated by cron? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: [Bug 498616] gcc -lpthread is broken
bugzi...@redhat.com wrote:
> Please do not reply directly to this email. All additional
> comments should be made in the comments box of this bug.
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=498616
>
>
>
>
>
> --- Comment #2 from Erik van Pienbroek
> 2009-05-20 11:51:53 EDT ---
> According to the README of pthreads-w32 this is the difference between the two
> .dll files:
>
> pthreadGC2.dll : No exception handling (uses setjmp/longjmp)
> pthreadGCE2.dll: C++ Exception handling
>
> Here's a snippet from the README file:
>
> There seems to be more opinion in favour of using the
> standard C version of the library (no EH) with C++ applications
> for the reason that this appears to be the assumption commercial
> pthreads implementations make. Therefore, if you use an EH version
> of pthreads-win32 then you may be under the illusion that
> your application will be portable, when in fact it is likely to
> behave differently when linked with other pthreads libraries.
>
> Therefore I'm proposing we create a symlink %{_mingw32_libdir}/libpthreadGC2.a
> -> %{_mingw32_libdir}/libpthread.a. The filename 'pthreadGC2.dll' is
> referenced
> in the libpthreadGC2.a file itself, so a symlink shouldn't cause any
> side-effects. The libtool solution as proposed earlier can be dropped.
>
> If libraries really want to make use of pthreadGCE2.dll (C++ EH) then they
> need
> to patch their build scripts so that they use '-lpthreadGCE2' instead of
> '-lpthread'.
>
> Any objections?
agree.
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: how to patch native pacakge
Farkas Levente wrote:
> Richard W.M. Jones wrote:
>> On Tue, May 19, 2009 at 03:19:02PM +0200, Farkas Levente wrote:
>>> Fridrich Strba wrote:
>>>> I meant the install.doc document
>>> ok we rtfm:-) so we fix it.
>>> may i apply this patch to the fedora cvs?
>> I don't think this patch is correct or follows Fridrich's suggestion
>> to look at install.doc. This really needs to be discussed with
>> 'upstream' libjpeg -- whoever that is at the moment [see my other
>> email]. Please make some effort to contact them and have them make a
>> decision on this.
>
> we do what install.doc says,
> - replace jconfig.cfg with jconfig.vc which is the visual c compiler's
> config suggested by install.doc
> - for INT32 we define the same way in jconfig.vc as they did for boolean
> - and use HAVE_INT32 for jmorecfg.h as they used for HAVE_BOOLEAN
> what's the problem?
ohh i send a half patch last time.
--
Levente "Si vis pacem para bellum!"
Index: configure.in
===
RCS file: /cvs/pkgs/rpms/mingw32-libjpeg/devel/configure.in,v
retrieving revision 1.1
diff -u -r1.1 configure.in
--- configure.in30 Jan 2009 11:48:26 - 1.1
+++ configure.in19 May 2009 14:16:40 -
@@ -1,7 +1,7 @@
dnl IJG auto-configuration source file.
dnl Process this file with autoconf to produce a configure script.
AC_INIT(jcmaster.c)
-AC_CONFIG_HEADER(jconfig.h:jconfig.cfg)
+AC_CONFIG_HEADER(jconfig.h:jconfig.vc)
dnl
dnl do these first since other macros rely on them
AC_PROG_CC
Index: jpeg-mingw32.patch
===
RCS file: /cvs/pkgs/rpms/mingw32-libjpeg/devel/jpeg-mingw32.patch,v
retrieving revision 1.1
diff -u -r1.1 jpeg-mingw32.patch
--- jpeg-mingw32.patch 30 Jan 2009 11:48:26 - 1.1
+++ jpeg-mingw32.patch 19 May 2009 14:16:40 -
@@ -1,7 +1,6 @@
-diff -rup jpeg-6b/makefile.cfg jpeg-6b.new/makefile.cfg
jpeg-6b/makefile.cfg 2008-09-09 09:54:38.0 -0400
-+++ jpeg-6b.new/makefile.cfg 2008-09-09 09:55:03.0 -0400
-@@ -169,7 +169,7 @@ libjpeg.a: @A2K_DEPS@ $(LIBOBJECTS)
+--- ./makefile.cfg.mingw32 2009-05-19 14:56:43.0 +0200
./makefile.cfg 2009-05-19 14:56:43.0 +0200
+@@ -169,7 +169,7 @@
# with libtool:
libjpeg.la: @A2K_DEPS@ $(LIBOBJECTS)
$(LIBTOOL) --mode=link $(CC) $(CFLAGS) -o libjpeg.la $(LIBOBJECTS) \
@@ -10,3 +9,28 @@
# sample programs:
+--- ./jconfig.vc.mingw32 2009-05-19 15:02:19.0 +0200
./jconfig.vc 2009-05-19 15:03:51.0 +0200
+@@ -21,6 +21,11 @@
+ #endif
+ #define HAVE_BOOLEAN /* prevent jmorecfg.h from redefining it */
+
++/* Define "INT32" as int, not long, per Windows custom */
++#ifndef __BASETSD_H__ /* don't conflict if basetsd.h already read */
++typedef int INT32;
++#endif
++#define HAVE_INT32/* prevent jmorecfg.h from redefining it */
+
+ #ifdef JPEG_INTERNALS
+
+--- ./jmorecfg.h.mingw32 2009-05-19 15:01:33.0 +0200
./jmorecfg.h 2009-05-19 15:02:07.0 +0200
+@@ -157,7 +157,7 @@
+
+ /* INT32 must hold at least signed 32-bit values. */
+
+-#ifndef XMD_H /* X11/xmd.h correctly defines INT32 */
++#ifndef HAVE_INT32
+ typedef long INT32;
+ #endif
+
Index: mingw32-libjpeg.spec
===
RCS file: /cvs/pkgs/rpms/mingw32-libjpeg/devel/mingw32-libjpeg.spec,v
retrieving revision 1.3
diff -u -r1.3 mingw32-libjpeg.spec
--- mingw32-libjpeg.spec26 Feb 2009 01:14:41 - 1.3
+++ mingw32-libjpeg.spec19 May 2009 14:16:40 -
@@ -10,7 +10,7 @@
Name: mingw32-libjpeg
Version:6b
-Release:10%{?dist}
+Release:11%{?dist}
Summary:MinGW Windows Libjpeg library
License:IJG
@@ -50,7 +50,7 @@
%patch5 -p1 -b .oflo
%patch6 -p1
-%patch100 -p1
+%patch100 -p1 -b .mingw32
# For long-obsolete reasons, libjpeg 6b doesn't ship with a configure.in.
# We need to re-autoconf though, in order to update libtool support,
@@ -137,6 +137,9 @@
%changelog
+* Tue May 19 2009 Zoltan Seress - 6b-11.el5
+- modify jpeg-mingw32.patch to use correct typedefs on Windows
+
* Wed Feb 25 2009 Fedora Release Engineering
- 6b-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: how to patch native pacakge
Richard W.M. Jones wrote: > On Tue, May 19, 2009 at 03:19:02PM +0200, Farkas Levente wrote: >> Fridrich Strba wrote: >>> I meant the install.doc document >> ok we rtfm:-) so we fix it. >> may i apply this patch to the fedora cvs? > > I don't think this patch is correct or follows Fridrich's suggestion > to look at install.doc. This really needs to be discussed with > 'upstream' libjpeg -- whoever that is at the moment [see my other > email]. Please make some effort to contact them and have them make a > decision on this. we do what install.doc says, - replace jconfig.cfg with jconfig.vc which is the visual c compiler's config suggested by install.doc - for INT32 we define the same way in jconfig.vc as they did for boolean - and use HAVE_INT32 for jmorecfg.h as they used for HAVE_BOOLEAN what's the problem? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: how to patch native pacakge
Fridrich Strba wrote:
> I meant the install.doc document
>
> Cheers
>
> Fridrich
>
> On Fri, 2009-05-15 at 23:00 +0200, Fridrich Strba wrote:
>> Why not to read the README in the sources concerning win32 and do
>> exactly what they suggest?
>>
>> Fridrich
>>
>> On Fri, 2009-05-15 at 16:19 +0200, Farkas Levente wrote:
>>> hi,
>>> it's turn out mingw32-libjpeg can't be used since it's contains a few
>>> typedef (INT32, boolean) which already defined in w32api so it's works
>>> as a native lib but not as mingw32 lib. i'd like to make a patch for
>>> this. what's the recommended way for this:
>>> - should i apply a patch which simply remove these typedefs or
>>> - add an extra ifdef for these typedef (and which ifdef use for this
>>> purpose)?
>>> thanks.
ok we rtfm:-) so we fix it.
may i apply this patch to the fedora cvs?
--
Levente "Si vis pacem para bellum!"
Index: jpeg-mingw32.patch
===
RCS file: /cvs/pkgs/rpms/mingw32-libjpeg/devel/jpeg-mingw32.patch,v
retrieving revision 1.1
diff -u -r1.1 jpeg-mingw32.patch
--- jpeg-mingw32.patch 30 Jan 2009 11:48:26 - 1.1
+++ jpeg-mingw32.patch 19 May 2009 13:17:56 -
@@ -1,7 +1,6 @@
-diff -rup jpeg-6b/makefile.cfg jpeg-6b.new/makefile.cfg
jpeg-6b/makefile.cfg 2008-09-09 09:54:38.0 -0400
-+++ jpeg-6b.new/makefile.cfg 2008-09-09 09:55:03.0 -0400
-@@ -169,7 +169,7 @@ libjpeg.a: @A2K_DEPS@ $(LIBOBJECTS)
+--- ./makefile.cfg.mingw32 2009-05-19 14:56:43.0 +0200
./makefile.cfg 2009-05-19 14:56:43.0 +0200
+@@ -169,7 +169,7 @@
# with libtool:
libjpeg.la: @A2K_DEPS@ $(LIBOBJECTS)
$(LIBTOOL) --mode=link $(CC) $(CFLAGS) -o libjpeg.la $(LIBOBJECTS) \
@@ -10,3 +9,28 @@
# sample programs:
+--- ./jconfig.vc.mingw32 2009-05-19 15:02:19.0 +0200
./jconfig.vc 2009-05-19 15:03:51.0 +0200
+@@ -21,6 +21,11 @@
+ #endif
+ #define HAVE_BOOLEAN /* prevent jmorecfg.h from redefining it */
+
++/* Define "INT32" as int, not long, per Windows custom */
++#ifndef __BASETSD_H__ /* don't conflict if basetsd.h already read */
++typedef int INT32;
++#endif
++#define HAVE_INT32/* prevent jmorecfg.h from redefining it */
+
+ #ifdef JPEG_INTERNALS
+
+--- ./jmorecfg.h.mingw32 2009-05-19 15:01:33.0 +0200
./jmorecfg.h 2009-05-19 15:02:07.0 +0200
+@@ -157,7 +157,7 @@
+
+ /* INT32 must hold at least signed 32-bit values. */
+
+-#ifndef XMD_H /* X11/xmd.h correctly defines INT32 */
++#ifndef HAVE_INT32
+ typedef long INT32;
+ #endif
+
Index: mingw32-libjpeg.spec
===
RCS file: /cvs/pkgs/rpms/mingw32-libjpeg/devel/mingw32-libjpeg.spec,v
retrieving revision 1.3
diff -u -r1.3 mingw32-libjpeg.spec
--- mingw32-libjpeg.spec26 Feb 2009 01:14:41 - 1.3
+++ mingw32-libjpeg.spec19 May 2009 13:17:56 -
@@ -10,7 +10,7 @@
Name: mingw32-libjpeg
Version:6b
-Release:10%{?dist}
+Release:11%{?dist}
Summary:MinGW Windows Libjpeg library
License:IJG
@@ -50,7 +50,7 @@
%patch5 -p1 -b .oflo
%patch6 -p1
-%patch100 -p1
+%patch100 -p1 -b .mingw32
# For long-obsolete reasons, libjpeg 6b doesn't ship with a configure.in.
# We need to re-autoconf though, in order to update libtool support,
@@ -137,6 +137,9 @@
%changelog
+* Tue May 19 2009 Zoltan Seress - 6b-11.el5
+- modify jpeg-mingw32.patch to use correct typedefs on Windows
+
* Wed Feb 25 2009 Fedora Release Engineering
- 6b-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: [Bug 497492] mingw32-libjpeg crash on windows, typedef
bugzi...@redhat.com wrote: > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug. > > > https://bugzilla.redhat.com/show_bug.cgi?id=497492 > > > > > > --- Comment #5 from Kevin Kofler 2009-04-26 > 01:14:47 EDT --- > Looks like the problem here is that rpcndr.h and libjpeg both define a > "boolean" type, and whoever is included first "wins". So programs including > rpcndr.h before libjpeg will try using the wrong boolean type. i don't understand the "wins" for me it's an error since: error: conflicting types for 'boolean' anyway the INT32 problem can be fixed easily, but my original question still do i simple remove the declaration of INT32 or do some more advance ifdef? and what other can do with the boolean problem? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: how to patch native pacakge
Erik van Pienbroek wrote: > Op vrijdag 15-05-2009 om 16:53 uur [tijdzone +0200], schreef Kevin > Kofler: >> Please see the existing discussion on this issue, somebody already wanted to >> patch mingw32-libjpeg that way, but libjpeg upstream said it's wrong, >> changing those typedefs breaks ABI compatibility. > > With the current state, the ABI is undefined anyway for Win32 targets, > so the question is what the libjpeg people actually think that the > datatype should be. When we've got an answer to that question we can > decide how to fix the issue. but until then it's currently unusable:-( -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
how to patch native pacakge
hi, it's turn out mingw32-libjpeg can't be used since it's contains a few typedef (INT32, boolean) which already defined in w32api so it's works as a native lib but not as mingw32 lib. i'd like to make a patch for this. what's the recommended way for this: - should i apply a patch which simply remove these typedefs or - add an extra ifdef for these typedef (and which ifdef use for this purpose)? thanks. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: mingw32-sqlite
Thomas Sailer wrote:
> On Thu, 2009-04-23 at 14:13 +0200, Erik van Pienbroek wrote:
>
>> The way you've overriden the MINGW32_CFLAGS might cause issues in the
>> future when the MINGW32_CFLAGS in /etc/rpm/macros.mingw32 might get
>> changed.
>
> I was worried about this too
>
>
>> You can try to change the line:
>> export MINGW32_CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
>> -fexceptions --param=ssp-buffer-size=4 -mms-bitfields
>> -DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DISABLE_DIRSYNC=1
>> -DSQLITE_ENABLE_FTS3=3 -DSQLITE_ENABLE_RTREE=1 -fno-strict-aliasing"
>>
>> to this:
>> export MINGW32_CFLAGS="$MINGW32_CFLAGS -DSQLITE_ENABLE_COLUMN_METADATA=1
>> -DSQLITE_DISABLE_DIRSYNC=1 -DSQLITE_ENABLE_FTS3=3
>> -DSQLITE_ENABLE_RTREE=1 -fno-strict-aliasing"
>
> Good idea - except it does not work, as MINGW32_CFLAGS are only set when
> configure runs, they are unset when I do the export. See
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1317231
>
> So a working solution might look something like:
> export MINGW32_CFLAGS="`rpm --eval %{_mingw32_cflags}`
> -DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DISABLE_DIRSYNC=1
> -DSQLITE_ENABLE_FTS3=3 -DSQLITE_ENABLE_RTREE=1 -fno-strict-aliasing"
why not:
export MINGW32_CFLAGS="%{_mingw32_cflags}
-DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DISABLE_DIRSYNC=1
-DSQLITE_ENABLE_FTS3=3 -DSQLITE_ENABLE_RTREE=1 -fno-strict-aliasing"
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: rpms/mingw32-filesystem/F-11 mingw32-filesystem.spec, 1.21, 1.22 mingw32-find-requires.sh, 1.1, 1.2
why we start to use this kind of release 3%{?dist}.1 ?
Richard W.M. Jones wrote:
> Author: rjones
>
> Update of /cvs/pkgs/rpms/mingw32-filesystem/F-11
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv28168
>
> Modified Files:
> mingw32-filesystem.spec mingw32-find-requires.sh
> Log Message:
> Fix dependency problem with + in DLL name (Thomas Sailer).
>
>
> Index: mingw32-filesystem.spec
> ===
> RCS file: /cvs/pkgs/rpms/mingw32-filesystem/F-11/mingw32-filesystem.spec,v
> retrieving revision 1.21
> retrieving revision 1.22
> diff -u -r1.21 -r1.22
> --- mingw32-filesystem.spec 27 Mar 2009 09:20:25 - 1.21
> +++ mingw32-filesystem.spec 21 Apr 2009 22:25:53 - 1.22
> @@ -2,7 +2,7 @@
>
> Name: mingw32-filesystem
> Version:50
> -Release:3%{?dist}
> +Release:3%{?dist}.1
> Summary:MinGW base filesystem and environment
>
> Group: Development/Libraries
> @@ -158,6 +158,9 @@
>
>
> %changelog
> +* Tue Apr 21 2009 Richard W.M. Jones - 50-3.1
> +- Fix dependency problem with + in DLL name (Thomas Sailer).
> +
> * Fri Mar 27 2009 Richard W.M. Jones - 50-3
> - Fix up and test mingw32-pkg-config changes.
>
>
>
> Index: mingw32-find-requires.sh
> ===
> RCS file: /cvs/pkgs/rpms/mingw32-filesystem/F-11/mingw32-find-requires.sh,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- mingw32-find-requires.sh 30 Oct 2008 09:49:17 - 1.1
> +++ mingw32-find-requires.sh 21 Apr 2009 22:25:53 - 1.2
> @@ -22,7 +22,7 @@
> dlls=$(echo $filelist | tr [:blank:] '\n' | grep -Ei '\.(dll|exe)$')
>
> for f in $dlls; do
> -$OBJDUMP -p $f | grep 'DLL Name' | grep -Eo '[-._[:alnum:]]+\.dll' |
> +$OBJDUMP -p $f | grep 'DLL Name' | grep -Eo '[-._\+[:alnum:]]+\.dll' |
> tr [:upper:] [:lower:] |
> sed 's/\(.*\)/mingw32(\1)/'
> done | sort -u
>
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Thanks and a question or two
Richard W.M. Jones wrote: > On Thu, Mar 26, 2009 at 10:44:37PM +0100, Farkas Levente wrote: >> Richard W.M. Jones wrote: >>> http://cvs.fedoraproject.org/viewvc/devel/mingw32-filesystem/macros.mingw32?annotate=1.2#l57 >>> >>> However it might be worth having a "mingw32-pkgconfig" shell script >>> which just sets that variable and runs pkgconfig ... >> as you like:-) > > Yes, that looks good, but let me check it more carefully tomorrow > morning. the reason to remove rpmlint versioned require since it's already at that version in f10, f11 and epel-5 too. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Thanks and a question or two
Richard W.M. Jones wrote:
> http://cvs.fedoraproject.org/viewvc/devel/mingw32-filesystem/macros.mingw32?annotate=1.2#l57
>
> However it might be worth having a "mingw32-pkgconfig" shell script
> which just sets that variable and runs pkgconfig ...
as you like:-)
ps. on monday i'll go for a 2 weeks holiday:-)
--
Levente "Si vis pacem para bellum!"
Index: macros.mingw32
===
RCS file: /cvs/pkgs/rpms/mingw32-filesystem/devel/macros.mingw32,v
retrieving revision 1.2
diff -u -r1.2 macros.mingw32
--- macros.mingw32 18 Feb 2009 17:06:07 - 1.2
+++ macros.mingw32 26 Mar 2009 21:37:08 -
@@ -78,6 +78,10 @@
done; \
unset x i
+%_mingw32_pkgconfig \
+ PKG_CONFIG_LIBDIR="%{_mingw32_libdir}/pkgconfig"; export PKG_CONFIG_LIBDIR; \
+ unset PKG_CONFIG_PATH; \
+ pkgconfig
%_mingw32_configure %{_mingw32_env} ; \
__mingw32_topdir=.; if ! test -x configure; then __mingw32_topdir=..; fi; \\\
Index: mingw32-filesystem.spec
===
RCS file: /cvs/pkgs/rpms/mingw32-filesystem/devel/mingw32-filesystem.spec,v
retrieving revision 1.20
diff -u -r1.20 mingw32-filesystem.spec
--- mingw32-filesystem.spec 26 Feb 2009 01:03:00 - 1.20
+++ mingw32-filesystem.spec 26 Mar 2009 21:37:08 -
@@ -1,8 +1,8 @@
%define debug_package %{nil}
Name: mingw32-filesystem
-Version:49
-Release:3%{?dist}
+Version:50
+Release:1%{?dist}
Summary:MinGW base filesystem and environment
Group: Development/Libraries
@@ -22,9 +22,9 @@
Requires: setup
Requires: rpm
-Requires: rpmlint >= 0.85-2
+Requires: rpmlint
-BuildRequires: rpmlint >= 0.85-2
+BuildRequires: rpmlint
# Note about 'Provides: mingw32(foo.dll)'
#
@@ -83,7 +83,7 @@
mkdir -p $RPM_BUILD_ROOT%{_bindir}
pushd $RPM_BUILD_ROOT%{_bindir}
-for i in mingw32-configure mingw32-make; do
+for i in mingw32-configure mingw32-make mingw32-pkgconfig; do
ln -s %{_libexecdir}/mingw32-scripts $i
done
popd
@@ -156,6 +156,9 @@
%changelog
+* Thu Mar 26 2009 Levente Farkas - 50-1
+- Add mingw32-pkgconfig
+
* Wed Feb 25 2009 Fedora Release Engineering
- 49-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Thanks and a question or two
John Stebbins wrote: > This may not be your area of concern, but MinGw has problems with large > file support. They've had a ticket open for it since 2006 and a few > patches have been floating around, but no resolution. I had to patch > several things to accommodate. the reason for this because msvcrt doesn't support it in early version. all you have to do build with: make CFLAGS="$CFLAGS -D__MSVCRT_VERSION__=0x0601" anyway it's be useful to show us the patches! -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
mingw32-gstreamer
hi, i create a new rr for mingw32-gstreamer: https://bugzilla.redhat.com/show_bug.cgi?id=491317 -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: mingw defines __MSVCRT_VERSION__
Kevin Kofler wrote: > Farkas Levente wrote: >> may be it's not the right place to ask and would be better to move to >> mingw mailing list, but it's the right version? >> ie. the current runtime really not support __MSVCRT_VERSION__ >= 0x0601? >> thanks. > > No, it's just that the default version is 0x0600 to be compatible with old > installed versions of msvcrt.dll. > > You can compile with -D__MSVCRT_VERSION__=0x0601, but then expect trouble on > systems which still ship the ancient 0x0600 version (e.g. Window$ 95 OSR 2, > I guess - the original Window$ 95 didn't include msvcrt.dll at all). I'm > not sure when the 0x0601 version was introduced nor whether it's worth > caring about the systems which shipped the 0x0600 version and never got > their msvcrt.dll upgraded by a newer M$VC application. ok i know that and it's works, but the real question is: do we want to support such old systems? if not shouldn't we have to add -D__MSVCRT_VERSION__=0x0601 (or even 0x0700) to macros.mingw32's %_mingw32_cflags? so which windows version we'd like to support? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
mingw defines __MSVCRT_VERSION__
hi,
while we try to compile gstreamer we got and error
error: storage size of 'stat_results' isn't known
and the reason is that because __stat64 is defined in
/usr/i686-pc-mingw32/sys-root/mingw/include/sys/stat.h
but only as :
#if __MSVCRT_VERSION__ >= 0x0601
struct __stat64
{
_dev_t st_dev;
_ino_t st_ino;
_mode_t st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
__int64 st_size;
__time64_t st_atime;
__time64_t st_mtime;
__time64_t st_ctime;
};
#endif /* __MSVCRT_VERSION__ */
and at the same time in
/usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h :
#ifndef __MSVCRT_VERSION__
/* High byte is the major version, low byte is the minor. */
# define __MSVCRT_VERSION__ 0x0600
#endif
may be it's not the right place to ask and would be better to move to
mingw mailing list, but it's the right version?
ie. the current runtime really not support __MSVCRT_VERSION__ >= 0x0601?
thanks.
yours.
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
mingw32-liboil
hi, i submit liboil as the first step to the gstreamer packages: https://bugzilla.redhat.com/show_bug.cgi?id=490704 i leave in comment the original devel part in case we move to static/devel subpackage in f12. also we use 0.3.15 even though in rawhide only has 3.14 since it can't compile on windows. scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1246533 i hope someone can review it:-) -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Fedora 12: What projects for F12?
Richard W.M. Jones wrote: > On Fri, Mar 13, 2009 at 03:30:21PM +0100, Farkas Levente wrote: >> NightStrike wrote: >>> On Fri, Mar 13, 2009 at 10:11 AM, Farkas Levente >>> wrote: >>>>> (2)? Use mingw-w64 project to build 32 bit w32api/runtime, since >>>>> mingw-w64 seems to be more active. >>>> we can still use mingw32 until mingw-64 will be ready to switch and the >>>> changes can be done in the background. >>> We're ready now :) >> ok:-) then wouldn't it be useful for everybody to megre mingw32 with >> mingw64. or at least start the process... > > I talked to NightStrike about this already, and said basically nothing > will get done until Fedora 11 is released. This thread is for > planning what happens *after* that. i mean above that the upstream mingw32 and mingw64 merge. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Fedora 12: What projects for F12?
NightStrike wrote: > On Fri, Mar 13, 2009 at 10:11 AM, Farkas Levente wrote: >>> (2)? Use mingw-w64 project to build 32 bit w32api/runtime, since >>> mingw-w64 seems to be more active. >> we can still use mingw32 until mingw-64 will be ready to switch and the >> changes can be done in the background. > > We're ready now :) ok:-) then wouldn't it be useful for everybody to megre mingw32 with mingw64. or at least start the process... -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Fedora 12: What projects for F12?
Richard W.M. Jones wrote: > On Fri, Mar 13, 2009 at 03:11:24PM +0100, Farkas Levente wrote: >> (9) gstreamer support. we already working on it, but it's not too easy:-( > > Have you got any candidate packages for this? What does it involve? we've got a few but as i don't have time to look into them i'd not like to share them. first i'd like to review they are very experimental. unfortunately gstreamer has a lots of dependencies:-( and most of he has problems to compile on windows... -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Fedora 12: What projects for F12?
Richard W.M. Jones wrote: > Fedora 11 is nearly in beta, and thanks to some judicious cuts at the > end, we made it to 100% feature complete. Thanks to the many people > who helped out reviewing packages and testing. > > What do we want to aim for in Fedora 12? > > Some ideas - please add your own to this thread. > > (1) Win64 support > (see: > http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-February/thread.html#464 > ) yes. > (2)? Use mingw-w64 project to build 32 bit w32api/runtime, since > mingw-w64 seems to be more active. we can still use mingw32 until mingw-64 will be ready to switch and the changes can be done in the background. > (3) Darwin / OS X support > (see: > https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00397.html ) yes (if won't have license problems) > (4) Get some of the issues resolved in the packaging guidelines: > http://fedoraproject.org/wiki/MinGW/Packaging_issues imho we can write packaging guide for CC as an f12 feature and we can start a discussion about it. (9) gstreamer support. we already working on it, but it's not too easy:-( -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Fedora 12: Let's think of a better name for the project
Richard W.M. Jones wrote: > "MinGW" has lots of baggage associated with it. It also conflicts > with the name of just one upstream project, whereas we are actually > using many upstream projects and MinGW code is only a tiny fraction of > the total. > > We also want to expand the project to cover Win64 and Darwin (if we > can make that work). > > Let's think of a new name for Fedora 12. > > The rules: > > (1) We cannot use trademarked words like "Windows" in the project > name. > > (2) The name must be unique, easy to pronounce, hard to confuse, and > available to register as a domain name. > > (3) Don't want to interfere with or get confused with the other > cross-compilers in Fedora, ie. the ones for embedded platforms. > > My vote is for: > > [Fedora] Consumer Cross-Compiler [Collection] > (abbreviated as CCC or ) > > Add your suggestions or votes below ... as i wrote earlier i'd like to merge these 3 (or even more) to one common name. cross-* packages names won't conflict anything and in this case "...Cross-Compiler..." would be good. ps. just not to conflict with CCC http://www.ccc.de/ which is a well-known group/name... -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Compiling with pthreads
Richard W.M. Jones wrote:
> On Fri, Mar 13, 2009 at 09:00:19AM -0400, David Shaw wrote:
>> Sure, that's possible. There are half a dozen or more autoconf-ish
>> ways to do this. What surprises me is that this is necessary. Isn't
>> part of the point here to not need to make such changes for a header
>> that is supposed to (as per POSIX) be in the main include directory,
>> rather than a subdirectory? It seems it would make cross-compiling a
>> much harder task if we need to modify code or put in special autoconf
>> tests to catch the cross-compiling case for something as simple (from
>> the outside, anyway) as pthreads.
>
> I think as you say if POSIX specifies it, it's a bug. Either in our
> package or in the upstream pthreads-win32 package. If you file a bug
> against it, we can resolve it [even better if you file a bug with a
> patch!] - http://bugzilla.redhat.com/
>
> Having said that, you shouldn't expect programs to just compile
> straightaway without changes. Although we happen to support an
> emulation of POSIX pthreads, we don't in general support POSIX at all,
> and sometimes you have to make big changes to code to make it run
> using our compiler -- eg. changing POSIX/libc calls to use Microsoft's
> Win32 APIs.
>
> mingw32-crossreport, q.v.
we can simple put it into the main include dir with in the spec file
change from:
install -m 0644 *.h $RPM_BUILD_ROOT%{_mingw32_includedir}/pthread
to:
install -m 0644 *.h $RPM_BUILD_ROOT%{_mingw32_includedir}
and i tend to agree with david that it'd be better since it's there on
linux too ...
should it hurt anyone/anything?
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Patch for ming32-zlib.spec to enable static package
Richard W.M. Jones wrote:
> On Tue, Mar 10, 2009 at 01:45:34PM +0100, Farkas Levente wrote:
>> Richard W.M. Jones wrote:
>>> On Tue, Mar 10, 2009 at 12:32:18AM +0100, Wojciech Pilorz wrote:
>>>> +%package static
>>>> +Summary: Static libraries for mingw32-zlib development.
>>>> +Group: Development/Libraries
>>>> +Requires: zlib = %{version}
>>>
>>>
>>> This patch is good, except did you mean 'Requires: mingw32-zlib =
>>> %{version}-%{release}' there?
>> why require mingw32-zlib at all for the static lib?
>
> It's debatable in this case, but in other cases the base package
> contains binaries, license and README files which are applicable to
> the static package too.
>
> (mingw32-zlib doesn't contain a license file, but that's a bug ...)
>
> It doesn't really matter if we pull in the DLL along with the static
> library, since this only applies on developer workstations. It
> doesn't affect the resultant binary or how it is deployed in any way.
ok. now i can ask it in a more general way.
do we like to support static libs? (i vote for yes)
if yes wouldn't it be better to create -static and -devel pacakges for
all packages (like in native version) and put those common stuff into
the base packages?
ok i know again another mingw packaging guide changes
but at least discuss what would be the 'right way tm'...
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Patch for ming32-zlib.spec to enable static package
Richard W.M. Jones wrote:
> On Tue, Mar 10, 2009 at 12:32:18AM +0100, Wojciech Pilorz wrote:
>> +%package static
>> +Summary: Static libraries for mingw32-zlib development.
>> +Group: Development/Libraries
>> +Requires: zlib = %{version}
>
>
> This patch is good, except did you mean 'Requires: mingw32-zlib =
> %{version}-%{release}' there?
why require mingw32-zlib at all for the static lib?
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Debugging information in MinGW packages
Daniel P. Berrange wrote: > On Wed, Feb 25, 2009 at 02:46:39PM +0100, Kevin Kofler wrote: >> Hi, >> >> what's the correct way to handle debugging information in MinGW packages? >> >> Currently, mingw32-nsis builds everything with debugging information (due to >> the debian-debug-opt patch), even the MinGW parts, but the MinGW debugging >> information is not extracted, so it's included within the binaries. This is >> particularly annoying for NSIS installers as it bloats the installer stubs. >> For example, the lzma_solid stub is 210185 bytes, running a MinGW strip on >> it reduces it to 55296 bytes. >> >> Do we really want debugging information in the MinGW stuff even if it can't >> be extracted into separate -debuginfo? Or should the MinGW portions of NSIS >> be built without -g instead? Should the same policy apply to everything or >> should NSIS be special? (I can see why a developer would want to have >> debugging information for a library, but for an installer?) > > Last time we tried, a cross compiled GDB crashed & burned. So unless someone > can demonstrate a usuable WINE/Win32 debugger that can use the gcc generated > debugging info, then we should not build with -g, nor create -debuginfo > sub-RPMs. the question still apply (i gdb will work) do we want to provide debuginfo for crosscompiled binaries? i don't know what's the good answer:-( -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: GCC 4.4 rebuild results
Richard W.M. Jones wrote:
> On Fri, Feb 20, 2009 at 06:41:46PM +, Richard W.M. Jones wrote:
>> - mingw32-qt-win (4.4.3)
>>
> [...]
>>version we were building, this fails. Solution requires upgrading
>>the mingw32-qt-win package and adding a hard BuildRequires on
>>qt-devel = %{version}.
>
> While I remember, the above didn't actually work. If I have:
>
> Version: 4.5.0
> ...
> BuildRequires: qt-devel = %{version}
>
> then it won't find qt-devel in Rawhide which is 4.5.0-<>
>
> So we still have an unversioned BuildRequires (and Requires) in that
> package.
>
> Anyone got any ideas about this? My best bet was this which is pretty
> ugly:
>
> BuildRequires: qt-devel >= 4.5.0
> BuildRequires: qt-devel < 4.5.1
or may be the mass rebuild starts today to rawhide is not in good shape
in these days...
and during the weekend there was a koji update too (may be a build
system) so you can find a bug:-(
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: GCC 4.4 rebuild results
Richard W.M. Jones wrote:
> On Fri, Feb 20, 2009 at 06:41:46PM +, Richard W.M. Jones wrote:
>> - mingw32-qt-win (4.4.3)
>>
> [...]
>>version we were building, this fails. Solution requires upgrading
>>the mingw32-qt-win package and adding a hard BuildRequires on
>>qt-devel = %{version}.
>
> While I remember, the above didn't actually work. If I have:
>
> Version: 4.5.0
> ...
> BuildRequires: qt-devel = %{version}
>
> then it won't find qt-devel in Rawhide which is 4.5.0-<>
>
> So we still have an unversioned BuildRequires (and Requires) in that
> package.
>
> Anyone got any ideas about this? My best bet was this which is pretty
> ugly:
>
> BuildRequires: qt-devel >= 4.5.0
> BuildRequires: qt-devel < 4.5.1
can you send a scratch build url?
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: rpms/mingw32-nsis/devel import.log, NONE, 1.1 mingw32-nsis.spec, NONE, 1.1 nsis-2.42-debian-64bit-fixes.patch, NONE, 1.1 nsis-2.43-debian-debug-opt.patch, NONE, 1.1 .cvsignore, 1.1, 1.2 sources,
Richard W.M. Jones wrote:
> # since nsis a 32 bit only apps
> #ExclusiveArch: %{ix86} ppc
> #BuildRequires: wxGTK-devel
> # The above is only required for Koji. In mock we _can_ build on
> # x86_64 provided we have the 32 bit libraries required by the next
> # two lines.
> BuildRequires: /usr/include/gnu/stubs-32.h
> BuildRequires: /usr/lib/libwx_baseu-2.8.so
why did you import in that way?
as i wrote it won't compile in koji. exactly that's why i put
ExclusiveArch: %{ix86} ppc
BuildRequires: wxGTK-devel
i even wrote it in the review and in the mailing list.
now you've to do another checkin, tag, build...
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
Richard W.M. Jones wrote: > On Fri, Feb 20, 2009 at 04:51:09PM +0100, Erik van Pienbroek wrote: >> +1 for having both shared and static MinGW libraries. > > We'd need to have -static subpackages, as per Fedora policy. > > This is loads and loads of work which I don't intend to do myself ... this is required for native packages not for mingw packages we can also include this exception in mingw packaging guide. may be we can wait a little bit when a new packaging guide will created/accepted for all of our target platform and in this guideline add this exception too. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: NSPR (Netscape Portable Runtime) and NSS (Netscape Security lib) uploaded
Richard W.M. Jones wrote:
> On Wed, Feb 18, 2009 at 04:36:52PM +0100, Farkas Levente wrote:
>> Richard W.M. Jones wrote:
>>> I just uploaded NSPR and NSS, source in the Mercurial repository, binaries
>>> for Rawhide in the temporary yum repository:
>>>
>>> http://homes.merjis.com/~rich/mingw/
>>>
>>> These are major libraries, used directly or indirectly by a lot of
>>> software, so any testing / bug reports gratefully received.
>> first quick look and no patches:
>> - nss
>> PatchX: missing from spec?
>> --
>> rpmlint mingw32-nss.spec
>> mingw32-nss.spec:96: W: rpm-buildroot-usage %build %{__mkdir_p}
>> $RPM_BUILD_ROOT/%{_libdir}/pkgconfig
>> mingw32-nss.spec:103: W: rpm-buildroot-usage %build
>> $RPM_BUILD_ROOT/%{_libdir}/pkgconfig/nss.pc
>> mingw32-nss.spec:115: W: rpm-buildroot-usage %build %{__mkdir_p}
>> $RPM_BUILD_ROOT/%{_bindir}
>> mingw32-nss.spec:123: W: rpm-buildroot-usage %build >
>> $RPM_BUILD_ROOT/%{_bindir}/nss-config
>> mingw32-nss.spec:125: W: rpm-buildroot-usage %build chmod 755
>> $RPM_BUILD_ROOT/%{_bindir}/nss-config
>> --
>> why eg. %{__mkdir_p} $RPM_BUILD_ROOT/%{_bindir} in the %build section
>> and not in the %install section?
>> and it's rather complicated so i can't take the plunge to review it now:-(
>>
>> - nspr
>> why:
>> %{_mingw32_configure} \
>> --prefix=%{_mingw32_prefix} \
>> --libdir=%{_mingw32_libdir} \
>> since _mingw32_configure already contains it.
>>
>> in stead of:
>> make \
>> NSINSTALL=$(pwd)/config/nsinstall \
>> RANLIB=i686-pc-mingw32-ranlib \
>> RC=i686-pc-mingw32-windres \
>> %{?_smp_mflags}
>> at least use _mingw32_ranlib etc or even better %{_mingw32_make}
>
> Thanks - these are all good suggestions.
>
> I've actually been tipped off[0] that these NSPR/NSS packages probably
> won't work because gcc ignores the __declspec(thread) annotations
> (Thread Local Storage under Windows, q.v.[1]). I'm going to look at a
> fix for this shortly.
>
> Rich.
>
> [0] Novell's packages:
>
> http://download.opensuse.org/repositories/home:/fstrba:/CrossMingw:/test/openSUSE_11.1/noarch/
hoops i don't know they take our spec files and now even ahead of us or
at least take all of our specs:-( it'd be nice if they can also help us...
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: NSPR (Netscape Portable Runtime) and NSS (Netscape Security lib) uploaded
Richard W.M. Jones wrote:
> I just uploaded NSPR and NSS, source in the Mercurial repository, binaries
> for Rawhide in the temporary yum repository:
>
> http://homes.merjis.com/~rich/mingw/
>
> These are major libraries, used directly or indirectly by a lot of
> software, so any testing / bug reports gratefully received.
first quick look and no patches:
- nss
PatchX: missing from spec?
--
rpmlint mingw32-nss.spec
mingw32-nss.spec:96: W: rpm-buildroot-usage %build %{__mkdir_p}
$RPM_BUILD_ROOT/%{_libdir}/pkgconfig
mingw32-nss.spec:103: W: rpm-buildroot-usage %build
$RPM_BUILD_ROOT/%{_libdir}/pkgconfig/nss.pc
mingw32-nss.spec:115: W: rpm-buildroot-usage %build %{__mkdir_p}
$RPM_BUILD_ROOT/%{_bindir}
mingw32-nss.spec:123: W: rpm-buildroot-usage %build >
$RPM_BUILD_ROOT/%{_bindir}/nss-config
mingw32-nss.spec:125: W: rpm-buildroot-usage %build chmod 755
$RPM_BUILD_ROOT/%{_bindir}/nss-config
--
why eg. %{__mkdir_p} $RPM_BUILD_ROOT/%{_bindir} in the %build section
and not in the %install section?
and it's rather complicated so i can't take the plunge to review it now:-(
- nspr
why:
%{_mingw32_configure} \
--prefix=%{_mingw32_prefix} \
--libdir=%{_mingw32_libdir} \
since _mingw32_configure already contains it.
in stead of:
make \
NSINSTALL=$(pwd)/config/nsinstall \
RANLIB=i686-pc-mingw32-ranlib \
RC=i686-pc-mingw32-windres \
%{?_smp_mflags}
at least use _mingw32_ranlib etc or even better %{_mingw32_make}
i've got flu and fever so won't send any patches in this week to these
packages.
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: [jkeat...@redhat.com: Fedora 11 Mass Rebuild]
Richard W.M. Jones wrote: > On Wed, Feb 18, 2009 at 10:30:46AM +, Daniel P. Berrange wrote: >> So we need to upgrade our mingw-gcc to version 4.4. The trouble is that >> they are not doing an ordered rebuild, so they may well rebuild the >> mingw packages before they rebuild our toolchain. > > I'm not sure I understand this bit - can you explain a bit more? first of all the rebuild only happened in rawhide and imho in our case the best would be wait the end of the rebuild and then update our gcc to 4.4. and mass rebuild all of our packages. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: pthreads
Richard W.M. Jones wrote: > On Mon, Feb 16, 2009 at 11:16:59AM +0100, Farkas Levente wrote: >> hi, >> i don't know whether i send this patch? >> this is the update to the latest cvs of pthreads (eg for mingw64). > > I'll have to have a look at this in the evening or later this week > because I'm busy for the next few days. But out of interest did it > compile with the mingw64-* compiler? i run other tests with mingw64... just after that i come back. so in short i didn't test it:-) -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
pthreads
hi,
i don't know whether i send this patch?
this is the update to the latest cvs of pthreads (eg for mingw64).
--
Levente "Si vis pacem para bellum!"
Index: mingw32-pthreads.spec
===
RCS file: /cvs/pkgs/rpms/mingw32-pthreads/devel/mingw32-pthreads.spec,v
retrieving revision 1.1
diff -u -r1.1 mingw32-pthreads.spec
--- mingw32-pthreads.spec 14 Jan 2009 09:45:11 - 1.1
+++ mingw32-pthreads.spec 16 Feb 2009 10:13:43 -
@@ -7,9 +7,11 @@
# The tests take ages to run and require Wine.
%define run_tests 0
+%define cvs_date 20090213
+
Name: mingw32-pthreads
Version:2.8.0
-Release:4%{?dist}
+Release:5.%{cvs_date}%{?dist}
Summary:MinGW pthread library
%define crazy_version %(echo %{version}|tr . -)
@@ -17,7 +19,12 @@
License:LGPLv2+
Group: Development/Libraries
URL:http://sourceware.org/pthreads-win32/
-Source0:
ftp://sourceware.org/pub/pthreads-win32/pthreads-w32-%{crazy_version}-release.tar.gz
+# The source for this package was pulled from upstream's vcs. Use the
+# following commands to generate the tarball:
+# cvs -d :pserver:anon...@sourceware.org:/cvs/pthreads-win32 checkout -D
%{cvs_date} pthreads
+# tar czvf pthreads-%{cvs_date}.tar.gz pthreads
+#Source0:
ftp://sourceware.org/pub/pthreads-win32/pthreads-w32-%{crazy_version}-release.tar.gz
+Source0:
ftp://sourceware.org/pub/pthreads-win32/pthreads-%{cvs_date}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
@@ -52,7 +59,7 @@
%prep
-%setup -q -n pthreads-w32-%{crazy_version}-release
+%setup -q -n pthreads
%patch0 -p1
%patch1 -p1
@@ -109,6 +116,9 @@
%changelog
+* Fri Feb 13 2009 Levente Farkas - 2.8.0-5.20090213
+- update to the cvs version
+
* Tue Jan 13 2009 Richard W.M. Jones - 2.8.0-4
- Cleanup to the spec file, no functional changes.
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: More notes on Darwin porting
Richard W.M. Jones wrote: > Now these runtime files are open source -- kinda. Apple distributes > them in the Csu package[1] which is under the APSL 1.0. This license > is listed under Bad Licenses here[2], but you should note that this > list includes both non-free licenses AND deprecated licenses (APSL > latest is 2.0), and I have not determined which category this falls > under. > > [1] http://www.opensource.apple.com/darwinsource/ > [2] http://fedoraproject.org/wiki/Licensing#Bad_Licenses it'd be easier to ask Tom "spot" Callaway before doing anything it's happened that he change his positions. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Example "cross-zlib" package added to Mercurial
Richard W.M. Jones wrote: >>> +BuildRequires: mingw64-filesystem >= 10 >> ihmo here again would be better to one common cross-filesystem which >> contains all macros, script, dirs etc. why we create 3 such packages? i >> think now and in a few months as many things get clear (as daniel >> suggested) would be better to create test packages based on a new >> 'feature for f12 cross-compiler'. > > There's not a lot of commonality. The filesystem layouts are quite > different between the three cross-compilers. most macros are very similar and keep them in one common packages can help to stay them in sync. >>> +BuildRequires: mingw64-gcc >>> +BuildRequires: mingw64-binutils >> and again if we create cross-xxx packages then we can create >> meta-packages like cross-gcc which requires all gcc and these BR can be >> 3 times shorter. > > On the other hand, this is an actively bad idea. We are currently > using 3 different versions of GCC from 3 different upstream projects. > Binutils doesn't even exist on Darwin. Go and have a look at this > diagram again: > > http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-February/000465.html ok may be not for gcc but imho it's much cleaner to: BuildRequires: cross-zlib than BuildRequires: mingw32-zlib BuildRequires: mingw64-zlib BuildRequires: darwin-zlib -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: nsiswrapper
Richard W.M. Jones wrote:
> On Sun, Feb 15, 2009 at 09:24:24PM +0100, Farkas Levente wrote:
>> hi,
>> in the script itself these settings:
>> -
>> # XXX Should make these configurable.
>> my $mingw32_prefix = '/usr/i686-pc-mingw32/sys-root/mingw';
>> my $mingw32_bindir = $mingw32_prefix . '/bin';
>> my $mingw32_libdir = $mingw32_prefix . '/lib';
>> my $mingw32_sysconfdir = $mingw32_prefix . '/etc';
>> -
>> can be set by
>> rpm --eval %{_mingw32_xxx}
>> it's be cleaner and more flexible.
>> also hard coded: i686-pc-mingw32-objdump to %_mingw32_objdump
>> and in the manual the path:
>> /usr/i686-pc-mingw32/sys-root/mingw/
>> can be somehow evaluated.
>
> You got an actual patch? It's easier to evaluate a patch, and also
> easier to apply one.
i don't know perl very well so leave the implementation for you:-) it
was just my quick review of the script.
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: nsis
Richard W.M. Jones wrote:
> On Sun, Feb 15, 2009 at 08:33:43PM +0100, Farkas Levente wrote:
>> hi,
>> you change to this in nsis:
>>
>> # since nsis a 32 bit only apps
>> #ExclusiveArch: %{ix86} ppc
>> #BuildRequires: wxGTK-devel
>> # The above is only required for Koji. In mock we _can_ build on
>> # x86_64 provided we have the 32 bit libraries required by the next
>> # two lines.
>> BuildRequires: /usr/include/gnu/stubs-32.h
>> BuildRequires: /usr/lib/libwx_baseu-2.8.so
>>
>> which is actually true but can't help us since we'd like to add to
>> fedora so build in koji!?
>
> We will do, but in the meantime I would like to build it using smock
> from the Mercurial repo, so I need those lines.
but both for koji and mock the
ExclusiveArch: %{ix86} ppc
BuildRequires: wxGTK-devel
work! (ok not on x86_64 but since can't build it in koji why do you like
to build in smock?)
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
nsiswrapper
hi,
in the script itself these settings:
-
# XXX Should make these configurable.
my $mingw32_prefix = '/usr/i686-pc-mingw32/sys-root/mingw';
my $mingw32_bindir = $mingw32_prefix . '/bin';
my $mingw32_libdir = $mingw32_prefix . '/lib';
my $mingw32_sysconfdir = $mingw32_prefix . '/etc';
-
can be set by
rpm --eval %{_mingw32_xxx}
it's be cleaner and more flexible.
also hard coded: i686-pc-mingw32-objdump to %_mingw32_objdump
and in the manual the path:
/usr/i686-pc-mingw32/sys-root/mingw/
can be somehow evaluated.
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
nsis
hi,
you can delete nsis-2.19-mingw-search.patch since it's no longer required.
imho these last few lines can be dropped from
nsis-2.42-debian-64bit-fixes.patch since even on x86_64 there is such
options, so is there any relevance?
--- ./SCons/Config/gnu.lfarkas 2009-01-14 16:55:33.0 +0100
+++ ./SCons/Config/gnu 2009-01-14 16:56:21.0 +0100
@@ -90,8 +90,6 @@
makensis_env.Append(CXXFLAGS = ['-Wno-non-virtual-dtor']) # ignore
virtual dtor warnings
conf = FlagsConfigure(makensis_env)
-conf.CheckCompileFlag('-m32') #
-conf.CheckLinkFlag('-m32')#
conf.CheckLinkFlag('$MAP_FLAG') # generate map file
if not defenv['DEBUG'] and defenv['STRIP'] and defenv['STRIP_CP']:
TestStrip(conf) # strip
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
nsis
hi,
you change to this in nsis:
# since nsis a 32 bit only apps
#ExclusiveArch: %{ix86} ppc
#BuildRequires: wxGTK-devel
# The above is only required for Koji. In mock we _can_ build on
# x86_64 provided we have the 32 bit libraries required by the next
# two lines.
BuildRequires: /usr/include/gnu/stubs-32.h
BuildRequires: /usr/lib/libwx_baseu-2.8.so
which is actually true but can't help us since we'd like to add to
fedora so build in koji!?
ps. anyway as the mass rebuild will change from i386 to i586 we'd have
to reveiw all packages and rewite i386 to ix86:-(
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
rpmlint
hi, now as rpmlint is at least 0.85-2 in f10, rawhide and epel-5 too it'd be better to remove versioned req and br for rpmlint from all packages. ie if we change something change it too. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Example "cross-zlib" package added to Mercurial
Richard W.M. Jones wrote:
> Here is the annotated diff from the current mingw32-zlib.spec file to
> the proposed new spec file that would build to multiple architectures.
>
> --- mingw32-zlib.spec 2009-01-19 19:03:53.0 +
> +++ mingw32-zlib.spec 2009-02-14 14:06:48.0 +
> @@ -6,8 +6,8 @@
>
> Name: mingw32-zlib
> Version:1.2.3
> -Release:12%{?dist}
> -Summary:MinGW Windows zlib compression library
> +Release:13%{?dist}
> +Summary:Cross-compiled zlib compression library
>
> As a general cleanup, we need to go through all the summary lines and
> remove "Windows" (trademark, see[1]) and "MinGW" (no longer
> appropriate for these packages). At the same time we don't want to
> get confused with other cross-compiler packages in Fedora.
> Suggestions welcome on a good summary line.
what's the plane here?
do you wanna include it in f10/f11 somehow or just an example?
i still prefer to rename the main package to cross-zlib. it's very
strance to be a mingw32-zlib which produce mingw64-zlib what's more
darwin-zlib?
> [1]
> https://www.redhat.com/archives/fedora-devel-announce/2009-January/msg00012.html
>
> License:zlib
> Group: Development/Libraries
> @@ -27,19 +27,42 @@
> BuildRequires: mingw32-filesystem >= 23
> BuildRequires: mingw32-gcc
> BuildRequires: mingw32-binutils
> +BuildRequires: mingw64-filesystem >= 10
ihmo here again would be better to one common cross-filesystem which
contains all macros, script, dirs etc. why we create 3 such packages? i
think now and in a few months as many things get clear (as daniel
suggested) would be better to create test packages based on a new
'feature for f12 cross-compiler'.
> +BuildRequires: mingw64-gcc
> +BuildRequires: mingw64-binutils
and again if we create cross-xxx packages then we can create
meta-packages like cross-gcc which requires all gcc and these BR can be
3 times shorter.
> %description
> -MinGW Windows zlib compression library.
> +Cross-compiled zlib compression library.
> +
> +
> +%package -n mingw64-zlib
> +Summary:Cross-compiled zlib compression library
> +Group: Development/Libraries
> +
> +
> +%description -n mingw64-zlib
> +Cross-compiled zlib compression library.
>
> Since we are going to build for Win32 and Win64, we need the extra
> BuildRequires and the extra subpackage.
>
> %prep
> -%setup -q -n zlib-1.2.3
> +%setup -q -c -n %{name}-%{version} -a 0
> +mv zlib-%{version} mingw32
> +%setup -q -c -D -n %{name}-%{version} -a 0
> +mv zlib-%{version} mingw64
>
> This is one of several ways to set up a directory structure like this:
>
> mingw32-zlib-1.2.3/
> mingw32 # full copy of the source
> mingw64 # second full copy of the source
>
> zlib has a strange build system with a custom configure script. For
> autoconf packages we could do this more efficiently using a single
> copy of the source and separate build directories.
>
> [Which reminds me -- we need to modify %{_mingw32_configure} so that
> it looks for a configure script in . and ..]
>
> +pushd mingw32
> +%patch100 -p1
> +popd
>
> +pushd mingw64
> %patch100 -p1
> +popd
why not used the same way as in kmod packages:
- first setup and patch the source
- then create as many new copy as required
- then build:
%prep
%setup -q -c -T -a 0
%patch0 -p1
for kvariant in %{kvariants} ; do
cp -a %{kmod_name}-%{version} _kmod_build_${kvariant}
done
%build
for kvariant in %{kvariants}; do
pushd _kmod_build_${kvariant}
ksrc=%{_usrsrc}/kernels/%{kverrel}${kvariant:+-$kvariant}-%{_target_cpu}
make %{?_smp_mflags} -C "${ksrc}" SUBDIRS=${PWD} modules
popd
done
%install
rm -rf $RPM_BUILD_ROOT
for kvariant in %{kvariants}; do
ksrc=%{_usrsrc}/kernels/%{kverrel}${kvariant:+-$kvariant}-%{_target_cpu}
pushd _kmod_build_$kvariant
make -C "${ksrc}" INSTALL_MOD_PATH=$RPM_BUILD_ROOT
INSTALL_MOD_DIR=extra/%{kmod_name} modules_install M=$PWD
popd
done
in our case it can be like this:
%prep
%setup -q -c -T -a 0
%patch0 -p1
for cvariant in %{cvariants} ; do
cp -a %{name}-%{version} _build_${cvariant}
done
%build
for cvariant in %{cvariants}; do
pushd _build_${cvariant}
%{_${cvariant}_configure}
%{_${cvariant}_make}
popd
done
%install
rm -rf $RPM_BUILD_ROOT
for cvariant in %{cvariants}; do
pushd _build_$cvariant
%{_${cvariant}_makeinstall}
popd
done
where cvariants can be mingw32, mingw32, darwinx.
it can work both autoconf and none autoconf case and imho it's not worth
to bother with autoconf case where the source copy is not required (it's
r
Re: [PATCH] Rename some source files in mingw32-filesystem
Richard W.M. Jones wrote: > Proposed patch to rename some source files in mingw32-filesystem. > This has no effect on the binary package. I made this change in > mingw64-filesystem, and this would be for consistency. exactly what i like to ask:-) -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: openssl-0.9.8j
Richard W.M. Jones wrote: > On Fri, Feb 13, 2009 at 11:57:54PM +0100, Farkas Levente wrote: >> Richard W.M. Jones wrote: >>> On Mon, Feb 02, 2009 at 10:32:58PM +0100, Farkas Levente wrote: >>>> Richard W.M. Jones wrote: >>>>> ACKed and applied to the Mercurial repository. >>>> in the meantime there is a newer native version:-( >>>> and here is the patches for this. >>> Is this patch still waiting for attention? >> yes imho should have to apply to the hg (at least this still diff from >> the hg repo). anyway why is there the hg repo when openssl is in fedora cvs? > > I should have removed it from the hg repository, and if I didn't then > that's a mistake. As is the case here, so I'll remove it shortly. > > Can you repost the latest version of your patch against the Fedora > CVS, and I'll try to take a look at it on Monday. sorry, fedora cvs already contains the latest version i just check against the hg wrongly:-( -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Win64 packages
Richard W.M. Jones wrote: > On Thu, Feb 12, 2009 at 03:08:58PM +0100, Farkas Levente wrote: >> Farkas Levente wrote: >>> Richard W.M. Jones wrote: >>>> Note that the directory layout for mingw64 is somewhat different from >>>> mingw32. I arrived at what I think is the right structure after >>>> extensive discussions and help from members of the mingw-w64 project. >>>> >>>> /usr/x86_64-pc-mingw32/sys-root/ (prefix & sysroot) >>>> share >>>> x86_64-pc-mingw32 >>>> mingw -> x86_64-pc-mingw32 >>>> >>>> /usr/x86_64-pc-mingw32/sys-root/x86_64-pc-mingw32 (exec_prefix) >>>> bin (bindir) >>>> include (includedir) >>>> include64 -> include >>>> lib (libdir) >>> can you explain it a bit? >>> why mingw32 and not mingw64? >>> >>> why /usr/x86_64-pc-mingw32/sys-root/x86_64-pc-mingw32 and not >>> /usr/x86_64-pc-mingw32/sys-root/? >>> >>> anyway the same question apply to mingw32 why >>> /usr/i686-pc-mingw32/sys-root/mingw/ and why not >>> /usr/i686-pc-mingw32/sys-root/? >> or why not /usr/i686-pc-mingw32/mingw/ ? > > This isn't a matter of guesswork or how we'd like it to be. Upstream > have set up their binutils, compiler, headers etc to work with a > specific directory structure. > > We have to replicate that structure. > > Otherwise it doesn't work. are you sure? i'll test it next week. what's the best and easiest way to test the whole system? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: openssl-0.9.8j
Richard W.M. Jones wrote: > On Mon, Feb 02, 2009 at 10:32:58PM +0100, Farkas Levente wrote: >> Richard W.M. Jones wrote: >>> ACKed and applied to the Mercurial repository. >> in the meantime there is a newer native version:-( >> and here is the patches for this. > > Is this patch still waiting for attention? yes imho should have to apply to the hg (at least this still diff from the hg repo). anyway why is there the hg repo when openssl is in fedora cvs? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: anybody can help in this?
Richard W.M. Jones wrote: > On Fri, Feb 13, 2009 at 01:52:11PM +0100, Farkas Levente wrote: >> do you mean ExclusiveArch: i386? > > Yes I did ... > >> anyway i rather add: >> ExcludeArch:x86_64, ppc64 >> it's build on ppc: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1124536 >> also build on i386: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1124544 >> the strange thing is koji try to build on x86_64 even if i add the above >> ExcludeArch???: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1124493 > > Strange ... Try ExclusiveArch? ok i was good tip:-) please update my previous patch with ExcludeArch:x86_64 ppc64 ie. remove the "," !...@$% -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: anybody can help in this?
Richard W.M. Jones wrote:
> BTW, wine must have the same problem, and that is built
> with ExcludeArch: i386.
>
> http://cvs.fedora.redhat.com/viewvc/devel/wine/wine.spec?view=markup
>
> Possibly we can also build nsis on ppc (but probably not ppc64).
>
> Rich.
>
do you mean ExclusiveArch: i386?
anyway i rather add:
ExcludeArch:x86_64, ppc64
it's build on ppc:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1124536
also build on i386:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1124544
the strange thing is koji try to build on x86_64 even if i add the above
ExcludeArch???:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1124493
anyway there is a newer nsis i updated the patches, remove
nsis-2.39-mingw32-search.patch as no longer needed.
so the result the needed source (all other can be removed):
nsis-2.43-src.tar.bz2
nsis-2.43-debian-debug-opt.patch
nsis-2.42-debian-64bit-fixes.patch
and attached the spec diff to the hg.
would be useful to apply and i'll approve the rr.
--
Levente "Si vis pacem para bellum!"
diff -up ./SCons/Config/gnu.debug ./SCons/Config/gnu
--- ./SCons/Config/gnu.debug2009-02-13 12:41:42.0 +0100
+++ ./SCons/Config/gnu 2009-02-13 12:42:37.0 +0100
@@ -68,13 +68,16 @@ cross_env(stub_env)
stub_env.Append(CPPPATH = ['#$BUILD_CONFIG'])
-if not defenv['DEBUG']:
- stub_env.Append(CCFLAGS = ['-Os'])# optimize for size
+if defenv['DEBUG_SYMBOLS']:
+ stub_env.Append(LINKFLAGS = '-g') # debugging
+ stub_env.Append(CCFLAGS = '-g') # debugging
+if not defenv['DEBUG'] and defenv['OPT']:
+ stub_env.Append(CCFLAGS = ['-O2']) # optimize
stub_env.Append(CCFLAGS = ['-Wall'])# all warnings
stub_env.Append(CCFLAGS = ['-xc']) # force compile as c
stub_env.Append(CCFLAGS = ['-fno-strict-aliasing']) # not safe for strict
aliasing
-if not defenv['DEBUG'] and defenv['STRIP'] and defenv['STRIP_W32']:
+if not defenv['DEBUG'] and not defenv['DEBUG_SYMBOLS'] and defenv['STRIP'] and
defenv['STRIP_W32']:
stub_env.Append(LINKFLAGS = ['-s']) # strip
stub_env.Append(LINKFLAGS = ['-mwindows']) # build windows executables
stub_env.Append(LINKFLAGS = ['$NODEFLIBS_FLAG'])# no standard libraries
@@ -88,15 +91,18 @@ makensis_env = defenv.Clone()
makensis_env.Append(CPPPATH = ['#$BUILD_CONFIG'])
-if not defenv['DEBUG']:
- makensis_env.Append(CCFLAGS = ['-O2']) # optimize
+if defenv['DEBUG_SYMBOLS']:
+ makensis_env.Append(LINKFLAGS = '-g') # debugging
+ makensis_env.Append(CCFLAGS = '-g') # debugging
+if not defenv['DEBUG'] and defenv['OPT']:
+ makensis_env.Append(CCFLAGS = ['-O2'])# optimize
makensis_env.Append(CFLAGS = ['-Wall']) # all warnings
makensis_env.Append(CXXFLAGS = ['-Wno-non-virtual-dtor']) # ignore virtual
dtor warnings
makensis_env.Append(CXXFLAGS = ['-Wall']) # all warnings
conf = FlagsConfigure(makensis_env)
conf.CheckLinkFlag('$MAP_FLAG') # generate map file
-if not defenv['DEBUG'] and defenv['STRIP'] and defenv['STRIP_CP']:
+if not defenv['DEBUG'] and not defenv['DEBUG_SYMBOLS'] and defenv['STRIP'] and
defenv['STRIP_CP']:
TestStrip(conf) # strip
conf.Finish()
@@ -105,12 +111,15 @@ conf.Finish()
plugin_env = defenv.Clone()
cross_env(plugin_env)
-if not defenv['DEBUG']:
- plugin_env.Append(CCFLAGS = ['-Os']) # optimize for size
+if defenv['DEBUG_SYMBOLS']:
+ plugin_env.Append(LINKFLAGS = '-g') # debugging
+ plugin_env.Append(CCFLAGS = '-g') # debugging
+if not defenv['DEBUG'] and defenv['OPT']:
+ plugin_env.Append(CCFLAGS = ['-O2'])# optimize
plugin_env.Append(CCFLAGS = ['-Wall']) # level 3 warnings
plugin_env.Append(CCFLAGS = ['-fno-strict-aliasing']) # not safe for strict
aliasing
-if not defenv['DEBUG'] and defenv['STRIP'] and defenv['STRIP_W32']:
+if not defenv['DEBUG'] and not defenv['DEBUG_SYMBOLS'] and defenv['STRIP'] and
defenv['STRIP_W32']:
plugin_env.Append(LINKFLAGS = ['-s']) # strip
plugin_env.Append(LINKFLAGS = ['-mwindows'])# build windows executables
plugin_env.Append(LINKFLAGS = ['$ALIGN_FLAG']) # 512 bytes align
@@ -122,7 +131,10 @@ cp_util_env = defenv.Clone()
cp_util_env.Append(CPPPATH = ['#$BUILD_CONFIG'])
-if not defenv['DEBUG']:
+if defenv['DEBUG_SYMBOLS']:
+ cp_util_env.Append(LINKFLAGS = '-g')# debugging
+ cp_util_env.Append(CCFLAGS = '-g') # debugging
+if not defenv['DEBUG'] and defenv['OPT']:
cp_util_env.Append(CCFLAGS = ['-O2']) # optimize
cp_util_env.Append(CCFLAGS = ['-Wall']) # all warnings
cp_util_env.Append(CCFLAGS = ['-fno-strict-aliasing']) # not safe for strict
aliasing
@@ -140,7
pthreads
hi, as the latest pthreads release is 2006-12-22 and the cvs is much newer (eg support win64) wouldn't it be useful to update to the latest cvs (which is 2008-06-06)? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: anybody can help in this?
Richard W.M. Jones wrote: > On Fri, Feb 13, 2009 at 11:45:28AM +0100, Erik van Pienbroek wrote: >> Why do you need to use i386 packages on an x86_64 environment to compile >> a program? > > IIRC, NSIS can only be compiled as a 32 bit program (native Fedora > though) because the code is full of 32 bit assumptions. > > Debian patched 2.39 to fix some of the 32 bit assumptions, but we are > still compiling it as 32 bit (ie. gcc -m32). > > Might be worth going back to Debian and finding out what patches/etc > they are shipping to make it work on 64 bit platforms. i already port those patches and update them to the latest version, although nsis need: # We really need the 32 bit version of this library. The 64 bit # version will definitely not work. XXX Need to do the right thing on # non-x86 architectures. anyway it's a common hack like this (the same is in eg: qemu): # We build with 'gcc -m32' and that fails on 64 bit platforms when we # include . On x86-64, this is provided by # glibc-devel.i386. Depend on the file explicitly, since only recent # versions of RPM let you require a package by architecture. BuildRequires: /usr/include/gnu/stubs-32.h -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
anybody can help in this?
hi, i try to test my new mingw32-nsis-2.42-1 and it's always fail on x86_64. here is a build log for f-10: http://koji.fedoraproject.org/koji/getfile?taskID=1124228&name=root.log but i do not understand it. it's execute: --- /usr/bin/yum --installroot /var/lib/mock/dist-f10-build-348185-64678/root/ resolvedep 'mingw32-gcc-c++' 'mingw32-gcc' 'python' '/usr/lib/libwx_baseu-2.8.so' 'mingw32-binutils' 'scons' '/usr/include/gnu/stubs-32.h' 'mingw32-filesystem >= 40' --- and gives: "No Package Found for /usr/lib/libwx_baseu-2.8.so" but if on my f10.x86_64 i run : --- # yum resolvedep /usr/lib/libwx_baseu-2.8.so Loaded plugins: downloadonly, priorities, refresh-packagekit Excluding Packages in global exclude list Finished 246 packages excluded due to repository priority protections Importing additional filelist information 0:wxGTK-devel-2.8.9-1.fc10.i386 --- so why mock can't find wxGTK-devel.i386? is it a mock or koji bug? or? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Win64 packages
Farkas Levente wrote: > Richard W.M. Jones wrote: >> There are some non-working/partially-working Win64 packages in the >> repository now: >> >> http://hg.et.redhat.com/cgi-bin/hg-misc.cgi/fedora-mingw--devel/ >> >> You need to build them yourselves, in the following order: >> >> mingw64-filesystem >> mingw64-binutils >> mingw64-headers >> mingw64-gcc-bootstrap (in mingw64-gcc/ subdir) >> mingw64-runtime >> mingw64-gcc >> > > where did you get gcc-core-4.4-20090206.tar.bz2? ok i find it. anyway is there any reason to jump to 4.4 while mingw32 is 4.3 and at the same time it won't compile on epel-5 since it has only MPFR 2.2.1 while gcc 4.4 require at least GMP 4.1+ and MPFR 2.3.2+. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Win64 packages
Richard W.M. Jones wrote: > There are some non-working/partially-working Win64 packages in the > repository now: > > http://hg.et.redhat.com/cgi-bin/hg-misc.cgi/fedora-mingw--devel/ > > You need to build them yourselves, in the following order: > > mingw64-filesystem > mingw64-binutils > mingw64-headers > mingw64-gcc-bootstrap (in mingw64-gcc/ subdir) > mingw64-runtime > mingw64-gcc > where did you get gcc-core-4.4-20090206.tar.bz2? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Discuss: Base packages for Win32 / Win64 / OS X cross-compilation
Richard W.M. Jones wrote: > On Thu, Feb 12, 2009 at 02:58:44PM +0100, Farkas Levente wrote: >> Richard W.M. Jones wrote: >>> On Thu, Feb 12, 2009 at 01:58:38PM +0100, Farkas Levente wrote: >>>> at the same time i'd name cross-headers on all platform (ie. rename >>>> mingw32-w32api to headers to use the same naming convention). >>> Yeah ... but ... >>> >>> The name of mingw32-w32api has almost no impact on end users, since we >>> wouldn't expect them to install this package explicitly. >>> >>> So we'd rename it, at a cost of a full review, hours of work at >>> minimum. But to what purpose? >> cross-headers can be build form the same src.rpm (which contains 3 >> source tarball) as any other cross pacakges. > > At this time this is not true. The three upstream projects > (mingw.org, mingw-w64 and Apple) ship different sets of headers. > > Because the mingw-w64 headers are supposedly a strict superset of the > mingw.org headers, we might be able to combine them at some point in > the future. However that certainly isn't possible now because there > are divergences between the headers. i'd not like to merge headers (although it'd be nice too), but build in one src.rpm the 3 platform same as with zlib. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Win64 packages
Farkas Levente wrote: > Richard W.M. Jones wrote: >> Note that the directory layout for mingw64 is somewhat different from >> mingw32. I arrived at what I think is the right structure after >> extensive discussions and help from members of the mingw-w64 project. >> >> /usr/x86_64-pc-mingw32/sys-root/ (prefix & sysroot) >> share >> x86_64-pc-mingw32 >> mingw -> x86_64-pc-mingw32 >> >> /usr/x86_64-pc-mingw32/sys-root/x86_64-pc-mingw32 (exec_prefix) >> bin (bindir) >> include (includedir) >> include64 -> include >> lib (libdir) > > can you explain it a bit? > why mingw32 and not mingw64? > > why /usr/x86_64-pc-mingw32/sys-root/x86_64-pc-mingw32 and not > /usr/x86_64-pc-mingw32/sys-root/? > > anyway the same question apply to mingw32 why > /usr/i686-pc-mingw32/sys-root/mingw/ and why not > /usr/i686-pc-mingw32/sys-root/? or why not /usr/i686-pc-mingw32/mingw/ ? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Win64 packages
Richard W.M. Jones wrote: > There are some non-working/partially-working Win64 packages in the > repository now: > > http://hg.et.redhat.com/cgi-bin/hg-misc.cgi/fedora-mingw--devel/ do you have binary src.rpms? i'd like to test layout. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Discuss: Base packages for Win32 / Win64 / OS X cross-compilation
Richard W.M. Jones wrote: > On Thu, Feb 12, 2009 at 01:58:38PM +0100, Farkas Levente wrote: >> at the same time i'd name cross-headers on all platform (ie. rename >> mingw32-w32api to headers to use the same naming convention). > > Yeah ... but ... > > The name of mingw32-w32api has almost no impact on end users, since we > wouldn't expect them to install this package explicitly. > > So we'd rename it, at a cost of a full review, hours of work at > minimum. But to what purpose? cross-headers can be build form the same src.rpm (which contains 3 source tarball) as any other cross pacakges. >> another good question is the filesystem layout which probably should >> have to change. > > Why? The filesystem layout is defined in the approved packaging > guidelines, and is partly imposed on us by decisions in the upstream > MinGW.org project. Changing this involves fielding packaging > guidelines through FPC (ie. weeks and weeks of argument), plus at > least recompiling and probably changing *all* the packages (ie. 1-2 > months of work), and that's assuming we could patch all the tools to > understand our particular filesystem layout. not rally actually in your previous letter you already modify it for mingw64. and filessystme layout only have to change in filesystem's macros and a mass rebuild. > So this is months of work, but really for no benefit whatsoever. the layout can be the same on all target platform. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Win64 packages
Richard W.M. Jones wrote: > Note that the directory layout for mingw64 is somewhat different from > mingw32. I arrived at what I think is the right structure after > extensive discussions and help from members of the mingw-w64 project. > > /usr/x86_64-pc-mingw32/sys-root/ (prefix & sysroot) > share > x86_64-pc-mingw32 > mingw -> x86_64-pc-mingw32 > > /usr/x86_64-pc-mingw32/sys-root/x86_64-pc-mingw32 (exec_prefix) > bin (bindir) > include (includedir) > include64 -> include > lib (libdir) can you explain it a bit? why mingw32 and not mingw64? why /usr/x86_64-pc-mingw32/sys-root/x86_64-pc-mingw32 and not /usr/x86_64-pc-mingw32/sys-root/? anyway the same question apply to mingw32 why /usr/i686-pc-mingw32/sys-root/mingw/ and why not /usr/i686-pc-mingw32/sys-root/? why put share one level ip? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Discuss: Base packages for Win32 / Win64 / OS X cross-compilation
Richard W.M. Jones wrote: > A good question. > > There are several things which restrict us here: (1) mingw32-* is the > naming scheme for 32 bit Windows cross-compiler packages, as approved > by various Fedora bodies. That approval took months of wrangling to > achieve. (2) The (moderate) difficulty of renaming existing source > packages. > > The naming scheme I suggested would be something like: > > mingw32-zlib.src.rpm > ||| > |generating | > ||| > VVV > mingw32-zlib mingw64-zlib darwinx-zlib > > An ideal naming scheme (if we could start over) might be something > like: > > cross-zlib.src.rpm > ||| > |generating | > ||| > VVV > zlib-win32 zlib-win64 zlib-darwin i think about it a lot last night:-(. let's just see the above example. how can we do this? cross-zlib.spec can contain 3 subpackage as zlib-win32, zlib-win64 and zlib-darwin, but how can we build it? one %build section probably not enough since we need make clean; make; 3 times so the first 2 result lost in %install section. solution can be command line defines to rpmbuild like rpmforge do it, but i don't know how can be done it in koji? on the other hand create 3x3 spec file for each packages (f10,devel,epel-5 and later it'll also add f11 and epel-6) x (mingw32, mingw64, darwin) 9-15 packages which are almost the same. so under all circumstances i _strongly_ prefer 1 spec file for one package eg. cross-zlib.spec. so how can we build 9-15 packages from 1 spec file? imho the ideal solution would be to change rpm and add - mingw32.rpm - mingw64.rpm - darwin.rpm and these rpm should have to be also arch independent rpms. if we can have build host for these we can simple build on different virtual host as we currently do with src.rpm -> i386, x86_64, ppc etc. or we can use our own build server which check out the main spec file generate platform specific spec files if there is changes then checkin to fedora cvs, tag it and build them in koji. but this need a separate build system (may be only a few lines of scripts and can be added to fedora infrastructure). anyway we need to write a few macros for supporting it. anyway about the naming i'd prefer: cross-zlib.spec cross-zlib.src.rpm cross-zlib-x.y-z.mingw32.rpm or cross-zlib-mingw32-x.y-z.noarch.rpm cross-zlib-x.y-z.mingw64.rpm or cross-zlib-mingw64-x.y-z.noarch.rpm cross-zlib-x.y-z.darwin.rpm or cross-zlib-darwin-x.y-z.noarch.rpm i use mingw32 instead of just to give credits for the mingw folks. i don't know the right name for darwin darwinx or osx? at the same time i'd name cross-headers on all platform (ie. rename mingw32-w32api to headers to use the same naming convention). there packages can require only their own platform, but we can make a cross-zlib-x.y-z.noarch.rpm too which is just a metapackage to require all 3 platforms cross-zlib packages so if someone like to create a full cross environment eg: yum install cross-openssl. cross-filesystem can be merge to one common cross-filesystem-x.y-z.noarch.rpm since i don't see the reason why we need 3-5 such packages and anyway it'd be useful to be able to install all cross environment on the same machine. that's why i'd rename it to cross-base like kdebase, openoffice.org-base, gstreamer-plugins-base. another good question is the filesystem layout which probably should have to change. it's be useful to start write draft for - CrossCompiler 'Fedora generalized cross compilers' - PackagingDrafts/CrossCompiler many things can be copied from mingw32. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Discuss: Base packages for Win32 / Win64 / OS X cross-compilation
Daniel P. Berrange wrote: > On Thu, Feb 12, 2009 at 08:31:17AM +, Richard W.M. Jones wrote: >> On Wed, Feb 11, 2009 at 11:40:54PM +0100, Farkas Levente wrote: >>> i can risk it! >>> let's ask fesco! >> There is no possible way we can do this before the Fedora 11 features >> deadline. Going back through FESCO would take a minimum of two weeks, >> assuming it went smoothly, which is highly unlikely. Then we'd have >> to do full reviews of 31 packages again. > > Given where we are in release process, I think maintaining focus on > mingw32 only for F11 is the right thing. Then have a new feature for > F12 'Fedora generalized cross compilers' to re-architect things to > cope with OS-X / Win64 (and whatever else people care about) ok let's start to discuss F12 'Fedora generalized cross compilers'. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
mingw32-crossreport
hi, i just thing about this package. why not put into filesystem? do you really want to maintain so much packages? and it's can fit into it. anyway imho filesystm would be better call as mingw32-base and put all such things into it (i've got other reasons for this just see my next mail about mingw64 and darwin). so imho please hold the pushing of these packages into the repos. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Discuss: Base packages for Win32 / Win64 / OS X cross-compilation
Richard W.M. Jones wrote: > On Wed, Feb 11, 2009 at 04:10:21PM -0600, Michael Cronenworth wrote: >> Original Message >> Subject: Re: Discuss: Base packages for Win32 / Win64 / OS X >> cross-compilation >> From: Richard W.M. Jones >> To: fedora-mingw@lists.fedoraproject.org >> Date: 02/11/2009 03:39 PM >> >>> Which raises also the possibility of combining mingw32-binutils and >>> mingw64-binutils together (as well as mingw32-gcc and mingw64-gcc as >>> mentioned in the previous email). >>> >> >> Does this call for a different arch naming classification? >> >> Now Fixed >> mingw32-gcc mingw-gcc >> mingw32-gtk2 mingw-gtk2-win32, mingw-gtk2-win64 >> >> ... or something similar? I see little sense in keeping the name >> "mingw32" as the main name if we're going to start including win64 >> capability. > > A good question. > > There are several things which restrict us here: (1) mingw32-* is the > naming scheme for 32 bit Windows cross-compiler packages, as approved > by various Fedora bodies. That approval took months of wrangling to > achieve. (2) The (moderate) difficulty of renaming existing source > packages. > > The naming scheme I suggested would be something like: > > mingw32-zlib.src.rpm > ||| > |generating | > ||| > VVV > mingw32-zlib mingw64-zlib darwinx-zlib > > An ideal naming scheme (if we could start over) might be something > like: > > cross-zlib.src.rpm > ||| > |generating | > ||| > VVV > zlib-win32 zlib-win64 zlib-darwin > > But the points (1) and (2) above make this difficult to really achieve > from where we are right now. Particularly (1). Anything where we > have to go back to FPC/FESCO is undesirable and might even jeopardise > the whole project. (Look back at the heated mailing list / IRC > arguments from last summer). anyway it's a good question wether osx or darwin is the better name? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Discuss: Base packages for Win32 / Win64 / OS X cross-compilation
Richard W.M. Jones wrote: > On Wed, Feb 11, 2009 at 04:10:21PM -0600, Michael Cronenworth wrote: >> Original Message >> Subject: Re: Discuss: Base packages for Win32 / Win64 / OS X >> cross-compilation >> From: Richard W.M. Jones >> To: fedora-mingw@lists.fedoraproject.org >> Date: 02/11/2009 03:39 PM >> >>> Which raises also the possibility of combining mingw32-binutils and >>> mingw64-binutils together (as well as mingw32-gcc and mingw64-gcc as >>> mentioned in the previous email). >>> >> >> Does this call for a different arch naming classification? >> >> Now Fixed >> mingw32-gcc mingw-gcc >> mingw32-gtk2 mingw-gtk2-win32, mingw-gtk2-win64 >> >> ... or something similar? I see little sense in keeping the name >> "mingw32" as the main name if we're going to start including win64 >> capability. > > A good question. > > There are several things which restrict us here: (1) mingw32-* is the > naming scheme for 32 bit Windows cross-compiler packages, as approved > by various Fedora bodies. That approval took months of wrangling to > achieve. (2) The (moderate) difficulty of renaming existing source > packages. try to get a newer approval! > The naming scheme I suggested would be something like: > > mingw32-zlib.src.rpm > ||| > |generating | > ||| > VVV > mingw32-zlib mingw64-zlib darwinx-zlib > > An ideal naming scheme (if we could start over) might be something > like: > > cross-zlib.src.rpm > ||| > |generating | > ||| > VVV > zlib-win32 zlib-win64 zlib-darwin i exactly suggest it! > But the points (1) and (2) above make this difficult to really achieve > from where we are right now. Particularly (1). Anything where we most approvals are on this list or even we can collect them from bugzilla and get them into this discussion. > have to go back to FPC/FESCO is undesirable and might even jeopardise > the whole project. (Look back at the heated mailing list / IRC > arguments from last summer). i can risk it! let's ask fesco! imho a whole crosscompile environment win32, win64 and osx would be useful for everybody! -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Discuss: Base packages for Win32 / Win64 / OS X cross-compilation
Richard W.M. Jones wrote: > I've noticed that the most recent mingw32-binutils package is in fact > using upstream binutils (it's shipped separately by mingw.org, but it > is identical to gnu.org binutils). So the diagram should look like > this: > > > mingw32- mingw64- darwinx- > > filesystem filesystem filesystem > > binutils <--- ? ---> binutils odcctools > (from upstream)(from upstream)(from Apple) > > gcc <--- ? ---> gccgcc > (from upstream)(from upstream)(from Apple) > > w32api headersheaders > (from mingw) (from mw64)(from Apple) > > runtimeruntime- > (from mingw) (from mw64) > > > Which raises also the possibility of combining mingw32-binutils and > mingw64-binutils together (as well as mingw32-gcc and mingw64-gcc as > mentioned in the previous email). as always i prefer to keep as little package as possible even if the spec files are a bit different. even only one crosscompile-filesystem and one mingw-gcc etc. even on crosscompile-headers (even is we rename w32ai). may be such names: -- ~ crosscompile or cross ~ win32, win64 and osx or darwinx ~ zlib as currently mingw32 packages not really widespread we can easily rename everything than later. so it'd be useful to thing about it. let's discuss it now before f11! -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: New tool: crossreport
Richard W.M. Jones wrote: > Inspired by the discussion a few days ago about APIs, I've written a > tool which you can use to analyze your Linux binaries, find out what > APIs they are using, and generate a report. Hopefully people can use > this report to estimate how much work they need to do in order to port > their programs. > > Two example reports are attached, from virt-viewer and inkscape. > > There is no RPM yet because my Rawhide machine is currently doing RHEL > virt testing. For now you have to build the package yourself from the > Mercurial repository: > > http://hg.et.redhat.com/cgi-bin/hg-misc.cgi/fedora-mingw--devel/file/tip/crossreport create rr for this!:-) -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
updates
hi, there are two more basic updates at least for devel branch: http://sourceforge.net/project/shownotes.php?release_id=19055 http://sourceforge.net/project/shownotes.php?release_id=16692 -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: Notes on OS X
Richard W.M. Jones wrote: > This revision contains a non-working Darwin / Mac OS X cross-compiler. > > http://hg.et.redhat.com/cgi-bin/hg-misc.cgi/fedora-mingw--devel/rev/70529a2e7640 > > New modules: > > darwinx-filesystem- Basic filesystem / layout. > darwinx-headers - Header files for cross-compilation. > darwinx-odcctools - (Like binutils; see the top of the spec file for >a lengthy explanation of the 'issues' with >this one) > darwinx-gcc - Xcode-based GCC cross-compiler > > Currently it segfaults somewhere inside the assembler (from > darwinx-odcctools) while building the darwinx-gcc module. The > segfault may be related to the patches I had to add to make odcctools > compile on my x86-64 machine, or may be down to odcctools itself. > > Patches welcome ... i like this line too:-) although we currently don't have osx machines, but in a few months we'll look into it... -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
nsis
hi,
my first patch for nsis:
- patch for the spec file
- two new updated patches
- you can remove:
nsis-2.19-debian-64bit-fixes.patch
nsis-2.19-debian-debug-opt.patch
nsis-2.19-mingw-search.patch
nsis-2.39-debian-64bit-fixes.patch
nsis-2.39-debian-debug-opt.patch
i didn't rename nsis-2.39-mingw32-search.patch since it's apply clean,
but you can update if you like it.
the only problem this this part of the orig spec is not true:
# We really need the 32 bit version of this library. The 64 bit
# version will definitely not work. XXX Need to do the right thing on
# non-x86 architectures.
BuildRequires: /usr/lib/libwx_baseu-2.8.so
since in 64 bit it's also /usr/lib/libwx_baseu-2.8.so. i'll look into it
when i have some free time (or anyone has any tip)?
--
Levente "Si vis pacem para bellum!"
diff -r 9f58deb1a4f9 nsis/mingw32-nsis.spec
--- a/nsis/mingw32-nsis.specMon Feb 02 19:08:07 2009 +
+++ b/nsis/mingw32-nsis.specMon Feb 02 23:24:08 2009 +0100
@@ -2,8 +2,8 @@
%define _default_patch_fuzz 2
Name: mingw32-nsis
-Version:2.39
-Release:5%{?dist}
+Version:2.42
+Release:1%{?dist}
Summary:Nullsoft Scriptable Install System
License:zlib and CPL
@@ -13,18 +13,18 @@
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
# Patches from Debian (mainly by Paul Wise).
-Patch0: nsis-2.39-debian-64bit-fixes.patch
-Patch1: nsis-2.39-debian-debug-opt.patch
+Patch0: nsis-2.42-debian-64bit-fixes.patch
+Patch1: nsis-2.42-debian-debug-opt.patch
# This patch is required for NSIS to find the correct cross-compiler.
Patch100: nsis-2.39-mingw32-search.patch
-BuildRequires: mingw32-filesystem >= 20
+BuildRequires: mingw32-filesystem >= 40
BuildRequires: mingw32-gcc
BuildRequires: mingw32-gcc-c++
BuildRequires: mingw32-binutils
BuildRequires: python
-BuildRequires: scons >= 0.96.93
+BuildRequires: scons
# We build with 'gcc -m32' and that fails on 64 bit platforms when we
# include . On x86-64, this is provided by
@@ -37,6 +37,8 @@
# non-x86 architectures.
BuildRequires: /usr/lib/libwx_baseu-2.8.so
+# since the above two BR
+ExcludeArch:ppc, ppc64
%description
NSIS, the Nullsoft Scriptable Install System, is a script-driven
@@ -51,8 +53,8 @@
%prep
%setup -q -n nsis-%{version}-src
-%patch0 -p1
-%patch1 -p1
+%patch0 -p1 -b .64bit
+%patch1 -p1 -b .debug
%patch100 -p1
@@ -76,14 +78,18 @@
%files
%defattr(-,root,root)
+%doc %{_docdir}/%{name}-%{version}
+%config(noreplace) %{_sysconfdir}/nsisconf.nsh
%{_bindir}/*
-%config(noreplace) %{_sysconfdir}/nsisconf.nsh
-%{_includedir}/nsis
-%doc %{_docdir}/%{name}-%{version}
+#{_includedir}/nsis
%{_datadir}/nsis
%changelog
+* Wed Jan 14 2009 Levente Farkas - 2.42-1
+- update to the latest upstream
+- a few small changes
+
* Fri Oct 17 2008 Richard W.M. Jones - 2.39-5
- Fix the Summary line.
--- ./Source/Plugins.cpp.lfarkas2009-01-14 17:03:11.0 +0100
+++ ./Source/Plugins.cpp2009-01-14 17:03:58.0 +0100
@@ -136,7 +136,7 @@
DWORD prd = FIX_ENDIAN_INT32(sections[i].PointerToRawData);
PIMAGE_EXPORT_DIRECTORY exports = PIMAGE_EXPORT_DIRECTORY(&dlldata[0]
+ prd + ExportDirVA - va);
DWORD na = FIX_ENDIAN_INT32(exports->AddressOfNames);
-unsigned long *names = (unsigned long*)((unsigned long) exports +
(char *) na - ExportDirVA);
+unsigned int *names = (unsigned int*)((unsigned long) exports + (char
*) na - ExportDirVA);
for (unsigned long j = 0; j <
FIX_ENDIAN_INT32(exports->NumberOfNames); j++)
{
const string name = string((char*)exports +
FIX_ENDIAN_INT32(names[j]) - ExportDirVA);
--- ./Source/ResourceEditor.cpp.lfarkas 2009-01-14 17:04:08.0 +0100
+++ ./Source/ResourceEditor.cpp 2009-01-14 17:07:47.0 +0100
@@ -665,7 +665,7 @@
rdDir.NumberOfIdEntries = ConvertEndianness(rdDir.NumberOfIdEntries);
CopyMemory(seeker, &rdDir, sizeof(IMAGE_RESOURCE_DIRECTORY));
-crd->m_dwWrittenAt = DWORD(seeker);
+crd->m_dwWrittenAt = long(seeker);
seeker += sizeof(IMAGE_RESOURCE_DIRECTORY);
for (int i = 0; i < crd->CountEntries(); i++) {
@@ -686,7 +686,7 @@
rDirE.UName.NameString.NameIsString = (crd->GetEntry(i)->HasName()) ? 1
: 0;
CopyMemory(seeker, &rDirE, sizeof(MY_IMAGE_RESOURCE_DIRECTORY_ENTRY));
- crd->GetEntry(i)->m_dwWrittenAt = DWORD(seeker);
+ crd->GetEntry(i)->m_dwWrittenAt = long(seeker);
seeker += sizeof(MY_IMAGE_RESOURCE_DIRECTORY_ENTRY);
}
qDirs.pop();
@@ -702,7 +702,7 @@
rDataE.Size = ConvertEndianness(cRDataE->GetSize());
CopyMemory(seeker, &rDataE, sizeof(IMAGE_RESOURCE_DATA_ENTRY));
-cRDataE->m_dwWrittenAt = DWORD(seeker);
+cRDataE->m_dwWrittenAt = long(seeker);
seek
Re: openssl-0.9.8j
Richard W.M. Jones wrote:
> ACKed and applied to the Mercurial repository.
in the meantime there is a newer native version:-(
and here is the patches for this.
--
Levente "Si vis pacem para bellum!"
diff -up openssl-0.9.8j/crypto/rand/rand_lcl.h.rng-seed
openssl-0.9.8j/crypto/rand/rand_lcl.h
--- openssl-0.9.8j/crypto/rand/rand_lcl.h.rng-seed 2009-02-02
13:40:37.0 +0100
+++ openssl-0.9.8j/crypto/rand/rand_lcl.h 2009-02-02 13:50:42.0
+0100
@@ -112,7 +112,7 @@
#ifndef HEADER_RAND_LCL_H
#define HEADER_RAND_LCL_H
-#define ENTROPY_NEEDED 32 /* require 256 bits = 32 bytes of randomness */
+#define ENTROPY_NEEDED 48 /* we need 48 bytes of randomness for FIPS rng */
#if !defined(USE_MD5_RAND) && !defined(USE_SHA1_RAND) &&
!defined(USE_MDC2_RAND) && !defined(USE_MD2_RAND)
diff -up openssl-0.9.8j/fips/rand/fips_rand.c.rng-seed
openssl-0.9.8j/fips/rand/fips_rand.c
--- openssl-0.9.8j/fips/rand/fips_rand.c.rng-seed 2008-09-16
12:12:18.0 +0200
+++ openssl-0.9.8j/fips/rand/fips_rand.c2009-02-02 14:06:58.0
+0100
@@ -155,7 +155,18 @@ static int fips_set_prng_seed(FIPS_PRNG_
{
int i;
if (!ctx->keyed)
- return 0;
+ {
+ FIPS_RAND_SIZE_T keylen = 16;
+
+ if (seedlen - keylen < AES_BLOCK_LENGTH)
+ return 0;
+ if (seedlen - keylen - 8 >= AES_BLOCK_LENGTH)
+ keylen += 8;
+ if (seedlen - keylen - 8 >= AES_BLOCK_LENGTH)
+ keylen += 8;
+ seedlen -= keylen;
+ fips_set_prng_key(ctx, seed+seedlen, keylen);
+ }
/* In test mode seed is just supplied data */
if (ctx->test_mode)
{
diff -up openssl-0.9.8j/fips/fips.c.rng-seed openssl-0.9.8j/fips/fips.c
--- openssl-0.9.8j/fips/fips.c.rng-seed 2009-02-02 13:40:38.0 +0100
+++ openssl-0.9.8j/fips/fips.c 2009-02-02 13:49:32.0 +0100
@@ -509,22 +509,22 @@ int FIPS_mode_set(int onoff)
goto end;
}
+ /* now switch into FIPS mode */
+ fips_set_rand_check(FIPS_rand_method());
+ RAND_set_rand_method(FIPS_rand_method());
+
/* automagically seed PRNG if not already seeded */
if(!FIPS_rand_status())
{
- if(RAND_bytes(buf,sizeof buf) <= 0)
+ RAND_poll();
+ if (!FIPS_rand_status())
{
fips_selftest_fail = 1;
ret = 0;
goto end;
}
- FIPS_rand_set_key(buf,32);
- FIPS_rand_seed(buf+32,16);
}
- /* now switch into FIPS mode */
- fips_set_rand_check(FIPS_rand_method());
- RAND_set_rand_method(FIPS_rand_method());
if(FIPS_selftest())
fips_set_mode(1);
else
diff -r 9f58deb1a4f9 openssl/mingw32-openssl.spec
--- a/openssl/mingw32-openssl.spec Mon Feb 02 19:08:07 2009 +
+++ b/openssl/mingw32-openssl.spec Mon Feb 02 22:32:15 2009 +0100
@@ -27,7 +27,7 @@
Name: mingw32-openssl
Version:0.9.8j
-Release:2%{?dist}
+Release:3%{?dist}
Summary:MinGW port of the OpenSSL toolkit
License:OpenSSL
@@ -77,6 +77,7 @@
Patch47:openssl-0.9.8j-readme-warning.patch
Patch48:openssl-0.9.8j-bad-mime.patch
Patch49:openssl-0.9.8j-fips-no-pairwise.patch
+Patch50:openssl-0.9.8j-fips-rng-seed.patch
# Backported fixes including security fixes
# MinGW-specific patches.
@@ -166,6 +167,7 @@
%patch47 -p1 -b .warning
%patch48 -p1 -b .bad-mime
%patch49 -p1 -b .no-pairwise
+%patch50 -p1 -b .rng-seed
%patch100 -p1 -b .mingw-header-files
%patch101 -p1 -b .mingw-configure
@@ -261,6 +263,8 @@
#%{__os_install_post} \
#fips/fips_standalone_sha1 $RPM_BUILD_ROOT/%{_lib}/libcrypto.so.%{version}
>$RPM_BUILD_ROOT/%{_lib}/.libcrypto.so.%{version}.hmac \
#ln -sf .libcrypto.so.%{version}.hmac
$RPM_BUILD_ROOT/%{_lib}/.libcrypto.so.%{soversion}.hmac \
+#fips/fips_standalone_sha1 $RPM_BUILD_ROOT/%{_lib}/libssl.so.%{version}
>$RPM_BUILD_ROOT/%{_lib}/.libssl.so.%{version}.hmac \
+#ln -sf .libssl.so.%{version}.hmac
$RPM_BUILD_ROOT/%{_lib}/.libssl.so.%{soversion}.hmac \
#%{nil}
if ! iconv -f UTF-8 -t ASCII//TRANSLIT CHANGES >/dev/null 2>&1 ; then
@@ -320,6 +324,7 @@
%{_mingw32_bindir}/libcrypto-%{soversion}.dll
%{_mingw32_bindir}/libssl-%{soversion}.dll
#{_mingw32_bindir}/.libcrypto*.hmac
+#{_mingw32_bindir}/.libssl*.hmac
%{_mingw32_libdir}/libcrypto.dll.a
%{_mingw32_libdir}/libssl.dll.a
%{_mingw32_libdir}/engines
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
rpmlint req
hi, it'd be nice to decrease rpmlint req lines to 0.85-1 according to https://bugzilla.redhat.com/show_bug.cgi?id=481601 it's enough and on epel only this version is available. or how can we solve this? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: openssl-0.9.8j
Richard W.M. Jones wrote: > ACKed and applied to the Mercurial repository. now it seems to work for me on my centos-5 and on fedora: http://koji.fedoraproject.org/koji/taskinfo?taskID=1099869 -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: openssl-0.9.8j
Richard W.M. Jones wrote:
> I didn't really look into it in detail yet, but I got a build failure
> in Koji:
>
> http://koji.fedoraproject.org/koji/getfile?taskID=1097899&name=build.log
>
> It built fine on my local machine though.
it's really strange, since centos's patch can work with it:-(
anyway here is a patch for the spec file and two new patch. of course
0.9.8j replace the previous 0.9.8g patches. previously i forget to send
the configure patch and header was updated.
ps. you can also remove openssl-0.9.8a-enginesdir.patch from hg.
--
Levente "Si vis pacem para bellum!"
--- ./crypto/seed/seed_ecb.c.mingw-header-files 2007-04-24 01:50:10.0
+0200
+++ ./crypto/seed/seed_ecb.c2009-02-02 18:28:55.0 +0100
@@ -49,7 +49,7 @@
*
*/
-#include
+#include "seed.h"
void SEED_ecb_encrypt(const unsigned char *in, unsigned char *out, const
SEED_KEY_SCHEDULE *ks, int enc)
{
--- ./crypto/seed/seed_locl.h.mingw-header-files2009-02-02
18:28:48.0 +0100
+++ ./crypto/seed/seed_locl.h 2009-02-02 18:28:55.0 +0100
@@ -27,7 +27,7 @@
#define HEADER_SEED_LOCL_H
#include "openssl/e_os2.h"
-#include
+#include "seed.h"
#ifdef SEED_LONG /* need 32-bit type */
--- ./crypto/seed/seed.c.mingw-header-files 2007-04-24 01:50:10.0
+0200
+++ ./crypto/seed/seed.c2009-02-02 18:28:55.0 +0100
@@ -32,7 +32,7 @@
#include
#endif
-#include
+#include "seed.h"
#include "seed_locl.h"
static seed_word SS[4][256] = {{
--- ./crypto/camellia/cmll_cbc.c.mingw-header-files 2006-12-02
13:00:27.0 +0100
+++ ./crypto/camellia/cmll_cbc.c2009-02-02 18:28:54.0 +0100
@@ -58,7 +58,7 @@
#include
#include
-#include
+#include "camellia.h"
#include "cmll_locl.h"
void Camellia_cbc_encrypt(const unsigned char *in, unsigned char *out,
--- ./crypto/camellia/cmll_cfb.c.mingw-header-files 2006-06-10
00:31:05.0 +0200
+++ ./crypto/camellia/cmll_cfb.c2009-02-02 18:28:54.0 +0100
@@ -113,7 +113,7 @@
#include
#include
-#include
+#include "camellia.h"
#include "cmll_locl.h"
#include "e_os.h"
--- ./crypto/camellia/cmll_ofb.c.mingw-header-files 2006-06-10
00:31:05.0 +0200
+++ ./crypto/camellia/cmll_ofb.c2009-02-02 18:28:55.0 +0100
@@ -111,7 +111,7 @@
# endif
#endif
#include
-#include
+#include "camellia.h"
#include "cmll_locl.h"
/* The input and output encrypted as though 128bit ofb mode is being
--- ./crypto/camellia/cmll_misc.c.mingw-header-files2009-02-02
18:29:19.0 +0100
+++ ./crypto/camellia/cmll_misc.c 2009-02-02 18:29:32.0 +0100
@@ -50,7 +50,7 @@
*/
#include
-#include
+#include "camellia.h"
#include "cmll_locl.h"
#include
#ifdef OPENSSL_FIPS
--- ./crypto/camellia/cmll_ecb.c.mingw-header-files 2006-06-10
00:31:05.0 +0200
+++ ./crypto/camellia/cmll_ecb.c2009-02-02 18:28:54.0 +0100
@@ -56,7 +56,7 @@
#endif
#include
-#include
+#include "camellia.h"
#include "cmll_locl.h"
void Camellia_ecb_encrypt(const unsigned char *in, unsigned char *out,
--- ./crypto/camellia/cmll_ctr.c.mingw-header-files 2006-06-10
00:31:05.0 +0200
+++ ./crypto/camellia/cmll_ctr.c2009-02-02 18:28:54.0 +0100
@@ -56,7 +56,7 @@
#endif
#include
-#include
+#include "camellia.h"
#include "cmll_locl.h"
/* NOTE: the IV/counter CTR mode is big-endian. The rest of the Camellia code
--- ./crypto/evp/e_seed.c.mingw-header-files2007-07-04 14:56:32.0
+0200
+++ ./crypto/evp/e_seed.c 2009-02-02 18:28:55.0 +0100
@@ -59,7 +59,7 @@
#include
#include
#ifndef OPENSSL_NO_SEED
-#include
+#include "../seed/seed.h"
#include "evp_locl.h"
static int seed_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key,
const unsigned char *iv, int enc);
--- ./crypto/evp/e_camellia.c.mingw-header-files2008-09-21
12:24:08.0 +0200
+++ ./crypto/evp/e_camellia.c 2009-02-02 18:28:55.0 +0100
@@ -59,7 +59,7 @@
#include
#include
#include
-#include
+#include "../camellia/camellia.h"
#include "evp_locl.h"
static int camellia_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key,
--- ./apps/speed.c.mingw-header-files 2009-01-07 11:48:22.0 +0100
+++ ./apps/speed.c 2009-02-02 18:28:54.0 +0100
@@ -165,7 +165,7 @@
#include
#endif
#ifndef OPENSSL_NO_CAMELLIA
-#include
+#include "../crypto/camellia/camellia.h"
#endif
#ifndef OPENSSL_NO_MD2
#include
@@ -202,7 +202,7 @@
#include
#endif
#ifndef OPENSSL_NO_SEED
-#include
+#include "../crypto/seed/seed.h"
#endif
#ifndef OPENSSL_NO_BF
#include
diff -r 9ce8bc84c7bc openssl/mingw32-openssl.spec
--- a/openssl/mingw32-openssl.spec Mon Feb 02 15:27:49 2009 +
+++ b/openssl/mingw32-openssl.spec Mon Feb 02 18:44:42 2009 +0100
@@ -80,8 +80,8 @@ Patch49:openssl-0.9.8j-fips-no-p
# Backported fixe
Re: openssl patch
Richard W.M. Jones wrote: > On Wed, Jan 28, 2009 at 04:01:01PM +0100, Farkas Levente wrote: >> Richard W.M. Jones wrote: >>> On Wed, Jan 28, 2009 at 01:43:20PM +0100, Farkas Levente wrote: >>>> hi, >>>> what about my openssl patch? >>>> i'd like to work on the new upstream openssl merge too. >>> Yes, I hate openssl too. >>> >>> Probably best if you go ahead and rebase to the new openssl and then >>> post an updated patch. >> ok the first question what we do with ca-certificates? on fedora it's >> been removed from openssl and a new packages created for this. >> do we create a new mingw32 packages? > > If the file is identical (or very similar) to the one in the native > Fedora package, then we should probably just drop the file. the question: do we need the ca certs on win32? since the ca-certificates package contains only root ca's cert. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
openssl-0.9.8j
hi,
i update the openssl package to the latest rawhide plus my previous
patches. the full hg diff is too large so i collect the changes:
- add all new patch files from openssl-0.9.8j-6.fc11.src.rpm
- mingw32-openssl-0.9.8g-shared.patch updated to
mingw32-openssl-0.9.8j-shared.patch (attached)
- remove these patches since no longer needed:
openssl-0.9.7-beta5-version-add-engines.patch
openssl-0.9.7f-ca-dir.patch
openssl-0.9.8a-enginesdir.patch
openssl-0.9.8g-bn-mul-bug.patch
openssl-0.9.8g-cve-2008-0891.patch
openssl-0.9.8g-cve-2008-1671.patch
openssl-0.9.8g-redhat.patch
openssl-0.9.8g-shlib-version.patch
openssl-0.9.8g-soversion.patch
openssl-0.9.8g-speed-bug.patch
and my spec file patch which is attached where i try to merge with
native spec file. a few comments about it:
- rename with_tests to run_tests (since it's called in that way in
ptheads package),
- update the patch sections,
- remove the gcc hack and replace Configure scripts with our macros,
- enable pthread tests too
- add files under pki/
- add license
--
Levente "Si vis pacem para bellum!"
diff -r 8bd4182dafe0 openssl/mingw32-openssl.spec
--- a/openssl/mingw32-openssl.spec Wed Jan 28 19:29:56 2009 +
+++ b/openssl/mingw32-openssl.spec Fri Jan 30 13:37:21 2009 +0100
@@ -4,14 +4,29 @@
%define __find_requires %{_mingw32_findrequires}
%define __find_provides %{_mingw32_findprovides}
+# For the curious:
+# 0.9.5a soversion = 0
+# 0.9.6 soversion = 1
+# 0.9.6a soversion = 2
+# 0.9.6c soversion = 3
+# 0.9.7a soversion = 4
+# 0.9.7ef soversion = 5
+# 0.9.8ab soversion = 6
+# 0.9.8g soversion = 7
+# 0.9.8j + EAP-FAST soversion = 8
+%define soversion 8
+
# Enable the tests.
# These only work some of the time, but fail randomly at other times
# (although I have had them complete a few times, so I don't think
# there is any actual problem with the binaries).
-%define with_tests 0
+%define run_tests 0
+
+# Number of threads to spawn when testing some threading fixes.
+%define thread_test_threads %{?threads:%{threads}}%{!?threads:1}
Name: mingw32-openssl
-Version:0.9.8g
+Version:0.9.8j
Release:1%{?dist}
Summary:MinGW port of the OpenSSL toolkit
@@ -30,34 +45,44 @@ Source10: opensslconf-new-warning.
Source10: opensslconf-new-warning.h
# Patches from Fedora native package.
-Patch0: openssl-0.9.8g-redhat.patch
+# Build changes
+Patch0: openssl-0.9.8j-redhat.patch
Patch1: openssl-0.9.8a-defaults.patch
Patch2: openssl-0.9.8a-link-krb5.patch
-Patch3: openssl-0.9.8g-soversion.patch
-Patch4: openssl-0.9.8a-enginesdir.patch
+Patch3: openssl-0.9.8j-soversion.patch
+Patch4: openssl-0.9.8j-enginesdir.patch
Patch5: openssl-0.9.8a-no-rpath.patch
Patch6: openssl-0.9.8b-test-use-localhost.patch
-Patch7: openssl-0.9.8g-shlib-version.patch
+Patch7: openssl-0.9.8j-shlib-version.patch
+# Bug fixes
Patch21:openssl-0.9.8b-aliasing-bug.patch
Patch22:openssl-0.9.8b-x509-name-cmp.patch
Patch23:openssl-0.9.8g-default-paths.patch
Patch24:openssl-0.9.8g-no-extssl.patch
+# Functionality changes
Patch32:openssl-0.9.8g-ia64.patch
-Patch33:openssl-0.9.7f-ca-dir.patch
+Patch33:openssl-0.9.8j-ca-dir.patch
Patch34:openssl-0.9.6-x509.patch
-Patch35:openssl-0.9.7-beta5-version-add-engines.patch
+Patch35:openssl-0.9.8j-version-add-engines.patch
Patch38:openssl-0.9.8a-reuse-cipher-change.patch
# Disabled this because it uses getaddrinfo which is lacking on Windows.
#Patch39:openssl-0.9.8g-ipv6-apps.patch
-Patch50:openssl-0.9.8g-speed-bug.patch
-Patch51:openssl-0.9.8g-bn-mul-bug.patch
-Patch52:openssl-0.9.8g-cve-2008-0891.patch
-Patch53:openssl-0.9.8g-cve-2008-1671.patch
+Patch40:openssl-0.9.8j-nocanister.patch
+Patch41:openssl-0.9.8j-use-fipscheck.patch
+Patch42:openssl-0.9.8j-fipscheck-hmac.patch
+Patch43:openssl-0.9.8j-evp-nonfips.patch
+Patch44:openssl-0.9.8j-kernel-fipsmode.patch
+Patch45:openssl-0.9.8j-env-nozlib.patch
+Patch46:openssl-0.9.8j-eap-fast.patch
+Patch47:openssl-0.9.8j-readme-warning.patch
+Patch48:openssl-0.9.8j-bad-mime.patch
+Patch49:openssl-0.9.8j-fips-no-pairwise.patch
+# Backported fixes including security fixes
# MinGW-specific patches.
Patch100: mingw32-openssl-0.9.8g-header-files.patch
Patch101: mingw32-openssl-0.9.8g-configure.patch
-Patch102: mingw32-openssl-0.9.8g-shared.patch
+Patch102: mingw32-openssl-0.9.8j-shared.patch
Patch103: mingw32-openssl-0.9.8g-global.patch
Patch104: mingw32-openssl-0.9.8g-sfx.patch
@@ -65,11 +90,12 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildArch: noarch
-BuildRequires: mingw32-filesystem >= 26
+BuildRequires: mingw32-filesystem >= 40
Build
Re: fontconfig
Richard W.M. Jones wrote: > On Thu, Jan 29, 2009 at 08:25:30PM +0100, Erik van Pienbroek wrote: >> I think it is safe to forget about fontconfig and freetype on Win32 and >> stick with the native font implementations of Cairo and Pango. > > Thanks for looking into this in detail. Do you think it's worth just > keeping the packages around? i'd keep them around but don't update it. -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: rpms/mingw32-filesystem/devel mingw32-filesystem.spec, 1.12, 1.13 mingw32-macros.mingw32, 1.7, 1.8
Richard W.M. Jones wrote:
> Author: rjones
>
> Update of /cvs/pkgs/rpms/mingw32-filesystem/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv3422
>
> Modified Files:
> mingw32-filesystem.spec mingw32-macros.mingw32
> Log Message:
> - Use PKG_CONFIG_LIBDIR instead of PKG_CONFIG_PATH so that native pkgconfig
> is never searched.
>
>
>
> Index: mingw32-filesystem.spec
> ===
> RCS file: /cvs/pkgs/rpms/mingw32-filesystem/devel/mingw32-filesystem.spec,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -u -r1.12 -r1.13
> --- mingw32-filesystem.spec 26 Jan 2009 17:21:27 - 1.12
> +++ mingw32-filesystem.spec 30 Jan 2009 09:38:05 - 1.13
> @@ -1,7 +1,7 @@
> %define debug_package %{nil}
>
> Name: mingw32-filesystem
> -Version:44
> +Version:45
> Release:1%{?dist}
> Summary:MinGW base filesystem and environment
>
> @@ -153,6 +153,10 @@
>
>
> %changelog
> +* Wed Jan 28 2009 Richard W.M. Jones - 45-1
> +- Use PKG_CONFIG_LIBDIR instead of PKG_CONFIG_PATH so that native pkgconfig
> + is never searched.
> +
> * Mon Jan 26 2009 Richard W.M. Jones - 44-1
> - Install rpmlint overrides file to suppress some rpmlint warnings.
>
>
>
> Index: mingw32-macros.mingw32
> ===
> RCS file: /cvs/pkgs/rpms/mingw32-filesystem/devel/mingw32-macros.mingw32,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -u -r1.7 -r1.8
> --- mingw32-macros.mingw3224 Jan 2009 18:11:43 - 1.7
> +++ mingw32-macros.mingw3230 Jan 2009 09:38:05 - 1.8
> @@ -54,7 +54,7 @@
> %_mingw32_findrequires/usr/lib/rpm/mingw32-find-requires.sh
>
> %_mingw32_env HOST_CC=gcc; export HOST_CC; \
> - PKG_CONFIG_PATH="%{_mingw32_libdir}/pkgconfig"; export PKG_CONFIG_PATH; \
> + PKG_CONFIG_LIBDIR="%{_mingw32_libdir}/pkgconfig"; export
> PKG_CONFIG_LIBDIR; \
>_PREFIX="%{_bindir}/%{_mingw32_target}-"; \
>for i in `ls -1 ${_PREFIX}* | grep -v 'gcc-'`; do \
> x=`echo $i|sed "s,${_PREFIX},,"|tr "a-z+-" "A-ZX_"`; \
>
is it sure? in man pkg-config:
-
PKG_CONFIG_PATH
A colon-separated (on Windows, semicolon-separated) list
of directories to search for .pc files. The default directory will
always be searched after searching the path; the
default is libdir/pkgconfig:datadir/pkgconfig where libdir
is the libdir where pkg-config and datadir is the datadir where
pkg-config was installed.
...
PKG_CONFIG_LIBDIR
Replaces the default pkg-config search directory.
-
so it seems to me it should have to be
PKG_CONFIG_LIBDIR="%{_mingw32_libdir}
isn't it?
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: [PATCH] Ignore the default %libdir/pkgconfig directory
Richard W.M. Jones wrote:
> On Wed, Jan 28, 2009 at 03:42:23PM -0800, Dan Nicholson wrote:
>> On Wed, Jan 28, 2009 at 3:38 PM, Richard W.M. Jones
>> wrote:
>>> On Wed, Jan 28, 2009 at 03:33:39PM -0800, Dan Nicholson wrote:
If you set
PKG_CONFIG_LIBDIR=/usr/i686-pc-mingw/sys-root/mingw/lib/pkgconfig,
does that also work? I believe that was the intention of this
variable.
>>> Yes, I think that should work, and I'm not sure why we didn't see it
>>> before. Anyhow, I'll try it out later this week.
>> Pretty easy to test. Assume you have foo.pc in
>> /usr/i686-pc-mingw/sys-root/mingw/lib/pkgconfig and
>> /usr/lib/pkgconfig.
>>
>> $ PKG_CONFIG_LIBDIR=/usr/i686-pc-mingw/sys-root/mingw/lib/pkgconfig
>> PKG_CONFIG_DEBUG_SPEW=1 pkg-config --print-errors --exists foo
>>
>> That should give you any information you need to see. You can also
>> make PKG_CONFIG_LIBDIR into a PATH like variable:
>>
>> PKG_CONFIG_LIBDIR=/usr/i686-pc-mingw/sys-root/mingw/lib/pkgconfig:/usr/i686-pc-mingw/sys-root/mingw/share/pkgconfig
>
> Yes, I confirmed this does work.
you mean in this way?
--
Levente "Si vis pacem para bellum!"
Index: mingw32-filesystem.spec
===
RCS file: /cvs/pkgs/rpms/mingw32-filesystem/devel/mingw32-filesystem.spec,v
retrieving revision 1.12
diff -u -r1.12 mingw32-filesystem.spec
--- mingw32-filesystem.spec 26 Jan 2009 17:21:27 - 1.12
+++ mingw32-filesystem.spec 28 Jan 2009 23:53:19 -
@@ -1,7 +1,7 @@
%define debug_package %{nil}
Name: mingw32-filesystem
-Version:44
+Version:45
Release:1%{?dist}
Summary:MinGW base filesystem and environment
@@ -153,6 +153,9 @@
%changelog
+* Wed Dec 29 2008 Levente Farkas - 45-1
+- Remove parameters from mingw32-make
+
* Mon Jan 26 2009 Richard W.M. Jones - 44-1
- Install rpmlint overrides file to suppress some rpmlint warnings.
Index: mingw32-macros.mingw32
===
RCS file: /cvs/pkgs/rpms/mingw32-filesystem/devel/mingw32-macros.mingw32,v
retrieving revision 1.7
diff -u -r1.7 mingw32-macros.mingw32
--- mingw32-macros.mingw32 24 Jan 2009 18:11:43 - 1.7
+++ mingw32-macros.mingw32 28 Jan 2009 23:53:19 -
@@ -55,6 +55,7 @@
%_mingw32_env HOST_CC=gcc; export HOST_CC; \
PKG_CONFIG_PATH="%{_mingw32_libdir}/pkgconfig"; export PKG_CONFIG_PATH; \
+ PKG_CONFIG_LIBDIR="%{_mingw32_libdir}/pkgconfig"; export PKG_CONFIG_LIBDIR; \
_PREFIX="%{_bindir}/%{_mingw32_target}-"; \
for i in `ls -1 ${_PREFIX}* | grep -v 'gcc-'`; do \
x=`echo $i|sed "s,${_PREFIX},,"|tr "a-z+-" "A-ZX_"`; \
@@ -97,22 +98,6 @@
--mandir=%{_mingw32_mandir} \\\
--infodir=%{_mingw32_infodir}
-%_mingw32_make %{_mingw32_env} ; \
- make \\\
- prefix=%{_mingw32_prefix} \\\
- exec_prefix=%{_mingw32_exec_prefix} \\\
- bindir=%{_mingw32_bindir} \\\
- sbindir=%{_mingw32_sbindir} \\\
- sysconfdir=%{_mingw32_sysconfdir} \\\
- datadir=%{_mingw32_datadir} \\\
- includedir=%{_mingw32_includedir} \\\
- libdir=%{_mingw32_libdir} \\\
- libexecdir=%{_mingw32_libexecdir} \\\
- localstatedir=%{_mingw32_localstatedir} \\\
- sharedstatedir=%{_mingw32_sharedstatedir} \\\
- mandir=%{_mingw32_mandir} \\\
- infodir=%{_mingw32_infodir}
-
%_mingw32_makeinstall %{_mingw32_env} ; \
make \\\
prefix=%{?buildroot:%{buildroot}}%{_mingw32_prefix} \\\
@@ -130,3 +115,4 @@
infodir=%{?buildroot:%{buildroot}}%{_mingw32_infodir} \\\
install
+%_mingw32_make %{_mingw32_env} ; make
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: filesystem patch
Richard W.M. Jones wrote:
> On Thu, Jan 29, 2009 at 12:04:53AM +0100, Farkas Levente wrote:
>> Richard W.M. Jones wrote:
>>> On Wed, Jan 28, 2009 at 09:09:16PM +0100, Farkas Levente wrote:
>>>> Richard W.M. Jones wrote:
>>>>> On Wed, Jan 28, 2009 at 04:53:40PM +, Richard W.M. Jones wrote:
>>>>>> On Wed, Jan 28, 2009 at 03:09:22PM +0100, Farkas Levente wrote:
>>>>>>> hi,
>>>>>>> as i previously send it (i just update it and resend) i agree with dan's
>>>>>>> comment so i remove params from mingw32_make.
>>>>>>> devel branch is enough for this.
>>>>>> ACK.
>>>>> Although I'm still questioning why we need _mingw32_make at all ...
>>>> to be able to use the same source (ie. mingw32-macros.mingw32) and have
>>>> to edit it one place, for all helper scripts (ie. mingw32-configure
>>>> mingw32-make).
>>> No, no, I mean why do we need a make macro or script at all?
>>>
>>> The GNU coding standards define that this will work in all circumstances:
>>>
>>> ./configure --lots-of-options
>>> make
>>>
>>> where options on the ./configure command line are turned into defaults
>>> for make.
>> suppose you make some cross compilation development. everywhere you put
>> %{_mingw32_make} into the spec file but wouldn't like to always run it
>> through rpmbuild you can use mingw32-make in the working directory.
>
> No, I don't mean this. Why don't we remove both the _mingw32_make
> macro and the mingw32-make script? Any usage of this macro/script
> would be replaced by a simple 'make' command.
not all projects use gnu toolchain:-(
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: filesystem patch
Richard W.M. Jones wrote:
> On Wed, Jan 28, 2009 at 09:09:16PM +0100, Farkas Levente wrote:
>> Richard W.M. Jones wrote:
>>> On Wed, Jan 28, 2009 at 04:53:40PM +, Richard W.M. Jones wrote:
>>>> On Wed, Jan 28, 2009 at 03:09:22PM +0100, Farkas Levente wrote:
>>>>> hi,
>>>>> as i previously send it (i just update it and resend) i agree with dan's
>>>>> comment so i remove params from mingw32_make.
>>>>> devel branch is enough for this.
>>>> ACK.
>>> Although I'm still questioning why we need _mingw32_make at all ...
>> to be able to use the same source (ie. mingw32-macros.mingw32) and have
>> to edit it one place, for all helper scripts (ie. mingw32-configure
>> mingw32-make).
>
> No, no, I mean why do we need a make macro or script at all?
>
> The GNU coding standards define that this will work in all circumstances:
>
> ./configure --lots-of-options
> make
>
> where options on the ./configure command line are turned into defaults
> for make.
suppose you make some cross compilation development. everywhere you put
%{_mingw32_make} into the spec file but wouldn't like to always run it
through rpmbuild you can use mingw32-make in the working directory.
--
Levente "Si vis pacem para bellum!"
___
fedora-mingw mailing list
fedora-mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: filesystem patch
Richard W.M. Jones wrote: > On Wed, Jan 28, 2009 at 04:53:40PM +, Richard W.M. Jones wrote: >> On Wed, Jan 28, 2009 at 03:09:22PM +0100, Farkas Levente wrote: >>> hi, >>> as i previously send it (i just update it and resend) i agree with dan's >>> comment so i remove params from mingw32_make. >>> devel branch is enough for this. >> ACK. > > Although I'm still questioning why we need _mingw32_make at all ... to be able to use the same source (ie. mingw32-macros.mingw32) and have to edit it one place, for all helper scripts (ie. mingw32-configure mingw32-make). -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
openssl problems
hi, while i try to megre the new openssl i found that even the current mingw32-openssl packages generate a lot's of such warning during make depend and the same happend with the new version. is it normal? why it's looks into the system's native header dir at all? it's genrated by makedepend (which is part of imake) and probably generate useless information. in this case shouldn't we have simple comment out make depend? making depend in crypto... make[1]: Entering directory `/home/lfarkas/rpm/BUILD/openssl-0.9.8g/crypto' makedepend: warning: cryptlib.c (reading /usr/include/stdlib.h, line 33): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/bits/types.h, line 31): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: cryptlib.c (reading /usr/include/sys/types.h, line 147): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: openssl patch
Richard W.M. Jones wrote: > On Wed, Jan 28, 2009 at 01:43:20PM +0100, Farkas Levente wrote: >> hi, >> what about my openssl patch? >> i'd like to work on the new upstream openssl merge too. > > Yes, I hate openssl too. > > Probably best if you go ahead and rebase to the new openssl and then > post an updated patch. ok the first question what we do with ca-certificates? on fedora it's been removed from openssl and a new packages created for this. do we create a new mingw32 packages? -- Levente "Si vis pacem para bellum!" ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
