got undefined symbol: _ZTIN9... when run executive file
Hello everyone!
This morning I have got unexpected error: "undefined symbol: _ZTIN9Fastcgipp3SQL12Results_baseE" when I run the executive file. The program was compiled on my local PC and then uploaded to remote server. I know this related with an library - c++filt: "typeinfo for Fastcgipp::SQL::Results_base". But yesterday (and all days before) it worked fine. I didn't change the code, didn't update any libs. The command "ldd myfile" shows the same version of the library. So what else is possible?
Maybe the server have updated something when I slept? This is from logs:
I've reinstalled the library - it didn't help.
What is going on? How to fix it? Any advice please?
This morning I have got unexpected error: "undefined symbol: _ZTIN9Fastcgipp3SQL12Results_baseE" when I run the executive file. The program was compiled on my local PC and then uploaded to remote server. I know this related with an library - c++filt: "typeinfo for Fastcgipp::SQL::Results_base". But yesterday (and all days before) it worked fine. I didn't change the code, didn't update any libs. The command "ldd myfile" shows the same version of the library. So what else is possible?
Maybe the server have updated something when I slept? This is from logs:
Aug 30 23:31:48 mail systemd[1]: Starting Daily apt download activities... Aug 30 23:31:50 mail systemd[1]: apt-daily.service: Succeeded. Aug 30 23:31:50 mail systemd[1]: Finished Daily apt download activities. Aug 30 23:31:50 mail systemd[1]: apt-daily.service: Consumed 2.014s CPU time. |
I've reinstalled the library - it didn't help.
What is going on? How to fix it? Any advice please?
I think I'd start with (replacing foo.so with your actual fastcgi library name)
nm -D foo.so | grep -E -i 'fastcgipp.*result'
nm -D lists all the dynamic symbols.
The grep does a case-insensitive search on a regex roughly matching your expected symbol.
Do the same thing on your local machine and the remote server.
Is the fastcgi library really the same on both machines?
Like being the same size and having the same sha256 checksum?
> I didn't change the code, didn't update any libs.
But did you recompile it?
nm -D foo.so | grep -E -i 'fastcgipp.*result'
nm -D lists all the dynamic symbols.
The grep does a case-insensitive search on a regex roughly matching your expected symbol.
Do the same thing on your local machine and the remote server.
Is the fastcgi library really the same on both machines?
Like being the same size and having the same sha256 checksum?
> I didn't change the code, didn't update any libs.
But did you recompile it?
post edited:
With "nm" command to libfastcgipp.so.3.1 - it gives the same dynamic symbols on both machines.
Size of ".so" files is different
The local machine:
The remote machine:
Folders has been downloaded from github and have the same size on both machines.
Yes, I recompiled my program, but I also tried to run old compiled file.
I have reinstalled the library after that, but the problem is still there.
It's funny - it worked fine all previous days. :))
It seems the server has two versions of the library:
The local machine has just one:
Should I remove the second one (/usr/local/lib/libfastcgipp.so.3.1) from the remote server?
With "nm" command to libfastcgipp.so.3.1 - it gives the same dynamic symbols on both machines.
Size of ".so" files is different
The local machine:
563896 Aug 20 18:46 /usr/lib/x86_64-linux-gnu/libfastcgipp.so.3.1 |
The remote machine:
489688 Aug 31 16:50 /usr/lib/x86_64-linux-gnu/libfastcgipp.so.3.1 |
Folders has been downloaded from github and have the same size on both machines.
Yes, I recompiled my program, but I also tried to run old compiled file.
I have reinstalled the library after that, but the problem is still there.
It's funny - it worked fine all previous days. :))
It seems the server has two versions of the library:
/usr/lib/x86_64-linux-gnu/libfastcgipp.so /usr/lib/x86_64-linux-gnu/libfastcgipp.so.3 /usr/lib/x86_64-linux-gnu/libfastcgipp.so.3.1 /usr/local/lib/libfastcgipp.so /usr/local/lib/libfastcgipp.so.3 /usr/local/lib/libfastcgipp.so.3.1 |
The local machine has just one:
/usr/lib/x86_64-linux-gnu/libfastcgipp.so /usr/lib/x86_64-linux-gnu/libfastcgipp.so.3 /usr/lib/x86_64-linux-gnu/libfastcgipp.so.3.1 |
Should I remove the second one (/usr/local/lib/libfastcgipp.so.3.1) from the remote server?
Last edited on
Usually
Question is, how did you end up with
Files in
Probably you want to understand that reason before removing the file...
/usr/local/lib is for libraries that were installed "locally" by the administrator and that are not managed by the package manager, whereas /usr/lib is for libraries that are considered to be a part of the operating system (distribution) and that are managed by the package manager. The purpose of a separate directory /usr/local/lib is to avoid clashes with the system-provided libraries.Question is, how did you end up with
/usr/local/lib/libfastcgipp.so in the first place?Files in
/usr/local/lib don't show up spontaneously. They have to be installed, often as a result of building some libraries on your local machine and then do a make install at the end. So, there should be a reason why this file exists. Obviously, somebody installed it.Probably you want to understand that reason before removing the file...
Last edited on
| kigar wrote: |
|---|
| Files in /usr/local/lib don't show up spontaneously. They have to be installed |
This library has some variants of installation - for ex. basic built and basic+PostgreSQL built. Firstly was installed basic built only. Probably this is the answer.
Also the basic built does not require c++20. I still can run apps for basic built. SQL built requires c++20 for std::chrono time stamps. Standard g++ version for Debian 11 is - 10. I forced to install g++-13 to make install of the SQL built. Here may be a weak link.
Looks like this lib has been switched to "basic build" mode itself without any notice. But how it is possible?
I even changed CMAKE_INSTALL_LIBDIR:PATH=lib/x86_64-linux-gnu in the CMakeCache.txt and reinstalled the lib (stupid attempt). But the problem is still actual.
Thinking to remove the library to install the SQL built from scratch. Unfortunately, the developer did not provide "make uninstall" command.
Last edited on
Ok, it's done and works again. I've made the following steps:
1. All the library's related folders and files were erased;
2. g++ was globally switched to the last version by "update-alternatives". Detailed info see here: https://askubuntu.com/questions/26498/how-to-choose-the-default-gcc-and-g-version;
3. The installation itself.
Thank you! :))
1. All the library's related folders and files were erased;
2. g++ was globally switched to the last version by "update-alternatives". Detailed info see here: https://askubuntu.com/questions/26498/how-to-choose-the-default-gcc-and-g-version;
3. The installation itself.
Thank you! :))
| Looks like this lib has been switched to "basic build" mode itself without any notice. But how it is possible? |
I don't know. But keep in mind that files in
/usr/lib (or, more generally, all files in /usr except for the /usr/local sub-tree) are installed/updated by the system's package manager. Updates can occur in an automated way, e.g. via Cronjob.That's why you install programs and libraries that you have built yourself, or that you want to install "locally" without using the package manager, into
/usr/local, so that they won't interfere with the system-provided libraries/programs.Also note:
https://renenyffenegger.ch/notes/Linux/fhs/etc/ld_so_conf
Last edited on
| kigar64551 wrote: |
|---|
| But keep in mind... |
Thank you.
btw, I hope there will no surprises anymore.
Topic archived. No new replies allowed.