llvm dev - Jul 2005 - [LLVMdev] External function 'pthread_once' could not be resolved

Hi LLVM'ers,

I'm trying to build the DotGNU project with the LLVM-tools.

After minor modifications of source and build code and some configure 
housekeeping, it seems that I've managed so far to build all the DotGNU 
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 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.

When LLVM tool gccld is linking above program, it doesn't complain that it 
cannot find the function or library.

Any ideas?


============================================================Henrik Bach
LLVM Open Source Developer

e-mail: henrik_bach_llvm at hotmail.com
============================================================'Nothing is
impossible; The impossible just takes longer time :)'
- Inventor of a new energy saver light bulp from Denmark.

No software patents - Thank you Parliment of EU
Got Freedom?
Software Freedom Day - 10th of september
http://www.softwarefreedomday.org/
============================================================
_________________________________________________________________
Log p� MSN Messenger direkte fra nettet  http://webmessenger.msn.com/

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 '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.
is there a .so of this?
> When LLVM tool gccld is linking above program, it doesn't complain that
it
> cannot find the function or library.
The problem is, I believe, that you are running things through the
interpreter.  If you compiled to native code you shouldn't have this
problem.  (If there is a .so of pthreads, try linking with that one).

Andrew

>From: Andrew Lenharth
>Date: Thu, 07 Jul 2005 10:37:53 -0500
>
>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 '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.
>
>is there a .so of this?
Yes.
>
> > When LLVM tool gccld is linking above program, it doesn't complain
that
>it
> > cannot find the function or library.
>
>The problem is, I believe, that you are running things through the
>interpreter.  If you compiled to native code you shouldn't have this
>problem.  (If there is a .so of pthreads, try linking with that one).
The idea is to move the bytecode files between systems and thus have llvm 
backends to compile or interprete these. Hence, I don't want to compile to 
native code, other than what the systems provide through native libraries.

Henrik
>
>Andrew
>
>_______________________________________________
>LLVM Developers mailing list
>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
_________________________________________________________________
F� alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/

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 tools/lli/Makefile:

TOOLLINKOPTS := -lpthread

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/

>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 add this to its tools/lli/Makefile:
>
>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?

Henrik.
>
>-Chris
>
>--
>http://nondot.org/sabre/
>http://llvm.cs.uiuc.edu/
>
>_______________________________________________
>LLVM Developers mailing list
>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
_________________________________________________________________
Undg� pop-ups med MSN Toolbar -  http://toolbar.msn.dk/ hent den gratis!

I am investigating some inlining issue, so I did

llvm-gcc aaa.c bbb.c ... nnn.c -o output
opt -inline -inline-threshold=xxx < output.bc | llc -march=c > 
output_inline.c

1)
I noticed that even if I set xxx to 0 or even a very small negative 
number, many functions are eliminated. I am wondering if these functions 
are inlined by the frontend, or identified as deadcode.

For instance, SPEC2k bzip2 has 79 functions, after these two steps, only 
61 functions are left. no other optimizations are used.

2)
I noticed that the inlining condition (in 
Transforms/IPO/InlineSimple.cpp) is tested during llvm-gcc but not 
during the opt phase ? Can anybody explain what happens during llvm-gcc 
and opt respectively ?


thanks,
--Long