misc/86029: undefined reference to `_thread_dump_info'

Christopher Sean Morrison brlcad at mac.com
Mon Sep 12 14:20:14 PDT 2005


>Number:         86029
>Category:       misc
>Synopsis:       undefined reference to `_thread_dump_info'
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 12 21:20:13 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Christopher Sean Morrison
>Release:        5.4-RELEASE-p6
>Organization:
BRL-CAD Lead Developer
>Environment:
FreeBSD *.*.*.* 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #0: Wed Sep  7 17:41:09 EST 2005     *@*.*.*.*:/usr/src/sys/amd64/compile/SMP  amd64
>Description:
Compiling code that uses the _thread_dump_info() call that should be in c_r fails with an unresolved symbol reference.  The symbol does show up in an nm of libc_r but c_r is apparently not used when -pthread is passed to the compiler/linker.  This same compilation on an identically configured ia32 freebsd install does not exhibit this same problem.

The code in question is being compiled through libtool which also presumes (as has been documented in the past, yes?) that -pthread takes care of providing -lc_r.  The script specifically tests for -lc_r ldflags and removes them when using -pthread.
>How-To-Repeat:
Compile and link against code that uses _thread_dump_info() using -pthread without manually adding -lc_r.
>Fix:
Manually compiling outside of libtool and adding -lc_r seems to fix the problem.  Similarly, tricking the libtool script by passing a cflag instead of an ldflag works:
make CFLAGS=-Wl,-lc_r
>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list