error while loading shared libraries: ?: cannot open shared object file: No such file or directory

[songqingshan]

When run a demo program (compiled in dos) in MINGW64, an error happens as follows $ ./ResRdDemo.exe test.rst "C:/users/user/desktop/bao/appwin/build/ResRdDemo.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory." But it runs well in dos windows.

In addition, I compile a small program in MINGW64 and the compiled small program can run in MINGW64. But it can not in windows dos.

In summary, the program compiled in windows dos can not run in mingw64. the program compiled in mingw64 can not run in windows dos neither. any helps are appreciated.

Song

[oscarfv]

Check the PATH environment variable. The required shared libraries shall be on the same directory as the executable or on one of the directories listed on that variable.

[songqingshan]

Hello Alex,

Thanks for your response.

1.the dll file is in the same directory as the running program. 2.I edit my mingw64's profile.local and add dll path. dll path is echoed. 3.the same error happens. 4.then I try it in msys instead of msys2 and use my another profile.local for msys. it works well. 5.I compare and contrast a few small programs in window dos, msys(old version) and msys2(new version include mingw64): the programs compiled in dos can run in old version msys and vice versa, but can not run in msys2 (mingw64). the programs compiled in mingw64 (in msys2) can run only in its command window. 6.Did I do something wrong for msys2 setting? But I follow msys2 installation instruction. What should I check? 7.In addition, I want to know where I can edit mingw64 environment variable PATH (or profile) so that PATH can be saved for next use.

Any helps are appreciated.

Song

[revelator]

an invalueable tool to see whats missing is some kind of dependency checker, msys2 has ntldd which is console only, if you strive for something a bit more visual use the dependencies tool from lucasg which supports win10 as well which the old depends.exe does not. Look for dll's with question marks and you will have your answer.

[oscarfv]

How depends.exe fails on Windows 10? It works for me.

[oscarfv]

@songqingshan : make sure that you are don't have around dlls compiled with different compilers/runtimes. To start, mixing MSYS/mingw32 and MSYS2/mingw-w64 binaries on the same system is asking for problems.

Then, as you probably know, if your executable depends on library A.DLL, this library may depend on other dlls, which must be reachable by the Windows rules. See https://msdn.microsoft.com/en-us/library/7d83bc18.aspx

[revelator]

It does not fail as such, but it does not support the new api load mechanism win10 uses, also its extremely slow to load on windows 10.

[songqingshan]

Hello Ralph,

I use windows 8.1 instead of windows 10.

two pieces of short code are attached for your try.

Regards,

Song

---

From: Ralph Engels notifications@github.com Sent: October 25, 2018 8:57 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

It does not fail as such, but it does not support the new api load mechanism win10 uses, also its extremely slow to load on windows 10.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433061386, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU1K5njPgc1KjENECNEd_cbEs_F2yks5uocNIgaJpZM4X4db7.

/*

• Since: 2.40. msys's glib version 2.38. can not be compiled with msys gcc pkg-config --cflags --libs glib-2.0 dbus-glib-1 spawn.c -lglib-2.0.dll -lglib-2.0 -lgio-2.0 -lgio-2.0.dll

  gcc pkg-config --cflags --libs glib-2.0 dbus-glib-1 spawn.c -lglib-2.0.dll -lglib-2.0 -lgio-2.0 -lgio-2.0.dll -o spawn.exe

Compile me with: gcc -o spawn spawn.c $(pkg-config --cflags --libs gtk+-3.0)

excuting results in MINGW64: situation 1: User@shan MINGW64 /c/users/user/desktop/gtkapp/thread-g-msys2-3/src $ ./spawn.exe

(spawn.exe:217612): GLib-GIO-CRITICAL **: 09:56:53.957: g_subprocess_get_identifier: assertion 'G_IS_SUBPROCESS (subprocess)' failed child_process id = (NULL) Segmentation fault

User@shan MINGW64 /c/users/user/desktop/gtkapp/thread-g-msys2-3/src

situation 2: User@shan MINGW64 /c/users/user/desktop/gtkapp/thread-g-msys2-3/src $ ./spawn.exe child_process id = 193508 end... Normal message no: 0. Normal message no: 1. Normal message no: 2. Normal message no: 3. Normal message no: 4. Normal message no: 5. Normal message no: 6. Normal message no: 7. Normal message no: 8. Normal message no: 9. helper end ... Error message no: 0. Error message no: 1. Error message no: 2. Error message no: 3. Error message no: 4. Error message no: 5. Error message no: 6. Error message no: 7. Error message no: 8. Error message no: 9.

User@shan MINGW64 /c/users/user/desktop/gtkapp/thread-g-msys2-3/src

error in msys2: User@shan MSYS /c/users/user/desktop/gtkapp/thread-g-msys2-3/src $ ./spawn C:/users/user/desktop/gtkapp/thread-g-msys2-3/src/spawn.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

User@shan MSYS /c/users/user/desktop/gtkapp/thread-g-msys2-3/src

error in dos "the procedure entry point g_subprocess_get_identifier could not be localted in the dynamic link libaray."

*/

//#include <gtk/gtk.h>

include <gio/gio.h>

include

static void show_reslut() { g_print("show_reslut\n"); }

static void store_result_cb (GObject source_object, GAsyncResult result, gpointer user_data) {
GAsyncResult *p = user_data; g_assert_nonnull (p); g_assert_null (p); *p = g_object_ref (result); g_print("store_result_cb \n");

}

