Ticket #71 (closed enhancement: fixed)

Opened 3 years ago

Last modified 3 years ago

MinGW cross compiler guidelines updated for mingw-w64 support

Reported by: epienbro Owned by: spot
Priority: minor Milestone:
Component: Guideline Draft Version:
Keywords: Cc: rjones
Blocked By: Blocking:

Description

Hi FPC,

Right now we already have a set of packages in Fedora which can be used to build binaries for the Win32 target. This set of packages is based on the mingw.org toolchain. This toolchain isn't well maintained anymore (by upstream) and doesn't have support for the Win64 target.

As there's quite a lot of demand for Win64 support these days we (the Fedora MinGW SIG) are planning to introduce the mingw-w64 toolchain in Fedora. This toolchain can build binaries for both the Win32 and the Win64 targets and is much better maintained.

In order to avoid duplication and making things easier for package maintainers we've decided to introduce a set of RPM macros which will assist package maintainers in building binaries for multiple targets from a single .spec file. This means that for example a source rpm named 'mingw-glib2' will generate two binary rpms called 'mingw32-glib2' and 'mingw64-glib2'.

This set of RPM macros is explained at https://fedoraproject.org/wiki/PackagingDrafts/MinGWCrossCompiler. These guidelines will obsolete the original MinGW packaging guidelines. All current mingw32-* packages can be rebuilt against this new toolchain. Only a small amount of mingw32-* packages require patching to build successfully (this has already been prepared in a separate testing repository). There's also a porting guide available for package maintainers who want to port their mingw32-* package to have Win64 support: https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework#Porting_guide_porting_guide

Could you please review and approve these guidelines?

Kind regards,

Erik van Pienbroek

Change History

comment:1 Changed 3 years ago by spot

Reworked draft at https://fedoraproject.org/wiki/PackagingDrafts/MinGWCrossCompiler to:

  • Make it clear that these guidelines only apply to MinGW and not to any other cross-compiler
  • Drop the section concerning the (external to Fedora Packaging Guidelines) porting guide, as it contains naming requirements that are outside the scope of just MinGW. The FPC would like to address any attempt at creating a unified cross-compiler guidelines in a separate ticket, so if you (or anyone) wants to propose new text for that situation, please feel free to open a new ticket.

comment:2 Changed 3 years ago by rjones

  • Cc rjones added

comment:3 Changed 3 years ago by spot

A few areas of concern that came up at today's meeting.

1) No valid spec template for this new approach. 2) No need for separated source RPMS (mingw-* is fine for everything, even if it only spits out mingw32-* or mingw64-* subpackages) 3) _mingw_find_lang should be renamed to mingw_find_lang for consistency. The same change applies to %{_mingw_configure} %{_mingw_cmake}, %{_mingw_make} and %{_mingw_make_install} 4) "Packages which don't support out of source compilation may require a different approach like performing everything in the %install phase." should be changed to "Packages which don't support out of source compilation may require a different approach like making multiple copies of the source tree in %prep." 5) This draft only covers Fedora 16+, we need guidance on what should be done with F-15 and older.

We will meet again on April 6, 2011 (1600 UTC at #fedora-meeting on irc.freenode.net) to discuss this. If possible, please attend!

comment:4 Changed 3 years ago by toshio

Additional note: I think in "Compilation of binaries", the %{_mingw32_configure} note is more complex than necessary but I'm not sure precisely the problem you're working around. I think that you're running into the problem that "%{macro} arg" doesn't give the argument to the macro. Please see if this syntax works: "%macro arg", no curly braces. If so, we probably want to write this more like what's in the note at the bottom of this section:

http://fedoraproject.org/wiki/Packaging:Python#Bytecompiling_with_the_correct_python_version

comment:5 Changed 3 years ago by epienbro

Sorry for the delay. I'm currently really swamped with work at my dayjob so my spare time is very limited. Unfortunately I can't make it to the meetings as I'm always on the road at the time the meeting is, so we have to keep discussions in this ticket or on IRC..

First of all: thanks for the review. I've read the meeting logs and I'll try to respond to all the concerns which were mentioned there:

16:05:16 <tibbs> Can we fix the FIXME at the top by just moving the template into the guideline?

I've just created a template spec file and published it at http://svn.openftd.org/svn/fedora_cross/mingw-example/mingw-example.spec. I'll replace the FIXME in the proposal with that URL

16:09:22 <abadger1999> Do the win64 and win32 binaries get placed into two different subpackages? 16:10:00 <tibbs> Tough to say without an updated example spec, I guess. 16:10:06 <tibbs> But I don't see why that would need to be the case. 16:10:09 <spot> Each cross compiled MinGW package which builds binaries for a specific target should put the binaries for that target in a separate subpackage. So if a package foo builds binaries for the Win32 and Win64 targets, then the source RPM should provide two subpackages named mingw32-foo and mingw64-foo. 16:10:17 <spot> So, yes. <snip> 16:13:37 <abadger1999> Not sure why we're separating mingw32, ming2, and mingw64 at the srpm level... seems more appropriate to name everything mingw- and separate at the binary package level.

The idea is that there is only 1 SRPM per package named 'mingw-foo'. When building this SRPM, it will generate two binary RPMS named 'mingw32-foo' and 'mingw64-foo'.

16:10:41 <tibbs> What about common files and such?

So far there have been no mingw32-* packages which provide common files. Almost all current mingw32-* packages manually remove stuff like man-pages and info-pages because of two reasons: 1) because they are already provided by their native counterparts and 2) because they aren't useful for cross-compilation. The only real useful files are binaries, headers, import libraries, static libraries and libtool .la files.

