search for: pthread_onc

...daemons, as well as user applications such as smbclient) i get a screen full of errors. Everything so far seems to be working, but the errors are a bit disturbing. Here is a sample of the messages: /usr/local/samba/bin/smbclient:/usr/local/kerberos/lib/libcom_err.so.3.0: undefined symbol 'pthread_once' /usr/local/samba/bin/smbclient: /usr/local/kerberos/lib/libcom_err.so.3.0: can't resolve reference 'pthread_once' /usr/local/samba/bin/smbclient:/usr/local/kerberos/lib/libkrb5support.so.0.0: undefined symbol 'pthread_once' /usr/local/samba/bin/smbclient: /usr/local/ke...

...U tools. However, when extensively using the DotGNU tools I get this error message: make[1]: Entering directory `/home/hb/projects/build/LLVM/pnet-1-1/samples' ../ilasm/ilasm -o evenodd.exe /home/hb/projects/src/pnet-1/pnet-0.7.0/samples/evenodd.il ERROR: Program used external function 'pthread_once' which could not be resolved! lli(_ZN85_GLOBAL__N__home_hb_projects_src_llvm_1_llvm_lib_System_Signals.cpp_17E02520_F7D322F615PrintStackTraceEv+0x1f)[0x835c40f] /lib/tls/libc.so.6(abort+0x1d2)[0x201302] lli[0x8116dbb] make[1]: *** [evenodd.exe] Aborted The 'pthread_once' is located i...

On Thu, 2005-07-07 at 13:52 +0200, Henrik Bach wrote: > make[1]: Entering directory `/home/hb/projects/build/LLVM/pnet-1-1/samples' > ../ilasm/ilasm -o evenodd.exe > /home/hb/projects/src/pnet-1/pnet-0.7.0/samples/evenodd.il > ERROR: Program used external function 'pthread_once' which could not be > resolved! > lli(_ZN85_GLOBAL__N__home_hb_projects_src_llvm_1_llvm_lib_System_Signals.cpp_17E02520_F7D322F615PrintStackTraceEv+0x1f)[0x835c40f] > /lib/tls/libc.so.6(abort+0x1d2)[0x201302] > lli[0x8116dbb] > make[1]: *** [evenodd.exe] Aborted > > The...

On Thu, 7 Jul 2005, Henrik Bach wrote: > The 'pthread_once' is located in the native library binary file: > /usr/lib/libpthread.a. I've also included the path to the library in > LLVM_LIB_SEARCH_PATH environment variable. If libpthread.a is a static library, lli won't be successful loading it. Try relinking lli, but add this to its t...

>From: Chris Lattner >Date: Thu, 7 Jul 2005 11:26:48 -0500 (CDT) > >On Thu, 7 Jul 2005, Henrik Bach wrote: >>The 'pthread_once' is located in the native library binary file: >>/usr/lib/libpthread.a. I've also included the path to the library in >>LLVM_LIB_SEARCH_PATH environment variable. > >If libpthread.a is a static library, lli won't be successful loading it. >Try relinking lli, but...

On Thu, 7 Jul 2005, Henrik Bach wrote: >> TOOLLINKOPTS := -lpthread > > There is both a static (.a) and dynamic (.so) version of the library. The > above advise worked for the static library. However, I think it is more > convenient to use the dynamic version. How do I achieve that? lli -load /path/to/libpthread.so foo.bc -Chris -- http://nondot.org/sabre/

...from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr.h:132: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr-default.h:100:68: error: weakref declaration must have internal linkage extern __typeof(pthread_once) __gthrw_pthread_once __attribute__ ((__weakref__("pthread_once"))); In one of the development phorums, I found somebody saying that LLVM does not support gcc 4.1 libraries. Is that true? If yes, which libraries should I use, in case I would like to use llvm 2.9? Regards, Dm...

...ite a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. TSan already supports pthread_once and dispatch_once by having interceptors that re-implement the logic. However, doing the same for call_once/__call_once doesn't work, because call_once is explicitly supposed to be exception-safe, but the sanitizer runtime libraries disallow exception handling. Any ideas how to handle call_o...

...100 +++ b/extras/mini-os/include/posix/pthread.h Thu May 22 16:08:29 2008 +0100 @@ -1,18 +1,56 @@ #ifndef _POSIX_PTHREAD_H #define _POSIX_PTHREAD_H +#include <stdlib.h> + /* Let''s be single-threaded for now. */ -typedef void *pthread_key_t; -typedef struct {} pthread_mutex_t, pthread_once_t; +typedef struct { + void *ptr; +} *pthread_key_t; +static inline int pthread_key_create(pthread_key_t *key, void (*destr_function)(void*)) +{ + *key = malloc(sizeof(**key)); + (*key)->ptr = NULL; + return 0; +} +static inline int pthread_setspecific(pthread_key_t key, const void...

...ptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. >> >> TSan already supports pthread_once and dispatch_once by having interceptors that re-implement the logic. However, doing the same for call_once/__call_once doesn't work, because call_once is explicitly supposed to be exception-safe, but the sanitizer runtime libraries disallow exception handling. >> >> Any ideas ho...

