llvm build not respecting DESTDIR?

Project Infrastructure LLVM Dev List Archives
1

Hello,

I'm updating the macports build of llvm, and I'm running into an issue trying to stage llvm into a temporary directory. It builds fine, but when I try to install it into a temporary location, it insists on installing into the final location. The only reference I saw to the standard gnu DESTDIR was in the llvm.spec file, but none of the generated Makefiles have that value. Is there another way to do this? Here's the commands I'm running:

> ./configure --prefix=/opt/local
> make ENABLED_OPTIMIZED=1 OPTIMIZE_OPTION='-O2' tools-only
> make install DESTDIR=/opt/local/var/db/dports/build/_unencrypted_erickt_Projects_macports-trunk_dports_lang_llvm/work/destroot

This is the output from make install. You can see that it's trying to install into the final location, /opt/local:

install: /opt/local/include/./llvm/Transforms/Utils/Local.h: No such file or directory
llvm[0]: Making install directory /opt/local/include/./llvm/Transforms/Utils
mkdir: /opt/local/include/./llvm: Permission denied
mkdir: /opt/local/include/./llvm: No such file or directory
mkdir: /opt/local/include/./llvm/Transforms: No such file or directory
...

I also tried "make install PREFIX=...", but that didn't work either. Are there any suggestions on how to get this to work?

Also, some questions about llvm-gcc. If we're just installing the binary version, does anything need to be done in order to let llvm find the libraries, such as modifying the DLYD_LIBRARY_PATH, or are all the paths relative? What about for the stuff compiled by llvm-gcc, does that need paths to be set as well?

Finally, does llvm require llvm-gcc for it's runtime, as mentioned by GettingStarted.html, or can it be used by itself? If not, does it make sense to package the two in the two packages? Macports is a source-based packaging system, so it would seem odd to have to temporarily install llvm-gcc to build llvm, but then install llvm-gcc in a separate package.

Thanks for all your help!

-e

2

Hi Erick,

Hello,

I'm updating the macports build of llvm, and I'm running into an issue
trying to stage llvm into a temporary directory. It builds fine, but
when I try to install it into a temporary location, it insists on
installing into the final location.

Okay.

The only reference I saw to the
standard gnu DESTDIR was in the llvm.spec file, but none of the
generated Makefiles have that value.

LLVM isn't strictly a GNU project. It has similarities, but this
obviously isn't one of them :slight_smile:

Is there another way to do this?

Probably.

Here's the commands I'm running:

> ./configure --prefix=/opt/local
> make ENABLED_OPTIMIZED=1 OPTIMIZE_OPTION='-O2' tools-only
> make install
DESTDIR=/opt/local/var/db/dports/build/_unencrypted_erickt_Projects_macports-trunk_dports_lang_llvm/work/destroot

DESTDIR isn't used by the makefiles so specifying a value for it isn't
going to accomplish what you want. The --prefix= configure option
controls where installation goes to.

This is the output from make install. You can see that it's trying to
install into the final location, /opt/local:

install: /opt/local/include/./llvm/Transforms/Utils/Local.h: No such
file or directory
llvm[0]: Making install directory /opt/local/include/./llvm/Transforms/Utils
mkdir: /opt/local/include/./llvm: Permission denied
mkdir: /opt/local/include/./llvm: No such file or directory
mkdir: /opt/local/include/./llvm/Transforms: No such file or directory
...

Yes, that's what I'd expect.

I also tried "make install PREFIX=...", but that didn't work either. Are
there any suggestions on how to get this to work?

Yes, but its a bit verbose. The variables that control this are all
defined in the Makefile.config file. The variables are:

PROJ_prefix := /proj/llvm/install-1
PROJ_bindir := /proj/llvm/install-1/bin
PROJ_libdir := /proj/llvm/install-1/lib
PROJ_datadir := /proj/llvm/install-1/share
PROJ_docsdir := /proj/llvm/install-1/docs/llvm
PROJ_etcdir := /proj/llvm/install-1/etc/llvm
PROJ_includedir := /proj/llvm/install-1/include
PROJ_infodir := /proj/llvm/install-1/info
PROJ_mandir := /proj/llvm/install-1/man

The values are from my environment. You can either override each of
these individually on the command line or replace their values in
Makefile.config.

Also, some questions about llvm-gcc. If we're just installing the binary
version, does anything need to be done in order to let llvm find the
libraries, such as modifying the DLYD_LIBRARY_PATH, or are all the paths
relative?

There aren't any shared libraries so the library path doesn't matter.
For llvm-gcc3, the path needs to be able to find gccas and gccld from
the LLVM build. For llvm-gcc4, everything is linked in statically so
after llvm-gcc4 is built, it doesn't matter where LLVM lives.

