Expose LLVMCreateTargetMachineData as data_layout.

As r263530 did for go. From that commit: "LLVMGetTargetDataLayout was
removed from the C API, and then TargetMachine.TargetData was removed.
Later, LLVMCreateTargetMachineData was added to the C API"

Differential Revision: http://reviews.llvm.org/D18677

llvm-svn: 265115

* LLVMDisposeMessage lives in llvm-c/Core.h, include this file where necessary
* LLVMAddTargetData has been removed, follow suit in the bindings

Differential Revision: http://reviews.llvm.org/D18633

llvm-svn: 265001

llvm-svn: 260720

Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html

"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi

Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark

Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits

Differential Revision: http://reviews.llvm.org/D16471

llvm-svn: 258861

This deprecates:
* LLVMParseBitcode
* LLVMParseBitcodeInContext
* LLVMGetBitcodeModuleInContext
* LLVMGetBitcodeModule

They are replaced with the functions with a 2 suffix which do not record
a diagnostic.

llvm-svn: 256065

Passing in a std::unique_ptr should help find errors when the module
is used after being linked into another module.

llvm-svn: 255842

Summary:
This patch does a couple of things:

  - Adds a new argument `--shared-mode` which accepts a list of components and prints whether or not the provided components need to be linked statically or shared.
  - Fixes `--libnames` when CMake BUILD_SHARED_LIBS is used.
  - Fixes `--libnames`, `--libs`, and `--libfiles` for dylib when static components aren't installed.
  - Fixes `--libnames`, `--libs`, `--libfiles`, and `--components` to use LLVM_DYLIB_COMPONENTS as the component manifest for dylib linking.
  - Uses the host platform's usual convention for filename extensions and such, instead of always defaulting to Unix-izms.

Because I don't own a Mac, I am not able to test the Mac platform dependent stuff locally. If someone would be willing to run a build for me on their machine (unless there's a better option), I'd appreciate it.

Reviewers: jfb, brad.king, whitequark, beanz

Subscribers: beanz, jauhien, llvm-commits

Differential Revision: http://reviews.llvm.org/D13198

llvm-svn: 252532

Patch by Jacques-Pascal Deplaix <jp.deplaix@gmail.com>

llvm-svn: 250912

Revert "Fix `llvm-config` to emit the linker flag for the combined shared object built by autoconfig/make instead of the individual components."

It seems I was wrong thinking `autoconf`/`make` only installed shared libraries if configured with `--enable-shared`, even if `--disable-static` is present. I'll re-address with a followup patch.

This reverts commit r243297 for causing PR#24154.

llvm-svn: 244108

Fix `llvm-config` to emit the linker flag for the combined shared object built by autoconfig/make instead of the individual components.

Summary:
When LLVM is configured to build shared libraries, CMake builds each component as it's own shared object, while autoconfig/make builds them statically and then links them all together to create a single shared object. This change adds compile time config flags to `llvm-config` so it can know whether LLVM's components are separated or not and act accordingly.

This fixes `llvm-config` instead of fixing the makefiles to behave like CMake because, AIUI, LLVM's autoconfig/make build system is on the way out anyway.

This change only affects `llvm-config` from builds that use autoconfig/make.

Reviewers: jfb

Subscribers: echristo, dschuff, llvm-commits

Differential Revision: http://reviews.llvm.org/D11392

llvm-svn: 243297

Revert the changes to the C API LLVMBuildLandingPad that were part of
the personality function move. We now set the personality on the parent
function when the C API attempts to construct a landingpad with a
personality.

This reverts commit r240010.

llvm-svn: 242372

ctypes 0.3 and earlier contains an interface-definig bug:
its ptr_of_raw_address accepts Int64 and not Nativeint. ctypes 0.4
was not released during the 3.6 cycle, and because of that, LLVM 3.6
was released with ctypes 0.3 as a dependency, which now breaks
the build on modern ctypes.

Unbreak.

llvm-svn: 240882

any tests and I even don't know how to run the tests. This seems like a
minimal change to make them work again, although I can't really verify
at this point. Additionally, it probably makes sense to propagate the
personality parameter removal further.

llvm-svn: 240010

llvm-svn: 228395

