April 2011 - openSUSE MinGW - openSUSE Mailing Lists

which pkg-config to use
by Maarten Bosmans 26 Apr '11

26 Apr '11

When pkg-config is required for a package because it is needed by the configure script, it needs to be listed as a BuildRequired dependency in the spec file. Currently I see three different versions of the dependency: BuildRequires: pkgconfig (most common) BuildRequires: pkg-config (e.g. mingw32-cairo) BuildRequires: mingw32-cross-pkg-config (e.g. mingw-poppler) Which one should be used? And a related question: I presume pkgconfig and pkg-config come from the native OpenSUSE package and mingw32-cross-pkg-config from the package with the same name. But what does the mingw32-pkg-config package provide? Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-mingw+help(a)opensuse.org

2 10

Linking against win_iconv
by Maarten Bosmans 22 Apr '11

22 Apr '11

2011/4/12 Fridrich Strba <fridrich.strba(a)bluewin.ch>: > Another policy is that we don't distribute static libraries unless there is > a huge reason for this. The exception nowadays is the iconv implementation > that we use win_iconv, because it only translates between iconv APIs and > win32 native APIs and distribute it as a dll would not make any sense, > especially that it is not developed as such by the developer. When trying to link a project (pulseaudio) against win_iconv, I got problems. The pulseaudio configure scripts detects the iconv implementation, but then tries to link against the dynamic library, which does not exist. The problem seems to lie in the following line in the mingw32-filesystem macros file: %_mingw32_ldflags -Wl,--exclude-libs=libintl.a -Wl,--exclude-libs=libiconv.a I had to explicitly disable the MINGW32_LDFLAGS to get pulseaudio to compile. Specfile here: https://build.opensuse.org/package/view_file?file=mingw32-pulseaudio.spec&p… Is this the correct way of statically linking against win_iconv, or is there some other way? Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-mingw+help(a)opensuse.org

2 2

.def files in packages :)
by Fridrich Strba 20 Apr '11

20 Apr '11

Hello, Just a quick note, that some packages have before make things like "rm -f gtk/gtk.def gdk/gdk.def" This is wanted, because the def files will be regenerated from the *.symbols files on build time and correspond to the system the packages are built for. Which is for us not the same as the system on which the "make dist" was run. So, it is good to leave them there, and they don't prevent from being able to distribute the def files in the packages. Cheers Fridrich -- Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-mingw+help(a)opensuse.org

2 1

renaming -debug packages
by Maarten Bosmans 20 Apr '11

20 Apr '11

