FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 04-08-2011, 11:57 AM
Mathew de Detrich
 
Default Issues with strip on package sources

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)

I looked through the man page for strip and there doesn't seem to be an
option for it to continue stripping even if it hits an incompatible source
file. The other option I guess would be to add more granularity (or another
option) where you can provide a mask for objects not to be stripped (so you
can do something like *64.so and any file matching that mask wont be
stripped). Or you could manually invoke strip on every object file, and not
terminate the makepkg process should it hit an "incompatible" object file

In any case its an annoyance
 
Old 04-08-2011, 12:10 PM
Allan McRae
 
Default Issues with strip on package sources

On 08/04/11 21:57, 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)

I looked through the man page for strip and there doesn't seem to be an
option for it to continue stripping even if it hits an incompatible source
file. The other option I guess would be to add more granularity (or another
option) where you can provide a mask for objects not to be stripped (so you
can do something like *64.so and any file matching that mask wont be
stripped). Or you could manually invoke strip on every object file, and not
terminate the makepkg process should it hit an "incompatible" object file

In any case its an annoyance



I can not be sure given no-one who hits this issue ever posts any actual
output... but you are probably hitting this binutils issue:

http://sourceware.org/bugzilla/show_bug.cgi?id=12632


But anyway, it appears the change from using a whitelist to choose what
files to strip to attempting to strip everything has caused some
packaging issues. So I also think some way to blacklist files/folders
from being stripped would be useful.


Allan
 
Old 04-08-2011, 12:12 PM
Dave Reisner
 
Default Issues with strip on package sources

On Fri, Apr 08, 2011 at 10:10:19PM +1000, Allan McRae wrote:
> On 08/04/11 21:57, 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)
> >
> >I looked through the man page for strip and there doesn't seem to be an
> >option for it to continue stripping even if it hits an incompatible source
> >file. The other option I guess would be to add more granularity (or another
> >option) where you can provide a mask for objects not to be stripped (so you
> >can do something like *64.so and any file matching that mask wont be
> >stripped). Or you could manually invoke strip on every object file, and not
> >terminate the makepkg process should it hit an "incompatible" object file
> >
> >In any case its an annoyance
> >
>
> I can not be sure given no-one who hits this issue ever posts any
> actual output... but you are probably hitting this binutils issue:
> http://sourceware.org/bugzilla/show_bug.cgi?id=12632
>
>
> But anyway, it appears the change from using a whitelist to choose
> what files to strip to attempting to strip everything has caused
> some packaging issues. So I also think some way to blacklist
> files/folders from being stripped would be useful.
>
> Allan
>

I think this is just a matter of strip encountering files that aren't of
the architecture of the current system. qemu is a good example of where
this fails:

/usr/bin/strip: Unable to recognise the format of the input file
`./usr/share/qemu/openbios-sparc32'

and file reports this as...

pkg/usr/share/qemu/openbios-sparc32: ELF 32-bit MSB executable, SPARC,
version 1 (SYSV), statically linked, stripped

These are files that are shipped precompiled and prestripped.

dave
 
Old 04-08-2011, 12:20 PM
Allan McRae
 
Default Issues with strip on package sources

On 08/04/11 22:12, Dave Reisner wrote:

On Fri, Apr 08, 2011 at 10:10:19PM +1000, Allan McRae wrote:

On 08/04/11 21:57, 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)

I looked through the man page for strip and there doesn't seem to be an
option for it to continue stripping even if it hits an incompatible source
file. The other option I guess would be to add more granularity (or another
option) where you can provide a mask for objects not to be stripped (so you
can do something like *64.so and any file matching that mask wont be
stripped). Or you could manually invoke strip on every object file, and not
terminate the makepkg process should it hit an "incompatible" object file

In any case its an annoyance



I can not be sure given no-one who hits this issue ever posts any
actual output... but you are probably hitting this binutils issue:
http://sourceware.org/bugzilla/show_bug.cgi?id=12632


But anyway, it appears the change from using a whitelist to choose
what files to strip to attempting to strip everything has caused
some packaging issues. So I also think some way to blacklist
files/folders from being stripped would be useful.

Allan



I think this is just a matter of strip encountering files that aren't of
the architecture of the current system. qemu is a good example of where
this fails:

/usr/bin/strip: Unable to recognise the format of the input file
`./usr/share/qemu/openbios-sparc32'

and file reports this as...

pkg/usr/share/qemu/openbios-sparc32: ELF 32-bit MSB executable, SPARC,
version 1 (SYSV), statically linked, stripped

These are files that are shipped precompiled and prestripped.



What does "file -bi" give on that file?
 
Old 04-08-2011, 12:36 PM
Dave Reisner
 
Default Issues with strip on package sources

On Fri, Apr 08, 2011 at 10:20:53PM +1000, Allan McRae wrote:
> On 08/04/11 22:12, Dave Reisner wrote:
> >On Fri, Apr 08, 2011 at 10:10:19PM +1000, Allan McRae wrote:
> >>On 08/04/11 21:57, 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)
> >>>
> >>>I looked through the man page for strip and there doesn't seem to be an
> >>>option for it to continue stripping even if it hits an incompatible source
> >>>file. The other option I guess would be to add more granularity (or another
> >>>option) where you can provide a mask for objects not to be stripped (so you
> >>>can do something like *64.so and any file matching that mask wont be
> >>>stripped). Or you could manually invoke strip on every object file, and not
> >>>terminate the makepkg process should it hit an "incompatible" object file
> >>>
> >>>In any case its an annoyance
> >>>
> >>
> >>I can not be sure given no-one who hits this issue ever posts any
> >>actual output... but you are probably hitting this binutils issue:
> >>http://sourceware.org/bugzilla/show_bug.cgi?id=12632
> >>
> >>
> >>But anyway, it appears the change from using a whitelist to choose
> >>what files to strip to attempting to strip everything has caused
> >>some packaging issues. So I also think some way to blacklist
> >>files/folders from being stripped would be useful.
> >>
> >>Allan
> >>
> >
> >I think this is just a matter of strip encountering files that aren't of
> >the architecture of the current system. qemu is a good example of where
> >this fails:
> >
> >/usr/bin/strip: Unable to recognise the format of the input file
> >`./usr/share/qemu/openbios-sparc32'
> >
> >and file reports this as...
> >
> >pkg/usr/share/qemu/openbios-sparc32: ELF 32-bit MSB executable, SPARC,
> >version 1 (SYSV), statically linked, stripped
> >
> >These are files that are shipped precompiled and prestripped.
> >
>
> What does "file -bi" give on that file?
>

$ file -bi pkg/usr/share/qemu/openbios-sparc32
application/x-executable; charset=binary


d
 
Old 04-08-2011, 06:04 PM
Rémy Oudompheng
 
Default Issues with strip on package sources

On 2011/4/8 Mathew de Detrich <deteego@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.
 
Old 04-08-2011, 10:08 PM
Mathew de Detrich
 
Default 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 <remyoudompheng@gmail.com>wrote:

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

Thread Tools




All times are GMT. The time now is 10:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org