[llvm-dev] Building llvm so it can be installed by other users

[Jonathan Roelofs via llvm-dev]

On 10/21/15 7:45 AM, David Lobron wrote:
> Hi Jon,
>
>> Build directories aren't easily redistributable, nor are they
>> really meant to be. Install directories on the other hand can be,
>> provided you build with the right options, and package together all
>> the dependencies.
>>
>> Is there a particular reason why you want to distribute your build
>> dir instead of your install dir?
>
> Oops, you are right: I think it's the install directory that I want
> to be rooted in a relative directory path.  My goal here is for other
> users to be able to install and use clang and the required headers
> and libraries, without having to build from scratch.  The install
> path for a given user would be, e.g.,
>
> /home/USERNAME/build/common/
>
> So for example, clang would be installed to
> /home/USERNAME/build/common/bin.
>
> When I did my initial build, I set -DCMAKE_INSTALL_PREFIX to the
> "common" path above, but the Makefiles and cmake_makefiles that were
> generated have a full path (/home/dlobron/build/common), which of

Don't worry about the paths in the makefiles.

What's important is to make sure that the resulting binaries are 
relocatable. There are two ways to do that:

     1)  Build everything statically linked.
         *   If you do this, your binaries will be a lot bigger, but the
             dependency management should be simpler.
         *   It is easier to get this one working.
         *   To do this, set:
             LDFLAGS="-L/usr/lib -static-libstdc++ -static-ligbcc"

     2)  Package up all the dependencies so that the dynamic linker
         knows to find them in a relative path, rather than an absolute
         path.
         *   There's two ways to make this one work:
             *    By setting an environment variable in your users'
                  environment:
                 `export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH`
                  Where $PREFIX is where you've installed this on your
                  user's system, not necessarily the same as
                  your CMAKE_INSTALL_PREFIX.
             *    By arranging for that at compiler compile time:
                  CFLAGS="-Wl,-rpath=../lib"

Once you've got it built, and tested, then you should use `make install` 
to package everything up into whatever folder you set 
CMAKE_INSTALL_PREFIX to. That folder is what you should redistribute to 
your users (via tar, or otherwise). You can check that it worked by 
moving the folder somewhere else, and seeing if the executables will 
still run.

> course is not portable to other users if they were to do a "make
> install".  Is it possible to set DCMAKE_INSTALL_PREFIX (or another
> variable) such that I could package my install directory and another
> user could use it to install to their
> /home/OTHER-USERNAME/build/common root?

Yeah, see above.

> Can I get it to write a relative path in the generated makefiles?

No, but you don't need it to. See above.

> I checked CMake.html in docs, but I did not see mention of this.

This would be a useful addition to the docs.

> Please also let me know if I appear to be thinking about this the

Yes. Let me reiterate: your users should not be running `make install` 
on the makefiles generated by cmake... That's something you'll do once 
before packaging everything up for them.

> wrong way- I've never attempted to package up a compiler collection
> for others' use before and I might be missing something obvious.

:) happy hacking!


Jon

>
> Thanks!
>
> --David
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded