How to make sure that one port gets updated before another? (MinGW)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

How to make sure that one port gets updated before another? (MinGW)

Mojca Miklavec-2
Hi,

A while ago I tried to update MinGW-w64 to version 6. The problem is
that one needs to update both of these ports:
    x86_64-w64-mingw32-crt         5.0.4_0 < 6.0.0_0
    x86_64-w64-mingw32-winpthreads 5.0.4_0 < 6.0.0_0
but I cannot figure out how to force "sudo port upgrade outdated" to
update the crt port first. I did try to add the crt port to explicit
dependencies, but it doesn't seem to help.

> port info x86_64-w64-mingw32-winpthreads
x86_64-w64-mingw32-winpthreads @6.0.0 (cross, devel)
Variants:             universal

Description:          Mingw-w64 is an advancement of the original
mingw.org project, created to support the GCC compiler on Windows
systems.
Homepage:             http://mingw-w64.sourceforge.net/

Build Dependencies:   x86_64-w64-mingw32-gcc-nothreads, x86_64-w64-mingw32-crt
Library Dependencies: x86_64-w64-mingw32-crt
...
> port installed 'x86_64-w64-mingw32*'
The following ports are currently installed:
  x86_64-w64-mingw32-binutils @2.31.1_0 (active)
  x86_64-w64-mingw32-crt @5.0.4_0 (active)
  x86_64-w64-mingw32-gcc @8.2.0_0 (active)
  x86_64-w64-mingw32-headers @5.0.4_0
  x86_64-w64-mingw32-headers @6.0.0_0 (active)
  x86_64-w64-mingw32-winpthreads @5.0.4_0 (active)
> port outdated
The following installed ports are outdated:
x86_64-w64-mingw32-crt         5.0.4_0 < 6.0.0_0
x86_64-w64-mingw32-winpthreads 5.0.4_0 < 6.0.0_0
> sudo port upgrade outdated
--->  Computing dependencies for x86_64-w64-mingw32-winpthreads
--->  Configuring x86_64-w64-mingw32-winpthreads
--->  Building x86_64-w64-mingw32-winpthreads
Error: Failed to build x86_64-w64-mingw32-winpthreads: command execution failed

I admit that the dependencies are a tiny bit "cyclic" (there are some
path-style dependencies), but I don't know a better way to implement
this strange bootstrap process. The installation works from scratch,
but the automatic update fails and I'm not sure where to look.

Thank you very much,
    Mojca
Reply | Threaded
Open this post in threaded view
|

Re: How to make sure that one port gets updated before another? (MinGW)

Joshua Root-8
On 2018-10-27 07:27 , Mojca Miklavec wrote:
> Hi,
>
> A while ago I tried to update MinGW-w64 to version 6. The problem is
> that one needs to update both of these ports:
>     x86_64-w64-mingw32-crt         5.0.4_0 < 6.0.0_0
>     x86_64-w64-mingw32-winpthreads 5.0.4_0 < 6.0.0_0
> but I cannot figure out how to force "sudo port upgrade outdated" to
> update the crt port first. I did try to add the crt port to explicit
> dependencies, but it doesn't seem to help.

If A depends on B, then B will be upgraded before A. If A doesn't depend
on B, then why would the order matter?

If you're doing bootstrap stuff, consider making a -bootstrap subport of
whatever is needed to break the dependency cycles.

- Josh
Reply | Threaded
Open this post in threaded view
|

Re: How to make sure that one port gets updated before another? (MinGW)

Mojca Miklavec-2
On Fri, 26 Oct 2018 at 22:58, Joshua Root wrote:

> On 2018-10-27 07:27 , Mojca Miklavec wrote:
> > Hi,
> >
> > A while ago I tried to update MinGW-w64 to version 6. The problem is
> > that one needs to update both of these ports:
> >     x86_64-w64-mingw32-crt         5.0.4_0 < 6.0.0_0
> >     x86_64-w64-mingw32-winpthreads 5.0.4_0 < 6.0.0_0
> > but I cannot figure out how to force "sudo port upgrade outdated" to
> > update the crt port first. I did try to add the crt port to explicit
> > dependencies, but it doesn't seem to help.
>
> If A depends on B, then B will be upgraded before A.

Except that this doesn't happen in my case.

I added an explicit dependency on x86_64-w64-mingw32-crt (both build
and lib, just to be sure) and it's still not being updated before
x86_64-w64-mingw32-winpthreads.

> If you're doing bootstrap stuff, consider making a -bootstrap subport of
> whatever is needed to break the dependency cycles.

I do have two bootstrapping subports of x86_64-w64-mingw32-gcc (with
suffix -boostrap and -nothreads). But maybe the logic is wrong
somehow?

Note that MacPorts doesn't complain about a dependency cycle and there
were never any issues with that so far (I'm talking exclusively about
existing ports, not about any new ones). The only change I made now
was to add an explicit dependency on -crt (but that didn't really help
in any way, and I'm not sure why not).

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: How to make sure that one port gets updated before another? (MinGW)

Joshua Root-8
On 2018-10-27 08:20 , Mojca Miklavec wrote:

> On Fri, 26 Oct 2018 at 22:58, Joshua Root wrote:
>> On 2018-10-27 07:27 , Mojca Miklavec wrote:
>>> Hi,
>>>
>>> A while ago I tried to update MinGW-w64 to version 6. The problem is
>>> that one needs to update both of these ports:
>>>     x86_64-w64-mingw32-crt         5.0.4_0 < 6.0.0_0
>>>     x86_64-w64-mingw32-winpthreads 5.0.4_0 < 6.0.0_0
>>> but I cannot figure out how to force "sudo port upgrade outdated" to
>>> update the crt port first. I did try to add the crt port to explicit
>>> dependencies, but it doesn't seem to help.
>>
>> If A depends on B, then B will be upgraded before A.
>
> Except that this doesn't happen in my case.
>
> I added an explicit dependency on x86_64-w64-mingw32-crt (both build
> and lib, just to be sure) and it's still not being updated before
> x86_64-w64-mingw32-winpthreads.

If dependencies didn't get upgraded before their dependents, there would
be a lot of serious problems. Since we don't see that, let's assume
something else is going on here. Is there an actual circular dependency?

- Josh
Reply | Threaded
Open this post in threaded view
|

Re: How to make sure that one port gets updated before another? (MinGW)

Joshua Root-8
In reply to this post by Mojca Miklavec-2
On 2018-10-27 08:20 , Mojca Miklavec wrote:
> Note that MacPorts doesn't complain about a dependency cycle
It won't if it can find some port that can be upgraded. Upgrade can work
a little differently to install in this respect, since often all
dependencies are already installed (if not the latest version).

- Josh
Reply | Threaded
Open this post in threaded view
|

Re: How to make sure that one port gets updated before another? (MinGW)

Mojca Miklavec-2
In reply to this post by Joshua Root-8
On Fri, 26 Oct 2018 at 23:26, Joshua Root wrote:

> On 2018-10-27 08:20 , Mojca Miklavec wrote:
> > On Fri, 26 Oct 2018 at 22:58, Joshua Root wrote:
> >> On 2018-10-27 07:27 , Mojca Miklavec wrote:
> >>> Hi,
> >>>
> >>> A while ago I tried to update MinGW-w64 to version 6. The problem is
> >>> that one needs to update both of these ports:
> >>>     x86_64-w64-mingw32-crt         5.0.4_0 < 6.0.0_0
> >>>     x86_64-w64-mingw32-winpthreads 5.0.4_0 < 6.0.0_0
> >>> but I cannot figure out how to force "sudo port upgrade outdated" to
> >>> update the crt port first. I did try to add the crt port to explicit
> >>> dependencies, but it doesn't seem to help.
> >>
> >> If A depends on B, then B will be upgraded before A.
> >
> > Except that this doesn't happen in my case.
> >
> > I added an explicit dependency on x86_64-w64-mingw32-crt (both build
> > and lib, just to be sure) and it's still not being updated before
> > x86_64-w64-mingw32-winpthreads.
>
> If dependencies didn't get upgraded before their dependents, there would
> be a lot of serious problems. Since we don't see that,

Except ... hmmm ...
    https://trac.macports.org/ticket/57457
    Travis CI: Sometimes declared dependencies aren't installed
?

> let's assume
> something else is going on here. Is there an actual circular dependency?

That's why I came up to ask for someone's help.

For the port x86_64-w64-mingw32-crt there is
    depends_build bin:x86_64-w64-mingw32-gcc:x86_64-w64-mingw32-gcc-bootstrap
which is satisfied by either of these:
- x86_64-w64-mingw32-gcc-bootstrap
- x86_64-w64-mingw32-gcc-nothreads
- x86_64-w64-mingw32-gcc

For the port x86_64-w64-mingw32-winpthreads there is now
    depends_build \
        path:x86_64-w64-mingw32/lib/libgcc_s.a:x86_64-w64-mingw32-gcc-nothreads
\
        port:x86_64-w64-mingw32-crt
where the first dependency is satisfied by either of the two:
- x86_64-w64-mingw32-gcc-nothreads
- x86_64-w64-mingw32-gcc

Further, the port x86_64-w64-mingw32-gcc-nothreads depends on:
    depends_lib port:x86_64-w64-mingw32-crt
    depends_build bin:x86_64-w64-mingw32-gcc:x86_64-w64-mingw32-gcc-bootstrap
and the port x86_64-w64-mingw32-gcc depends on
    depends_lib
        port:x86_64-w64-mingw32-crt \
        port:x86_64-w64-mingw32-winpthreads
   depends_build \
        path:x86_64-w64-mingw32/lib/libgcc_s.a:x86_64-w64-mingw32-gcc-nothreads

At the time of updating both of these ports are deactivated:
    x86_64-w64-mingw32-gcc-bootstrap
    x86_64-w64-mingw32-gcc-nothreads
and only
    x86_64-w64-mingw32-gcc
is activated.

So in theory crt and winpthreads are runtime dependencies of gcc,
while gcc could in theory be considered a *build* dependency of both
crt and winpthreads. I don't know whether that counts as a dependency
cycle or not. But gcc is up to date.

> > Note that MacPorts doesn't complain about a dependency cycle
> It won't if it can find some port that can be upgraded. Upgrade can work
> a little differently to install in this respect, since often all
> dependencies are already installed (if not the latest version).

In general you then users wouldn't even notice this issue. At least it
has never been the issue for me for the exact same ports as long as I
was upgrading to the next (minor) version. But it became an issue when
updating from version 5.0.4 to 6.0.0 since winpthreads apparently
cannot be built against crt that's too old. I assume that users
getting binary updates would not be hit by the problem, but I don't
want to hurt those who install from source.

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: How to make sure that one port gets updated before another? (MinGW)

Ryan Schmidt-24


On Oct 27, 2018, at 12:53, Mojca Miklavec wrote:

> On Fri, 26 Oct 2018 at 23:26, Joshua Root wrote:
>
>> If dependencies didn't get upgraded before their dependents, there would
>> be a lot of serious problems. Since we don't see that,
>
> Except ... hmmm ...
>    https://trac.macports.org/ticket/57457
>    Travis CI: Sometimes declared dependencies aren't installed
> ?

That's a problem I've only ever seen on Travis CI; I can't explain why since I haven't attempted to understand what we're doing on Travis.


>> let's assume
>> something else is going on here. Is there an actual circular dependency?
>
> That's why I came up to ask for someone's help.
>
> For the port x86_64-w64-mingw32-crt there is
>    depends_build bin:x86_64-w64-mingw32-gcc:x86_64-w64-mingw32-gcc-bootstrap
> which is satisfied by either of these:
> - x86_64-w64-mingw32-gcc-bootstrap
> - x86_64-w64-mingw32-gcc-nothreads
> - x86_64-w64-mingw32-gcc
>
> For the port x86_64-w64-mingw32-winpthreads there is now
>    depends_build \
>        path:x86_64-w64-mingw32/lib/libgcc_s.a:x86_64-w64-mingw32-gcc-nothreads
> \
>        port:x86_64-w64-mingw32-crt
> where the first dependency is satisfied by either of the two:
> - x86_64-w64-mingw32-gcc-nothreads
> - x86_64-w64-mingw32-gcc
>
> Further, the port x86_64-w64-mingw32-gcc-nothreads depends on:
>    depends_lib port:x86_64-w64-mingw32-crt
>    depends_build bin:x86_64-w64-mingw32-gcc:x86_64-w64-mingw32-gcc-bootstrap
> and the port x86_64-w64-mingw32-gcc depends on
>    depends_lib
>        port:x86_64-w64-mingw32-crt \
>        port:x86_64-w64-mingw32-winpthreads
>   depends_build \
>        path:x86_64-w64-mingw32/lib/libgcc_s.a:x86_64-w64-mingw32-gcc-nothreads
>
> At the time of updating both of these ports are deactivated:
>    x86_64-w64-mingw32-gcc-bootstrap
>    x86_64-w64-mingw32-gcc-nothreads
> and only
>    x86_64-w64-mingw32-gcc
> is activated.
>
> So in theory crt and winpthreads are runtime dependencies of gcc,
> while gcc could in theory be considered a *build* dependency of both
> crt and winpthreads. I don't know whether that counts as a dependency
> cycle or not. But gcc is up to date.

Then yes, in that situation (where x86_64-w64-mingw32-gcc is active) there are two dependency cycles:

x86_64-w64-mingw32-crt depends on x86_64-w64-mingw32-gcc
x86_64-w64-mingw32-gcc depends on x86_64-w64-mingw32-crt

x86_64-w64-mingw32-winpthreads depends on x86_64-w64-mingw32-gcc
x86_64-w64-mingw32-gcc depends on x86_64-w64-mingw32-winpthreads

MacPorts does not support dependency cycles. I don't think there's any code in MacPorts for detecting dependency cycles, so MacPorts behavior when there is a dependency cycle is undefined. Portfile authors must ensure no dependency cycles exist.

Reply | Threaded
Open this post in threaded view
|

Re: How to make sure that one port gets updated before another? (MinGW)

Mojca Miklavec-2
On Sat, 27 Oct 2018 at 20:06, Ryan Schmidt wrote:

> On Oct 27, 2018, at 12:53, Mojca Miklavec wrote:
> > On Fri, 26 Oct 2018 at 23:26, Joshua Root wrote:
> >
> >> let's assume
> >> something else is going on here. Is there an actual circular dependency?
> >
> > That's why I came up to ask for someone's help.
> >
> > For the port x86_64-w64-mingw32-crt there is
> >    depends_build bin:x86_64-w64-mingw32-gcc:x86_64-w64-mingw32-gcc-bootstrap
> > which is satisfied by either of these:
> > - x86_64-w64-mingw32-gcc-bootstrap
> > - x86_64-w64-mingw32-gcc-nothreads
> > - x86_64-w64-mingw32-gcc
> >
> > For the port x86_64-w64-mingw32-winpthreads there is now
> >    depends_build \
> >        path:x86_64-w64-mingw32/lib/libgcc_s.a:x86_64-w64-mingw32-gcc-nothreads
> > \
> >        port:x86_64-w64-mingw32-crt
> > where the first dependency is satisfied by either of the two:
> > - x86_64-w64-mingw32-gcc-nothreads
> > - x86_64-w64-mingw32-gcc
> >
> > Further, the port x86_64-w64-mingw32-gcc-nothreads depends on:
> >    depends_lib port:x86_64-w64-mingw32-crt
> >    depends_build bin:x86_64-w64-mingw32-gcc:x86_64-w64-mingw32-gcc-bootstrap
> > and the port x86_64-w64-mingw32-gcc depends on
> >    depends_lib
> >        port:x86_64-w64-mingw32-crt \
> >        port:x86_64-w64-mingw32-winpthreads
> >   depends_build \
> >        path:x86_64-w64-mingw32/lib/libgcc_s.a:x86_64-w64-mingw32-gcc-nothreads
> >
> > At the time of updating both of these ports are deactivated:
> >    x86_64-w64-mingw32-gcc-bootstrap
> >    x86_64-w64-mingw32-gcc-nothreads
> > and only
> >    x86_64-w64-mingw32-gcc
> > is activated.
> >
> > So in theory crt and winpthreads are runtime dependencies of gcc,
> > while gcc could in theory be considered a *build* dependency of both
> > crt and winpthreads. I don't know whether that counts as a dependency
> > cycle or not. But gcc is up to date.
>
> Then yes, in that situation (where x86_64-w64-mingw32-gcc is active) there are two dependency cycles:
>
> x86_64-w64-mingw32-crt depends on x86_64-w64-mingw32-gcc
> x86_64-w64-mingw32-gcc depends on x86_64-w64-mingw32-crt
>
> x86_64-w64-mingw32-winpthreads depends on x86_64-w64-mingw32-gcc
> x86_64-w64-mingw32-gcc depends on x86_64-w64-mingw32-winpthreads
>
> MacPorts does not support dependency cycles. I don't think there's any code in MacPorts for detecting dependency cycles, so MacPorts behavior when there is a dependency cycle is undefined. Portfile authors must ensure no dependency cycles exist.

Do you happen to have any suggestions for the fix?
I kind of ran out of ideas. I probably had the initial ticket open for
years, and when I committed these ports I thought this trick could
eventually work ...

Initially I tried to make these three installable side-by-side:
- x86_64-w64-mingw32-gcc-bootstrap
- x86_64-w64-mingw32-gcc-nothreads
- x86_64-w64-mingw32-gcc
I would remove files already installed by
x86_64-w64-mingw32-gcc-bootstrap from
x86_64-w64-mingw32-gcc-nothreads, and remove files installed by either
of the two from x86_64-w64-mingw32-gcc, but some files need to be
different (I remember that some header would include different files
depending on whether we were in bootstrap stage or in "fully
functional" stage), making my idea useless. Well, maybe I could have
another six ports providing just those conflicting headers in a
similarly messy way as I currently do with these gcc compilers ...

Thank you,
    Mojca