Error while loading shared libraries cannot open shared object file no such file or directory - Исправление ошибок и поиск оптимальных решений проблем

There is a list of common errors I often see in Ubuntu. There is problem with merge list, then there is BADSIG error, and a number of common Ubuntu update errors.

One of such common errors which I often see while installing a program from its source code is error while loading shared libraries. The full error generally looks like this:

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

For example, I was trying to use FreeRADIUS server and it showed me this error:

radiusd: error while loading shared libraries:
libfreeradius-radius-2.1.10.so:
cannot open shared object file: No such file or directory

The reason behind this error is that the libraries of the program have been installed in a place where dynamic linker cannot find it.

Let me show you how you can go about fixing this issue.

One quick way to fix this “error while loading shared libraries” automatically is to use ldconfig.

All you need to do is to open terminal (Ctrl+Alt+T) and type the following command:

sudo /sbin/ldconfig -v

This one liner should solve the problem in most cases. However, if it doesn’t, I have discussed another method to handle this error. But before that, let me tell you what does the above command do.

What are shared object files? How does the above command fixes the issue?

You see, in C/C++, a .so (shared object) is a compiled library file. It is called shared object because this library file can be shared by several programs. These generated libraries are usually located in /lib or /usr/lib directories.

Now if you wonder how did this tiny command fixed this problem, you should read the man page of ldconfig which says:

ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/lib and /usr/lib). The cache is used by the run-time linker, ld.so or ld-linux.so. ldconfig checks the header and filenames of the libraries it encounters when determining which versions should have their links updated.

I hope this quick fix helps you in eliminating the nasty error while loading shared libraries message in Ubuntu and other Linux.

If not, you can do some investigation and try to fix the issue the way it is mentioned in the next section.

The above discussed method fixes the issue if the library in question is available in your system. But that may not always be the case.

If you do not have the program installed on your system, you won’t have its library file. The ldconfig cannot do anything if there is no library file in the first place.

So, the alternate method is to install the required program and it should create the library automatically.

Let me show it to you by an example. Let’s say you see this error:

error while loading shared libraries: libgobject-2.0.so.0: cannot open shared object file: No such file or directory

The problem is with libgobject version 2.0. The version number is important because some programs depend on a specific version of the library and if they don’t find, they complain about it.

Now, apt provides the search option that can be used for searching a package and knowing its version before installing it.

[email protected]:~$ apt search libgobject
Sorting... Done
Full Text Search... Done
librust-gobject-sys-dev/focal 0.9.0-2 amd64
  FFI bindings to libgobject-2.0 - Rust source code

Now, this librust-gobject-sys-dev package could be what you need if you know that you were trying to run a Rust program. But what if it was a Python program you were running that complained about it?

You can widen your search by removing the lib from the package name while searching. The lib signifies library and libraries may be provided by a generic package that could be named gobject-xyz.

It would be a good idea to search for the string in the names of the package (instead of description) to get more concise results.

[email protected]:~$ apt search --names-only gobject
Sorting... Done
Full Text Search... Done
gobject-introspection/focal-updates 1.64.1-1~ubuntu20.04.1 amd64
  Generate interface introspection data for GObject libraries

libavahi-gobject-dev/focal 0.7-4ubuntu7 amd64
  Development headers for the Avahi GObject library

libavahi-gobject0/focal 0.7-4ubuntu7 amd64
  Avahi GObject library

libcairo-gobject-perl/focal,now 1.005-2 amd64 [installed,automatic]
  integrate Cairo into the Glib type system in Perl

libcairo-gobject2/focal,now 1.16.0-4ubuntu1 amd64 [installed,automatic]
  Cairo 2D vector graphics library (GObject library)

libghc-gi-gobject-dev/focal 2.0.19-1build1 amd64
  GObject bindings

libghc-gi-gobject-doc/focal,focal 2.0.19-1build1 all
  GObject bindings; documentation

In the above truncated output, you’ll have to see if the package is related to the original program you were trying to run. You must also check the version of the library provided.

Once you have identified the correct package, install it like this:

sudo apt install package_name

Once installed, you may run the ldconfig command again to update the cache:

sudo /sbin/ldconfig -v

This method requires some effort on your end but this is how the dependencies are handled.

Nothing works, what now?

If you are unfortunate enough, the above methods might not work for you. What can you do?

First, keep in mind that the shared libraries may be used from other packages in some cases. If you were trying to run XYZ program and ABC program installs the correct version of the shared library, it may (or may not) work for you. You can give it a hit and trial.

