msys2-users — Using MSYS2

Re: [Msys2-users] Msys2-Mingw64, Qt - does not work correctly

[David G. <dav...@gm...>]

Looking at the GCC command you issued in example 1, it looks like you are
using pieces of the regular qt5 package and also pieces of the qt5-static
package.  You should decide which package you want to use and then just
stick to using only that one package.  It might be a good idea to uninstall
the other package just so you don't get confused.  Specifically, it looks
like you are using the "Qt5Core" include directory from the regular Qt5
package, which would probably define qVersion to a be function imported
from a DLL.  But then at link time you are actually linking to the static
version of Qt, which means qVersion would be a function that comes from a
static library, not a DLL.

--David

On Sun, Jul 26, 2020 at 8:07 AM Il'dar Al'Miev <ia...@ya...> wrote:

> Dear All,
> hello,
>
> Windows 7 (64-bit), Msys2-Mingw64 are installed in my computer.
> i installed Qt using the command,
> pacman -S mingw-w64-x86_64-qt-creator
> and
> pacman -S mingw-w64-x86_64-qt
>
> i am a newbie in Qt programming. i discovered two examples in Internet.
>
> example1.cpp
> ---------------------------------------
> #include <QtCore>
>
> #include <iostream>
>
> int main() {
>
> std::cout << "Qt version: " << qVersion() << std::endl;
>
> }
>
> in order to compile the example1.cpp, i used a command found in Internet,
>
> g++ -o example1.exe example1.cpp -I/C:/msys64/mingw64/include/QtCore
> -I/C:/msys64/mingw64/qt5-static/include/QtCore
> -L/C:/msys64/mingw64/qt5-static/lib -lQt5Core -fPIC
>
> however, compilation comes with an error message,
>
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> C:\msys64\tmp\ccpq7uZL.o:my_qt_program2.cpp:(.text+0x2c): undefined
> reference to `__imp_qVersion'
> collect2.exe: error: ld returned 1 exit status
>
>
>
> may be i have not installed all Qt-packages required in Msys2-Mingw64 ?
>
>
>
> example2.cpp
>
> -----------------------------
>
> #include <QApplication>
> #include <QWidget>
>
> int main(int argc, char *argv[]) {
>
> QApplication app(argc, argv);
>
> QWidget window;
>
> window.resize(250, 150);
> window.setWindowTitle("Simple example");
> window.show();
>
> return app.exec();
>
> }
>
> that file i saved in a separate directory, and as it was recomended in
> Internet i used the following commands,
>
> qmake -project
> qmake
> make
>
>
>
> after that the separate directory "release" was created (inside), where
> the executable "example2.exe" was created. however, when i try to execute
> that file in Mingw64 console, nothing is happened, that is the windows
> "Simple example" does not appear.
>
>
>
> i would appreciate someone(s) in the Forum to explain me, where i made a
> compilation error; or it is associated with Mingw64-Msys2 ?
>
> Thank you.
> _______________________________________________
> Msys2-users mailing list
> Msy...@li...
> https://lists.sourceforge.net/lists/listinfo/msys2-users
>

[Msys2-users] Msys2-Mingw64, Qt - does not work correctly

[Il'dar Al'M. <ia...@ya...>]

<div>Dear All,</div><div>hello,</div><div> </div><div>Windows 7 (64-bit), Msys2-Mingw64 are installed in my computer.</div><div>i installed Qt using the command,</div><div><code>pacman -S mingw-w64-x86_64-qt-creator</code></div><div><code>and </code></div><div><code>pacman -S mingw-w64-x86_64-qt</code></div><div> </div><div>i am a newbie in Qt programming. i discovered two examples in Internet.</div><div><div> </div><div>example1.cpp</div><div>---------------------------------------</div><div>#include &lt;QtCore&gt;</div><p>#include &lt;iostream&gt;</p><p>int main() {<!-- --></p><pre><code>std::cout &lt;&lt; "Qt version: " &lt;&lt; qVersion() &lt;&lt; std::endl;
</code></pre><div><code>}</code></div><div> </div><div>in order to compile the example1.cpp, i used a command found in Internet,</div><p>g++ -o example1.exe example1.cpp -I/C:/msys64/mingw64/include/QtCore -I/C:/msys64/mingw64/qt5-static/include/QtCore -L/C:/msys64/mingw64/qt5-static/lib -lQt5Core -fPIC</p><p>however, compilation comes with an error message,</p><p>C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccpq7uZL.o:my_qt_program2.cpp:(.text+0x2c): undefined reference to `__imp_qVersion'<br />collect2.exe: error: ld returned 1 exit status</p><p> </p><p>may be i have not installed all Qt-packages required in Msys2-Mingw64 ?</p><p> </p><p>example2.cpp</p><p>-----------------------------</p><p>#include &lt;QApplication&gt;<br />#include &lt;QWidget&gt;</p><p>int main(int argc, char *argv[]) {<!-- --></p><pre><code>QApplication app(argc, argv);

QWidget window;

window.resize(250, 150);
window.setWindowTitle("Simple example");
window.show();

return app.exec();
</code></pre><div><code>}</code></div><div> </div><div>that file i saved in a separate directory, and as it was recomended in Internet i used the following commands,</div><p>qmake -project<br />qmake<br />make</p><p> </p><p>after that the separate directory "release" was created (inside), where the executable "example2.exe" was created. however, when i try to execute that file in Mingw64 console, nothing is happened, that is the windows "Simple example" does not appear.</p><p> </p><p>i would appreciate someone(s) in the Forum to explain me, where i made a compilation error; or it is associated with Mingw64-Msys2 ?</p><div> </div><div>Thank you.</div></div>

