produces broken binary: Inconsistency detected by ld.so [regression gcc-7 7.3.0-15ubuntu2 => 7.3.0-16ubuntu2]

Note that Debian's 7.3.0-16 works fine too.

Installing 16ubuntu2 in the Debian container makes it fail there too, so it seems highly likely that whatever is different between 16 and 16ubuntu2 is the cause

Summary of bisecting:

15ubuntu1 good
15ubuntu2 good
16 good
16ubuntu2 bad

Also:

jak@jak-t480s:~/Projects/Ubuntu/adequate-0.15.1ubuntu5/tests/testpkg$ ldd /home/jak/Projects/Ubuntu/adequate-0.15.1ubuntu5/tests/testpkg/debian/tmp-15u2/libadequate-test-versionless.so.0
        linux-vdso.so.1 (0x00007fff3bbfb000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f92bab2a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f92bb11d000)
jak@jak-t480s:~/Projects/Ubuntu/adequate-0.15.1ubuntu5/tests/testpkg$ ldd /home/jak/Projects/Ubuntu/adequate-0.15.1ubuntu5/tests/testpkg/debian/tmp-16u2/libadequate-test-versionless.so.0
        statically linked

there are almost no changes between 16 and 16ubuntu2. Are you sure that 16 is good? There might be a related problem reported as Debian #896012, but that is reported with 16.

the output of the link command run with -v would probaböy help, as well as the contents of the linker scripts

there's agcc-7 test build building in ppa:doko/toolchain. please check this as well.

Here's the output of gcc -v -shared -Wl,--soname=libadequate-test-versionless.so.0 lib.c with the PPA build, does not seem to help.

Here's the output with 15ubuntu2 which is working.

The lib.c is just:

void this_symbol_might_be_undefined(void)
{ }

#if !defined(ADEQUATE_SYMBOL_SIZE)
#define ADEQUATE_SYMBOL_SIZE 37
#endif
char this_symbol_size_varies[ADEQUATE_SYMBOL_SIZE];

the version script is:

ADEQUATE_TEST {
  global: *;
};

and undef.c, which is linked against the first build with versioning is:

extern void this_symbol_might_be_undefined(void);

int main(int argc, char **argv)
{
        this_symbol_might_be_undefined();
        return 0;
}

But in any case what's broken is the unversioned build - it does not even register as dynamically linked in ldd...

Status changed to 'Confirmed' because the bug affects multiple users.

i have the same(?) problem in ubuntu 18.10 starting sweethome3d
https://bugs.launchpad.net/ubuntu/+source/sweethome3d/+bug/1797920

I am experiencing this issue when trying to start Terasology with OpenJDK 11.

java --version

openjdk 11.0.1 2018-10-16
OpenJDK Runtime Environment (build 11.0.1+13-Ubuntu-3ubuntu3.18.10.1)
OpenJDK 64-Bit Server VM (build 11.0.1+13-Ubuntu-3ubuntu3.18.10.1, mixed mode, sharing)

I also have this problem when trying to run Neuroph, I get the below error

Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!

I ran into a similar issue with Eclipse crashing (exit code 127) with this error in the console:

> Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!

The crash happens consistently with Ubuntu's OpenJDK 11 JVM, but not with another JVM, for example AdoptOpenJDK's.

Crashing JVM
$ /usr/lib/jvm/java-11-openjdk-amd64/bin/java -version
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3)
OpenJDK 64-Bit Server VM (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3, mixed mode, sharing)

Not crashing JVM
$ /usr/local/lib/jvm/java-11-openjdk-amd64/bin/java -version
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.4+11, mixed mode)

The issue seems to be a duplicate of https://bugs.launchpad.net/ubuntu/+source/openjdk-lts/+bug/1838740

The https://bugs.launchpad.net/ubuntu/+source/openjdk-lts/+bug/1838740 (comment #1) contains a simple Java program to reproduce the problem.