16:17:49 <abadger1999> Rename this macro: %_mingw_find_lang => %mingw_find_lang

Do you want me to apply this change to just this macro or for every macro? All other mingw macros already start with an underscore.

16:24:59 <abadger1999> "Packages which don't support out of source compilation may require a different approach like performing everything in the %install phase." <= I'd prefer copying of the source tree in %prep to what they seem to be saying here (do the configure and build steps in the %install section) <snip> 16:29:24 <spot> 4) "Packages which don't support out of source compilation may require a different approach like performing everything in the %install phase." should be changed to "Packages which don't support out of source compilation may require a different approach like making multiple copies of the source tree in %prep."

Sounds good enough to me, I'll update the draft

16:26:07 <abadger1999> %{_mingw_configure "--disable-xlib" "--enable-win32"} I think that and the following disclaimer can be changed to => %_mingw_configure --disable-xlib --enable-win32 16:26:41 <spot> abadger1999: well, i think that won't actually work.

I remember that some time ago I tried something along these lines, but failed to get it working correctly. Let me dig through my archives for more details about that..

16:32:57 <tibbs> We're also going to have to figure out what to do on F13-F15. 16:33:05 <tibbs> Since this is an F16-only draft.

The current approved mingw guidelines can be kept alive for Fedora <= 15 and EPEL 5. The proposed new guidelines are fully backwards compatible with the original mingw guidelines. That is: all macros which are mentioned in the original mingw guidelines are also still available with these new guidelines. All packages which are valid according to the old guidelines can also be rebuilt successfully with the RPM macros provided by the new mingw-filesystem package which implements the proposed new guidelines.

The following links might also be of interest to you. They contain all the RPM macros which are mentioned in the proposed guidelines and are part of the mingw-filesystem package:

http://svn.openftd.org/svn/fedora_cross/mingw-filesystem/macros.mingw http://svn.openftd.org/svn/fedora_cross/mingw-filesystem/macros.mingw32 http://svn.openftd.org/svn/fedora_cross/mingw-filesystem/macros.mingw64

If you've got more questions feel free to drop them here or on IRC (my nick is 'epienbro')

comment:6 Changed 3 years ago by spot

  • Owner set to spot
  • Status changed from new to assigned

Approved with two changes: 1) Include spec template inline (at the end of the page) 2) Switch _mingw* macros in draft and template spec to mingw* (+1:7, 0:0, -1:0)

comment:7 Changed 3 years ago by epienbro

The mingw-filesystem package which implements the macros for the approved guidelines has been put up for review at https://bugzilla.redhat.com/show_bug.cgi?id=673784

The use of macros without the curly braces (mingw_configure, mingw_make, ...) is working with this updated package as well. In order to get it to work without any side-effects I had to terminate the macros with a %nil so the current guidelines can stand as is

About the two changes you mentioned in your last reply, do you want me to apply those changes or do you prefer to do it yourselves?

comment:8 Changed 3 years ago by spot

Announcement text:

The Guidelines covering MinGW packaging have been updated for Fedora 16. The previous guidelines still apply for older Fedora releases (Fedora 15 and older) and all RHEL releases.

https://fedoraproject.org/wiki/Packaging:MinGW https://fedoraproject.org/wiki/Packaging:MinGW_Old

comment:9 Changed 3 years ago by spot

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.