Re: [Msys2-users] (no subject)

[David G. <dav...@gm...>]

Hello.  It seems like the code you posted outputs the right bytes , but
there is some layer of MSYS2 that is doing extra interpretation on it using
out-of-band metadata to figure out what characters you really wanted to
print on the screen.  I don't understand the full story of what is going on
here, but I got your code to work by following the advice here:

https://stackoverflow.com/a/19071749/28128

Here is the code that worked for me:

#include <stdio.h>
#include <windows.h>

int main(int argc,char *argv[])
{
  SetConsoleOutputCP(65001);
  printf("Привет, Мир !\n");
  printf("Hello, World ! \n");
}

--David


On Wed, Jul 8, 2020 at 10:03 AM Il'dar Al'Miev <ia...@ya...> wrote:

> Dear All,
> hello,
>
> Windows 7 (64-bit), Msys2-Mingw64 are installed in my computer.
>
> i wrote very little code in C to display Russian/Cyrillic characters.
> however it does not work. i still get some strange pseudo-symbols instead
> of correct Russian words (charactres).
>
> i would appreciate if someone in the forum could assist me to resolve the
> issues associated with locating (locale, setlocale) the ANSII-coding of
> Latin (English), and Cyrillic (Russian) symbols in terms of gcc-compiler in
> Msys2-Mingw64.
>
> Thank you.
>
> Il'dar
>
> -------------------------
> #include<stdio.h>
> #include<stdlib.h>
> #include<locale.h>
>
> int main(int argc,char *argv[])
>   {
>         setlocale(LC_ALL,"Rus");
>
>         printf("Привет, Мир !\n");
>         printf("Hello, World ! \n");
>
>         return 0;
>   }
> ---------------------------------------
>
>
>
>
> _______________________________________________
> Msys2-users mailing list
> Msy...@li...
> https://lists.sourceforge.net/lists/listinfo/msys2-users
>

[Msys2-users] Msys2-Mingw64, gcc, setlocale - does not work

[Il'dar Al'M. <ia...@ya...>]

Dear All,
hello,

Windows 7 (64-bit), Msys2-Mingw64 are installed in my computer.

i wrote very little code in C to display Russian/Cyrillic characters. however it does not work. i still get some strange pseudo-symbols instead of correct Russian words (charactres).

i would appreciate if someone in the forum could assist me to resolve the issues associated with locating (locale, setlocale) the ANSII-coding of Latin (English), and Cyrillic (Russian) symbols in terms of gcc-compiler in Msys2-Mingw64.

Thank you.

Il'dar

-------------------------
#include<stdio.h>
#include<stdlib.h>
#include<locale.h>

int main(int argc,char *argv[])
  {
        setlocale(LC_ALL,"Rus");

        printf("Привет, Мир !\n");
        printf("Hello, World ! \n");

        return 0;
  }
---------------------------------------

[Msys2-users] (no subject)

[Il'dar Al'M. <ia...@ya...>]

Dear All,
hello,

Windows 7 (64-bit), Msys2-Mingw64 are installed in my computer.

i wrote very little code in C to display Russian/Cyrillic characters. however it does not work. i still get some strange pseudo-symbols instead of correct Russian words (charactres).

i would appreciate if someone in the forum could assist me to resolve the issues associated with locating (locale, setlocale) the ANSII-coding of Latin (English), and Cyrillic (Russian) symbols in terms of gcc-compiler in Msys2-Mingw64.

Thank you.

Il'dar

-------------------------
#include<stdio.h>
#include<stdlib.h>
#include<locale.h>

int main(int argc,char *argv[])
  {
	setlocale(LC_ALL,"Rus");
	
	printf("Привет, Мир !\n");
	printf("Hello, World ! \n");
	
	return 0;
  }
---------------------------------------

Re: [Msys2-users] Tcl-Tk package, Msys2-Mingw64 (64-bit)

[Óscar F. <of...@wa...>]

Il'dar Al'Miev <ia...@ya...> writes:

> i use Windows 7 (64-bit) in my computer, and installed Msys2, and Mingw64.
>  
> i have a question. is it possible to install Tcl-Tk package(s) in
> Mingw64/Msys2 (64-bit), that could be called from C, or C++ ?
>  
> i would appreciate if anybody in the forum could explain me how to
> set-up (install) Tcl-Tk in Msys2 (64-bit).

Tcl/Tk on MinGW64 has nothing special. Just install the packages
(execute this command from a MSYS2/MinGW64 shell):

pacman -S mingw-w64-x86_64-tcl mingw-w64-x86_64-tk

and that will provide the necessary libraries.

In case you have not installed gcc yet:

pacman -S mingw-w64-x86_64-gcc

If you need help about how to call Tcl/Tk packages from C/C++, ask on
Tcl specific forums.

Re: [Msys2-users] gendef is not found (missing)

[Zach B. <wow...@gm...>]

I don't know if your gendef question was answered the package you want is
mingw-w64-x86_64-tools or for 32bit mingw-w64-i686-tools

as for tcl-tk you'll want the package mingw-w64-x86_64-tcl
and mingw-w64-x86_64-tk packages respectively. (just replace the x86_64
with i686 if you want 32bit install of it)

On Tue, Jul 7, 2020 at 12:20 PM Il'dar Al'Miev <ia...@ya...> wrote:

> Dear All,
> hello,
>
> i use Windows 7 (64-bit) in my computer, and installed Msys2, and Mingw64.
>
> i have a question. is it possible to install Tcl-Tk package(s) in
> Mingw64/Msys2 (64-bit), that could be called from C, or C++ ?
>
> i would appreciate if anybody in the forum could explain me how to set-up
> (install) Tcl-Tk in Msys2 (64-bit).
>
> Thank you.
>
> Il'dar
>
>
> 12.12.2019, 09:26, "Il'dar Al'Miev" <ia...@ya...>:
>
> Dear All,
> hello,
>
> i installed Msys2 in my computer. now i need to use "gendef"-command in my
> task. however, the bash-environment displays a message, that the command
> "gendef" is not found (that is missing).
>
> i tried to use commands "pacman -Ss gendef", and "pacman -S gendef",
> however such package (gendef) is not found in Msys2-installation server.
>
> i would appreciate if anybogy in the forum could help me to find, or to
> send me an Internet-link, where i could download a complete gendef-package,
> and could explain me, in details, how to compile, and how to install it
> into Msys2-system (package) that is installed in my computer ?
>
> Thank you.
>
> Il'dar
>
>
>
> --
> Dr. Ильдар Рифович Альмиев, D.Phil. (Oxford, UK),
> д. 18, кв. 94,
> ул. Кул-Гали,
> г. Казань 420141,
> Татарстан,
> Россия
>
> E-mail: ia...@ya...
>
> _______________________________________________
> Msys2-users mailing list
> Msy...@li...
> https://lists.sourceforge.net/lists/listinfo/msys2-users
>

[Msys2-users] Tcl-Tk package, Msys2-Mingw64 (64-bit)

[Il'dar Al'M. <ia...@ya...>]

<div> </div><div>Dear All,</div><div>hello,</div><div> </div><div>i use Windows 7 (64-bit) in my computer, and installed Msys2, and Mingw64.</div><div> </div><div>i have a question. is it possible to install Tcl-Tk package(s) in Mingw64/Msys2 (64-bit), that could be called from C, or C++ ?</div><div> </div><div>i would appreciate if anybody in the forum could explain me how to set-up (install) Tcl-Tk in Msys2 (64-bit).</div><div> </div><div>Thank you.</div><div> </div><div>Il'dar</div>

Re: [Msys2-users] gendef is not found (missing)

[Il'dar Al'M. <ia...@ya...>]

<div>Dear All,</div><div>hello,</div><div> </div><div>i use Windows 7 (64-bit) in my computer, and installed Msys2, and Mingw64.</div><div> </div><div>i have a question. is it possible to install Tcl-Tk package(s) in Mingw64/Msys2 (64-bit), that could be called from C, or C++ ?</div><div> </div><div>i would appreciate if anybody in the forum could explain me how to set-up (install) Tcl-Tk in Msys2 (64-bit).</div><div> </div><div>Thank you.</div><div> </div><div>Il'dar</div><div><br /></div><div><br /></div><div>12.12.2019, 09:26, "Il'dar Al'Miev" &lt;ia...@ya...&gt;:</div><blockquote><p>Dear All,<br />hello,<br /><br />i installed Msys2 in my computer. now i need to use "gendef"-command in my task. however, the bash-environment displays a message, that the command "gendef" is not found (that is missing).<br /><br />i tried to use commands "pacman -Ss gendef", and "pacman -S gendef", however such package (gendef) is not found in Msys2-installation server.<br /><br />i would appreciate if anybogy in the forum could help me to find, or to send me an Internet-link, where i could download a complete gendef-package, and could explain me, in details, how to compile, and how to install it into Msys2-system (package) that is installed in my computer ?<br /><br />Thank you.<br /><br />Il'dar<br /><br /></p></blockquote><div><br /></div><div><br /></div><div>-- </div><div>Dr. Ильдар Рифович Альмиев, D.Phil. (Oxford, UK),</div><div>д. 18, кв. 94,</div><div>ул. Кул-Гали,</div><div>г. Казань 420141,</div><div>Татарстан,</div><div>Россия</div><div> </div><div>E-mail: ia...@ya...</div><div><br /></div>

[Msys2-users] cmake Visual Studio generator

[Иван Т. <tr...@gm...>]

Is it possible to set up msys or mingw cmake so that it would be able to
generate  Visual Studio projects?

Re: [Msys2-users] Install dirs for own libs

[Filippo R. <lis...@la...>]

Greetings, David,

On Mon, Jun 22, 2020 at 12:53:46PM -0700, David Grayson wrote:
>The "MSYS Makefiles" generator is by far the most common generator used in
>the MINGW-packages repository, so I just use that and didn't experiment
>with many other generators.
>
>Yes, you must be aware that an MSYS2 installation supports three different
>toolchains with different behaviors, and have a clear idea of which one you
>want to use.  I spend a lot of time explaining this on StackOverflow
>because people come in with questions about MSYS2 but they usually forget
>to tell us which MSYS2 shell they launched, and what the outputs of `which
>gcc` and `echo $MSYSTEM` are.

Yeah, that is the point: which shell is started, which PATH is associated to it
and then which binaries are used (make, gcc, ...).

Of course, I start the MinGW64 shell :-).

Thank you for your answers,

Sincerely,
Filippo

-- 

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄⠀⠀⠀⠀  http://msxpertsuite.org
           http://www.debian.org

Re: [Msys2-users] Install dirs for own libs

[David G. <dav...@gm...>]

The "MSYS Makefiles" generator is by far the most common generator used in
the MINGW-packages repository, so I just use that and didn't experiment
with many other generators.

