|
Message-ID: <20140525080748.GA3655@openwall.com> 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.