[pacman-dev] [arch-general] SOLVED - Re: Need help understanding new "make install" failures - libtool: install: error: relink `blah...la' ??

[Allan McRae]

On 10/04/12 20:24, Martti Kühne wrote:
> On Tue, Apr 10, 2012 at 10:47:35AM +0300, Bogdan Ionuț wrote:
>> On Mon, Apr 9, 2012 at 17:02, David C. Rankin <
>> drankinatty at suddenlinkmail.com> wrote:
>>
>>> On 04/07/2012 06:54 PM, David C. Rankin wrote:
>>>> Guys,
>>>>
>>>>   After the latest updates, I'm getting a number of package() "make
>>> install"
>>>> failures on packages that have, until now, packaged just fine. Is
>>> anybody else
>>>> experiencing this on packages you build? If so, do you know what is
>>> causing it
>>>> -- and how to fix?  I've searched and found that sometimes reordering
>>> the link
>>>> commands in the Makefile can help, but I can't figure out why things have
>>>> packaged just fine up until now and are now failing. Since everything
>>> built fine
>>>> with the build() command -- why the failure on package()??
>>>>
>>>>   I've also read another solution is to do away with the .la files
>>> completely
>>>> and replace with a package config setup. However, before I try and tackle
>>>> something like that, I want to figure out what broke. The failures
>>> during "make
>>>> install" look like this (gwenview and tdegames examples:)
>>>>
>>>> the failure:
>>>>
>>>> /usr/bin/ld: cannot find -ltdeinit_gwenview
>>>> collect2: error: ld returned 1 exit status
>>>> libtool: install: error: relink `gwenview.la' with the above command
>>> before
>>>> installing it
>>>>
>>>
>>> All,
>>>
>>>  The answer was provided in an AUR post for spice-gtk:
>>>
>>>  Try editing the PKBUILD in package()
>>>
>>> make -j1 DESTDIR="$pkgdir/" install
>>>
>>>  It seems that parallel building during package was the culprit. The build
>>> of
>>> tdegames went fine after adding -j1.
>>>
>>> --
>>> David C. Rankin, J.D.,P.E.
>>>
>>
>> Or options=(!makeflags)
> 
> Moving thread over here from aur-general, I think -j<something> is a great
> makeflag to build a kernel with, but there's no way to tell what packages will
> break with the flag. This kind of taints the /etc/makepkg.conf MAKEFLAGS
> variable, which is meant as a convenience. I followed the discussion earlier
> when someone tried to include a dynamic value for -j into a pkgbuild based on
> the number of cpus that could be located. Yeah, I too told him to use
> makepkg.conf, which is now under the impression of being a bad idea.
> 
> Ideas? Let the people rot with inserting !makeflags into all PKGBUILDs that
> break on their config?
> 

This has nothing to do with pacman or makepkg.  MAKEFLAGS is not a bad
idea when the developer of the software you are trying to packages are
competent enough to write a Makefile (or use tool that does it for them...).

Allan