Yes, you must be aware that an MSYS2 installation supports three different
toolchains with different behaviors, and have a clear idea of which one you
want to use.  I spend a lot of time explaining this on StackOverflow
because people come in with questions about MSYS2 but they usually forget
to tell us which MSYS2 shell they launched, and what the outputs of `which
gcc` and `echo $MSYSTEM` are.

--David

On Mon, Jun 22, 2020 at 12:41 PM Filippo Rusconi <lis...@la...>
wrote:

> Greetings, David,
>
> thank you so much for your answer (see below).
>
> On Mon, Jun 22, 2020 at 09:50:56AM -0700, David Grayson wrote:
> >This is the pattern I typically use for building a MinGW program with
> CMake
> >and installing it in the correct directory:
> >
> >mkdir build
> >cd build
> >MSYS2_ARG_CONV_EXCL=- cmake .. -G"MSYS Makefiles"
> >-DCMAKE_INSTALL_PREFIX=$MINGW_PREFIX
> >make install DESTDIR=/
>
> I use -G "Unix Makefiles". Would that change something to your logic ?
> What is
> the benefit of using -G"MSYS Makefiles" ? It's interesting. My programs
> make
> heavy use of Qt5. Would the binaries created using -G"MSYS Makefiles" be
> compatible with the Qt dll files in /mingw64/bin ?
>
> This is something I really would like to understand: what is the difference
> between using the development environment in Msys2 and the development
> environment in MinGW64. I have read tons of documents that used to say "be
> careful to have this or that path in your env PATH variable otherwise
> you'd use
> this or that compiler and the images generated would be incompatible". I
> never
> really took the time to experiment... Does that kind of writing still apply
> today ?
>
> Again, thank you for your message,
>
> Sincerely,
> Filippo Rusconi
>
> --
>
> ⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
> ⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
> ⢿⡄⠘⠷⠚⠋⠀   Debian Developer
> ⠈⠳⣄⠀⠀⠀⠀  http://msxpertsuite.org
>            http://www.debian.org
>

Re: [Msys2-users] Install dirs for own libs

[Filippo R. <lis...@la...>]

Greetings, David,

thank you so much for your answer (see below).

On Mon, Jun 22, 2020 at 09:50:56AM -0700, David Grayson wrote:
>This is the pattern I typically use for building a MinGW program with CMake
>and installing it in the correct directory:
>
>mkdir build
>cd build
>MSYS2_ARG_CONV_EXCL=- cmake .. -G"MSYS Makefiles"
>-DCMAKE_INSTALL_PREFIX=$MINGW_PREFIX
>make install DESTDIR=/

I use -G "Unix Makefiles". Would that change something to your logic ? What is
the benefit of using -G"MSYS Makefiles" ? It's interesting. My programs make
heavy use of Qt5. Would the binaries created using -G"MSYS Makefiles" be
compatible with the Qt dll files in /mingw64/bin ?

This is something I really would like to understand: what is the difference
between using the development environment in Msys2 and the development
environment in MinGW64. I have read tons of documents that used to say "be
careful to have this or that path in your env PATH variable otherwise you'd use
this or that compiler and the images generated would be incompatible". I never
really took the time to experiment... Does that kind of writing still apply
today ?

Again, thank you for your message,

Sincerely,
Filippo Rusconi

-- 

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄⠀⠀⠀⠀  http://msxpertsuite.org
           http://www.debian.org

Re: [Msys2-users] Install dirs for own libs

[David G. <dav...@gm...>]

This is the pattern I typically use for building a MinGW program with CMake
and installing it in the correct directory:

mkdir build
cd build
MSYS2_ARG_CONV_EXCL=- cmake .. -G"MSYS Makefiles"
-DCMAKE_INSTALL_PREFIX=$MINGW_PREFIX
make install DESTDIR=/

It's a little bit tricky because of how MSYS2's automatic path conversions
work, but if you just follow that formula it will probably be fine.

--David Grayson

On Mon, Jun 22, 2020 at 8:16 AM Filippo Rusconi via Msys2-users <
msy...@li...> wrote:

> Greetings, Fellow Developers,
>
> I am happily using MSYS2/MinGW64 since a number of years without delving
> too
> much into the file system hierarchy.
>
> I am now developing and packaging a set of libs/exec programs that are
> built
> using CMake. I would like to be able to reproduce what I am used to with
> GNU/Linux and thus my question:
>
> I see that libraries, like Qt5, for example, are installed in /mingw64/bin
> and
> not /mingw64/usr/lib. What is the rationale for this ?
>
> If I wanted to adhere to the MSYS2/MinGW64 scheme nonetheless, what
> CMAKE_INSTALL_PREFIX value should I set ?
>
> Thank you for your enlightening remarks,
>
> Sincerely,
> Filippo Rusconi
>
> --
>
> ⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
> ⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
> ⢿⡄⠘⠷⠚⠋⠀   Debian Developer
> ⠈⠳⣄⠀⠀⠀⠀  http://msxpertsuite.org
>            http://www.debian.org
>
>
> _______________________________________________
> Msys2-users mailing list
> Msy...@li...
> https://lists.sourceforge.net/lists/listinfo/msys2-users
>

[Msys2-users] Install dirs for own libs

[Filippo R. <lis...@la...>]

Greetings, Fellow Developers,

I am happily using MSYS2/MinGW64 since a number of years without delving too
much into the file system hierarchy.

I am now developing and packaging a set of libs/exec programs that are built
using CMake. I would like to be able to reproduce what I am used to with
GNU/Linux and thus my question:

I see that libraries, like Qt5, for example, are installed in /mingw64/bin and
not /mingw64/usr/lib. What is the rationale for this ?

