search for: linklibrari

gccld would barf if you tried to specify the full pathname of an archive on the command line to gcc, (e.g., instead of gcc ... -L/full/path/to -lFOO you say gcc ... /full/path/to/libFOO.a) which many GNU Makefiles try to do. This patch fixes that. Ok to commit? -- gaeke at uiuc.edu gccld.cpp: Fix typo in header. Add IsArchive static method. Roll LoadLibraryFromDirectory() into

...xternal libraries generating *only* one executable (all in memory)? Can I invoke externals functions from a guest (LLVM generated) code which exist in the host code (the code that execute the first one)? And a problem: I made a little aplication with use the functions llvm::LinkModules and llvm::LinkLibraries that, I suppouse, exist in libLLVMLinker.a archive, but gcc linker reports 'undefined' errors for this functions. I don't use the makefile system from LLVM because is so complex to incorporate in this point of my work that it isn't usefull at the moment. I use the libraries direct...

...ompiler will resolve symbols within its own executable or dynamically via a loadable plug-in (-load option). Some platforms don't support this currently (Cygwin for example). > > And a problem: > > I made a little aplication with use the functions llvm::LinkModules and > llvm::LinkLibraries that, I suppouse, exist in libLLVMLinker.a archive, that is correct. > but > gcc linker reports 'undefined' errors for this functions. The only thing I can think of is dependencies that libLLVMLinker has. You will probably want a linke line that looks something like: gcc -o my...

Here is a revised patch after some suggestions: 1. Removed extraneous changes (the white space changes that are -/+ whitespace), and the commented out code. 2. Keep the warning for linking dynamic libraries in LinkLibraries.cpp I still don't have a good solution to the problem of -L paths that include bytecode versions of the native libraries we're trying to link. Consider the following situation... A directory in our -L path has a libFoo.so native library that we need to link. It also contains a li...

...ompiler will resolve symbols within its own executable or dynamically via a loadable plug-in (-load option). Some platforms don't support this currently (Cygwin for example). > > And a problem: > > I made a little aplication with use the functions llvm::LinkModules and > llvm::LinkLibraries that, I suppouse, exist in libLLVMLinker.a archive, that is correct. > but > gcc linker reports 'undefined' errors for this functions. The only thing I can think of is dependencies that libLLVMLinker has. You will probably want a linke line that looks something like: gcc -o my...

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached