[libtool] make install fails after an incremental build after a prefix change?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[libtool] make install fails after an incremental build after a prefix change?

Kees-Jan Dijkzeul
Hi,

On my buildserver, I'd like to do something along the lines of

# build 1
./configure --prefix=${HOME}/opt/1 && make && make install
# build 2 (incrementally)
./configure --prefix=${HOME}/opt/2 && make && make install

The second make install fails for some libraries, with the message
libtool: install: error: cannot install `<libname.la>' to a directory
not ending in ${HOME}/opt/1

Apparently, libname.la needs to be rebuilt after the prefix changed,
but automake didn't generate the rules to do so.

Any tips? Is this at all possible?

Thanks!

Kees-Jan

Reply | Threaded
Open this post in threaded view
|

Re: [libtool] make install fails after an incremental build after a prefix change?

Bob Friesenhahn
On Tue, 29 Dec 2015, Kees-Jan Dijkzeul wrote:

> Hi,
>
> On my buildserver, I'd like to do something along the lines of
>
> # build 1
> ./configure --prefix=${HOME}/opt/1 && make && make install
> # build 2 (incrementally)
> ./configure --prefix=${HOME}/opt/2 && make && make install
>
> The second make install fails for some libraries, with the message
> libtool: install: error: cannot install `<libname.la>' to a directory
> not ending in ${HOME}/opt/1
>
> Apparently, libname.la needs to be rebuilt after the prefix changed,
> but automake didn't generate the rules to do so.
>
> Any tips? Is this at all possible?

Try adding 'make clean' to your build steps.

The best thing to do is to build outside of the source tree and use a
separate build directory for each configure incantation.

Bob
--
Bob Friesenhahn
[hidden email], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Reply | Threaded
Open this post in threaded view
|

Re: [libtool] make install fails after an incremental build after a prefix change?

Kees-Jan Dijkzeul
Hi Bob,

Thanks for your reply

On Tue, Dec 29, 2015 at 8:46 PM, Bob Friesenhahn
<[hidden email]> wrote:
> Try adding 'make clean' to your build steps.
>
> The best thing to do is to build outside of the source tree and use a
> separate build directory for each configure incantation.

Either would obviously work, but kind of defeat the purpose of having
incremental builds, and unnecessarily  load the buildserver. A
solution where I could do an incremental build after a configure
incantation would be much preferred.

Note that this already seems to work well for configure incantations
that modify config.h :-)

Groetjes,

Kees-Jan

Reply | Threaded
Open this post in threaded view
|

Re: [libtool] make install fails after an incremental build after a prefix change?

Gavin Smith
On 29 December 2015 at 19:52, Kees-Jan Dijkzeul <[hidden email]> wrote:
> Either would obviously work, but kind of defeat the purpose of having
> incremental builds, and unnecessarily  load the buildserver. A
> solution where I could do an incremental build after a configure
> incantation would be much preferred.
>
> Note that this already seems to work well for configure incantations
> that modify config.h :-)

You want not to rebuild files that don't need to be rebuilt. Depending
on config.h doesn't achieve this: any source files including it will
have to be compiled again. If most of the source files do include
config.h, they'll all be rebuilt and it won't be much quicker to avoid
running "make clean" first.

Running configure changes the Makefile, and I believe that this is a
difficult problem to solve to know what has to be rebuilt in this
case. A similar problem is directly editing a Makefile to change the
flags being passed to the compiler: when you re-run "make", it doesn't
know that the flags have changed and the compiler won't be run again,
even though it should be. As long as "make" is being used to know what
depends on what, what would be needed in such a case would be for the
facts that change to be in a separate file that the Makefile refers to
and that "make" could see has changed. I expect that's difficult to
achieve with changing the installation directories.

Reply | Threaded
Open this post in threaded view
|

Re: [libtool] make install fails after an incremental build after a prefix change?

Kees-Jan Dijkzeul
On Tue, Dec 29, 2015 at 9:14 PM, Gavin Smith <[hidden email]> wrote:
>
> You want not to rebuild files that don't need to be rebuilt.

Although I tend to agree, we may differ on opinion on the importance
of this. I'd argue that it is much more important to not forget
rebuilding files that actually needed to be rebuilt. The only good
thing I can say about the current behaviour is that, at least, it is
not failing silently.

> Depending
> on config.h doesn't achieve this: any source files including it will
> have to be compiled again. If most of the source files do include
> config.h, they'll all be rebuilt and it won't be much quicker to avoid
> running "make clean" first.

I'm not suggesting to solve this particular problem using config.h. I
was merely pointing it out as a precedent where the autotools do their
best to manage dependencies. It is also an example of where autotools
err on the side of safety. If only one setting changes in config.h,
all files that depend on it are rebuilt, regardless of whether they
depend on that particular setting. It defaults to doing too much, and
this is a good thing.

> Running configure changes the Makefile, and I believe that this is a
> difficult problem to solve to know what has to be rebuilt in this
> case.

Then I'd propose to err on the side of safety again, and rebuild everything :-)

Note, though, that in my particular case, rebuilding everything is not
required. It seems sufficient to just re-link everything. Normally,
compling takes much longer than linking, so relinking everything when
the Makefile changes should be much faster than doing a clean build.

Groetjes,

Kees-Jan

Reply | Threaded
Open this post in threaded view
|

Re: [libtool] make install fails after an incremental build after a prefix change?

Bob Friesenhahn
On Wed, 30 Dec 2015, Kees-Jan Dijkzeul wrote:

> On Tue, Dec 29, 2015 at 9:14 PM, Gavin Smith <[hidden email]> wrote:
>>
>> You want not to rebuild files that don't need to be rebuilt.
>
> Although I tend to agree, we may differ on opinion on the importance
> of this. I'd argue that it is much more important to not forget
> rebuilding files that actually needed to be rebuilt. The only good
> thing I can say about the current behaviour is that, at least, it is
> not failing silently.

In order to successfully function, autotools must make several basic
assumptions.  For example, it must assume that the compilation
environment does not change since the configure script was run, and it
must assume that the configuration is not changed while there are
already built files present.  Automake depends on portable make
constructs so only so much can be done.

Your concern is unlikely to be addressed so it is wise to deal with
the current behavior and make adjustments to your build processes.

Bob
--
Bob Friesenhahn
[hidden email], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Reply | Threaded
Open this post in threaded view
|

Re: [libtool] make install fails after an incremental build after a prefix change?

Peter Johansson-6
In reply to this post by Kees-Jan Dijkzeul
Hi Kees-Jan,

On 12/30/2015 05:52 AM, Kees-Jan Dijkzeul wrote:

> On Tue, Dec 29, 2015 at 8:46 PM, Bob Friesenhahn
> <[hidden email]>  wrote:
>> >Try adding 'make clean' to your build steps.
>> >
>> >The best thing to do is to build outside of the source tree and use a
>> >separate build directory for each configure incantation.
> Either would obviously work, but kind of defeat the purpose of having
> incremental builds, and unnecessarily  load the buildserver. A
> solution where I could do an incremental build after a configure
> incantation would be much preferred.
Similarly, you could add a 'rm foo.la' in your build steps, which will
be less [cpu] expensive. Or you could manually add the dependency you're
after, i.e., try something like

foo.la: Makefile

in 'Makefile.am'.

Cheers,
Peter