If I wanted to adhere to the MSYS2/MinGW64 scheme nonetheless, what
CMAKE_INSTALL_PREFIX value should I set ?

Thank you for your enlightening remarks,

Sincerely,
Filippo Rusconi

-- 

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄⠀⠀⠀⠀  http://msxpertsuite.org
           http://www.debian.org

Re: [Msys2-users] Broken libraries loads after updating msys2

[Greg J. <gv...@gm...>]

Alan,
This is not such an old system, only one update ...
 In a universe where that was going to be my solution I would abandon Win
platform altogether.
As it stands, I am guessing my problem will disappear when I downgrade
msys-runtime to previous version.
Before I do that I'll keep things in this state for diagnosis.

On Tue, Jun 2, 2020 at 7:30 PM Alan W. Irwin <Ala...@gm...>
wrote:

> Hi Greg:
>
> Have you tried the alternative of installing MSYS2 from scratch?
>
> I suggest that might help because that is a much simpler problem for
> software packaging systems than attempting to update an existing
> installation (which is apparently what you have been trying to do).
>
> Alan
> __________________________
> Alan W. Irwin
>
> Research affiliation with the Department of Physics and Astronomy,
> University of Victoria, Victoria, BC, Canada.
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.org); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>

Re: [Msys2-users] Broken libraries loads after updating msys2

[Alan W. I. <Ala...@gm...>]

Hi Greg:

Have you tried the alternative of installing MSYS2 from scratch?

I suggest that might help because that is a much simpler problem for
software packaging systems than attempting to update an existing
installation (which is apparently what you have been trying to do).

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Msys2-users] Broken libraries loads after updating msys2

[Greg J. <gv...@gm...>]

On Tue, Jun 2, 2020 at 2:17 PM Greg Jung <gv...@gm...> wrote:

> At this point I'm not sure why this happens.  Could you have Procmon
>> running when an /opt64 program execution is attempted and check which
>> paths are accessed when looking for DLLs?
>
>
> OK I'll try to do that but procmon is new today to me (and its not simple)
>
> I'll also look into downgrading bash to previous, if that'll make a diff.
>
> Greg
>
>>
>>
>
>> Just an early tip that of course bash is the same bash but the msys
runtime difference is between 3.0.7 to the latest 3.1.4-3.
I only run one MINGW program on my computer and it is built at any epoch
under /d/bld/gdl/<name> and to run them I use
a bash shell.  I set this shell up from a simple command prompt and use:

> target: c:\msys64\usr\bin\bash.exe -login -i

Start in: C:\msys64\usr\bin

This is in preference to running via the standard msys shell as the console
device acts properly for this setup.

Adding to the strange collection of symptoms, a recent build of the program
("GDL") now results in a successful
looking readout from "ldd" but hangs when I run the program:
>From the bash window:

> greg@i7Wx MSYS ~/cache
> $ ldd /d/bld/gdl/mingw64-git/src/gdl.exe
>         ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fffaf920000)
>         KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7fffaebd0000)
>         KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll
> (0x7fffad3e0000)
>         ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7fffade40000)
>         msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7fffaf380000)



> <etc.>
>
        mgwxdr-0.dll => /msysC/mingw64/bin/mgwxdr-0.dll (0x6bdc0000)

        zlib1.dll => /msysC/mingw64/bin/zlib1.dll (0x62e80000)
>         comdlg32.dll => /c/WINDOWS/System32/comdlg32.dll (0x7fffadef0000)
>         libplplot.dll => /msysC/opt64/bin/libplplot.dll (0x64cc0000)
>         shcore.dll => /c/WINDOWS/System32/shcore.dll (0x7fffaeaa0000)
>         libplplotcxx.dll => /msysC/opt64/bin/libplplotcxx.dll (0x62d40000)
>         SHELL32.dll => /c/WINDOWS/System32/SHELL32.dll (0x7fffaec90000)
>         libGraphicsMagick++-Q32-12.dll =>
> /msysC/opt64/bin/libGraphicsMagick++-Q32-12.dll (0x6a040000)

        libpslib.dll => /msysC/opt64/bin/libpslib.dll (0x65ec0000)


greg@i7Wx MSYS ~/cache

> $ /d/bld/gdl/mingw64-git/src/gdl.exe

    (hungup)

Whereas, when run from the MINGW64 window (after export
PATH=/opt64/bin:$PATH applied)

>
> greg@i7Wx MINGW64 ~
> $ /d/bld/gdl/mingw64-git/src/gdl.exe
> D:/home/greg/.gdl_startup: Exception: basic_string::substr: __pos (which
> is 4294967295) > this->size() (which is 0)
> D:/home/greg/.gdl_startup: Exception: basic_string::substr: __pos (which
> is 4294967295) > this->size() (which is 0)
> D:/home/greg/.gdl_startup: Exception: basic_string::substr: __pos (which
> is 4294967295) > this->size() (which is 0)
> pwd
> % Compiled module: PWD.
> C:/msys64/home/greg
>

OTOH a version built before the upgrade fails to load libraries


> greg@i7Wx MINGW64 ~
> $ /d/bld/gdl/git-nowdraw/src/gdl
> D:/bld/gdl/git-nowdraw/src/gdl.exe: error while loading shared libraries:
> libGraphicsMagick++-Q32-12.dll: cannot open shared object file: No such
> file or directory
>
> greg@i7Wx MINGW64 ~
> $ echo $PATH
>
> /opt64/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
>
> greg@i7Wx MINGW64 ~
> $ ldd /d/bld/gdl/git-nowdraw/src/gdl.exe
>         ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fffaf920000)
>
 <list of /c/WINDOWS/ contributing libraries, and a few