Hi all, Some source packages have different names than the produced noarch packages (e.g. mingw32-cairo vs. mingw32-libcairo2). This is not a problem per se, but I thought it would be good to at least have the -debug package always have the same name as the package that provides the corresponding DLLs. So I propose the following name changes: (along with some -tools changes) mingw32-bzip2-debug mingw32-libbz2-debug mingw32-jasper-debug mingw32-libjasper-debug mingw32-jpeg-debug mingw32-libjpeg-debug mingw32-lcms-debug mingw32-liblcms-debug mingw32-lcms2-debug mingw32-liblcms2-debug mingw32-poppler-debug mingw32-libpoppler-debug mingw32-tiff-debug mingw32-libtiff-debug mingw32-tiff mingw32-libtiff-tools mingw32-rsvg-view mingw32-librsvg-tools mingw32-cairo-debug mingw32-libcairo2-debug mingw32-cairo-devel mingw32-libcairo2-devel Would the proposed package renaming pose a problem for anybody? Furthermore, it would be good to move some bindir/*.exe to the -devel package, in order to make the main package as minimalistic as possible, with only the .dll file. This can be done for instance in libcroco, fontconfig and libxml2. I'm not sure about querymodules.exe in pango. Should it go into -tools or can it go into -devel? Also, glib2 has gspawn-win32-helper.exe. Is that needed at runtime or can it also go into -tools? I myself never had the need for these programs. Then there is the problem of actually naming the debug package something different than the source package name with the -debug suffix. The definition of the macro in mingw32-filesystem suggests that it is possible to give it a package name as argument, so I have tried the following for mingw32-lcms: %_mingw32_debug_package liblcms-debug %_mingw32_debug_package -n liblcms-debug %_mingw32_debug_package(liblcms-debug) None of those work. How is this supposed to work? Currently no package uses the argument to rename the debug package, so there is no example. May be it isn't possible after all? Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-mingw+help(a)opensuse.org

2 1

differences between mingw32 and mingw64
by Maarten Bosmans 20 Apr '11

20 Apr '11

Hi list, In order to understand the differences between mingw32 and mingw64 packages, I made a diff between all the packages in the two projects. To be able to compare the two, a script was used to rename all directories/files with mingw32 or mingw64 in the name to mingwXX and do the same replacement for contents of .spec files. There are several types of differences between win32 and win64 projects: Unintentional whitespace differences or added empty lines, e.g. --- windows:mingw:win32/mingwXX-freetype/mingwXX-freetype.spec 2011-04-13 16:54:02.444618000 +0200 +++ windows:mingw:win64/mingwXX-freetype/mingwXX-freetype.spec 2011-04-13 16:53:57.968618000 +0200 @@ -14,7 +14,7 @@ -Source1: http://download.savannah.gnu.org/releases/freetype/freetype-doc-%{version}.… +Source1: http://download.savannah.gnu.org/releases/freetype/freetype-doc-%{version}.… Unsynchronized versions, e.g. --- windows:mingw:win32/mingwXX-gc/mingwXX-gc.spec 2011-04-13 16:54:02.456618000 +0200 +++ windows:mingw:win64/mingwXX-gc/mingwXX-gc.spec 2011-04-13 16:53:57.980618000 +0200 -Version: 7.1 +Version: 7.2alpha4 (with corresponding different .tar.gz files) Differences I'm unable to tell whether they are intentional or unintenional, e.g. --- windows:mingw:win32/mingwXX-gcc/mingwXX-cross-gcc.spec 2011-04-13 16:54:02.464618000 +0200 +++ windows:mingw:win64/mingwXX-gcc/mingwXX-cross-gcc.spec 2011-04-13 16:53:57.992618000 +0200 -%define include_java 1 +%define include_java 0 Real differences in packaging that are correct, e.g. --- windows:mingw:win32/mingwXX-glib2/mingwXX-glib2.spec 2011-04-13 16:54:02.556618000 +0200 +++ windows:mingw:win64/mingwXX-glib2/mingwXX-glib2.spec 2011-04-13 16:53:58.084618000 +0200 -%{_mingwXX_bindir}/gspawn-win32-helper.exe +%{_mingwXX_bindir}/gspawn-win64-helper.exe Is there some (semi-)automated way to keep the packages in both repositories synchronized? That would prevent a lot of these little mistakes. (In general I'm quite unaware of what the workflow is to get both win32 and win64 packages. I only submit mingw32 requests and let Fridrich handle the rest.) A possible (but quite intrusive) solution could be to rename all the packages to just a mingw- prefix (without numbers) and do the same for the rpm macros. That way all the packages in win64 could be branched of the win32 packages. For most packages this would just work and packages that need specific changes, those can be added to the mingw64 package. Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-mingw+help(a)opensuse.org

2 2

Invocation of make in spec file
by Maarten Bosmans 15 Apr '11

15 Apr '11

When comparing win32 and win64 packages (see previous mail), I saw a lot of trivial differences of the following kind: (- is win32 and + is win64) -%{_mingwXX_make} %{?_smp_mflags} || %{_mingwXX_make} +%{_mingwXX_make} or just -make %{?_smp_mflags} || make +make Why is the first style (with ||) used? I would think that a package maintainer should know whether a package is buildable in parallel or not and just give the right invocation, without the retry on fail. The extra make also makes errors harder to spot in the build log. I'd propose to just do a batch convert to make %{?_smp_mflags} (at least for all autotools-based packages) and if any packages fail to build, replace that line with a simple make. Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-mingw+help(a)opensuse.org

2 1

OBS repositories and static libraries
by Fridrich Strba 13 Apr '11

13 Apr '11

Hello, good people, I wanted just to point out some policies we decided when we started this mingw cross-compiling in OBS. These policies were based on our experience with win32 porting. One is that we don't distribute the *.la files. They hard-code the configure time paths and are basically worthless for linking. If something does not link without them there is a problem somewhere else :) Another policy is that we don't distribute static libraries unless there is a huge reason for this. The exception nowadays is the iconv implementation that we use win_iconv, because it only translates between iconv APIs and win32 native APIs and distribute it as a dll would not make any sense, especially that it is not developed as such by the developer. It is true that in the win32 world, many people, me including (Tor will remember) liked to make as much binaries as possible statically linked so that they can distribute only one *.exe. But, from experience, a multitude of dlls is better even for pixman that might be at one point used by something else then cairo. Cheers Fridrich -- Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-mingw+help(a)opensuse.org

3 3

CRT_glob.o in latest MinGW32 cross-compiler
by Roger Oberholtzer 11 Apr '11

11 Apr '11

Previous to the recent Mingw32 cross compiler update, linking with /usr/i686-pc-mingw32/sys-root/mingw/lib/CRT_glob.o added expansion of command line wild cards to applications. After the new compiler release, and linking with /usr/i686-w64-mingw32/sys-root/mingw/lib/CRT_glob.o, this no longer works. In fact, main() never gets called. The program simply exits. It looks odd that CRT_glob.o is only 917 bytes. Must be some darned efficient code! Is it expected that this should be working? Is it still enough to simply link with the object? Does order play a role? Or some additional flags? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer(a)ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-mingw+help(a)opensuse.org

1 0

GNOME3/GTK 3 libraries and strategy
by Fridrich Strba 08 Apr '11

08 Apr '11

Hello, good people, For those that would be interested in starting to package some GNOME3/GTK3 libraries, not that in the windows:mingw:win32:EXPERIMENTAL and windows:mingw:win64:EXPERIMENTAL I have already started some of them. For the while mainly as links to their GNOME2/GTK2 counterparts. This situation is temporary though. Since GTK3 is far from being ready for prime-time on Windows, it is likely that we will have both versions around for some time. That is why I suggest that we little by little start to think about renaming the relevant packages so that they can coexist in the same repository. I suggest that we look how the GNOME OBS project does with the naming and inspire ourselves for windows from there. And I would not mind to have some opinions. F. -- Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-mingw+help(a)opensuse.org

1 0

Python script to download packages from the download repository
by Maarten Bosmans 07 Apr '11

07 Apr '11

Hi all, For a couple of months now I am using a python script to automate the downloading of packages for windows. as it might by of interest for more people, I have now cleaned it up a bit. See attached file. Keep in mind that although very much usable, this is still work in progress. The only dependencies are Python (>= v3.1) and 7zip. I use it mainly from cygwin on Windows, but is also works from cmd.exe (make sure you have 7z.exe in the path) and Linux. The simplest usage form is: ./download-mingw-rpm.py libpoppler This downloads DLLs of poppler(mingw32-libpoppler package + dependencies) and extracts the packages below the location of the script. You can also specify another repository and build a zip file of the extracted packages. This is what I use to build a zip file of a mingw build of PulseAudio, to provide an easy download for people that want to try PulseAudio on Windows: ./download-mingw-rpm.py --make-zip --project home:mkbosmans:mingw32:pulseaudio pulseaudio I hope this can be of convenience for some people. Feedback appreciated. Maarten

2 2