On Tue, Jun 2, 2020 at 2:17 PM Greg Jung <[email protected]> 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
_______________________________________________
Msys2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/msys2-users