What about for the stuff compiled by llvm-gcc, does that need
paths to be set as well?

It shouldn't. llvm-gcc will pre-pend its library paths to the search
list. Wherever it installed the libraries it will search first.

Finally, does llvm require llvm-gcc for it's runtime, as mentioned by
GettingStarted.html, or can it be used by itself?

LLVM does not require llvm-gcc for its runtime. The runtime library is
only to support llvm-gcc3 and building it requires llvm-gcc3 to be
available. However, release 2.0 (current one we're working on) will drop
support for llvm-gcc3. Its replacement, llvm-gcc4 will not require the
runtime library as it will use llvm-gcc's normal runtime (libgcc.a).

LLVM can be used by itself but the only languages it can process are
LLVM assembly and Stacker. llvm-gcc4 just provides the C/C++/Obj-C/Obj-C
++ front end languages. Other front ends could be developed.

If not, does it make
sense to package the two in the two packages?
Macports is a source-based
packaging system, so it would seem odd to have to temporarily install
llvm-gcc to build llvm, but then install llvm-gcc in a separate package.

That issue goes away with llvm-gcc4. You would simply build llvm and
then build llvm-gcc4. With llvm-gcc3, its a little more contorted:

1. build llvm tools only (don't build the runtime)
2. build llvm-gcc3
3. build the llvm runtime library

Thanks for all your help!

You're welcome.

Reid.

3

Hi Reid,

> The only reference I saw to the standard gnu DESTDIR was in the
> llvm.spec file, but none of the generated Makefiles have that value.

LLVM isn't strictly a GNU project. It has similarities, but this
obviously isn't one of them :slight_smile:

It would be nice to support the common conventions as it means
installation tools like GNU stow would work.

    Stow - GNU Project - Free Software Foundation

> Is there another way to do this?

Probably.

The stow recipe for building package foo is

    ./configure &&
    make all check &&
    make install prefix=/some/place/else

That is, the desired end installation location is used during
configuration, in this case the default, and building. It's only during
installation that the makefile puts foo somewhere else. (GNU stow comes
along later and sets up symlinks from the default location to
/some/place/else allowing easy switching between different versions of
foo.)

The variables that control this are all defined in the Makefile.config
file. The variables are:

PROJ_prefix := /proj/llvm/install-1
PROJ_bindir := /proj/llvm/install-1/bin
PROJ_libdir := /proj/llvm/install-1/lib
PROJ_datadir := /proj/llvm/install-1/share
PROJ_docsdir := /proj/llvm/install-1/docs/llvm
PROJ_etcdir := /proj/llvm/install-1/etc/llvm
PROJ_includedir := /proj/llvm/install-1/include
PROJ_infodir := /proj/llvm/install-1/info
PROJ_mandir := /proj/llvm/install-1/man

Again, it's `normal' to have `prefix = ...' in the Makefile and then use
`$(prefix)' as a prefix when defining all the others. Then just one
needs changing on the command line.

Cheers,

Ralph.

4

Reid Spencer wrote:

Yes, but its a bit verbose. The variables that control this are all
defined in the Makefile.config file. The variables are:

PROJ_prefix := /proj/llvm/install-1
PROJ_bindir := /proj/llvm/install-1/bin
PROJ_libdir := /proj/llvm/install-1/lib
PROJ_datadir := /proj/llvm/install-1/share
PROJ_docsdir := /proj/llvm/install-1/docs/llvm
PROJ_etcdir := /proj/llvm/install-1/etc/llvm
PROJ_includedir := /proj/llvm/install-1/include
PROJ_infodir := /proj/llvm/install-1/info
PROJ_mandir := /proj/llvm/install-1/man

The values are from my environment. You can either override each of
these individually on the command line or replace their values in
Makefile.config.

Great, that worked, thanks. For a future release though, think that DESTDIR could be supported? It shouldn't be that difficult, all that would need to be changed is in Makefile.config.in:

DESTDIR :=
PROJ_prefix := $(DESTDIR)@prefix@
PROJ_bindir := $(DESTDIR)@prefix@/bin
PROJ_libdir := $(DESTDIR)@prefix@/lib
PROJ_datadir := $(DESTDIR)@prefix@/share
PROJ_docsdir := $(DESTDIR)@prefix@/docs/llvm
PROJ_etcdir := $(DESTDIR)@prefix@/etc/llvm
PROJ_includedir := $(DESTDIR)@prefix@/include
PROJ_infodir := $(DESTDIR)@prefix@/info
PROJ_mandir := $(DESTDIR)@prefix@/man

And then the makefile would be (more) gnu-compliant, and make linux packaging much more simple and straightforward.

Also, some questions about llvm-gcc. If we're just installing the binary version, does anything need to be done in order to let llvm find the libraries, such as modifying the DLYD_LIBRARY_PATH, or are all the paths relative?

There aren't any shared libraries so the library path doesn't matter.
For llvm-gcc3, the path needs to be able to find gccas and gccld from
the LLVM build. For llvm-gcc4, everything is linked in statically so
after llvm-gcc4 is built, it doesn't matter where LLVM lives.

So does that mean that if we're doing a pure llvm, or llvm + llvm-gcc4, we can just do "make" and not "make tools-only"?

LLVM can be used by itself but the only languages it can process are
LLVM assembly and Stacker. llvm-gcc4 just provides the C/C++/Obj-C/Obj-C
++ front end languages. Other front ends could be developed.

We hope to add http://felix.sourceforge.net to that list :slight_smile: It currently is backed by a c++ generator, but we'd like to branch out to our own back end.

Thanks for all your help!

You're welcome.

Reid.

Thanks again!

-e

5

Hi Erick,

Reid Spencer wrote:
> Yes, but its a bit verbose. The variables that control this are all
> defined in the Makefile.config file. The variables are:
>
> PROJ_prefix := /proj/llvm/install-1
> PROJ_bindir := /proj/llvm/install-1/bin
> PROJ_libdir := /proj/llvm/install-1/lib
> PROJ_datadir := /proj/llvm/install-1/share
> PROJ_docsdir := /proj/llvm/install-1/docs/llvm
> PROJ_etcdir := /proj/llvm/install-1/etc/llvm
> PROJ_includedir := /proj/llvm/install-1/include
> PROJ_infodir := /proj/llvm/install-1/info
> PROJ_mandir := /proj/llvm/install-1/man
>
> The values are from my environment. You can either override each of
> these individually on the command line or replace their values in
> Makefile.config.

Great, that worked, thanks. For a future release though, think that
DESTDIR could be supported?

Yes. Could you please file a bug report for this so we don't forget
about it. I would really appreciate it.

Thanks,

Reid.

It shouldn't be that difficult, all that
would need to be changed is in Makefile.config.in:

DESTDIR :=
PROJ_prefix := $(DESTDIR)@prefix@
PROJ_bindir := $(DESTDIR)@prefix@/bin
PROJ_libdir := $(DESTDIR)@prefix@/lib
PROJ_datadir := $(DESTDIR)@prefix@/share
PROJ_docsdir := $(DESTDIR)@prefix@/docs/llvm
PROJ_etcdir := $(DESTDIR)@prefix@/etc/llvm
PROJ_includedir := $(DESTDIR)@prefix@/include
PROJ_infodir := $(DESTDIR)@prefix@/info
PROJ_mandir := $(DESTDIR)@prefix@/man

And then the makefile would be (more) gnu-compliant, and make linux
packaging much more simple and straightforward.

>> Also, some questions about llvm-gcc. If we're just installing the binary
>> version, does anything need to be done in order to let llvm find the
>> libraries, such as modifying the DLYD_LIBRARY_PATH, or are all the paths
>> relative?
>
> There aren't any shared libraries so the library path doesn't matter.
> For llvm-gcc3, the path needs to be able to find gccas and gccld from
> the LLVM build. For llvm-gcc4, everything is linked in statically so
> after llvm-gcc4 is built, it doesn't matter where LLVM lives.

So does that mean that if we're doing a pure llvm, or llvm + llvm-gcc4,
we can just do "make" and not "make tools-only"?

Yes. The makefile detects llvm-gcc4 and skips the runtime libraries.

> LLVM can be used by itself but the only languages it can process are
> LLVM assembly and Stacker. llvm-gcc4 just provides the C/C++/Obj-C/Obj-C
> ++ front end languages. Other front ends could be developed.

We hope to add http://felix.sourceforge.net to that list :slight_smile: It currently
is backed by a c++ generator, but we'd like to branch out to our own
back end.

Wonderful! We need more front ends. Let us know how we can help :slight_smile:

>> Thanks for all your help!
>
> You're welcome.
>
> Reid.

Thanks again!

You're welcome again :slight_smile:

Reid.

6

Reid Spencer wrote:

Yes. Could you please file a bug report for this so we don't forget
about it. I would really appreciate it.
  
Will do.

Yes. The makefile detects llvm-gcc4 and skips the runtime libraries.
  
Just to be clear, what happens if llvm-gcc4 is not installed yet?

We hope to add http://felix.sourceforge.net to that list :slight_smile: It currently is backed by a c++ generator, but we'd like to branch out to our own back end.
    
Wonderful! We need more front ends. Let us know how we can help :slight_smile:

Great! Well first off, are you aware of any ocaml interfaces to llvm? Our compiler is written in ocaml, and while we could go through the llvm source file, it may be more efficient to pass it through an interface.

-e

7

Reid Spencer wrote:

Yes. Could you please file a bug report for this so we don't forget
about it. I would really appreciate it.
  
Will do.

So does that mean that if we're doing a pure llvm, or llvm + llvm-gcc4, we can just do "make" and not "make tools-only"?
    
Yes. The makefile detects llvm-gcc4 and skips the runtime libraries.

Just to be clear, what happens if llvm is being installed before llvm-gcc4?

We hope to add http://felix.sourceforge.net to that list :slight_smile: It currently is backed by a c++ generator, but we'd like to branch out to our own back end.
    
Wonderful! We need more front ends. Let us know how we can help :slight_smile:
  
Great! One thing that would help: are you aware of any ocaml-bindings to llvm? The compiler is written in it, and I suspect that it may be faster to go through a binding than to route it through a intermediary source language.

-e

8

Erick,

9

Reid Spencer wrote:

If not, does it make sense to package the two in the two packages? Macports is a source-based packaging system, so it would seem odd to have to temporarily install llvm-gcc to build llvm, but then install llvm-gcc in a separate package.
    
That issue goes away with llvm-gcc4. You would simply build llvm and
then build llvm-gcc4. With llvm-gcc3, its a little more contorted:

1. build llvm tools only (don't build the runtime)
2. build llvm-gcc3
3. build the llvm runtime library
  
Hi Reid,

I got llvm all up and running, thanks. I'm now trying to set up llvm-gcc4. Does llvm-gcc4 require the llvm object files, or can I install llvm, remove all the intermediary files, and then build llvm-gcc4? Also, if I'm just doing a one-off build, do I have to make an obj and install directory, or can I just build it straight out of the llvm-gcc4 source directory? Finally, do I have to install into the parallel install directory, or can I install into any directory I'd like?

Thanks again,
-e

10

Reid Spencer wrote:

If not, does it make sense to package the two in the two packages? Macports is a source-based packaging system, so it would seem odd to have to temporarily install llvm-gcc to build llvm, but then install llvm-gcc in a separate package.
    
That issue goes away with llvm-gcc4. You would simply build llvm and
then build llvm-gcc4. With llvm-gcc3, its a little more contorted:

1. build llvm tools only (don't build the runtime)
2. build llvm-gcc3
3. build the llvm runtime library
  
Hi Reid,

I got llvm all up and running, thanks. I'm now trying to set up llvm-gcc4. Does llvm-gcc4 require the llvm object files, or can I install llvm, remove all the intermediary files, and then build llvm-gcc4? Also, if I'm just doing a one-off build, do I have to make an obj and install directory, or can I just build it straight out of the llvm-gcc4 source directory? Finally, do I have to install into the parallel install directory, or can I install into any directory I'd like?

Thanks again,
-e

11

Hi Erick,

Reid Spencer wrote:
>> If not, does it make
>> sense to package the two in the two packages?
>> Macports is a source-based
>> packaging system, so it would seem odd to have to temporarily install
>> llvm-gcc to build llvm, but then install llvm-gcc in a separate package.
>>
>
> That issue goes away with llvm-gcc4. You would simply build llvm and
> then build llvm-gcc4. With llvm-gcc3, its a little more contorted:
>
> 1. build llvm tools only (don't build the runtime)
> 2. build llvm-gcc3
> 3. build the llvm runtime library
>

Hi Reid,

I got llvm all up and running, thanks.

Great!

I'm now trying to set up
llvm-gcc4. Does llvm-gcc4 require the llvm object files, or can I
install llvm, remove all the intermediary files, and then build
llvm-gcc4?

llvm-gcc4 links in the objects and libraries built by LLVM, so you can't
remove them.

Also, if I'm just doing a one-off build, do I have to make an
obj and install directory, or can I just build it straight out of the
llvm-gcc4 source directory?

The recommended way to build any gcc or variant is in a separate obj
directory. It will make things much easier when you want to rebuild (rm
-rf *).

Finally, do I have to install into the
parallel install directory, or can I install into any directory I'd like?

You can install anywhere you like, just set --prefix=/path/to/install/to
on your llvm-gcc configure command.

Thanks again,
-e

You're welcome.

Reid.