static void wait_for_result (GAsyncResult *result) {
while (result == NULL) { g_print("while\n"); g_main_context_iteration (NULL, TRUE); g_print("wait\n"); } g_print("return\n");

}

int main( int argc, char *argv ) { g_autoptr (GError) error = NULL; g_autoptr (GSubprocess) subprocess = NULL; g_autoptr (GAsyncResult) result = NULL; g_autofree gchar first_id = NULL; g_autofree gchar second_id = NULL; //const gchar example_requester;

//example_requester = g_test_get_filename (G_TEST_BUILT, "example-requester", NULL); gint count=0; do { subprocess = g_subprocess_new (G_SUBPROCESS_FLAGS_STDOUT_PIPE, &error, "./helper", NULL); count++; }while(subprocess == NULL && count<=100); g_print("count = %d\n", count); return( 0 ); }

/*

• Compile me with:
• gcc -o helper helper.c */

  include

  include

int main( int argc, char **argv ) { int i; int num1=0; int num2=0;

for( i = 0; i < 10; i++ )
{
    char stdout_string[] = "Normal message no:  .";
    char stderr_string[] = "Error message no:  .";

    stdout_string[19] = '0' + i;
    stderr_string[18] = '0' + i;

    sleep( 1 );
    num1 = fprintf( stdout, "%s\n", stdout_string );
    printf( "num1 = %d\n", num1);
   fflush(stdout);
    sleep( 1 );
    num2 = fprintf( stderr, "%s\n", stderr_string );
   printf( "num2 = %d\n", num2);
    fflush(stderr);
}

return( 0 );

}

[revelator]

Ill try later tonight, though these functions might have changed in later versions because of instability. Atleast gtk works fine here with gimp-2.10.6 but specific use cases might allways break stuff. P.s you say msys's glib version, are we talking about Msys2 or MinGW64 compiles ?.

[songqingshan]

Hello,

I believe that you are on the point which is what I am going to say to you.

I try another independent test: 1.A dll is compiled with another compiler and I dump function's names in the dll from its relevant tool. 2.Change dumped function's names into appropriate names (e.g., to small case and append a underscore) which are needed by gcc gfortran compiler and create a .def file. 3.create a static library .a using the created .def file. 4.compile a small piece of code against the static library using gfortran. 5.run the created program. 6.the same runtime happens. In the error message, only a new function name replaces old function name. 7.above 1 to 6 explains what you said "don't have around dlls compiled with different compilers/runtimes".

However, when I compile my test code (like spawn.c and help.c) in msys2 mingw64, I have not used other dll files except for build-in gtk libraries in msys2 mingw64. According to 1-6 and 8, I personally think the error is caused by the symbols of the gtk libraries in msys2 mingw64. In other words, the symbols are not compatible in windows dos. Therefore, some programs compiled in msys2 mingw64 can not be activated in windows dos commands. This is for your reference only.

Regards, Song

---

From: oscarfv notifications@github.com Sent: October 25, 2018 7:58 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

@songqingshanhttps://github.com/songqingshan : make sure that you are don't have around dlls compiled with different compilers/runtimes. To start, mixing MSYS/mingw32 and MSYS2/mingw-w64 binaries on the same system is asking for problems.

Then, as you probably know, if your executable depends on library A.DLL, this library may depend on other dlls, which must be reachable by the Windows rules. See https://msdn.microsoft.com/en-us/library/7d83bc18.aspx

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433040227, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBUwGXgaMD3OtHchJYv8bo3tWcCkO3ks5uobVpgaJpZM4X4db7.

[songqingshan]

Hello,

msys2 does not have ntldd. I search all subdirectories. I can not find it. I think that error is caused by build-in gtk in Msys2 mingw64.

Song

---

From: Ralph Engels notifications@github.com Sent: October 25, 2018 4:39 AM To: Alexpux/MINGW-packages Cc: songqingshan; Author Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

an invalueable tool to see whats missing is some kind of dependency checker, msys2 has ntldd which is console only, if you strive for something a bit more visual use the dependencies tool from lucasg which supports win10 as well which the old depends.exe does not. Look for dll's with question marks and you will have your answer.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-432984406, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU20Zi9IhhJHZI9ui4K3Kv3k4fjbfks5uoYbZgaJpZM4X4db7.

[songqingshan]

I use windows 8.1. so I cannot answer your question.

---

From: oscarfv notifications@github.com Sent: October 25, 2018 7:53 AM To: Alexpux/MINGW-packages Cc: songqingshan; Author Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

How depends.exe fails on Windows 10? It works for me.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433038827, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBUyhyMv24R0RQ841Sv8bizwwpB7Ulks5uobRdgaJpZM4X4db7.

[songqingshan]

Hello,

I have not installed MSYS2/mingw32.

As you see, I have not used other libraries except for built-in gtk libraries in msys2 mingw64.

Please do not mix msys and msys2. msys works fine for me. The reason I am going to change from msys to msys2 is gtk version. msys does not have a new gtk version which I need.

I think that if the programs compiled in MSYS2/MINGW64 does not work in windows dos, MSYS2/MINGW64 does not reach its goal.

Regards,

Song

---

From: oscarfv notifications@github.com Sent: October 25, 2018 7:58 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

@songqingshanhttps://github.com/songqingshan : make sure that you are don't have around dlls compiled with different compilers/runtimes. To start, mixing MSYS/mingw32 and MSYS2/mingw-w64 binaries on the same system is asking for problems.

Then, as you probably know, if your executable depends on library A.DLL, this library may depend on other dlls, which must be reachable by the Windows rules. See https://msdn.microsoft.com/en-us/library/7d83bc18.aspx

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433040227, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBUwGXgaMD3OtHchJYv8bo3tWcCkO3ks5uobVpgaJpZM4X4db7.

[revelator]

Do you per chance have anything using gtk or dependent libraries installed on your PC/LapTop ? A good way to find out is using Depends.exe if you use win 8.1 it should work ok. Set it to show full paths and notice if any dll is located outside Msys2 dir. If any are they most likely will interfere with your programs execution.

ntldd seems to have no package, get it from this repo, its located in the folder mingw-w64-ntldd-git after getting the git repo cd to that folder in an msys2 shell and do makepkg-mingw -c -i --skippgp --nocheck and wait untill its done building and installing, then do ntldd with the full path to the program you want to check, remember if using the msys2 shell that paths need forward slashes eg. c:/someprogram.exe or /c/someprogram.exe

example on codeblocks.exe

ntldd c:/msys64/codeblocks.exe COMCTL32.DLL => C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.17134.345_none_40ff7c964511edcf\COMCTL32.DLL (0x00760000) KERNEL32.dll => C:\Windows\SYSTEM32\KERNEL32.dll (0x01080000) msvcrt.dll => C:\Windows\SYSTEM32\msvcrt.dll (0x01080000) SHELL32.dll => C:\Windows\SYSTEM32\SHELL32.dll (0x01470000) SHFOLDER.DLL => C:\Windows\SYSTEM32\SHFOLDER.DLL (0x00020000) USER32.dll => C:\Windows\SYSTEM32\USER32.dll (0x010d0000) exchndl.dll => c:\msys64\exchndl.dll (0x00020000) wxmsw28u_gcc_cb.dll => c:\msys64\wxmsw28u_gcc_cb.dll (0x01470000) codeblocks.dll => c:\msys64\codeblocks.dll (0x01470000) wxpropgrid.dll => c:\msys64\wxpropgrid.dll (0x01080000)

[songqingshan]

1. how can I "notice if any dll is located outside Msys2 dir"

  2.  Can you show me how I can get ntldd step by step?

in MINGW-package/mingw-w64-ntldd-git/, only PKGBUILD exists.

currently I can not get ntldd.

Song

---

From: Ralph Engels notifications@github.com Sent: October 25, 2018 1:19 PM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

Do you per chance have anything using gtk or dependent libraries installed on your PC/LapTop ? A good way to find out is using Depends.exe if you use win 8.1 it should work ok. Set it to show full paths and notice if any dll is located outside Msys2 dir. If any are they most likely will interfere with your programs execution.

ntldd seems to have no package, get it from this repo, its located in the folder mingw-w64-ntldd-git after getting the git repo cd to that folder in an msys2 shell and do makepkg-mingw -c -i --skippgp --nocheck and wait untill its done building and installing, then do ntldd with the full path to the program you want to check, remember if using the msys2 shell that paths need forward slashes eg. c:/someprogram.exe or /c/someprogram.exe

example on codeblocks.exe

ntldd c:/msys64/codeblocks.exe COMCTL32.DLL => C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.17134.345_none_40ff7c964511edcf\COMCTL32.DLL (0x00760000) KERNEL32.dll => C:\Windows\SYSTEM32\KERNEL32.dll (0x01080000) msvcrt.dll => C:\Windows\SYSTEM32\msvcrt.dll (0x01080000) SHELL32.dll => C:\Windows\SYSTEM32\SHELL32.dll (0x01470000) SHFOLDER.DLL => C:\Windows\SYSTEM32\SHFOLDER.DLL (0x00020000) USER32.dll => C:\Windows\SYSTEM32\USER32.dll (0x010d0000) exchndl.dll => c:\msys64\exchndl.dll (0x00020000) wxmsw28u_gcc_cb.dll => c:\msys64\wxmsw28u_gcc_cb.dll (0x01470000) codeblocks.dll => c:\msys64\codeblocks.dll (0x01470000) wxpropgrid.dll => c:\msys64\wxpropgrid.dll (0x01080000)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433154413, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU3dfAS8ADgYpwkfV-4YsdqAyDBo1ks5uogCZgaJpZM4X4db7.

[revelator]

see my example and notice the paths :), ofc dlls like C:\Windows\SYSTEM32\KERNEL32.dll are ok since its a windows system dll but if you see for example c:\msys64\codeblocks.dll in a place other than where you currently have codeblocks, then you have a problem cause it would pick that one up and it might not be the same version. In old days this is what we called dll hell because back then most dll's where not versioned so easily got mixed up causing system crashes and all sorts of nasty instability.

