Skip to content
  1. Feb 25, 2010
  2. Feb 23, 2010
  3. Feb 18, 2010
    • Jeffrey Yasskin's avatar
    • Jeffrey Yasskin's avatar
      Add a shared library for LLVM, named libLLVM2.7svn.(so|dylib), and add an · f750fefa
      Jeffrey Yasskin authored
      --enable-shared configure flag to have the tools linked shared. (2.7svn is just
      $(LLVMVersion) so it'll change to "2.7" in the release.)  Always link the
      example programs shared to test that the shared library keeps working.
      
      On my mac laptop, Debug libLLVM2.7svn.dylib is 39MB, and opt (for example) is
      16M static vs 440K shared.
      
      Two things are less than ideal here:
      1) The library doesn't include any version information. Since we expect to break
      the ABI with every release, this shouldn't be much of a problem. If we do
      release a compatible 2.7.1, we may be able to hack its library to work with
      binaries compiled against 2.7.0, or we can just ask them to recompile. I'm
      hoping to get a real packaging expert to look at this for the 2.8 release.
      2) llvm-config doesn't yet have an option to print link options for the shared
      library. I'll add this as a subsequent patch.
      
      llvm-svn: 96559
      f750fefa
  4. Feb 17, 2010
  5. Feb 15, 2010
  6. Feb 11, 2010
  7. Feb 10, 2010
  8. Feb 09, 2010
  9. Feb 03, 2010
  10. Jan 27, 2010
    • Jeffrey Yasskin's avatar
      Kill ModuleProvider and ghost linkage by inverting the relationship between · 091217be
      Jeffrey Yasskin authored
      Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
      GlobalValues now, and doesn't provide modules, it's renamed to
      "GVMaterializer". Code that used to need a ModuleProvider to materialize
      Functions can now materialize the Functions directly. Functions no longer use a
      magic linkage to record that they're materializable; they simply ask the
      GVMaterializer.
      
      Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
      the functions that refer to it. Instead, because Module now exposes the same
      functionality ModuleProvider used to, we store a Module* in any
      LLVMModuleProviderRef and translate in the wrapper methods.  The bindings to
      other languages still use the ModuleProvider concept.  It would probably be
      worth some time to update them to follow the C++ more closely, but I don't
      intend to do it.
      
      Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
      
      llvm-svn: 94686
      091217be
    • Jeffrey Yasskin's avatar
      Roll r94484 (avoiding RTTI problems in tests) forward again in a way that isn't · 6d7deae2
      Jeffrey Yasskin authored
      broken by setting CXXFLAGS on the command line.
      
      llvm-svn: 94619
      6d7deae2
  11. Jan 26, 2010
  12. Jan 24, 2010
  13. Jan 22, 2010
    • Torok Edwin's avatar
      Fix TimeValue::now() on Unix. · fbcd2c76
      Torok Edwin authored
      TimeValue()::now().toEpochTime() is supposed to be the same as time(),
      but it wasn't, because toEpoch subtracted PosixZeroTime, but now()
      didn't add PosixZeroTime!
      Add a unittest to check this works.
      
      llvm-svn: 94178
      fbcd2c76
    • Chris Lattner's avatar
      Stop building RTTI information for *most* llvm libraries. Notable · 7ba0661f
      Chris Lattner authored
      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.
      
      llvm-svn: 94164
      7ba0661f
  14. Jan 05, 2010
  15. Dec 31, 2009
  16. Dec 25, 2009
  17. Dec 24, 2009
  18. Dec 23, 2009
  19. Dec 21, 2009
  20. Dec 18, 2009
  21. Dec 17, 2009
  22. Dec 13, 2009
Loading