lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Advance note about a change to MinGW packages in Debian


From: Greg Chicares
Subject: Re: [lmi] Advance note about a change to MinGW packages in Debian
Date: Tue, 10 Jan 2023 00:06:15 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0

On 1/8/23 15:53, Vadim Zeitlin wrote:
> 
>  Let me start by saying that there is nothing that needs to be done about
> this right now, but I just wanted to let you know about the following
> message I got from apt-listchanges when upgrading one of my Debian systems:
> 
> ---------------------------------- >8 --------------------------------------
> gcc-mingw-w64 (25) unstable; urgency=medium
> 
>     The sets of packages for POSIX and Win32 thread models are no longer
>     co-installable; the appropriate thread model must now be chosen at
>     installation time, not using alternatives.
> 
>  -- Stephen Kitt <skitt@debian.org>  Mon, 12 Dec 2022 08:50:30 +0100
> ---------------------------------- >8 --------------------------------------
> 
>  And, indeed, the "-win32" and "-posix" versions of the various MinGW
> packages can't be installed together any longer: by default, the "-win32"
> variant is installed and if you install "-posix" one manually later, the
> "-win32" one is removed.

That default works fine for lmi (as long as we don't use threads).

> change log 
> (https://metadata.ftp-master.debian.org/changelogs/main/g/gcc-mingw-w64/gcc-mingw-w64_25.1_changelog)
> says
> 
>> It is no longer possible to tweak the installation directory for
>> different thread models, so the -posix and -win32 packages are no longer
>> co-installable.
> 
> so it might not even be the Debian maintainers' decision, but in any case
> we'll have to live with it.

Sounds like upstream formerly maintained separate directories
for the two models, but no longer does. Or something like that.

>  Right now it shouldn't create any problems for us because I believe lmi
> has always used "-win32" variants of the packages that still remain the
> default ones.

Exactly. We invoke it (mostly) without "-win32", and 'alternatives'
adds that suffix:

$ls -l `whence x86_64-w64-mingw32-gcc-10`
lrwxrwxrwx 1 root lmi 43 Apr 15  2022 /usr/bin/x86_64-w64-mingw32-gcc-10 -> 
/etc/alternatives/x86_64-w64-mingw32-gcc-10
$ls -l /etc/alternatives/x86_64-w64-mingw32-gcc-10
lrwxrwxrwx 1 root root 40 Jun 21  2022 
/etc/alternatives/x86_64-w64-mingw32-gcc-10 -> 
/usr/bin/x86_64-w64-mingw32-gcc-10-win32

> In principle, I think it would be better to use the "-posix"
> variant as only it provides working std::thread and related classes
> currently (I don't lose hope that this will change in the future, but so
> far this hasn't happened), and the only drawback is that another MinGW DLL
> (winpthreads one) would need to be distributed with the application, but as
> long as we don't use std::thread anywhere in lmi code, there is no urgency
> to change it.

Good to know. But, as you note, we don't have to deal with this
until we want std::thread.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]