as for building ntdll, you need to install msys2 since we use a package manager to build things. when done that open msys2_shell.cmd and in the shell window change directory to the folder mingw-w64-ntdll-git. not write this makepkg-mingw -c -i --skippgp --nocheck and it will build and install ntdll.

cant remember if the installer sets up shortcuts for mingw32 / mingw64 shells but if it does, open one of these and write ntldd path to the executable or dll you want to check. Example ntldd C:/something/somedll.dll and it will spit out a list like my example.

Examine that and notice if any dll's are out of place, if they are then you need to take care of that by either temporarily removing those dll's (just copy them somewhere else) or uninstalling the program using them if you no longer need it.

After that test if your own program works, if it does then we found the culprit, if it does not then we have a real bug and we need to fix that :).

P.s remember to copy back the dll's you moved after testing.

Im not the best to explain these things, so if its to hard to follow, i have ntldd prebuilt and can upload the packages if needed.

[peterbud]

Why not use lddinstead of ntldd? lddcomes with msys2 by default.

[revelator]

i seem to remember ldd having problems with windows dll's but i might be wrong ?, if i am by all means use it :) its easier than the other thing.

[revelator]

or use this https://github.com/lucasg/Dependencies It a recreation of microsofts old depends.exe, it supports windows 10 apisets also so thats a plus.

