similar to: [LLVMdev] Something wrong with my libpthread.so

Hi, On Sat, Oct 31, 2009 at 11:42 AM, Nan Zhu <zhunansjtu at gmail.com> wrote: > Hi,all > > I tried to run the generated whole-program bitcode of BIND,but I got some > information: > > 0   lli             0x0000000000feda16 > 1   lli             0x0000000000fed88f > 2   libpthread.so.0 0x0000003df340eee0 > 3   libc.so.6       0x0000003df28332f5 gsignal + 53 >

Mahadevan R wrote: > Hi, > > On Sat, Oct 31, 2009 at 11:42 AM, Nan Zhu <zhunansjtu at gmail.com> wrote: >> Hi,all >> >> I tried to run the generated whole-program bitcode of BIND,but I got some >> information: >> >> 0 lli 0x0000000000feda16 >> 1 lli 0x0000000000fed88f >> 2 libpthread.so.0

I have a question about module-level METADATA_BLOCKs in the bitcode. There are currently two blocks with the METADATA_BLOCK id at module scope. The first has the module-level metadata values (consisting of some combination of METADATA_* record codes except for METADATA_KIND). The second consists only of METADATA_KIND records. The latter is used only in the METADATA_ATTACHMENT block within function

The XCB developers have introduced a new library, libpthread-stubs. This library provides weak aliases for pthread functions not provided in libc or otherwise available by default. Libraries like libxcb rely on pthread stubs to use pthreads optionally, becoming thread-safe when linked to libpthread, while avoiding any performance hit when running single-threaded. libpthread-stubs supports this

I compile Samba for the first time on LINUX (SLES 10) and have a weird libpthread warning message. I dug the list to find some explanations about the way I have to handle this problem, without success. Below are the 'configure' parameters and the part of config.log about libpthread. Is there a way to not link libpthread to avoid this performance degradation ? What must I do with this

> That worked, but I do get a few linking warnings. Are these serious? > > /usr/lib/libc.so.4: WARNING! setkey(3) not present in the system! > /usr/lib/libc.so.4: warning: this program uses gets(), which is unsafe. > /usr/lib/libc.so.4: warning: mktemp() possibly used unsafely; consider using mkstemp() > /usr/lib/libc.so.4: WARNING! des_setkey(3) not present in the system!

It appears that Mingw gcc included in RTools is missing a dependent library. If I compile a program with '-lgomp' switch (for OpenMP support), I get a errors about undefined references to functions like '_imp__pthread_mutex_destroy'. Adding the '-static' switch, I get the following error: c:/rtools/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe:

This project provides a a pkg-config [.pc] file, pthread-stubs.pc, which provides the necessary flags for the given platform to link with the most lightweight implementation of the POSIX threads functions for that platform which is known to work with the XCB family of libraries. This release mainly affects the build & distribution process - the primary change to the installed contents is the

I just installed EMC PowerPath 5.0.0 and Navisphere Agent and CLI on a CentOS 4.4/x86_64 system. When I try to start naviagent, I get the error below. Before upgrading to CentOS4.4, this same system had RHEL3 ES for x86_64 on it, and the same problem was encountered. I spent weeks going back and forth with EMC tech support, but the problem was never resolved. I'm hoping someone here on this

Heres a question for anyone awake at this hour, does icecast2 require libpthread? I'm trying to build it on a freebsd 4.3 box, and it wants to link against libpthread. If this is not required on the freebsd platform, then is it safe to just take out of the makefile? Thanks Mike -- <mystica@darktech.org> --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project

On Mon, 22 Oct 2001 00:07:39 -0600 Jack Moffitt <jack@xiph.org> wrote: > It needs pthreads. FreeBSD provides this in the reentrant c library. > > For FreeBSD, you should remove -lpthread from LIBS and add -pthread to > CFLAGS. I believe this should be the only change required. > > I will fix FreeBSD building in the next few days (or at least this is my > intention)

Hi Jan, > I've been looking into how to make llvm bitcode files smaller. There is one > simple change that appears to shrink linked bitcode files by about 15%. See > this spreadsheet for some rough data: > > https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E the improvement is wonderful! ... > In any case, the patch is attached if

Hi all, I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E The change is in how operand ids are encoded in bitcode files. Rather than use an "absolute

http://bugs.freedesktop.org/show_bug.cgi?id=14597 Summary: randr12 failures on 12" powerbooks, and workarounds Product: xorg Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org