I'm learning the xray library and try if it can be built on windows, in xray_fdr_logging_impl.h line 152 , comment written as // Using pthread_once(...) to initialize the thread-local data structures but at line 175, 183, code written as thread_local pthread_key_t key; // Ensure that we only actually ever do the pthread initialization once. thread_local bool UNUSED Unused = [] { new (&TLSBuffer) ThreadLocalData(); auto res...

...11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. >>>> >>>> TSan already supports pthread_once and dispatch_once by having interceptors that re-implement the logic. However, doing the same for call_once/__call_once doesn't work, because call_once is explicitly supposed to be exception-safe, but the sanitizer runtime libraries disallow exception handling. >>>> >>>&...

...ND_HAS_NO_EHA_FLAG - Failed -- Performing Test LIBUNWIND_HAS_NO_GR_FLAG -- Performing Test LIBUNWIND_HAS_NO_GR_FLAG - Failed -- Performing Test LIBUNWIND_HAS_STD_CXX11 -- Performing Test LIBUNWIND_HAS_STD_CXX11 - Success -- Looking for dladdr in dl -- Looking for dladdr in dl - found -- Looking for pthread_once in pthread -- Looking for pthread_once in pthread - found -- Failed to locate sphinx-build executable (missing: SPHINX_EXECUTABLE) -- Linker detection: LLD -- Looking for fopen in c -- Looking for fopen in c - found -- Performing Test LIBCXXABI_HAS_NODEFAULTLIBS_FLAG -- Performing Test LIBCXXABI_...

...for __arm__ -- Looking for __arm__ - not found -- Looking for __USING_SJLJ_EXCEPTIONS__ -- Looking for __USING_SJLJ_EXCEPTIONS__ - not found -- Looking for __ARM_DWARF_EH__ -- Looking for __ARM_DWARF_EH__ - not found -- Looking for dladdr in dl -- Looking for dladdr in dl - not found -- Looking for pthread_once in pthread -- Looking for pthread_once in pthread - not found -- Performing Test LIBUNWIND_SUPPORTS_WERROR_EQ_RETURN_TYPE_FLAG -- Performing Test LIBUNWIND_SUPPORTS_WERROR_EQ_RETURN_TYPE_FLAG - Failed -- Performing Test LIBUNWIND_SUPPORTS_W_FLAG -- Performing Test LIBUNWIND_SUPPORTS_W_FLAG - Faile...

...- Performing Test LIBCXXABI_HAS_NODEFAULTLIBS_FLAG -- Performing Test LIBCXXABI_HAS_NODEFAULTLIBS_FLAG - Success -- Performing Test LIBCXXABI_HAS_NOSTDINCXX_FLAG -- Performing Test LIBCXXABI_HAS_NOSTDINCXX_FLAG - Success -- Looking for dladdr in dl -- Looking for dladdr in dl - found -- Looking for pthread_once in pthread -- Looking for pthread_once in pthread - found -- Looking for __cxa_thread_atexit_impl in c -- Looking for __cxa_thread_atexit_impl in c - found -- Performing Test LIBCXXABI_SUPPORTS_WERROR_EQ_RETURN_TYPE_FLAG -- Performing Test LIBCXXABI_SUPPORTS_WERROR_EQ_RETURN_TYPE_FLAG - Success --...

...nown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/x86_64-unknown-linux-gnu/bits/gthr.h:114: /usr/local/gcc-4.1/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/x86_64-unknown-linux-gnu/bits/gthr-default.h:88:1: error: weakref declaration must have internal linkage __gthrw(pthread_once) ^ /usr/local/gcc-4.1/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/x86_64-unknown-linux-gnu/bits/gthr-default.h:71:23: note: instantiated from: #define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name) ^ /usr/local/gcc-4.1/lib/gcc/x86_64-unknown-linux...

...gmail.com> wrote: > > On 17 Nov 2017, at 00:44, comic fans via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > I'm learning the xray library and try if it can be built on windows, in > xray_fdr_logging_impl.h > > line 152 , comment written as > // Using pthread_once(...) to initialize the thread-local data structures > > > but at line 175, 183, code written as > > thread_local pthread_key_t key; > > // Ensure that we only actually ever do the pthread initialization once. > thread_local bool UNUSED Unused = [] { > new (&TLSB...

https://bugzilla.mindrot.org/show_bug.cgi?id=2107 Bug ID: 2107 Summary: seccomp sandbox breaks GSSAPI Classification: Unclassified Product: Portable OpenSSH Version: 6.2p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: Kerberos support

...ction. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. >>>>>> >>>>>> TSan already supports pthread_once and dispatch_once by having interceptors that re-implement the logic. However, doing the same for call_once/__call_once doesn't work, because call_once is explicitly supposed to be exception-safe, but the sanitizer runtime libraries disallow exception handling. >>>>>> >&...

On 2018-04-07 11:24, Bernard Spil wrote: > On 2018-04-07 9:04, Joel Sing wrote: >> On Friday 06 April 2018 21:31:01 Bernard Spil wrote: >>> Hi, >>> >>> When using OpenSSH with LibreSSL 2.7.x it cannot read existing RSA >>> and >>> ECDSA private keys. >>> >>> Error loading key "./id_rsa": invalid format