[songqingshan]

Hello Ralph,

Your explanation is so good. I so appreciate your work and explanation.

A progress is made.

I have used depends, ntldd and ldd. Depends identify one of culprits as you said "dll hell". Although while compiling, the libraries of msys2 mingw 64 are specified, the program steals three libraries from msys mingw64. After disabling msys mingw64, the programs compiled in msys2 mingw64 can run in window dos, msys (after enabling it) and msys2 mingw64.

However, there is one issue that remains: the program compiled with intel fortran compiler (ifort) can run in windows dos, and msys, but can not run in msys2 and msys2 mingw64 command windows. I use depends to identify the issues as well. it seems that issues are related to three: API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL, API-MS-WIN-CORE-PRIVATEPROFILE-L1-1-1.DLL and API-MS-WIN-SERVICE-PRIVATE-L1-1-1.DLL. I want to know who (windows or mingw64) provides these files. I can send you two *.dwi files (static and dynamic) if you want.

Error is as follows:

User@shan MINGW64 /c/users/user/desktop/bao/appwin/build

$ ./ResRdDemo.exe test.rst

C:/users/user/desktop/bao/appwin/build/ResRdDemo.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

　

User@shan MINGW64 /c/users/user/desktop/bao/appwin/build

Thank your work once again,

Song

---

From: Ralph Engels notifications@github.com Sent: October 27, 2018 12:10 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

see my example and notice the paths :), ofc dlls like C:\Windows\SYSTEM32\KERNEL32.dll are ok since its a windows system dll but if you see for example c:\msys64\codeblocks.dll in a place other than where you currently have codeblocks, then you have a problem cause it would pick that one up and it might not be the same version. In old days this is what we called dll hell because back then most dll's where not versioned so easily got mixed up causing system crashes and all sorts of nasty instability.

as for building ntdll, you need to install msys2 since we use a package manager to build things. when done that open msys2_shell.cmd and in the shell window change directory to the folder mingw-w64-ntdll-git. not write this makepkg-mingw -c -i --skippgp --nocheck and it will build and install ntdll.

cant remember if the installer sets up shortcuts for mingw32 / mingw64 shells but if it does, open one of these and write ntldd path to the executable or dll you want to check. Example ntldd C:/something/somedll.dll and it will spit out a list like my example.

Examine that and notice if any dll's are out of place, if they are then you need to take care of that by either temporarily removing those dll's (just copy them somewhere else) or uninstalling the program using them if you no longer need it.

After that test if your own program works, if it does then we found the culprit, if it does not then we have a real bug and we need to fix that :).

P.s remember to copy back the dll's you moved after testing.

Im not the best to explain these things, so if its to hard to follow, i have ntldd prebuilt and can upload the packages if needed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433591706, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU1orG0CqSNrtr6rZ7acfxrGYSIRaks5uo-rVgaJpZM4X4db7.

[revelator]

sounds like api incompatibility, msys2 mingw64 uses the latest crt and headers for mingw64, and they shifted focus to ucrt (microsofts universal C runtime) this is a windows 10 feature and unfortunatly incompatible with any program compiled with older api. You will probably have to recompile everything you need in msys2 to get around that one, sorry to be the bearer of bad news :/.

[revelator]

Oh and btw those dlls are part of ucrt so definatly something to take into account. In essence all microsoft dll's starting with API- are part of the universal C runtime.

And Thanks :)

[songqingshan]

I wish that I can compile the subprogram in msys2 mingw64. But I can not because it imports a library which is compiled using ifort. I do not have the library code and I can not compile it even if I have.

---

From: Ralph Engels notifications@github.com Sent: October 27, 2018 12:15 PM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

sounds like api incompatibility, msys2 mingw64 uses the latest crt and headers for mingw64, and they shifted focus to ucrt (microsofts universal C runtime) this is a windows 10 feature and unfortunatly incompatible with any program compiled with older api. You will probably have to recompile everything you need in msys2 to get around that one, sorry to be the bearer of bad news :/.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433638555, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU6SQvjB-EPwh52u4ZZ3r_O2PQeumks5upJShgaJpZM4X4db7.

[revelator]

if it utililizes a dll you could probably make an import library and use the exports from that to link to your own code, but and thats a big but. You need the headers that came with that program, and if built using non gnu compilers you might have to modify a few things in those headers to make them compliant with gcc / gfortran. Also the code might not be happy with a bash shell, not all windows programs like this.

If you dont mind sharing the code ? i might be able to come up with something.

[songqingshan]

Hello Ralph,