/msysC/mingw64 libraries>

So my initial conclusion is that the updated msys runtime seems to have
acquired some bugs.

Greg

Re: [Msys2-users] Broken libraries loads after updating msys2

[Greg J. <gv...@gm...>]

>
> At this point I'm not sure why this happens.  Could you have Procmon
> running when an /opt64 program execution is attempted and check which
> paths are accessed when looking for DLLs?


OK I'll try to do that but procmon is new today to me (and its not simple)

I'll also look into downgrading bash to previous, if that'll make a diff.

Greg

>
>

On Tue, Jun 2, 2020 at 9:50 AM David Macek <dav...@gm...> wrote:

> At this point I'm not sure why this happens.  Could you have Procmon
> running when an /opt64 program execution is attempted and check which
> paths are accessed when looking for DLLs?
>
> --
> David Macek
>

Re: [Msys2-users] Broken libraries loads after updating msys2

[David M. <dav...@gm...>]

At this point I'm not sure why this happens.  Could you have Procmon
running when an /opt64 program execution is attempted and check which
paths are accessed when looking for DLLs?

-- 
David Macek

Re: [Msys2-users] Broken libraries loads after updating msys2

[Greg J. <gv...@gm...>]

I can't run the programs that I've made because the libraries that
are located in places other than /mingw64, are not found.

The rest of the mails are my efforts at diagnosing what is going on.
"msysC" was a mount point
for C:/msys64 that I thought might have been the issue, fstab being written
over.  But it didn't
matter, including it in fstab again still results in missing library path.

I show "echo $PATH" to show that /opt64/bin is in the path, where the
libgraphicsmagick libraries are to be
drawn from.  The ldd shows that the whole list of libraries are not found
in the updated system, and another ldd
shows what should be seen from an "ldd" command.

In fact, the path issue does not happen in the mingw64 window, when PATH is
modified:

> $ echo $PATH
>
> /mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
>
 $ export PATH=/opt64/bin:$PATH

> greg@i7Wx MINGW64 /d/bld/gdl/mingw64-git
> $  src/gdl
>
<NORMAL OPERATION>

But the problem occurs when I try to use my usual CMD icon which
invokes bash, starting in /bin:
 Icon properties:
Target: C:\msys64\usr\bin\bash.exe -login -i
Start in: C:\msys64\usr\bin

I use bash.exe directly because otherwise I get terminal behavior issues.
After this I run a shell program to modify the path so that my program can
run.

Thanks,
Greg

On Mon, Jun 1, 2020 at 1:05 PM David Macek <dav...@gm...> wrote:

> Hi. I read your messages 3 times already and I'm still confused
> regarding what's wrong.
>
> 1) What is `/msysC`?  Is there a extra mount?
>
> 2) Putting Ldd output aside, are there any other issues?
>
> --
> David Macek
>

Re: [Msys2-users] Broken libraries loads after updating msys2

[David M. <dav...@gm...>]

Hi. I read your messages 3 times already and I'm still confused
regarding what's wrong.

1) What is `/msysC`?  Is there a extra mount?

2) Putting Ldd output aside, are there any other issues?

-- 
David Macek

Re: [Msys2-users] Broken libraries loads after updating msys2

[Greg J. <gv...@gm...>]

Here's what it looks like on my healthy (NOT upgraded) system:

$ ldd /opt64/bin/gdl.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x76d00000)
 <...>
        NSI.dll => /c/Windows/system32/NSI.dll (0x7fefefe0000)
        libgcc_s_seh-1.dll => /msysC/mingw64/bin/libgcc_s_seh-1.dll
(0x61440000)
        libgomp-1.dll => /msysC/mingw64/bin/libgomp-1.dll (0x63600000)
        libstdc++-6.dll => /msysC/mingw64/bin/libstdc++-6.dll (0x6fc40000)
        libfftw3-3.dll => /msysC/mingw64/bin/libfftw3-3.dll (0x70680000)
        libfftw3f-3.dll => /msysC/mingw64/bin/libfftw3f-3.dll (0x63740000)
        libgeotiff-2.dll => /msysC/mingw64/bin/libgeotiff-2.dll (0x6d1c0000)
        libproj-9.dll => /msysC/mingw64/bin/libproj-9.dll (0x66100000)
        libtiff-5.dll => /msysC/mingw64/bin/libtiff-5.dll (0x68ec0000)
        libjpeg-8.dll => /msysC/mingw64/bin/libjpeg-8.dll (0x10000000)
        liblzma-5.dll => /msysC/mingw64/bin/liblzma-5.dll (0x63cc0000)
        zlib1.dll => /msysC/mingw64/bin/zlib1.dll (0x62e80000)
        libgsl-19.dll => /msysC/mingw64/bin/libgsl-19.dll (0x61880000)
        libgslcblas-0.dll => /msysC/mingw64/bin/libgslcblas-0.dll
