[Solved] undefined symbol: acs_map

[GNUser]

Linux applications generally have good forward compatibility (i.e., they work with newer versions of kernel and linked libraries including glibc).

Lately (since upgrading from TCL14 x86_64 to TCL15 x86_64) I've noticed that sometimes when Juanito updates a library, an application that uses that library will fail with "undefined symbol: acs_map". As an example, a recent update to libnl.tcz broke bmon.tcz:

Code: [Select]

bmon: symbol lookup error: bmon: undefined symbol: acs_map

The fix is to recompile the application. (I've submitted recompiled bmon.tcz for TCL15 x86_64 repo but it hasn't posted yet, so you can still reproduce the error.)

I have two questions for you guys:

1. What causes this "undefined symbol: acs_map" error? I'd like to understand the cause.

2. Is there a compilation flag that we can use to prevent this general sort of error, so that the applications we compile have more robust forward compatibility?

[Paul_123]

A cursory google search shows that acs_map is an ncusrses symbol.   ncurses libraries are problematic for some programs configure scripts to find everything properly.

[GNUser]

If that's true, the plot thickens: ncurses was not updated recently, so cannot have been responsible for breaking bmon.

Here is the full story: bmon was working, I updated my system (only opus.tcz and libnl.tcz were updated), I rebooted, then bmon started erroring-out with the acs_map error.

Recompiling bmon fixed the problem, as I mentioned above. So I know the solution, just trying to understand the issue now.

[Juanito]

The problem was created by the update ncurses-6.3 to ncurses-6.4 - I had to recompile six or eight extensions because of it, but it didn't affect all extensions with a dep on ncursesw.

As much as I know, if the break in the ncurses abi had been intentional, the symlink libncursesw.so.6 would have been changed to something else.

The above being said, autotools and cmake builds have a lot of problems with ncurses because they don't use pkgconfig to detect ncurses, but rely on various manual methods instead (the ncurses pkgconfig files are not installed by default). In contrast, meson builds use pkgconfig and seem to have more success with ncurses.

[GNUser]

I see. So this is an  unintentional break in ncurses abi.

Also, I had noticed that some applications that depend on ncurses are difficult to successfully compile. Now I understand why.

I guess the answer to my second question (if there is a special compilation trick to boost forward compatibility) is "no". In other words, if an application is dynamically linked, it will be susceptible to abi changes in libraries and there's nothing we can do about that.

Thanks, Juanito. Topic solved.

[Rich]

Hi GNUser
If you still have your TC14 build environment and want
to try a little experiment:
Edit the Makefile and find  LIBS = -lncursew
Change it to  LIBS = -lncursew -ltinfo
Compile bmon and see if it now runs on TC15.

    [Edit]: Fixed typo. Changed  -llncursew  to  -lncursew.  Rich

[GNUser]

Hi Rich. I still do have a TCL14 build environment. All my TCL environments are x86_64.

In Makefile I could not find LIBS = -llncursew
but I did find LIBS = -lrt -lm
which for our experiment I changed to LIBS = -lrt -lm -llncursew -ltinfo
I then compiled bmon in TCL14 using the tweaked Makefile

Result: bmon works in TCL14 but fails in TCL15 with the same "undefined symbon: acs_map" error.

[Rich]

Hi GNUser
It was a long shot. I fixed a typo in my previous post, but
it would have made no difference. There doesn't appear
to be libtinfo.so any more. I think it was absorbed by
libncursesw.so.

[GNUser]

Thanks, Rich.

BTW I figured out why I thought libnl was the culprit: I only use bmon periodically. I upgraded the machine in question from TCL14 to TCL15 recently, at which point it picked up the new version of ncurses. I guess I didn't test bmon after the upgrade. It seems the first time I used bmon was after the recent libnl upgrade. My blaming libnl for the problem was a classic example of the "post hoc ergo propter hoc" fallacy My falling into this fallacy/trap was almost unavoidable in this case, since libnl is, in fact, a dependency of bmon!

This thread is thoroughly solved

[Rich]

Hi GNUser

... This thread is thoroughly solved

Marked as such.