Without this common features like off_t and strdup are missing.
This should bring back those bots.
Configure bits by Meador Inge.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203701 91177308-0d34-0410-b5e6-96231b3b80d8
The shared library generated by autoconf will now be called
libLLVM-$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_PATCH)$(VERSION_SUFFIX).so
and a symlink named
libLLVM-$(VERSION_MAJOR).$(VERSION_MINOR)$(VERSION_SUFFIX).so will
also be created in the install directory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202720 91177308-0d34-0410-b5e6-96231b3b80d8
baseline is now C++11, and we unconditionally add -std=c++11 to the
flags.
This has the dim potential to break some non-GNU-compatible compiler (in
terms of -std flags) using the makefiles, but those makefiles are
littered with GNU-style compile flags so it would be very surprising to
me for it to actually happen in practice. As always, do let me know if
there is a toolchain you're using where this doesn't work, and I'll be
watching the bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202569 91177308-0d34-0410-b5e6-96231b3b80d8
This centralizes the Makefile handling of -install_name and -rpath. It also
moves the cmake build to using @rpath. The reason being that libclang needs it,
and it works for everything else.
A followup patch will move clang to using this and then there will be a single
point to edit to support other systems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202499 91177308-0d34-0410-b5e6-96231b3b80d8
Teach the Makefile build system to generate and install CMake modules
LLVMConfig.cmake and LLVMConfigVersion.cmake so that applications that
build with CMake can use 'find_package(LLVM)' even when LLVM is not
built with CMake. These modules tell such applications about available
LLVM libraries and their dependencies.
Run llvm-config to generate the list of libraries and use the results of
llvm-build to generate the library dependencies. Use sed to perform
substitutions in the LLVMConfig.cmake.in and LLVMConfigVersion.cmake.in
sources that our CMake build system uses.
Teach the Makefile build system to generate the LLVMExports.cmake file
with content similar to that produced by the CMake install(EXPORT)
command. Extend llvm-build with an option to generate the library
dependencies fragment for this file.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201053 91177308-0d34-0410-b5e6-96231b3b80d8
This reduces the size of clang-format from 22 MB to 1.8 MB, diagtool goes from
21 MB to 2.8 MB, libclang.so goes from 29 MB to 20 MB, etc. The size of the
bin/ folder shrinks from 270 MB to 200 MB.
Targets that support plugins and don't already use EXPORTED_SYMBOL_FILE
(which libclang and libLTO already do) can set NO_DEAD_STRIP to opt out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198087 91177308-0d34-0410-b5e6-96231b3b80d8
subdirectories. The only thing needed here is to create the appropriate
object file directories and add those as dependencies for the
compilation rules.
As a consequence, factor the non-source-file-specific dependencies for
compilation rules into a helper variable. This fixes an issue where the
project makefile wasn't actually a dependency of a bunch of compilation
make rules for no apparant reason.
This should have no observable effect for current makefile usage, but
will simplify how we build other libraries and is something CMake
already supports.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194753 91177308-0d34-0410-b5e6-96231b3b80d8
Back in r140220 we removed the autoconf code that would set LLVMCC_OPTION
since it was only used by the test-suite. This patch now removes code
that would only be used if LLVMCC_OPTION was set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187154 91177308-0d34-0410-b5e6-96231b3b80d8
This kind of simplification is sometimes useful, but in general it's not correct.
As GNU/kFreeBSD is an hybrid system, for kernel-related issues we want to match the
build definitions used for FreeBSD, whereas for userland-related issues we want to
match the definitions used for other systems with Glibc.
The current modification adjusts the build system so that they can be distinguished,
and explicitly adds GNU/kFreeBSD to the build checks in which it belongs.
Fixes bug #16444.
Patch by Robert Millan in the context of Debian.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185311 91177308-0d34-0410-b5e6-96231b3b80d8
This is essentially reverting one piece of 184793 to try to fix one of Apple's
buildbots. I will check with Eric to see if this is OK or if we need to find
some other solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185060 91177308-0d34-0410-b5e6-96231b3b80d8
when building llvm. This saves quite a bit of time and space when
linking. Please report any problems via bugzilla.
Caveats:
a) This will only work on linux
b) This requires a fairly new binutils
c) This requires a fairly new gdb
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184808 91177308-0d34-0410-b5e6-96231b3b80d8
command line. Change the darwin universal binary options to
be TargetCommonOpts so that they'll be passed to the linker since
-arch at least is still needed.
Someone on darwin with a buildit based build should probably verify
that this doesn't break anything there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184793 91177308-0d34-0410-b5e6-96231b3b80d8
This built clean with clang, but if we see false positives on the bots
then we'll revert and turn it into a compiler specific check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181836 91177308-0d34-0410-b5e6-96231b3b80d8
catches uses of an extremely minor and widely-available C++ extension (which
every C++ compiler I could find supports, but EDG and Clang reject in strict
mode).
The diagnosed code pattern looks like this:
struct X {
union {
struct {
int a;
int b;
} S;
};
};
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174103 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a new --with-python option to allow configuration of the python binary
for building. If not specified, $PATH will be searched for common python binary
names (python, python2, python3). If specified, and the path is not executable,
it will attempt to search $PATH.
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
Reviewed-by: Eric Christopher <echristo@gmail.com>, Daniel Dunbar <daniel@zuster.org>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173890 91177308-0d34-0410-b5e6-96231b3b80d8
configure checks whether -Wno-missing-field-initializers is a valid
compiler flag but it was never actually used in Makefile.rules.
Enable it to avoid some ridiculous warnings from gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172870 91177308-0d34-0410-b5e6-96231b3b80d8
If the compiler is gcc, disable variants of -Wuninitialized depending
on the gcc version. This gets a lot of false positive warnings out of
the build.
Generate a new configure for the gcc -Wno-uninitialized fix.
Pick up -Wno-uninitialized from configure
Add the option -Wno[-maybe]-uninitialized as determined by configure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172006 91177308-0d34-0410-b5e6-96231b3b80d8
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
When aliasing tools, rather than using the base TOOLEXENAME, we should
instead use the built tool's basename (for 'make') or the installed
tool's basename (for 'make install').
This should not cause any changes for anyone building unprefixed 'clang'
and 'clang++' tools.
Patch by Rick Foos!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165189 91177308-0d34-0410-b5e6-96231b3b80d8
The Apple buildbots have been modified not to pass --target,
so they shouldn't choke on a default program prefix anymore.
Patch by Rick Foos!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164956 91177308-0d34-0410-b5e6-96231b3b80d8
The Apple buildbots are set up to pass --target to configure for both
cross- and non-cross-compile builds, and the standard autoconf response
to this is to set the program prefix to '<target>-'. Until we can figure
out the proper way to handle this (don't pass --target? pass an explicit
--program-prefix=""? don't auto-populate program_prefix with target_alias?)
it's more important to keep the buildbots running.
This reverts r164633 / ba48ceb1a3.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164651 91177308-0d34-0410-b5e6-96231b3b80d8
