missing ones are libsupport, libsystem and libvmcore. libvmcore is
currently blocked on bugpoint, which uses EH. Once it stops using
EH, we can switch it off.
This #if 0's out 3 unit tests, because gtest requires RTTI information.
Suggestions welcome on how to fix this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94164 91177308-0d34-0410-b5e6-96231b3b80d8
In the latest binutils the plugin-api.h needs this - without
it the LLVM gold plugin fails to compile.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84861 91177308-0d34-0410-b5e6-96231b3b80d8
This is conventional command-line tool behavior. -f now just means
"enable binary output on terminals".
Add a -f option to llvm-extract and llvm-link, for consistency.
Remove F_Force from raw_fd_ostream and enable overwriting and
truncating by default. Introduce an F_Excl flag to permit users to
enable a failure when the file already exists. This flag is
currently unused.
Update Makefiles and documentation accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79990 91177308-0d34-0410-b5e6-96231b3b80d8
instead of as two bools. Use this to add a F_Append flag
which has the obvious behavior.
Other unrelated changes conflated into this patch:
1. REmove EH stuff from llvm-dis and llvm-as, the try blocks
are dead.
2. Simplify the filename inference code in llvm-as/llvm-dis,
because raw_fd_ostream does the right thing with '-'.
3. Switch machine verifier to use raw_ostream instead of ostream
(Which is the thing that needed append in the first place).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79807 91177308-0d34-0410-b5e6-96231b3b80d8
an existing file is considered an error. Convert several tools
to use raw_fd_ostream instead of std::ostream, and to use this
new option instead of doing a manual check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75801 91177308-0d34-0410-b5e6-96231b3b80d8
Windows variant, strerror_s, but I couldn't test that.
I'll update configure and config.h.in in a subsequent patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74621 91177308-0d34-0410-b5e6-96231b3b80d8
Look for as in the path. Doing it here instead
of llvm-gcc because llvm-gcc has nothing as
convenient as sys::Program::FindProgramByName.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73383 91177308-0d34-0410-b5e6-96231b3b80d8
run when assembling.
Wire this up to the gold plugin. You can now pass --plugin-opt gcc=/foo/bar/gcc
and it will run that gcc instead of looking for it on the path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70490 91177308-0d34-0410-b5e6-96231b3b80d8
with the rest of the parallel directories.
Build lto when possible on all platforms. Make gold to explicitly depend on
libLTO.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@65518 91177308-0d34-0410-b5e6-96231b3b80d8
list that can in turn be passed to -internalize pass through
-internalize-public-api-file.
Pass gold -plugin-opt=generate-api-file to produce "apifile.txt" in the current
directory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@65295 91177308-0d34-0410-b5e6-96231b3b80d8
Before this change, the program:
int var;
int main(void) { return 0; }
when run under 'nm -g' would show 'U var' with the gold plugin and
'B var' with gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64616 91177308-0d34-0410-b5e6-96231b3b80d8
really solve the problem. Also it changed the
name from libLLVMgold to LLVMgold (correcting
the name resulted in the original problem
suddenly reappearing).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63861 91177308-0d34-0410-b5e6-96231b3b80d8
dependencies between libraries due to __dso_handle
when doing "make install". I don't know what the
LINK_COMPONENTS stuff is about, so I left it alone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63860 91177308-0d34-0410-b5e6-96231b3b80d8