1. the program runs well in msys/mingw64 command window, but it cannot run in msys2/mingw64 command window. That is what you need to think about. 2. I did what you said "make an import library and use the exports from that to link to your own code..." before we start our talk. I use gfortran to compile it. But during run time, it cannot link to the functions in the exported library. As you said, I have modified some things in the header. I tried a few ways. the outcome is the same: it cannot link to the functions in the lib. I am going to try a new means. 3. I agree that "the code might not be happy with a bash shell", but again it runs well in msys/mingw64. 4. I do not mind to share my own code. But this is a library and its demo from another company. It is the company's proprietary product which can not be copied. However, if you really have interest, you can download it subject to some terms. thanks

---

From: Ralph Engels notifications@github.com Sent: October 28, 2018 12:57 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

if it utililizes a dll you could probably make an import library and use the exports from that to link to your own code, but and thats a big but. You need the headers that came with that program, and if built using non gnu compilers you might have to modify a few things in those headers to make them compliant with gcc / gfortran. Also the code might not be happy with a bash shell, not all windows programs like this.

If you dont mind sharing the code ? i might be able to come up with something.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433678882, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU2sEgERC3Bj4_gicnQp81PfugsU1ks5upUdQgaJpZM4X4db7.

[revelator]

Msys and Msys2 are two very different beasts :) Msys uses code to get around mapping unix paths to windows paths in a totally different way, Msys2 is closer to Cygwin in that regard eg. needs cygpath for certain otherwise hard to compile stuff, If you remove fstab from /etc you even get /cygdrive back, Msys does not have this option it maps to root by default.

Can you post a log about the linker errors ? it might give me some idea about whats going on.

[songqingshan]

I know that Msys and Msys2 are two very different beasts before I download msys2. The purpose of comparing and contracting Msys2 against Msys reminds you of mapping unix paths which maybe is a culprit (but I am not sure). Msys2 command window should run the programs compiled by other compilers like Msys command window. In addition, I have not excluded the interfere of Msys. However, I have renamed Msys in the C drive although I have removed it.

What does "post a log about the linker errors" mean? it means the output in msys2/mingw64 window as follows

"

$ ./ResRdDemo test.rst

C:/users/user/desktop/bao/appwin/build/ResRdDemo.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

"

or dwi files from depends? or other log files?

I believe more information can give you some idea about what's going on.

---

From: Ralph Engels notifications@github.com Sent: October 28, 2018 11:50 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

Msys and Msys2 are two very different beasts :) Msys uses code to get around mapping unix paths to windows paths in a totally different way, Msys2 is closer to Cygwin in that regard eg. needs cygpath for certain otherwise hard to compile stuff, If you remove fstab from /etc you even get /cygdrive back, Msys does not have this option it maps to root by default.

Can you post a log about the linker errors ? it might give me some idea about whats going on.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433721861, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU_JMBWobGXHoyrDrBRqD5PFCdliAks5upeA4gaJpZM4X4db7.

[revelator]

$ ./ResRdDemo test.rst C:/users/user/desktop/bao/appwin/build/ResRdDemo.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

like that aye, just a bit more of it so that i can see where it looks for the dll.

Whats unclear to me is if its a dependency of the dll your trying to link to or the dll itself it cannot find, one sure way is putting a copy of the dll your trying to link to in C:\Windows\System32 and then try building it again, if it fails with the same error then its most likely a dependency of that dll that it complains about, and we then need to find out which.

[songqingshan]

$ ldd ResRdDemo test.rst

ResRdDemo:

ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ff81aa10000)

KERNEL32.DLL => /c/Windows/system32/KERNEL32.DLL (0x7ff819a50000)

KERNELBASE.dll => /c/Windows/system32/KERNELBASE.dll (0x7ff817e40000)

binlib.dll => /c/users/user/desktop/bao/appwin/build/binlib.dll (0x7ff80f0b0000)

imagehlp.dll => /c/Windows/system32/imagehlp.dll (0x7ff81a700000)

MSVCR110.dll => /c/Windows/SYSTEM32/MSVCR110.dll (0x7ff80eee0000)

test.rst:

ldd: test.rst: Exec format error

　

---

From: Ralph Engels notifications@github.com Sent: October 29, 2018 1:48 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

$ ./ResRdDemo test.rst C:/users/user/desktop/bao/appwin/build/ResRdDemo.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

like that aye, just a bit more of it so that i can see where it looks for the dll.

Whats unclear to me is if its a dependency of the dll your trying to link to or the dll itself it cannot find, one sure way is putting a copy of the dll your trying to link to in C:\Windows\System32 and then try building it again, if it fails with the same error then its most likely a dependency of that dll that it complains about, and we then need to find out which.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433804414, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU6Tg2qpeH2oAMBNFlwQz5gB-taltks5upqSigaJpZM4X4db7.

[songqingshan]

note: test.rst is in current directory.

$ ntldd ResRdDemo test.rst

ResRdDemo:

binlib.dll (0x00000000003c0000)

KERNEL32.dll => C:\Windows\SYSTEM32\KERNEL32.dll (0x0000000000720000)

imagehlp.dll => C:\Windows\SYSTEM32\imagehlp.dll (0x00000000003c0000)

test.rst:

test.rst: not found

---

From: Ralph Engels notifications@github.com Sent: October 29, 2018 1:48 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

$ ./ResRdDemo test.rst C:/users/user/desktop/bao/appwin/build/ResRdDemo.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

like that aye, just a bit more of it so that i can see where it looks for the dll.