Second, if you are trying to run a program which is too old or too new, it may require a library version which is not available for your Linux distribution.

What you may do is to check if you can use some other version of the program. For example, using Eclipse version 3 instead of version 4. This may help your case.

The other way would be to check the developers website or forums and see if you can manually install the correct version of the library from its source code. That requires a lot of effort (in 2020) but you don’t have a lot of options.

Did it work for you?

I hope I have make things a bit more clear for you. Did you manage to fix the issue of shared libraries in your system? If you have questions, suggestions, feel free to drop a comment. Ciao

Источник

Новые и опытные пользователи Linux могут сталкиваться с ошибкой error loading shared libraries во время запуска программ, также с ней могут сталкиваться программисты и все желающие компилировать программное обеспечение в своей системе. Эта ошибка в дословном переводе означает что возникла проблема во время загрузки общей библиотеки. О том что такое библиотеки и зачем они нужны вы можете узнать из статьи библиотеки Linux.

В этой же статье мы рассмотрим что значит ошибка error while loading shared libraries более подробно, а главное, как ее решить.

Даже если вы не компилируете свои программы, то вы можете увидеть ошибку error while loading shared libraries: имя_библиотеки: cannot open shared object file: No such file or directory достаточно часто во время установки новых программ не через пакетный менеджер или программ, предназначенных для другого дистрибутива. Как я уже говорил, она возникает потому, что система не может найти библиотеку.

А вот почему ее нельзя найти и загрузить, это уже интересно. Этому может быть несколько причин:

Библиотека не установлена в системе;
Библиотека установлена, но неизвестно куда;
Библиотека установлена правильно, но имеет не ту версию.

При решении проблемы мы будем руководствоваться именно этими причинами и пытаться их решить.

Как исправить ошибку?

1. Библиотека не установлена

Первый вариант, тут все понятно, библиотеки просто нет в системе, поэтому мы и получаем такую ошибку. Верный способ ее решения — просто найти пакет библиотеки с помощью пакетного менеджера и установить ее. Обычно, пакеты с библиотеками называются так же, как и сами библиотеки с префиксом lib.

Например, если нам не хватает библиотеки libfuse2.so, то мы можем найти ее в Ubuntu такой командой:

sudo apt search libfuse2

Затем осталось только установить ее:

sudo apt install libfuse2

Если перед вами стоит задача собрать программу из исходников, то вам понадобится не только установить саму библиотеку, но и заголовочные файлы для нее:

sudo apt install libfuse-dev

И так для любой библиотеки. Но это не всегда помогает.

2. Библиотека находится не в том каталоге

Бывает что библиотека установлена, мы установили ее или она поставлялась вместе с программой, но ошибка как была, так и есть. Причиной этому может быть то, что загрузчик Linux не может найти библиотеку.

Поиск библиотек выполняется по всех папках, которые указаны в конфигурационных файлах /etc/ld.conf.d/. По умолчанию, это такие каталоги, как /usr/lib, /lib, /usr/lib64, /lib64. Если библиотека установлена в другой каталог, то, возможно, это и есть причина проблемы.

Вы можете посмотреть какие библиотеки сейчас доступны загрузчику с помощью команды:

ldconfig -p

Найти, где находится ваша библиотека можно с помощью команды locate. Например, нас интересует библиотека librtfreader.so:

locate librtfreader

Теперь мы знаем, что она находится по адресу /opt/kingsoft/wps-office/office6/. А значит, для работы программы необходимо сделать чтобы загрузчик библиотек ее видел. Для этого можно добавить путь в один из файлов /etc/ld.so.conf.d/ или же в переменную LD_LIBRARY_PATH:

export LD_LIBRARY_PATH=/opt/kingsoft/wps-office/office6/

Опять же, так вы можете поставить с любой библиотекой, которая взывает ошибку. Еще один более простой метод — это просто создать символическую ссылку на нужную библиотеку в правильной папке:

ln -s /opt/kingsoft/wps-office/office6/librtfreader.so /usr/lib/librtfreader.so

3. Неверная версия библиотеки

Эта причина ошибки довольно часто встречается при использовании программ не для вашего дистрибутива. Каждая библиотека имеет дополнительную версию, так называемую ревизию, которая записывается после расширения .so. Например, libav.so.1. Так вот, номер версии меняется всякий раз, когда в библиотеку вносятся какие-либо исправления.

