Re: [pacman-dev] Issues with strip on package sources

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 wrote:

On 2011/4/8 Mathew de Detrich 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.