Question about bootstrapping MinGW
Mojca Miklavec
mojca at macports.org
Thu Dec 8 16:10:13 CET 2016
Hi,
Here's the forgotten link:
https://github.com/mojca/macports-user-mojca/tree/master/ports/cross
On 7 December 2016 at 22:02, Mojca Miklavec wrote:
>
> I have finally managed to come up with ports for MinGW-w64. It seems
> to work as expected except for a tiny problem: gcc has to be compiled
> in two stages. The first stage installs the bootstrapped version of
> the compiler and the second stage installs everything (else).
>
> I created two subports (it would have to be three if support for
> pthreads is required):
> x86_64-w64-mingw32-gcc
> x86_64-w64-mingw32-all
> (suggestions for better names welcome, I don't particularly like
> "-all", maybe the first one could be "-gcc-bootstrap" and the second
> one simply "-gcc").
>
> The first one does "make all-gcc && make install-gcc".
> The last one does "make && make install" on the same sources (after
> the same configure), except that the second one needs additional
> dependencies to complete.
>
> (The intermediate port would do "make all-target-libgcc && make
> install-target-libgcc" if it was required.)
>
> The problem is that both subports install the same files (the
> bootstrapped version installs a subset). I'm not sure if the
> overlapping files are actually the same or not. Maybe I could do some
> testing with binary comparison (like the one Clemens presented at the
> meeting), upstream suggested to use the result of the final "make
> install" rather than the bootstrapped files.
>
> How could I solve that? A few things come to mind.
>
> (1) In a post-destroot phase of the second subport ("-all") iterate
> through the installed files and delete all the files that were already
> installed by the bootstrapping port ("-gcc"). A potential disadvantage
> might be that those files might not be the same. But I would have to
> double check that.
>
> (2) Install the bootstrapping port to a completely different location.
> Slightly more annoying to implement.
>
> (3) I tried the deactivate hack:
>
> set mingw_target x86_64-w64-mingw32
> set mingw_gcc_bootstrap ${mingw_target}-gcc
>
> subport ${mingw_target}-all {
> depends_build-append \
> port:${mingw_target}-crt \
> bin:${mingw_target}-gcc:${mingw_target}-gcc
>
> pre-activate {
> if {![catch {set installed [lindex [registry_active
> ${mingw_gcc_bootstrap}] 0]}]} {
> registry_deactivate_composite ${mingw_gcc_bootstrap} ""
> [list ports_nodepcheck 1]
> }
> }
> }
>
> Maybe I added this to the port too late (I added it once I already had
> it destrooted and manually forced-deactivated x86_64-w64-mingw32-gcc
> first), but it insisted that I should have installed
> x86_64-w64-mingw32-gcc before activating x86_64-w64-mingw32-all. I'll
> try it once again. I'm not sure if this is something that is supposed
> to work at all.
I tried building everything from scratch once again and it seems to
have worked. Maybe I indeed added that block too late. What's still
not clear to me is how to properly specify the conflict between
"*-gcc" and "*-all". Either one may be installed when the other one is
being built, but both may not be activated at the same time.
Also, in an ideal world the package manager would check whether
"*-all" is already installed or available in a binary form and only if
it is not, it would start building the "*-gcc" port. But I don't know
if I can express the dependencies in that way. Probably not. If anyone
has any idea how to install "*-all" without having to install &
activate and deactivate the "*-gcc" port, I would be grateful.
> Which one sounds best? Or perhaps there are other better options?
I guess that either (1) or (3) should then be used. I don't know if I
should expect other random problems afterwards if I use (3).
> What's the proper licence for x86_64-w64-mingw32-gcc? The portgroup
> seems to set GPL-3+, while gcc6 has {GPL-3+ Permissive}.
>
> I would be also grateful for hints about the licence of headers and crt:
> https://github.com/mirror/mingw-w64/blob/master/COPYING
>From the following link:
https://trac.macports.org/wiki/PortfileRecipes#licensekeyword
I just realised that ZPL is already a known licence and MacPorts
treats the ports as distributable. So all seems to be fine from the
licencing perspective.
Another question. Some files installed by "*-crt" are object files for
windows (I guess they are totally independent of the host
architecture). Should these ports be declared "noarch" or not?
Mojca
More information about the macports-dev
mailing list