Часто возникает ситуация, когда в одном дистрибутиве программа собирается с зависимостью от библиотеки, например, libc.so.1, а в другом есть только libc.so.2. Отличия в большинстве случаев здесь небольшие и программа могла бы работать на второй версии библиотеки. Поэтому мы можем просто создать символическую ссылку на нее.

Например, библиотеки libusb-1.0.so.1 нет. Но зато есть libusb-1.0.so.0.1, и мы можем ее использовать:

Для этого просто создаем символическую ссылку на библиотеку:

sudo ln -s /usr/lib/libusb-1.0.so.0.1 /usr/lib/libusb-1.0.so.1

В большинстве случаев программа не заметит подмены и будет работать, как и ожидалось. Также для решения этой проблемы можно попытаться найти нужную версию библиотеки в интернете для своей архитектуры и поместить ее в папку /usr/lib/ или /usr/lib64/. Но после этого желательно обновить кэш:

sudo ldconfig

Выводы

В этой статье мы рассмотрели почему возникает ошибка Error while loading shared libraries, а также как ее решить. В большинстве случаев проблема решается довольно просто и вы получите работоспособную программу. Надеюсь, эта информация была полезной для вас.

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Источник

Sometimes, when you try to install a program or a package from its source code, you might end up getting an error which looks like :

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

In general, if the package shared library name is lib, the error sometimes shows the following :

“error while loading shared libraries: lib.so.X: cannot open shared object file: No such file or directory “

Where X is a number.

These dynamically generated shared libraries, which are required by executables, are stored under /lib or /usr/lib directories.

The command below can help find out the libraries that are needed for a given executable :

ldd nw

As a quick workaround, you could try to fix the issue by running ldconfig command below :

sudo ldconfig -v

Now at runtime, the system would need to locate the ‘.so’ corresponding library file since the package or the program is linked with the library shared version.

To locate the library, invoke the command below :

sudo find / -name lib_file.so.x

or you could use apt search command. Jot down the path in which the lib_file.so.x is found, path_to_so_file.

Read: How to find the largest files on Linux

To include the folder in which the library is installed, the shell variable LD_LIBRARY_PATH has to be provided.

If LD_LIBRARY_PATH is not defined (run echo $LD_LIBRARY_PATH to find out), you could set it using the command (in the Bash shell) :

LD_LIBRARY_PATH=/usr/local/lib

Now using the path of the .so file that you found above, path_to_so_file, run the commands below :

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:path_to_so_file

export LD_LIBRARY_PATH $ ./your_package

You can find out more about shared libraries here.

If you like the content, we would appreciate your support by buying us a coffee. Thank you so much for your visit and support.

Nikolaus Oosterhof

Nikolaus has a degree in software development. He is passionate about gadgets with a screen, nostalgic for phones, a retired gamer and open source programmer. He likes also to write about macOS and Windows. design web pages and debug long programs!

Источник

The program evince complains that it can’t find libfreetype.so.6; however I clearly have the file and its included in my LD_LIBRARY_PATH; furthermore I have another program which uses libfreetype6 and is able to run just fine. What’s going on here?

jbud@jb-pc ~> evince
evince: error while loading shared libraries: libfreetype.so.6: cannot open shared object file: No such file or directory

jbud@jb-pc ~> ldd /usr/bin/evince | grep freetype
libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x00007f912179d000)

