summaryrefslogtreecommitdiffstats
path: root/llvm/projects/sample/autoconf/m4/link_options.m4
Commit message (Collapse)AuthorAgeFilesLines
* Remove projects/sample.Rafael Espindola2014-03-121-109/+0
| | | | | | | | | | | | | | | As an example that was not actually being used, it suffered from a slow bitrot. The two main issues with it were that it had no cmake support and included a copy of the autoconf directory. The reality is that autoconf is not easily composable. The lack of composabilty is why we have clang options in llvm's configure. Suggesting that users include a copy of autoconf/ in their projects seems a bad idea. We are also in the process of switching to cmake, so pushing autoconf to new project is probably not what we want. llvm-svn: 203728
* Link with -rdynamic instead of -Wl,-export-dynamic.Bob Wilson2013-08-021-4/+5
| | | | | | | | | | | | | | | Recent versions of the OS X linker support this but follow the existing OS X linker convention of using an underscore in the option name, i.e., -export_dynamic. Rather than changing our configure scripts to check for that alternate spelling, it is simpler to just use the compiler's -rdynamic option and let it deal with translating that to the appropriate linker option. One potential disadvantage of this approach is that the compiler will typically ignore -rdynamic on platforms where it is not supported, so the HAVE_LINK_EXPORT_DYNAMIC in config.h will not necessarily show whether that option has any effect or not. I don't see any in-tree uses of that macro, so I'm assuming it is OK. llvm-svn: 187686
* Update all outdated autoconf files in the sample project.Benjamin Kramer2012-05-051-1/+1
| | | | | | We might just use symlinks here, but I'm afraid of possible portability issues. llvm-svn: 156235
* projects/sample: Import adapted form of current LLVM autoconf/Makefile setup ↵Daniel Dunbar2011-10-181-0/+108
so that projects/sample is standalone and not tied to the LLVM build setup. - This currently just moves over all of the behavior from LLVM. Eventually all of the configure checks that are directly needed by the LLVM build setup should probably go away, and the project should manage their own configuration checks if necessary. - This is the 1st half of this work, the actual Makefile.common hasn't moved over yet. I've tried to stage this in such a way that incremental builds will properly reconfigure for most active developers (the Makefiles don't handle reconfiguring in a perfectly reliable way, and I haven't found an easy way to make them do so). llvm-svn: 142456
OpenPOWER on IntegriCloud