[pacman-dev] [arch-general] SOLVED - Re: Need help understanding new "make install" failures - libtool: install: error: relink `blah...la' ??
allan at archlinux.org
Tue Apr 10 06:32:43 EDT 2012
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:
>>>> After the latest updates, I'm getting a number of package() "make
>>>> 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
>>>> 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
>>>> installing it
>>> 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
>>> 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...).
More information about the pacman-dev