Whats unclear to me is if its a dependency of the dll your trying to link to or the dll itself it cannot find, one sure way is putting a copy of the dll your trying to link to in C:\Windows\System32 and then try building it again, if it fails with the same error then its most likely a dependency of that dll that it complains about, and we then need to find out which.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433804414, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU6Tg2qpeH2oAMBNFlwQz5gB-taltks5upqSigaJpZM4X4db7.

[revelator]

Sounds like test.rst is in a format your current windows does not support, is it by chance a 16 bit dos format one ?. in that case it will be impossible to load unless you have a 32 bit windows, 64 bit windows does not support 8 and 16 bit format anymore.

You might have luck with a virtual machine like windows 7's XP mode.

Try dragging it inside the dependencies window, if it cannot load the symbols then its most likely we have a real DOS format executable on hand.

If not then it might be in OMF format which went out of style years back, but atleast then we can convert it to COFF.

[revelator]

Wait a second... rst is a restructured text file (ANSYS), you cannot link to it like you would a normal dll. rst's are also used by python doctools like sphinx for api documentation.

[revelator]

So its python we need to link to :), that should be easy, export LIBS+=" -lpython2.7" and make. Then your test should work.

[songqingshan]

Sounds like unreasonable. test.rst is a binary file which is read well by ResRdDemo in Windows/dos and Msys/Mingw64 except for Msys2/mingw64. I believe that either Msys2/mingw64's setting or Msys2/ming64 itself causes an issue.

---

From: Ralph Engels notifications@github.com Sent: November 1, 2018 4:40 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

Sounds like test.rst is in a format your current windows does not support, is it by chance a 16 bit dos format one ?. in that case it will be impossible to load unless you have a 32 bit windows, 64 bit windows does not support 8 and 16 bit format anymore.

You might have luck with a virtual machine like windows 7's XP mode.

Try dragging it inside the dependencies window, if it cannot load the symbols then its most likely we have a real DOS format executable on hand.

If not then it might be in OMF format which went out of style years back, but atleast then we can convert it to COFF.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-434986482, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU8vu5PRfT4Yyqa7qewcHntNfmzXkks5uqsGTgaJpZM4X4db7.

[songqingshan]

test.rst is a binary data file instead of a text file. I have not linked to any dll.

---

From: Ralph Engels notifications@github.com Sent: November 1, 2018 4:58 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

Wait a second... rst is a restructured text file (ANSYS), you cannot link to it like you would a normal dll. rst's are also used by python doctools like sphinx for api documentation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-434991056, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBUyZTsgbQf3Xqh70dx8eTlmMdpgOiks5uqsXEgaJpZM4X4db7.

[songqingshan]

It is "make" or "linking" issue. It is a running issue under Msys2/mingw64. It runs well in Windows/dos or Msys/mingw64. Some of other programs maybe have similar issues.

---

From: Ralph Engels notifications@github.com Sent: November 1, 2018 9:22 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

So its python we need to link to :), that should be easy, export LIBS+=" -lpython2.7" and make. Then your test should work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435037702, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU6NvsxSBeHS1ZFK5qd3ThO5QKlCLks5uqwOfgaJpZM4X4db7.

[songqingshan]

By the way, I can use both "ls" and "dir" commads in dos console and Msys/mingw. After installing Msys2/mingw64, "ls" command is invalid in cos console.

---

From: Ralph Engels notifications@github.com Sent: November 1, 2018 9:22 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

So its python we need to link to :), that should be easy, export LIBS+=" -lpython2.7" and make. Then your test should work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435037702, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU6NvsxSBeHS1ZFK5qd3ThO5QKlCLks5uqwOfgaJpZM4X4db7.

[revelator]

you can use ls in cmd ?, did you export msys\bin to PATH ? atleast that might explain some things. well i noticed the rst extension and according to what i could find its a python docutils file, but it would not be the first time people have used extensions for other things. But just for curiosity try open it with notepad :), if its readable then its text, if it shows garbadge characters then its most likely as you say a binary. As for having ls avaliable in cmd, if msys\bin was exported to PATH it would interfere with msys2 possibly breaking certain functions like the ability to correctly run this.

[songqingshan]

I install both Msys/mingw64 and Msys2/mingw64 in C drive:

C:MinGW (Msys/mingw64)

C:msys64 (Msys2/mingw64)

In Msys, path is

$ echo $PATH echo $PATH .:/local32/bin:/mingw32/bin:/mingw/bin:/bin:/opt/bin:/opt/python3:/MinGW/msys/1.0/local/bin

However, when I use Msys/mingw64 commands console, I use my profile.local to set environment variable and path is as follows: $ echo $PATH .:/local64/bin:/mingw64/bin:/mingw/bin:/bin:/opt/bin:/opt/python3:\C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler

in Msys2/mingw64,

$ 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

However, when I use Msys2/mingw64 console, I have to change "C:MinGW" into "C:MinGW-bak". Otherwise, "Msys2/mingw64" console searches for library files in "C:MinGW".

In windows system, path is as follows.

