llvm dev - Oct 2015 - Building llvm so it can be installed by other users

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 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?  Can I get it to write a relative path
in the generated makefiles?  I checked CMake.html in docs, but I did not see
mention of this.

Please also let me know if I appear to be thinking about this the wrong way-
I've never attempted to package up a compiler collection for others' use
before and I might be missing something obvious.

Thanks!

--David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2863 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151021/48a95c8d/attachment.bin>

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

On Wed, Oct 21, 2015 at 10:38 AM, Jonathan Roelofs via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>     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"
>
If you go with dynamic linking, using rpath is preferred over LD_LIBRARY_PATH.
https://www.google.com/search?q=LD_LIBRARY_PATH+problems

Thanks, Jonathan- this worked like a charm.
>> I checked CMake.html in docs, but I did not see mention of this.
> 
> This would be a useful addition to the docs.
I would be glad to add instructions to that page.  I'll give that a try!

Thank you again,

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2863 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151022/566e2a8a/attachment.bin>