(0x6be00000)
        libhdf5-0.dll => /msysC/mingw64/bin/libhdf5-0.dll (0x68300000)
        libszip-0.dll => /msysC/mingw64/bin/libszip-0.dll (0x6da40000)
        libnetcdf.dll => /msysC/mingw64/bin/libnetcdf.dll (0x6d640000)
        libcurl-4.dll => /msysC/mingw64/bin/libcurl-4.dll (0x2d0000)
        WLDAP32.dll => /c/Windows/system32/WLDAP32.dll (0x7fefd5f0000)
        LIBEAY32.dll => /msysC/mingw64/bin/LIBEAY32.dll (0x63000000)
        libidn-11.dll => /msysC/mingw64/bin/libidn-11.dll (0x69540000)
        libiconv-2.dll => /msysC/mingw64/bin/libiconv-2.dll (0x1210000)
        libintl-8.dll => /msysC/mingw64/bin/libintl-8.dll (0x61cc0000)
        librtmp-1.dll => /msysC/mingw64/bin/librtmp-1.dll (0x350000)
        libgmp-10.dll => /msysC/mingw64/bin/libgmp-10.dll (0x6acc0000)
        libgnutls-30.dll => /msysC/mingw64/bin/libgnutls-30.dll (0x1320000)
        CRYPT32.dll => /c/Windows/system32/CRYPT32.dll (0x7fefc870000)
        MSASN1.dll => /c/Windows/system32/MSASN1.dll (0x7fefc860000)
        libhogweed-4-1.dll => /msysC/mingw64/bin/libhogweed-4-1.dll
(0x69000000)
        libnettle-6-1.dll => /msysC/mingw64/bin/libnettle-6-1.dll
(0x67780000)
        libp11-kit-0.dll => /msysC/mingw64/bin/libp11-kit-0.dll (0x380000)
        SHELL32.dll => /c/Windows/system32/SHELL32.dll (0x7fefd760000)
        libffi-6.dll => /msysC/mingw64/bin/libffi-6.dll (0x6b740000)
        libtasn1-6.dll => /msysC/mingw64/bin/libtasn1-6.dll (0x65f00000)
        WINMM.dll => /c/Windows/system32/WINMM.dll (0x7fefade0000)
        libssh2-1.dll => /msysC/mingw64/bin/libssh2-1.dll (0x63b40000)
        SSLEAY32.dll => /msysC/mingw64/bin/SSLEAY32.dll (0x6e400000)
        libhdf5_hl-0.dll => /msysC/mingw64/bin/libhdf5_hl-0.dll (0x64740000)
        libpng16-16.dll => /msysC/mingw64/bin/libpng16-16.dll (0x68b40000)
        libreadline6.dll => /msysC/mingw64/bin/libreadline6.dll (0x65980000)
        libtermcap-0.dll => /msysC/mingw64/bin/libtermcap-0.dll (0x6ac40000)
        libshp-1.dll => /msysC/mingw64/bin/libshp-1.dll (0x70100000)
        libsystre-0.dll => /msysC/mingw64/bin/libsystre-0.dll (0x6bcc0000)
        libtre-5.dll => /msysC/mingw64/bin/libtre-5.dll (0x63bc0000)
        wxbase30u_gcc_custom.dll =>
/msysC/mingw64/bin/wxbase30u_gcc_custom.dll (0x66ac0000)
        ole32.dll => /c/Windows/system32/ole32.dll (0x7fefcfd0000)
        wxmsw30u_adv_gcc_custom.dll =>
/msysC/mingw64/bin/wxmsw30u_adv_gcc_custom.dll (0x67bc0000)
        wxmsw30u_core_gcc_custom.dll =>
/msysC/mingw64/bin/wxmsw30u_core_gcc_custom.dll (0x1450000)
        COMCTL32.dll =>
/c/Windows/WinSxS/amd64_microsoft.windows.common-controls_6595b64144ccf1df_5
.82.7601.18837_none_a4d981ff711297b6/COMCTL32.dll (0x7fef9230000)
        comdlg32.dll => /c/Windows/system32/comdlg32.dll (0x7fefee70000)
        OLEACC.dll => /c/Windows/system32/OLEACC.dll (0x7fef90e0000)
        OLEAUT32.dll => /c/Windows/system32/OLEAUT32.dll (0x7fefd510000)
        WINSPOOL.DRV => /c/Windows/system32/WINSPOOL.DRV (0x7fef9140000)
        mgwxdr-0.dll => /msysC/mingw64/bin/mgwxdr-0.dll (0x6bdc0000)
        libplplot.dll => /msysC/opt64/bin/libplplot.dll (0x64cc0000)
        libcsirocsa.dll => /msysC/opt64/bin/libcsirocsa.dll (0x1040000)
        libcsironn.dll => /msysC/opt64/bin/libcsironn.dll (0x6a1c0000)
        libqhull.dll => /msysC/mingw64/bin/libqhull.dll (0x68dc0000)
        libqsastime.dll => /msysC/opt64/bin/libqsastime.dll (0x61ac0000)
        libplplotcxx.dll => /msysC/opt64/bin/libplplotcxx.dll (0x62d40000)
        libGraphicsMagick++-Q32-3.dll =>
/msysC/opt64/bin/libGraphicsMagick++-Q32-3.dll (0x69400000)

        libGraphicsMagick-Q32-3.dll =>
/msysC/opt64/bin/libGraphicsMagick-Q32-3.dll (0x6c340000)
        libbz2-1.dll => /msysC/mingw64/bin/libbz2-1.dll (0x626c0000)
        libfreetype-6.dll => /msysC/mingw64/bin/libfreetype-6.dll
(0x1070000)
        libharfbuzz-0.dll => /msysC/mingw64/bin/libharfbuzz-0.dll
(0x61600000)
        libglib-2.0-0.dll => /msysC/mingw64/bin/libglib-2.0-0.dll
