search for: _dl_close

I get the errors: zip4_lnx.a(generic.o)(.text+0xb16): more undefined references to `__ctype_b' follow zip4_lnx.a(libdl.so): undefined reference to `_dl_close at GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_catch_error at GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_addr at GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_versioned_symbol_skip at GLIBC_2.0' zip4_lnx.a(libdl.so): undefined...

...==15093== by 0x285A3BD1: __tcf_5 (DwarfDebug.cpp:85) ==15093== by 0x441867: __cxa_finalize (in /lib/tls/libc-2.3.4.so) ==15093== by 0x282212F2: (within libCORTEXA9MP.mx_DBG.so) ==15093== by 0x28EEBB05: (within libCORTEXA9MP.mx_DBG.so) ==15093== by 0x518C41: _dl_close (in /lib/tls/libc-2.3.4.so) ==15093== by 0x56DD59: dlclose_doit (in /lib/libdl-2.3.4.so) ==15093== by 0x40966D: _dl_catch_error (in /lib/ld-2.3.4.so) ==15093== by 0x56E2BA: _dlerror_run (in /lib/libdl-2.3.4.so) ==15093== by 0x56DD89: dlclose (in /lib/libdl-2.3.4....

...ke `doveadm purge`. Do you need any more information to reproduce and fix this? Florian backtrace: > 0x00007ffff5eaf1e0 in pthread_mutex_unlock () from /usr/lib/libpthread.so.0 > #0 0x00007ffff5eaf1e0 in pthread_mutex_unlock () from /usr/lib/libpthread.so.0 > #1 0x00007ffff7def753 in _dl_close_worker () from /lib64/ld-linux-x86-64.so.2 > #2 0x00007ffff7defede in _dl_close () from /lib64/ld-linux-x86-64.so.2 > #3 0x00007ffff7dea124 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 > #4 0x00007ffff6d235e1 in ?? () from /usr/lib/libdl.so.2 > #5 0x00007ffff6d230bf in dlc...

...Arch Linux with an updated glibc version, I doubt the problem is with Dovecot's code. >> 0x00007ffff5eaf1e0 in pthread_mutex_unlock () from /usr/lib/libpthread.so.0 >> #0 0x00007ffff5eaf1e0 in pthread_mutex_unlock () from /usr/lib/libpthread.so.0 >> #1 0x00007ffff7def753 in _dl_close_worker () from /lib64/ld-linux-x86-64.so.2 >> #2 0x00007ffff7defede in _dl_close () from /lib64/ld-linux-x86-64.so.2 >> #3 0x00007ffff7dea124 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 >> #4 0x00007ffff6d235e1 in ?? () from /usr/lib/libdl.so.2 >> #5 0x00007ff...

I get the errors: zip4_lnx.a(generic.o)(.text+0xb16): more undefined references to `__ctype_b' follow zip4_lnx.a(libdl.so): undefined reference to `_dl_close at GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_catch_error at GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_addr at GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_versioned_symbol_skip at GLIBC_2.0' zip4_lnx.a(libdl.so): undefined...

Inconsistency detected by ld.so: dl-close.c: 736: _dl_close: Assertion `map->l_init_called' failed!

Rick Sullivan <ricks at carbondesignsystems.com> writes: [snip] > The problem is this. For some simulations, the LLVM shared library > seems to take a segfault on exit. It runs correctly, but when the > simulator finishes, it crashes on exit. [snip] > > Does anybody have any ideas as to why this might be happening? Can you run the application under gdb and obtain a

We're using the LLVM 3.3 AArch64 disassembler in the following way. We have built LLVM 3.3 on Linux as a shared library; and have a main program that dynamically loads shared objects (.so libraries). The program is a simulator (though that shouldn't be relevant to this question), and the shared objects it loads are electronic components that participate in the simulation. If the electronic