[pacman-dev] Issues with strip on package sources

[Mathew de Detrich]

This package is just a Java IDE (intellij) which is a commercial product
(thats why it contains prebuilt object files) which contains both 32bit and
64bit object files in the download. I think its also an issue with package
maintainers being lazy, since I guess technically speaking the package
maintainer should remove those 64bit object files after the source is
extracted (although in some rare cases this could cause problems?)

In any case there are two solutions to this problem, either rely on package
maintainers to remove the 64bit object files (which I don't think its too
reliable) or just make sure that strip doesn't hit 64bit object files

On Sat, Apr 9, 2011 at 4:04 AM, Rémy Oudompheng <remyoudompheng at gmail.com>wrote:

> On 2011/4/8 Mathew de Detrich <deteego at gmail.com> wrote:
> > A problem that seems to be occurring on packages (typically on AUR) where
> > makepkg using gnu's strip causes the package building process to fail
> (since
> > /usr/bin/strip terminates with a different error message) when there is
> an
> > incompatible object file in the source. As an example with this current
> > package (read the latest comments)
> > https://aur.archlinux.org/packages.php?ID=31566
> >
> > It fails to build unless you add
> > options=(!strip)
> > into the PKGBUILD, which of course solves the problem in a bastardized
> way
> > since it doesn't strip anything at all (and causes ridiculously bloated
> > packages)
> >
> > In this case the problem seems to be that the source package contains an
> > object file from a different architecture (x64) which when stripped,
> causes
> > the strip to prematurely terminate (and thus the building of the package
> to
> > fail)
>
> What is the point of installing object files for a different
> architecture than the target architecture? Is this package a
> cross-compilation toolchain?
>
> Regards,
> Rémy.
>