(0x1aa0000)
        liblcms2-2.dll => /msysC/mingw64/bin/liblcms2-2.dll (0x6b240000)
        libltdl-7.dll => /msysC/mingw64/bin/libltdl-7.dll (0x6d480000)
        IMM32.DLL => /c/Windows/system32/IMM32.DLL (0x7fefcf80000)
        MSCTF.dll => /c/Windows/system32/MSCTF.dll (0x7fefed60000)
        ncrypt.dll => /c/Windows/system32/ncrypt.dll (0x7fefc1e0000)
        bcrypt.dll => /c/Windows/system32/bcrypt.dll (0x7fefc1b0000)
        CRYPTSP.dll => /c/Windows/system32/CRYPTSP.dll (0x7fefc0d0000)
        rsaenh.dll => /c/Windows/system32/rsaenh.dll (0x7fefbcf0000)
        CRYPTBASE.dll => /c/Windows/system32/CRYPTBASE.dll (0x7fefc6f0000)


On Sun, May 31, 2020 at 2:10 PM Greg Jung <gv...@gm...> wrote:

> more info:
> $ echo $PATH
>
> /mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
>
> $  export PATH=/opt64/bin:$PATH
>
> greg@i7Wx MSYS ~
> $ which gdl.exe
> /opt64/bin/gdl.exe
>
> greg@i7Wx MSYS ~
> $ ldd gdl.exe
> ldd: gdl.exe: No such file or directory
>
> greg@i7Wx MSYS ~
> $ ldd /opt64/bin/gdl.exe
>         ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe80080000)
>    <etc>
> libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000)
>
> and nothing from /msysC/opt64/bin, which is usual place where /opt64/ is
> designated by ldd.
>
> On Sun, May 31, 2020 at 2:03 PM Greg Jung <gv...@gm...> wrote:
>
>>   I downloaded QEMU and followed their "Native MSYS2" update directions,
>> and since that happened my use of /opt64/bin as a library depository
>> fails.
>> pacman -Syu
>> pacman -Su
>> pacman -S base-devel mingw-w64-x86_64-toolchain git python
>> pacman -S mingw-w64-x86_64-glib2 mingw64/mingw-w64-x86_64-gtk3
>> mingw64/mingw-w64-x86_64-SDL2
>>
>> cd /mingw64/bin
>> cp x86_64-w64-mingw32-gcc-ar.exe x86_64-w64-mingw32-ar.exe
>> cp x86_64-w64-mingw32-gcc-ranlib.exe x86_64-w64-mingw32-ranlib.exe
>> cp windres.exe x86_64-w64-mingw32-windres.exe
>> cp nm.exe x86_64-w64-mingw32-nm.exe
>> cp objcopy.exe x86_64-w64-mingw32-objcopy.exe
>>
>> So I suspect one of these has rendered my computer useless.
>> except for the directory /mingw64/bin, other locations in PATH do not
>> load when I run.
>>
>> Greg
>>
>>
>>

Re: [Msys2-users] Broken libraries loads after updating msys2

[Greg J. <gv...@gm...>]

more info:
$ echo $PATH
/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

$  export PATH=/opt64/bin:$PATH

greg@i7Wx MSYS ~
$ which gdl.exe
/opt64/bin/gdl.exe

greg@i7Wx MSYS ~
$ ldd gdl.exe
ldd: gdl.exe: No such file or directory

greg@i7Wx MSYS ~
$ ldd /opt64/bin/gdl.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe80080000)
   <etc>
libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000)

and nothing from /msysC/opt64/bin, which is usual place where /opt64/ is
designated by ldd.

On Sun, May 31, 2020 at 2:03 PM Greg Jung <gv...@gm...> wrote:

>   I downloaded QEMU and followed their "Native MSYS2" update directions,
> and since that happened my use of /opt64/bin as a library depository fails.
> pacman -Syu
> pacman -Su
> pacman -S base-devel mingw-w64-x86_64-toolchain git python
> pacman -S mingw-w64-x86_64-glib2 mingw64/mingw-w64-x86_64-gtk3
> mingw64/mingw-w64-x86_64-SDL2
>
> cd /mingw64/bin
> cp x86_64-w64-mingw32-gcc-ar.exe x86_64-w64-mingw32-ar.exe
> cp x86_64-w64-mingw32-gcc-ranlib.exe x86_64-w64-mingw32-ranlib.exe
> cp windres.exe x86_64-w64-mingw32-windres.exe
> cp nm.exe x86_64-w64-mingw32-nm.exe
> cp objcopy.exe x86_64-w64-mingw32-objcopy.exe
>
> So I suspect one of these has rendered my computer useless.
> except for the directory /mingw64/bin, other locations in PATH do not load
> when I run.
>
> Greg
>
>
>

[Msys2-users] Broken libraries loads after updating msys2

[Greg J. <gv...@gm...>]

  I downloaded QEMU and followed their "Native MSYS2" update directions,
and since that happened my use of /opt64/bin as a library depository fails.
pacman -Syu
pacman -Su
pacman -S base-devel mingw-w64-x86_64-toolchain git python
pacman -S mingw-w64-x86_64-glib2 mingw64/mingw-w64-x86_64-gtk3
mingw64/mingw-w64-x86_64-SDL2

cd /mingw64/bin
cp x86_64-w64-mingw32-gcc-ar.exe x86_64-w64-mingw32-ar.exe
cp x86_64-w64-mingw32-gcc-ranlib.exe x86_64-w64-mingw32-ranlib.exe
cp windres.exe x86_64-w64-mingw32-windres.exe
cp nm.exe x86_64-w64-mingw32-nm.exe
cp objcopy.exe x86_64-w64-mingw32-objcopy.exe

So I suspect one of these has rendered my computer useless.
except for the directory /mingw64/bin, other locations in PATH do not load
when I run.

Greg