In order to use this feature, configure LLVM as usual,
but then build and install it as:

   make all install SYSTEM_LLVM_CONFIG=llvm-config

where llvm-config is the llvm-config binary installed on your
system (possibly llvm-config-VERSION on e.g. Debian).

llvm-svn: 225787

As a result, installations of LLVM in non-standard locations
will not require passing custom -ccopt -L flags when building
the binary, nor absolute paths would be embedded in the cma/cmxa
files. Additionally, the executables will not require changes
to LD_LIBRARY_PATH, although CAML_LD_LIBRARY_PATH still
has to be set for ocamlc without -custom.

See http://caml.inria.fr/mantis/view.php?id=6642.
Note that the patch is approved, but not merged yet.
It will be released in 4.03 and likely 4.02.

llvm-svn: 225778

The latter variable is internal.

Original patch by Ramkumar Ramachandra <artagnon@gmail.com>

llvm-svn: 224977

Patch by Ramkumar Ramachandra <artagnon@gmail.com>.

Also remove Llvm_executionengine.get_pointer_to_global, as it
is actually deprecated and didn't appear in a stable release.

llvm-svn: 224801

Fixes pr21901.

llvm-svn: 224782

Patch by Evangelos Foutras <evangelos@foutrelis.com>.

llvm-svn: 224766

Patch by Gideon Smeding <gideon.smeding@3ds.com>.

llvm-svn: 223129

This way most code won't link this (substantially large) library,
if compiled statically with LLVM.

llvm-svn: 223072

Closes PR15325.

llvm-svn: 223071

Also, revert r221142--it was an incorrect fix to this bug
which fixed tests by accident.

llvm-svn: 221149

Thanks echristo for pointing this out.

llvm-svn: 221145

llvm-svn: 221143

On 4.02, the OCaml unwinder otherwise gets confused and segfaults.

llvm-svn: 221142

llvm-svn: 221141

llvm-svn: 221140

Bindings built out-of-tree, e.g. via OPAM, should append
a line to META.llvm like the following:

linkopts = "-cclib -L$libdir -cclib -Wl,-rpath,$libdir"

where $libdir is the lib/ directory where LLVM libraries are
installed.

llvm-svn: 221139

The default Makefile.rules BUILD_ARCHIVE machinery was
unintentionally enabled.

llvm-svn: 221138

ocamlfind ignores the predicates in this case, making the package
unavailable for batch compilation as well.

llvm-svn: 221136

Interpreter support was removed in r220957.

llvm-svn: 221135

Specifically:
  * Directories match module names.
  * Test names match module names.
  * The language is called "OCaml", not "Ocaml".

llvm-svn: 220958

Since JIT->MCJIT migration, most of the ExecutionEngine interface
became deprecated and/or broken. This especially affected the OCaml
bindings, as runFunction is no longer available, and unlike in C,
it is not possible to coerce a pointer to a function and call it
in OCaml.

In practice, LLVM 3.5 shipped completely unusable
Llvm_executionengine.

The GenericValue interface and runFunction were essentially
a poor man's FFI. As such, this interface was removed and instead
a dependency on ctypes >=0.3 added, which handled platform-specific
aspects of accessing data and calling functions.

The new interface does not expose JIT (which is a shim around MCJIT),
as well as the interpreter (which can't handle a lot of valid IR).

Llvm_executionengine.add_global_mapping is currently unusable
due to PR20656.

llvm-svn: 220957

llvm-svn: 220903

llvm-svn: 220902

This commit updates the OCaml bindings and tests to use ocamlfind.
The bindings are migrated in order to use ctypes, which are now
required for MCJIT-backed Llvm_executionengine.
The tests are migrated in order to use OUnit and to verify that
the distributed META.llvm allows to build working executables.

Every OCaml toolchain invocation is now chained through ocamlfind,
which (in theory) allows to cross-compile the OCaml bindings.

The configure script now checks for ctypes (>= 0.2.3) and
OUnit (>= 2). The code depending on these libraries will be added
later. The configure script does not check the package versions
in order to keep changes less invasive.

Additionally, OCaml bindings will now be automatically enabled
if ocamlfind is detected on the system, rather than ocamlc, as it
was before.

llvm-svn: 220899

llvm-svn: 220898

llvm-svn: 220847