C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018.5.274\windows\mpi\intel64\bin;%INTEL_DEV_REDIST%redist\intel64_win\mpirt;%INTEL_DEV_REDIST%redist\ia32_win\mpirt;%INTEL_DEV_REDIST%redist\intel64_win\compiler;%INTEL_DEV_REDIST%redist\ia32_win\compiler;%SystemRoot%;%SystemRoot%\system32;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Python37\;C:\Python37\Scripts\;C:\MinGW\msys\1.0\bin;C:\MinGW\mingw32\bin;C:\MinGW\mingw64\bin;C:\MinGW\mingw64\share\aclocal;C:\MinGW\mingw64\include\libxml2\libxml;C:\MinGW\msys\1.0\local\bin;C:\MinGW\mingw64\local\bin;C:\MinGW\mingw64\opt\bin;C:\MinGW\mingw64\opt\usr\bin;C:\MinGW\mingw32\opt\lib\python2.7\config;C:\Program Files\ANSYS Inc\ANSYS Student\v190\ansys\bin\winx64;C:\ANSYS\v190\ansys\bin\winx64;C:\ANSYS\v190\CFX\tools\icemcfd-19.0\winx64\IcemExe2CfxC:\ANSYS\v190\TurboGrid\tools\icemcfd-19.0\winx64\IcemExe2Cfx;C:\Users\User\Desktop\bao\ansys\binlib;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\msys64\mingw64\bin;C:\msys64\mingw64\lib\gio\modules;C:\Program Files\Git\cmd;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\

Before changing "C:MinGW" into "C:MinGW-bak", I can use "ls" command in windows dos console.

After changing "C:MinGW" into "C:MinGW-bak", I can not use "ls" command in windows dos console.

Please forget about rst file. The rst file is a binary data file only. I use a demo program to read this rst file. The demo program works well in windows dos console and Msys console. But Even after changing "C:MinGW" into "MinGW-bak", the demo program can not run (can not find shared library) in "Msys2/mingw64 console". For sure there is no program about the rst file, demo program and its library. I choose them to test or check "Msys2/mingw64" because they are reliable, simple and easy to use. The problem is in that the demo program can not dynamically load its dynamic library in "Msys2/mingw64 console". I personally think that the issue is caused by path setting for "Msys2/ming64". In other words, my question is how to correctly set the path of "Msys2/ming64" so that it works well.

---

From: Ralph Engels notifications@github.com Sent: November 2, 2018 1:49 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

you can use ls in cmd ?, did you export msys\bin to PATH ? atleast that might explain some things. well i noticed the rst extension and according to what i could find its a python docutils file, but it would not be the first time people have used extensions for other things. But just for curiosity try open it with notepad :), if its readable then its text, if it shows garbadge characters then its most likely as you say a binary. As for having ls avaliable in cmd, if msys\bin was exported to PATH it would interfere with msys2 possibly breaking certain functions like the ability to correctly run this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435287498, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU6h2vgzCxqtagZHD54zL-pqfnTGpks5uq-sSgaJpZM4X4db7.

[songqingshan]

Hello Ralph,

The issue seems resolved. As I predict that it is path setting issue in msys2/mingw64.

When I use my profile to set path with adding a library path needed for search, It works.

When I use "set PATH=...", and "export PATH=..." commands in msys2/ming64 to add a library path needed for search , these commands are executed without any errors. But the library path is not added.

If either without modifying .profile in etc holders in msys2 or without using my profile, how can I add a new path to environment variable PATH directly.

I appreciate your help and your discussion with me.

Song

---

From: Ralph Engels notifications@github.com Sent: November 2, 2018 1:49 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

you can use ls in cmd ?, did you export msys\bin to PATH ? atleast that might explain some things. well i noticed the rst extension and according to what i could find its a python docutils file, but it would not be the first time people have used extensions for other things. But just for curiosity try open it with notepad :), if its readable then its text, if it shows garbadge characters then its most likely as you say a binary. As for having ls avaliable in cmd, if msys\bin was exported to PATH it would interfere with msys2 possibly breaking certain functions like the ability to correctly run this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435287498, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU6h2vgzCxqtagZHD54zL-pqfnTGpks5uq-sSgaJpZM4X4db7.

[revelator]

Custom paths can sometimes be a pain to setup in Msys or Cygwin, but glad you got some inspiration from our talks :). I remember setting paths like we did in old msys did not work entirely the same if we put those in etc/fstab since Msys2 is closer to Cygwin than Msys is, things sometimes got real screwy. Instead we use cygpath for most of the path mangling, but it does have its flaws.

[revelator]

Put them in /etc/fstab though i cannot remember the exact way to write them, but alexy should be able to help with that. In old msys you just did it this way C:\yourpath /yourpath but if i remember correctly its a little different in msys2. You can have multiple paths linked to windows mounted directories that way if you write each on a new line.

Also be sure not to delete this line from it -> "none / cygdrive binary,posix=0,noacl,user 0 0" or else you get cygwin paths with /cygdrive prefixed to all paths.

[revelator]

Ok just checked it, its written like this in cygwin c:/yourpath /home/yourpath/ ntfs binary,posix=0,user 0 0 but since we allready have that portion in "none / cygdrive binary,posix=0,noacl,user 0 0" you should be able to just write c:/yourpath /home/yourpath/

[revelator]

also need to uncomment this in /home/.bash_profile

Set PATH so it includes user's private bin if it exists

if [ -d "${HOME}/bin" ] ; then PATH="${HOME}/bin:${PATH}" fi

and change all paths you link to in fstab to something like this c:/yourpath /home/bin/. Means you could pretty much use visual studio or anything you like really from within msys2 :), but its a bit more complicated to setup than the old msys.

[songqingshan]

I enjoy our discussions. I really got inspiration from our talk. thanks.

---

From: Ralph Engels notifications@github.com Sent: November 3, 2018 4:18 PM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

