Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 25 May 2014 12:07:48 +0400
From: croco@...nwall.com
To: owl-dev@...ts.openwall.com
Subject: Re: trying to build Owl for Raspberry Pi

Vasily, All,

On Sun, May 11, 2014 at 09:14:08PM +0400, Vasily Kulikov wrote:
> 
> Please post several log files from /usr/src/world/logs/$package (the
> last lines from it with 'failed' or 'error' strings of compiler/building
> scripts output).  It is not obvious what's missing/broken for your arch.

Oh, actually speaking, I simply didn't know about these files.  Errr... I
strongly believe that this worth to be mentioned in the BUILD.txt file.

With the new knowledge, I was able to install some packages (such as
texinfo and libtool, that appear to be build-deps for some of the Owl
packages) into my Raspberry, and this allowed me to proceed a little
further.  I'm still playing with installing more previously-failed build
dependencies; Raspberry Pi is *S*L*O*W* so I'm still unable to give a
result summary :)

However, another problem appeared which perhaps I'm unable to fix myself.
Some Owl patches failed to apply:

# root@...pi /usr/src/world/logs# grep ^Hunk * | grep FAILED
# acct:Hunk #1 FAILED at 5.
# bash:Hunk #2 FAILED at 357.
# ed:Hunk #1 FAILED at 8.
# flex:Hunk #1 FAILED at 454.
# gdb:Hunk #1 FAILED at 1205.
# glibc:Hunk #1 FAILED at 1075.
# iputils:Hunk #1 FAILED at 31.
# man-pages:Hunk #3 FAILED at 169.
# man-pages:Hunk #4 FAILED at 330.
# man-pages:Hunk #2 FAILED at 146.
# procps:Hunk #3 FAILED at 854.
# tcp_wrappers:Hunk #1 FAILED at 28.
# time:Hunk #1 FAILED at 1.
# vixie-cron:Hunk #1 FAILED at 1.
# root@...pi /usr/src/world/logs# 

# root@...pi /usr/src/world/logs# patch --version
# patch 2.6.1
# Copyright (C) 1988 Larry Wall
# Copyright (C) 2003, 2009 Free Software Foundation, Inc.
[...]

I'm attaching a file with more verbose log excerpts, that include the patch
numbers.  Could someone please look into this?  This is a bit surprising
for me, as I'm used to consider the diff/patch couple as ascii text
manipulation utilities that should not depend on the architecture.  May be
the version of patch is the problem?  However, if this is the case, I'd say
it could be better to provide patches that are good for more versions of
the utility; is there a chance for such a solution?


Also, building any particular package with 'make PACKAGE=...', I get the
following:

# build@...pi ~$ make PACKAGE=owl-setup
[...]
# Usage: fgrep [OPTION]... PATTERN [FILE]...
# Try 'fgrep --help' for more information.

# build@...pi ~$ fgrep --version
# fgrep (GNU grep) 2.13
# Copyright (C) 2012 Free Software Foundation, Inc.
[...]

Not yet understood what particular fgrep option triggers this.  The funny
thing is that the build actually continues after these messages, and in
some cases it successfully completes.



> Also several packages have scripts for specific architectures only.
> In this case you should investigate whether the package or building
> scripts have arch-specific things and try to fix it.  Probably simple
> addition of your arch into *Arch might fix it.
> 
>     $ grep ExclusiveArch native/Owl/packages/*/*spec
>     native/Owl/packages/cdrkit/cdrkit.spec:ExclusiveArch: %ix86 x86_64
>     native/Owl/packages/dev86/dev86.spec:ExclusiveArch: %ix86 x86_64
>     native/Owl/packages/dmidecode/dmidecode.spec:ExclusiveArch: %ix86 x86_64
>     native/Owl/packages/elftoaout/elftoaout.spec:ExclusiveArch: sparc sparcv9 sparc64
>     native/Owl/packages/kernel/kernel.spec:ExclusiveArch: i686 x86_64
>     native/Owl/packages/lilo/lilo.spec:ExclusiveArch: %ix86 x86_64
>     native/Owl/packages/ltrace/ltrace.spec:ExclusiveArch: %ix86 x86_64 sparc sparcv9
>     native/Owl/packages/owl-cdrom/owl-cdrom.spec:ExclusiveArch: %ix86 x86_64
>     native/Owl/packages/prtconf/prtconf.spec:ExclusiveArch: sparc sparcv9 sparc64
>     native/Owl/packages/setarch/setarch.spec:ExclusiveArch: %ix86 x86_64 sparc sparcv9 sparc64 ppc ppc64 mips mips64 ia64 s390 s390x
>     native/Owl/packages/silo/silo.spec:ExclusiveArch: sparc sparcv9 sparc64
>     native/Owl/packages/syslinux/syslinux.spec:ExclusiveArch: %ix86 x86_64

Some of these (e.g. lilo (?)) are simply unneeded on Raspberry; as of now,
I'm going to try without them all.

Anyway, during all the builds I see  '-march=armv6' on the gcc's command
line, and 'armv6hl' suffix in Pidora's package names.  What should I add to
ExclusiveArch?  armv6? armv6hl? Both?



Thanks!


--
Croco

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.