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

[Martti Kühne]

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?

cheers!
mar77i