[Libclc-dev] [PATCH] Fix build with LLVM 3.4

[Peter Collingbourne]

On Thu, Jul 18, 2013 at 12:08:12PM -0700, Tom Stellard wrote:
> On Thu, Jul 18, 2013 at 01:14:40PM -0500, Aaron Watry wrote:
> > On Thu, Jul 18, 2013 at 10:00 AM, Tom Stellard <tom at stellard.net> wrote:
> > > On Thu, Jul 18, 2013 at 08:53:01AM -0500, Aaron Watry wrote:
> > >> F_Binary and friends were moved to include/Support/FileSystem.h
> > >>
> > >> Signed-off-by: Aaron Watry <awatry at gmail.com>
> > >> ---
> > >>  utils/prepare-builtins.cpp | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/utils/prepare-builtins.cpp b/utils/prepare-builtins.cpp
> > >> index be1624b..536359f 100644
> > >> --- a/utils/prepare-builtins.cpp
> > >> +++ b/utils/prepare-builtins.cpp
> > >> @@ -66,7 +66,7 @@ int main(int argc, char **argv) {
> > >>    std::string ErrorInfo;
> > >>    OwningPtr<tool_output_file> Out
> > >>    (new tool_output_file(OutputFilename.c_str(), ErrorInfo,
> > >> -                        raw_fd_ostream::F_Binary));
> > >> +                        sys::fs::F_Binary));
> > >
> > > I think we should wrap this in an ifdef, so it works with 3.3 and 3.4.
> > >
> > > The other question I have is do we even need the prepare-builtin
> > > program?  All it does is change the linkage to linkonce_odr, I'm not
> > > sure why we need to do this.
> > >
> > > -Tom
> > 
> > I agree about 3.3/3.4 compatibility, v2 is incoming.
> > 
> > For future reference, it looks like the code currently only supports
> > going back to 3.3, so I guess that can serve as a baseline.
> > 
> > I'm not sure if prepare-builtins is necessary...  I took a look at the
> > llvm-link command's options, and I don't see anything that we could
> > use as an easy way to do the same thing, but maybe it's not documented
> > by 'llvm-link --help'.... or maybe that's the wrong place to do it.
> > Something for a follow-on patch?
> > 
> 
> This can be a follow on patch, but it's not really a high priority, just
> something I was curious about.  It would be nice if we could drop this
> code, though, since it is the only part of the library that depends on
> the LLVM API.

If you want to drop prepare-builtins I think you will need to come
up with another mechanism for building a library such that it can
be linked with a client program, with any unused symbols in the
library being discarded, and without the possibility of needed
symbols being discarded (e.g. through LTO) before the full library
is ready.  I couldn't see a way of doing this without something like
prepare-builtins.  Although now that I think about it, it may be nice
for the LLVM linker to have the ability to act as though all symbols
in one of the given modules are linkonce_odr.

Thanks,
-- 
Peter