Precompiled dcmtk-tls raises glibc error on Ubuntu (different versions)

[Markus Sabin]

Dear Dcmtk-Team,

for a self-contained test environment, I have downloaded the statically linked dcmtk-3.6.6 pre-compiled executables with openssl support from the download page (dcmtk-3.6.6-linux-x86_64-static-tls.tar.bz2).
I first "installed" on an Ubuntu-16 virtual machine, i.e. I unpacked the binaries to a test-tools folder. I should mention that we are using this environment for building dcmtk and dcmtk-based software without any issues, including TLS support.

Running a first test - storagescp-tls vs. echoscu-tls:

• storagescp-tls starts and listens on the given port
  echoscu-tls starts and opens TCP connection to the SCP

Upon the SCU connecting, the SCP terminates with the following message:

storescp-tls: dl-call-libc-early-init.c:37: _dl_call_libc_early_init: Assertion `sym != NULL' failed.

Well, Ubuntu16.04 LTS is quite outdated, so it was about time for an update anyway. Updating from v16 to v20 requires an update to v18 as an intermediate step. After update to Ubuntu-18, the problem got worse: The error message written above occurred upon starting echoscu-tls. I used telnet to verify what happens if I connect to the SCP port -> same error as mentioned above.

An update to Ubuntu20.04 LTS did not change this behavior.

Any ideas?

Funny side note: The only hint on the internet on this error was a page in reddit which recommended the use of a packet manager called "pacman" to fix the glibc. I installed pacman and started it as recommended. Guess what happened: A clone of the 70s arcade game started

[Michael Onken]

Hi,

no idea where this comes from. I tried on my (up-to-date) Ubuntu machine and the call you mentioned worked.

I hope someone else comes up with an idea.

Best regards,
Michael

P.S: At least a "bug" causing some fun -- installed pacman as well, thanks for the tip

[J. Riesmeier]

I tested it on my Ubuntu 20.04 (LTS) machine with latest updates and got the following (on SCU side):

Code: Select all

echoscu-tls: dl-call-libc-early-init.c:37: _dl_call_libc_early_init: Assertion `sym != NULL' failed.
Aborted (core dumped)

Here is the --version output:

Code: Select all

$dcmtk: echoscu v3.6.6 2021-01-14 $

echoscu: DICOM verification (C-ECHO) SCU

Host type: x86_64-Linux
Character encoding: UTF-8

External libraries used:
- ZLIB, Version 1.2.11
- OpenSSL 1.1.1f  31 Mar 2020

When sending the C-ECHO Request from echoscu (no TLS), the storescp-tls "core dumps":

Code: Select all

storescp-tls: dl-call-libc-early-init.c:37: _dl_call_libc_early_init: Assertion `sym != NULL' failed.
Aborted (core dumped)

[Markus Sabin]

@Michael, Jörg: Thank you very much for sharing your experience!

I really needed to solve the "root problem" urgently, which is that I need a self-contained distributable set of TLS test tools. So I gave the precompiled static binaries of the V3.6.5 release a try. They work fine on both, Ubuntu 16 and 20. As they will only be used for testing purposes, it is not a problem that they are linking to an older version of openssl.

So my problem is now somehow solved. Just want to let you know my further observations in case they are useful for debugging.

[Michael Onken]

Thank you for reporting!

We are trying to fix this anyway, of course, and let you know if/once there are updated binaries.

Best regards,
Michael

[Marco Eichelberg]

This is just a guess, but I believe that even statically linked binaries on Linux will load some glibc code from shared objects (I think the linker warns about this).
The name of the error location (dl-call-libc-early-init.c) seems to indicate that the error is related to the loading of libc code from a dynamic library (shared object), which would confirm that guess.
Probably this simply means that the static DCMTK 3.6.6 binaries are not compatible anymore with the glibc on your (older) Ubuntu installation. If that is correct, simply compiling the code on your own should fix the problem.

[Markus Sabin]

Yes Marco, that is what I was thinking as well. But I would have expected that updating to the latest LTS version of Ubuntu would do the trick, which it did not. Unfortunately ldd does not show me any dynamically linked libraries for these executables.