jbud@jb-pc ~> file /usr/local/lib/libfreetype.so.6
/usr/local/lib/libfreetype.so.6: symbolic link to `libfreetype.so.6.11.1'

jbud@jb-pc ~> file /usr/local/lib/libfreetype.so.6.11.1
/usr/local/lib/libfreetype.so.6.11.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x21a4b8005e0c9a42af001b35fb984f4e25efc71c, not stripped

jbud@jb-pc ~> echo $LD_LIBRARY_PATH
/usr/lib/:/usr/lib64/:/usr/lib/x86_64-linux-gnu/:/usr/local/lib/

jbud@jb-pc ~> ldd jdrive/jstuff/work/personal/noengine/client | grep freetype
libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x00007feb5ac89000)

asked Jan 22, 2014 at 18:51

Creating a symbolic link to /usr/lib/libfreetype.so.6 should not be applied if the error was thrown by a 32-bit application on a 64-bit Linux distribution. The library could be left ‘broken’.

What you want on a 64-bit system is to install the necessary 32-bit dependencies around your 32-bit application, so that it will be able to detect and use the already existing libfreetype.so.6. This differs per application, but commonly missing are these:

sudo apt-get install libgtk2.0-0:i386 libidn11:i386 libglu1-mesa:i386

And these may possibly fix the problem too:

sudo apt-get install libpangox-1.0-0:i386 libpangoxft-1.0-0:i386

Regards,
Albert Kok

answered Mar 5, 2014 at 10:59

I was able to fix this problem however I’m still not entirely sure why this was a problem in the first place.

After running strace, I saw open("/usr/local/lib/libfreetype.so.6", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) which doesn’t quite make sense since other programs (without sudo powers) which depended on libfreetype were able to run, and the permissions are set for read/write for all, also running evince under sudo didn’t help either.

My apt-get of libfreetype placed the library in /usr/lib/x86_64-linux-gnu/libfreetype.so.6 but for some reason evince wasn’t checking that folder (even though it was added to LD_LIBRARY_PATH). However I created a symbolic link to a folder which it does check sudo ln -s /usr/lib/x86_64-linux-gnu/libfreetype.so.6.10.1 /usr/lib/libfreetype.so.6 and now evince runs fine.

answered Jan 23, 2014 at 15:44

glitchymeglitchyme

1911 gold badge1 silver badge5 bronze badges

Источник

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

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.

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

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.

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

@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

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.

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 GitHub<https://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433061386>, or mute the thread<https://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 <glib.h>

static void show_reslut()
{
g_print(«show_reslutn»);
}

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(«whilen»);
g_main_context_iteration (NULL, TRUE);
g_print(«waitn»);
}
g_print(«returnn»);

}

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 = %dn», count);
return( 0 );
}

/*
* Compile me with:
* gcc -o helper helper.c
*/
#include <stdio.h>
#include <unistd.h>

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, «%sn», stdout_string );
printf( «num1 = %dn», num1);
fflush(stdout);
sleep( 1 );
num2 = fprintf( stderr, «%sn», stderr_string );
printf( «num2 = %dn», num2);
fflush(stderr);
}

return( 0 );
}

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 ?.

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

…

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)

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

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

…

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:WindowsWinSxSx86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.17134.345_none_40ff7c964511edcfCOMCTL32.DLL (0x00760000)
KERNEL32.dll => C:WindowsSYSTEM32KERNEL32.dll (0x01080000)
msvcrt.dll => C:WindowsSYSTEM32msvcrt.dll (0x01080000)
SHELL32.dll => C:WindowsSYSTEM32SHELL32.dll (0x01470000)
SHFOLDER.DLL => C:WindowsSYSTEM32SHFOLDER.DLL (0x00020000)
USER32.dll => C:WindowsSYSTEM32USER32.dll (0x010d0000)
exchndl.dll => c:msys64exchndl.dll (0x00020000)
wxmsw28u_gcc_cb.dll => c:msys64wxmsw28u_gcc_cb.dll (0x01470000)
codeblocks.dll => c:msys64codeblocks.dll (0x01470000)
wxpropgrid.dll => c:msys64wxpropgrid.dll (0x01080000)

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)

example on codeblocks.exe

ntldd c:/msys64/codeblocks.exe
COMCTL32.DLL => C:WindowsWinSxSx86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.17134.345_none_40ff7c964511edcfCOMCTL32.DLL (0x00760000)
KERNEL32.dll => C:WindowsSYSTEM32KERNEL32.dll (0x01080000)
msvcrt.dll => C:WindowsSYSTEM32msvcrt.dll (0x01080000)
SHELL32.dll => C:WindowsSYSTEM32SHELL32.dll (0x01470000)
SHFOLDER.DLL => C:WindowsSYSTEM32SHFOLDER.DLL (0x00020000)
USER32.dll => C:WindowsSYSTEM32USER32.dll (0x010d0000)
exchndl.dll => c:msys64exchndl.dll (0x00020000)
wxmsw28u_gcc_cb.dll => c:msys64wxmsw28u_gcc_cb.dll (0x01470000)
codeblocks.dll => c:msys64codeblocks.dll (0x01470000)
wxpropgrid.dll => c:msys64wxpropgrid.dll (0x01080000)

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

see my example and notice the paths :), ofc dlls like C:WindowsSYSTEM32KERNEL32.dll are ok since its a windows system dll but if you see for example c:msys64codeblocks.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.

Why not use ldd instead of ntldd? ldd comes with msys2 by default.

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.

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)

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 GitHub<https://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433591706>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ApTBU1orG0CqSNrtr6rZ7acfxrGYSIRaks5uo-rVgaJpZM4X4db7>.

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 :/.

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

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)

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

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.

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 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 GitHub<https://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433678882>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ApTBU2sEgERC3Bj4_gicnQp81PfugsU1ks5upUdQgaJpZM4X4db7>.

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.

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)

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 GitHub<https://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-433721861>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ApTBU_JMBWobGXHoyrDrBRqD5PFCdliAks5upeA4gaJpZM4X4db7>.

$ ./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:WindowsSystem32 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.

$ 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.

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

note: test.rst is in current directory.

$ ntldd ResRdDemo test.rst

ResRdDemo:

binlib.dll (0x00000000003c0000)

KERNEL32.dll => C:WindowsSYSTEM32KERNEL32.dll (0x0000000000720000)

imagehlp.dll => C:WindowsSYSTEM32imagehlp.dll (0x00000000003c0000)

test.rst:

test.rst: not found

…

$ ./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.

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

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.

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.

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

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)

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 GitHub<https://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-434986482>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ApTBU8vu5PRfT4Yyqa7qewcHntNfmzXkks5uqsGTgaJpZM4X4db7>.

you can use ls in cmd ?, did you export msysbin 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 msysbin was exported to PATH it would interfere with msys2 possibly breaking certain functions like the ability to correctly run this.

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 FilesIntelShared Librariesredistintel64_wincompiler

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)IntelSWToolscompilers_and_libraries_2018.5.274windowsmpiintel64bin;%INTEL_DEV_REDIST%redistintel64_winmpirt;%INTEL_DEV_REDIST%redistia32_winmpirt;%INTEL_DEV_REDIST%redistintel64_wincompiler;%INTEL_DEV_REDIST%redistia32_wincompiler;%SystemRoot%;%SystemRoot%system32;%SystemRoot%System32Wbem;%SYSTEMROOT%System32WindowsPowerShellv1.0;C:Python37;C:Python37Scripts;C:MinGWmsys1.0bin;C:MinGWmingw32bin;C:MinGWmingw64bin;C:MinGWmingw64shareaclocal;C:MinGWmingw64includelibxml2libxml;C:MinGWmsys1.0localbin;C:MinGWmingw64localbin;C:MinGWmingw64optbin;C:MinGWmingw64optusrbin;C:MinGWmingw32optlibpython2.7config;C:Program FilesANSYS IncANSYS Studentv190ansysbinwinx64;C:ANSYSv190ansysbinwinx64;C:ANSYSv190CFXtoolsicemcfd-19.0winx64IcemExe2CfxC:ANSYSv190TurboGridtoolsicemcfd-19.0winx64IcemExe2Cfx;C:UsersUserDesktopbaoansysbinlib;C:Program FilesMicrosoft SQL Server130ToolsBinn;C:msys64mingw64bin;C:msys64mingw64libgiomodules;C:Program FilesGitcmd;C:Program Files (x86)Windows Kits8.1Windows 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 are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435287498>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ApTBU6h2vgzCxqtagZHD54zL-pqfnTGpks5uq-sSgaJpZM4X4db7>.

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

…

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

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.

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.

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/

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.

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 GitHub<https://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435621637>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ApTBU-fvOCQCaNBwSg6ExxXI4b5CkIRwks5urggdgaJpZM4X4db7>.

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)

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 GitHub<https://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435621947>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ApTBUx4dnmR15I0nj1Gv5i2VE9S08jxJks5urglogaJpZM4X4db7>.

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.

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

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

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

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 / cygdrive binary,posix=0,noacl,user 0 0
export PATH=$PATH:C:Program Files (x86)/
Common FilesIntelShared Librariesredistintel64_wincompiler

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)

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 GitHub<https://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435919111>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ApTBU_yPPqXbUMinRTLR0Z7KQ8rb_8HNks5usFrQgaJpZM4X4db7>.

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.

…

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 GitHub<https://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-435919111>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ApTBU_yPPqXbUMinRTLR0Z7KQ8rb_8HNks5usFrQgaJpZM4X4db7>.

uh no like this ->

after the
none / cygdrive binary,posix=0,noacl,user 0 0 which is allready there.

put C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler /intelc <- notice this.

now open a bash shell and do export PATH=$PATH:/intelc

you might run into trouble with paths that have spaces in them, in that case put «» around C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler so that it looks like this
«C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler» /intelc

Yep definatly trouble with that, just tested.
If i use a short path like c:dmbin it works but C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler does not.

Unfortunatly it seems even putting it in braces is not enough, so only other solution would be doing it with a batch file, it will be rather messy though.

Ok had a look at the cygwin mount tables and theres a workaround for the substitution.
the spaces need to be escaped with 40 so it becomes C:/Program40Files40(x86)/Common40Files/Intel/Shared40Libraries/redist/intel64_win/compiler .

https://cygwin.com/cygwin-ug-net/using.html

another way is creating a symlink to C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler in say C:/intel and then use that as path.

«C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler» is only what I need to add.

I do not understand why need to put

«C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler /intelc»

«C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler /intelc <»

or «C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler /intelc <- »

what is «/intelc» used for?

Anyway, these do not work.

…

putting «C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler» /intelc only can add /intelc.

I do not understand why I should have /intelc. what is /intelc used for.

…

This way does not work.

…

________________________________
From: Ralph Engels <notifications@github.com>
Sent: November 6, 2018 2:33 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)

https://cygwin.com/cygwin-ug-net/using.html

Chapter 3. Using Cygwin<https://cygwin.com/cygwin-ug-net/using.html>
cygwin.com
The Cygwin DLL supports both POSIX- and Win32-style paths. Directory delimiters may be either forward slashes or backslashes. Paths using backslashes or starting with a drive letter are always handled as Win32 paths.

another way is creating a symlink to C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler in say C:/intel and then use that as path.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/Alexpux/MINGW-packages/issues/4588#issuecomment-436171145>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ApTBU8jyfn1oHg2U1MwlIP0MXWn2k5TRks5usUlhgaJpZM4X4db7>.

/intelc becomes the new posix path of C:/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64_win/compiler.

so instead of that long windows path you have a shorter one thats easier to work with :).

Источник

For the past few days, I have been extensively testing PIP and Pipenv tools in my Arch Linux system. While testing these tools, I had to reinstall and downgrade Python2.x, Python 3.x packages and some other Python dependencies package many times. At some point, It broke my Arch Linux and pacman stopped working. Whenever I run pacman, I got an error that says «pacman: error while loading shared libraries: libidn2.so.0: cannot open shared object file: No such file or directory».

pacman: error while loading shared libraries: libidn2.so.0: cannot open shared object file: No such file or directory

Not just pacman, some other applications, such as pacaur, yaourt, packer, virtualbox and transmission etc., also stopped working. When I try to open any one of these applications, I keep getting this message — «error while loading shared libraries: libidn2.so.0: cannot open shared object file».

Chances are that I may have uninstall something that I couldn’t remember. To my bad luck, It was my personal system and I don’t want to reinstall it because it has a lot of applications. So, reinstalling OS and all applications might took two or may be more days.

After vigorously searching on Arch Linux wiki and other Linux forums like a mad man, I finally managed to fixed it. If you ever run into a problem something like this, look nowhere, just download the source file and copy the missing file(s) to /usr/lib/ folder. As far as I searched on the web, this method seems very easiest one so far. Read on to know how I fixed this error.

Fix «pacman: error while loading shared libraries» Error In Arch Linux

As I said already, I kept getting this error — «pacman: error while loading shared libraries: libidn2.so.0: cannot open shared object file: No such file or directory» when I run pacman command or any AUR helpers such as pacaur, packer, yaourt and I even can’t open VirtualBox application and Transmission client. So, the actual problem here is the file «libidn2.so.0» has gone missing. We need to find it out!

$ ls -la /usr/lib/libidn*

Sample output from my Arch Linux system:

lrwxrwxrwx 1 root root 22 Jul 22 2013 /usr/lib/libidnkitlite.so -> libidnkitlite.so.1.0.2
lrwxrwxrwx 1 root root 22 Jul 22 2013 /usr/lib/libidnkitlite.so.1 -> libidnkitlite.so.1.0.2
-rw-r--r-- 1 root root 276352 Jul 22 2013 /usr/lib/libidnkitlite.so.1.0.2
lrwxrwxrwx 1 root root 18 Jul 22 2013 /usr/lib/libidnkit.so -> libidnkit.so.1.0.2
lrwxrwxrwx 1 root root 18 Jul 22 2013 /usr/lib/libidnkit.so.1 -> libidnkit.so.1.0.2
-rw-r--r-- 1 root root 282368 Jul 22 2013 /usr/lib/libidnkit.so.1.0.2
lrwxrwxrwx 1 root root 17 Aug 15 19:00 /usr/lib/libidn.so -> libidn.so.11.6.16
lrwxrwxrwx 1 root root 17 Aug 15 19:00 /usr/lib/libidn.so.11 -> libidn.so.11.6.16
-rwxr-xr-x 1 root root 210872 Aug 15 19:00 /usr/lib/libidn.so.11.6.16

I had «libidn.so», but can’t find «libidn2.so.0». Since pacman and any other package manager didn’t work, there is no way to install, upgrade or downgrade any packages from official repository or local cache. So, I thought that the only way might be to download the package that has the missing file from Internet, extract it and finally copy the missing file(s) to /usr/lib/ directory. Let me create a directory to save libdin2 tar file:

$ mkdir libidn

$ cd libidn

Find and download the latest version of this package. A quick google search brought me here. Extract the file:

$ tar xf libidn2-2.0.4-2-x86_64.pkg.tar.xz

The above command extracted the contents of the file in a directory named «usr». Go to the usr/lib folder: (Note — It is usr/lib, not /usr/lib)

$ cd usr/lib

Finally copy the missing file, in our case it is libidn2.so.0, to /usr/lib/ directory of your Arch Linux system.

$ sudo cp libidn2.so.0 /usr/lib/

Then, I ran:

$ sudo pacman -syu

Update Arch Linux

Voila! Pacman works now!! Oops! Oh no, wait.. It didn’t work. I got this error after few minutes.

[....]
(511/511) checking keys in keyring [######################] 100%
(511/511) checking package integrity [######################] 100%
(511/511) loading package files [######################] 100%
(511/511) checking for file conflicts [######################] 100%
error: failed to commit transaction (conflicting files)
libidn2: /usr/lib/libidn2.so.0 exists in filesystem
Errors occurred, no packages were upgraded.

To fix this, I ran:

$ sudo pacman -S libidn2 --force

Then, I tried update again:

$ sudo pacman -Syu

Fixed!! All good now. So, if you guys ever run into an issue something like «error while loading shared libraries: .. cannot open shared object file: No such file or directory», one way to fix this is to find the the package that contains the missing files, download the latest version of that package, extract it and copy the missing files to /usr/lib/ directory. Of course, there could be many ways to fix such kind of issues. But this is the only working solution I could find and I find this much easier and faster. This trick might work on other Linux distros too.

Related read:

How To Restore Broken Arch Linux To Previous Working State
How To Fix “unable to lock database” Error In Arch Linux
How To Fix “invalid or corrupted package (PGP signature)” Error In Arch Linux
How To Solve “Starting full system upgrade… there is nothing to do” Issue In Arch Linux
How To Solve “error: failed to commit transaction (conflicting files)” In Arch Linux

sk

Senthilkumar Palani (aka SK) is the Founder and Editor in chief of OSTechNix. He is a Linux/Unix enthusiast and FOSS supporter. He lives in Tamilnadu, India.

Источник

In linux, there are both static(.a file) and dynamic(.so file).

To run ./db_bench executable compiled from rocksDB to benchmark SSD. I read the installation of facebook’s install.md. after I did, the problem happened

it was :

[hyunyoung.lee@localhost rocksdb]$ ./db_bench

./db_bench: error while loading shared libraries: libgflags.so.2: cannot open shared object file: No such file or directory

So I haved looking for way to make it. the solution refers to this site(lonesysadmin)

the article below refer to this site(lonesysadmin)
After I watched “./db_bench: error while loading shared libraries: libgflags.so.2: cannot open shared object file: No such file or directory”, I checked /usr/local/lib and the files are there.

there are five fixes, which this site(lonesysadmin). introduces. and the site divided five fixes into good idea & terrible idea.

Suboptimal Fixes / Terrible Ideas[0]

Install the libraries to /usr/lib instead of /usr/local/lib.
I think of this is not good method because you’re installing add-on software into a system directory, and you might introduce a conflict, overwrite a pre-existing library, and/or destablize other parts of the system. People complain about Windows being unstable, and this sort of thing is exactly why it gets unstable — installers overwrite system DLLs with their own all the time, Linux doesn’t have something that deals with the problem, it just assumes that you know what you’re doing. Such is the power of UNIX.
When you’re building open-source software under a UNIX OS, you often use the “configure” command. You can change where the software installs by using the “prefix” flag.

$ ./configure -prefix =/usr

this will also install all the binaries, header files, etc. into the system directories. If you were one of my system administrators I’d get on your case for doing this and make you go back and do it right. This isn’t the right way. Don’t do it this way. The right ways are simple, do those instead.
Make a symbolic link from /lib to the files in /usr/local/lib
This is less intrusive than installing everyhing to /usr, but It’s still bad idea.

$ sudo ln -s /usr/loca/lib/libgflags.so.2 /usr/lib/libgflags.so.2
$ sudo ldconfig

Obviously substitute the correct file name for libgflags.so.2. The ‘ldconfig’ command updates the system’s dynamic library cache so it sees the chandged libraries.
Still, don’t do this. Bad sysadmin.
Copy the files from /usr/local/lib into /usr/lib.
this is even more of a bad idea than #2, because now you’ve got two sets of libraries, and if you ever have to patch or upgrade it, you’ll probably forget about ont set.

$ sudo cp /usr/local/lib/libev.* /usr/lib    
$ sudo ldconfig

With all these ideas you’re also very likely to run afoul of the 32-bit vs 64-bit thing with newer OSes, where 32-bit libraries go in /usr/lib and 64-bit libraries go in /usr/lib64.it might work, it might not work, but the better ways are a heck of a lot simpler.

Better Idea

Set the enviroment variable LD_LIBRARY_PATH to point to /usr/local/lib.
If you are new to UNIX/LINUX and don’t know what shell you’re running, use the ‘ps’ command to see the processes you’re running.

[hyunyoung.lee@localhost lib]$ ps
  PID TTY          TIME CMD
 5501 pts/0    00:00:00 bash
32736 pts/0    00:00:00 ps

Hey look, I’m running bash, so my command would be :

export LD_LIBRARY_PATH=”/usr/local/lib”

and you can put that into your ~/.bashrc so it’s always there.

Changing the environment is a per-user thing, so other users on the system will need to do this, or you’d need to put the fixes in /etc/bashrc, the system-wide login scripts. This fix is nice,though, if you don’t have root-level privileges on a system, and/or want to install those things into your own home directory.

Abolutely Simple, Best Fix Ever[2]

If you have root privileges on this Linux box, why not just ask the dynamic linker to check /usr/local/lib, too?
Edit the file /etc/ld.so.conf and add “/usr/local/lib” on its own line at the bottom. DO NOT REMOVE THINGS FROM THIS FILE. When you’re done, it might look somegthing like :

[hyunyoung.lee@localhost etc]$ cat /etc/ld.so.conf
include ld.so.conf.d/*.conf
/usr/local/lib

or it might look completely different, with the exception of the last line. Run ldconfig to tell it to update the cache :

You can check your work with :

$ ldconfig -p  | grep local

[hyunyoung.lee@localhost etc]$ ldconfig -p | grep local
	libsvn_ra_local-1.so.0 (libc6,x86-64) => /lib64/libsvn_ra_local-1.so.0
[hyunyoung.lee@localhost etc]$ sudo ldconfig
[sudo] password for hyunyoung.lee: 
[hyunyoung.lee@localhost etc]$ ldconfig -p | grep local
	libsvn_ra_local-1.so.0 (libc6,x86-64) => /lib64/libsvn_ra_local-1.so.0
	libgflags_nothreads.so.2.2 (libc6,x86-64) => /usr/local/lib/libgflags_nothreads.so.2.2
	libgflags_nothreads.so.2 (libc6,x86-64) => /usr/local/lib/libgflags_nothreads.so.2
	libgflags_nothreads.so (libc6,x86-64) => /usr/local/lib/libgflags_nothreads.so
	libgflags.so.2.2 (libc6,x86-64) => /usr/local/lib/libgflags.so.2.2
	libgflags.so.2 (libc6,x86-64) => /usr/local/lib/libgflags.so.2
	libgflags.so (libc6,x86-64) => /usr/local/lib/libgflags.so

something above is my state on my system. You should see the stuff in /usr/local/lib show up now, and your binary works. Boy, that was easy, and you didn’t make more work for yourself down the road, destablize the system, overwrite system files, or leave security vulnerabilities lying around.

so if you know more about library on the linux, refer to this site(ibm’s l-dynamic-libraries)

if you want brief detail. plead refers to this site(gnu’s Shared-Libraries)

Источник