Custom paths can sometimes be a pain to setup in Msys or Cygwin, but glad you got some inspiration from our talks :). I remember setting paths like we did in old msys di not work entirely the same if we put those in etc/fstab since Msys2 is closer to Cygwin than Msys is, things sometimes got real screwy. Instead we use cygpath for most of the path mangling, but it does have its flaws.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435621637, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU-fvOCQCaNBwSg6ExxXI4b5CkIRwks5urggdgaJpZM4X4db7.

[songqingshan]

Just putting PATH in /etc/sfstas does not work thought.

---

From: Ralph Engels notifications@github.com Sent: November 3, 2018 4:23 PM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

Put them in /etc/fstab though i cannot remember the exact way to write them, but alexy should be able to help with that. In old msys you just did it this way C:\yourpath /yourpath but if i remember correctly its a little different in msys2.

Also be sure not to delete this line from it -> "none / cygdrive binary,posix=0,noacl,user 0 0" or else you get cygwin paths with /cygdrive prefixed to all paths.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435621947, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBUx4dnmR15I0nj1Gv5i2VE9S08jxJks5urglogaJpZM4X4db7.

[songqingshan]

I have check it. it does not work.

---

From: Ralph Engels notifications@github.com Sent: November 3, 2018 4:29 PM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

Ok just checked it, its written like this in cygwin c:/yourpath /home/yourpath/ ntfs binary,posix=0,user 0 0 but since we allready have that portion in "none / cygdrive binary,posix=0,noacl,user 0 0" you should be able to just write c:/yourpath /home/yourpath/

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435622305, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU5rt2z7lzUqRRf3tNwkBzKHSlLXeks5urgq1gaJpZM4X4db7.

[revelator]

no you need to expand the path in /etc/fstab into PATH by either exporting it like this export PATH=$PATH:/yourpath where /yourpath is the posix version of c:/yourpath linked to in fstab. Easier ways to do it but this way you dont end up mixing in a lot of unessesary stuff. the resulting PATH should look something like this "/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/yourpath"

if /yourpath has a bin directory export that instead, since thats where binaries usually are so export PATH=$PATH:/yourpath/bin

if you have multiple paths in fstab just do it like this export PATH=$PATH:/yourpath1/bin:/yourpath2/bin etc.

[songqingshan]

Inserting this code after "none / cygdrive binary,posix=0,noacl,user 0 0" in /etc/fstab does not work. I attempt to use this code in command console, it does not work neither.

---

From: Ralph Engels notifications@github.com Sent: November 3, 2018 4:35 PM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

also need to uncomment this in /home/.bash_profile

Set PATH so it includes user's private bin if it exists

if [ -d "${HOME}/bin" ] ; then PATH="${HOME}/bin:${PATH}" fi

and change all paths you link to in fstab to something like this c:/yourpath /home/bin/. Means you could pretty much use visual studio or anything you like really from within msys2 :), but its a bit more complicated to setup than the old msys.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435622674, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBUwhzWpi9jrZk7s9XngTQZuTJkwwAks5urgwqgaJpZM4X4db7.

[songqingshan]

I put it in fstab file as follows

none / cygdrive binary,posix=0,noacl,user 0 0 export PATH=$PATH:C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler

or

none / cygdrive binary,posix=0,noacl,user 0 0 export PATH=$PATH:/C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler

or

none / cygdrive binary,posix=0,noacl,user 0 0 export PATH=$PATH:\C:\Program Files (x86)/ \Common Files\Intel\Shared Libraries\redist\intel64_win\compiler

None of them works.

---

From: Ralph Engels notifications@github.com Sent: November 5, 2018 9:35 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

no you need to expand the path in /etc/fstab into PATH by either exporting it like this export PATH=$PATH:/yourpath where /yourpath is the posix version of c:/yourpath linked to in fstab. Easier ways to do it but this way you dont end up mixing in a lot of unessesary stuff. the resulting PATH should look something like this "/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/yourpath"

if /yourpath has a bin directory export that instead, since thats where binaries usually are so export PATH=$PATH:/yourpath/bin

if you have multiple paths in fstab just do it like this export PATH=$PATH:/yourpath1/bin:/yourpath2/bin etc.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435919111, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU_yPPqXbUMinRTLR0Z7KQ8rb_8HNks5usFrQgaJpZM4X4db7.

[songqingshan]

you mean that in fstab file they should like this,

"none / cygdrive binary,posix=0,noacl,user 0 0

export PATH=$PATH:C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler"

No, I try all what you said. they do not work.

---

From: Ralph Engels notifications@github.com Sent: November 5, 2018 9:35 AM To: Alexpux/MINGW-packages Cc: songqingshan; Mention Subject: Re: [Alexpux/MINGW-packages] error while loading shared libraries: ?: cannot open shared object file: No such file or directory (#4588)

no you need to expand the path in /etc/fstab into PATH by either exporting it like this export PATH=$PATH:/yourpath where /yourpath is the posix version of c:/yourpath linked to in fstab. Easier ways to do it but this way you dont end up mixing in a lot of unessesary stuff. the resulting PATH should look something like this "/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/yourpath"

if /yourpath has a bin directory export that instead, since thats where binaries usually are so export PATH=$PATH:/yourpath/bin

if you have multiple paths in fstab just do it like this export PATH=$PATH:/yourpath1/bin:/yourpath2/bin etc.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435919111, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApTBU_yPPqXbUMinRTLR0Z7KQ8rb_8HNks5usFrQgaJpZM4X4db7.