included when using global symbols to ask the linker for the addresses of
various functions. One of the symbols was actually getting declared by a
header included in DynamicLibrary.cpp, which conflicted with the "extern void*"
declaration in SearchForAddressOfSpecialSymbol().
llvm-svn: 98243
DynamicLibrary::SearchForAddressOfSymbol and force them to have "C"
linkage.
Interestingly, GCC treats the block-scoped "extern" declarations we
previously had as if they were extern "C" declarations (or, at least,
were in the global namespace), so that GCC bug papered over this LLVM
bug. Clang and EDG get the linkage correct; this new variant seems to
work for both GCC and Clang.
llvm-svn: 92020
This fixes PR4512 and eliminating static ctors is always good. Losing
thread safety is unfortunate, but the code is just incredibly poorly
designed.
If someone is interested, the "right" solution is to split
DynamicLibrary.cpp into two separate pieces: a stateless piece in
libsystem, and a simple support file in libsupport that has the
"state" (e.g. AddSymbol) in managed static objects.
Doing this would both fix memory leaks we already have, as well as make
the code thread safe again. it would also make sense to move all the
unix specific code in System/DynamicLibrary.cpp into
System/Unix/DynamicLibrary.inc.
llvm-svn: 74927
I did my best at implementing this for Win32, but I don't have a way to test it.
Can someone with access to a Win32 machine test/fix this?
llvm-svn: 74188
LoadLibraryPermanently. The current code modifies the value of a pointer
that is passed by value, so the caller never gets the message.
Patch by Julien Lerouge!
llvm-svn: 48270
Owen Anderson
Chris Lattner
Dan Gohman
Jeffrey Yasskin
Douglas Gregor
Chandler Carruth
Torok Edwin
Duncan Sands
Devang Patel
Anton Korobeynikov