Date: Wed, 26 Jun 2013 17:28:43 -0400
From: Dubiousjim <lists+alpine-devel@jimpryor.net>
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Can't build apk-tools
Message-ID: <20130626212843.GA18572@zen>
Mail-Followup-To: alpine-devel@lists.alpinelinux.org
References: <1371469130.31289.140661244826657.5DE65BF9@webmail.messagingengine.com>
 <20130618085359.78d9215d@vostro>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130618085359.78d9215d@vostro>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Tue, Jun 18, 2013 at 08:53:59AM +0300, Timo Teras wrote:
> 
> How about uclibc-dev? Is that upstream or left broken from older
> install?
> 
> The thing is that __stack_chk_fail_local is a special kind of symbol
> that gcc inserts, and is expected to be linked in with the executable
> (most _not_ be in a .so). Thus you will not find it
> in /lib/libc.so.0.9.32 (or glibc .so either for that matter).
> 
> Instead, if you look at "/usr/lib/libc.so", it's a linker script
> telling to link with the real .so and a set of nonshared static
> objects, with uclibc, namely uclibc_nonshared.a. You should find
> __stack_chk_fail_local in /usr/lib/uclibc_nonshared.a.
> 
> You might want to check that /usr/lib/uclibc_nonshared.a
> and /usr/lib/libc.so come from uclibc-dev matching the libc0.9.32
> installed. You could try "apk audit --system /usr/lib/*libc*" and/or
> "apk fix uclibc-dev".

Thanks for the suggestions with this. I did end up fixing it. It was a
very idiosyncratic issue that I don't expect others to encounter, but
just in case: I had manually created a /lib/libc.so -> libc.so.0.9.32
symlink, when I was trying to install/debug cross-compilers on my
system. I had lost track of that and neglected to remove it. apk audit
--system didn't report it because it's not a file that apk considers
owned. I didn't experience total build failures because I guess /lib
isn't one of the standard locations that gcc looks for libraries, so it
was just a few buildsystems that included -L/lib which would break,
because this symlink would shadow the script at /usr/lib/libc.so.

(The only breaking buildsystems I came across were apk-tools and
cryptsetup, and some of the stub files that various ./configure scripts
try to build to see if various components exist on the host
system---which is how I in the end tracked this down.) Anyway, that
symlink shouldn't be there.

While debugging this I noticed a larger issue with apk-tools though: for
some reason a bunch of files and links get (correctly) reported as owned
by `apk info -W /path/to/file`, but get (incorrectly) reported as unowned
(that is, no output and exit code 1) by `apk info -e /path/to/file`.

Just run this to find some:

  find /sbin /bin /lib /usr \! -type d -exec sh -c 'apk info -q -e $1 \
  || { apk info -W $1 2>/dev/null | fgrep -q " is owned by " && \
  echo $1; }' sh {} \;

In fact I have a bunch of patches to propose against apk-tools, all of
them UI-based. I've been using them locally for a while, and now that
Timo is actively pushing new stuff to the apk-tools tree, I figure I'd
better rebase them and clean them up and write up a rationale, so that
you guys can consider them for inclusion in the main tree. I'll send
those along in the next few days. I'll try to remember to ask again
about the `apk info -e` then.

I've got a bunch of other little local patches against aports and some
of the other Alpine repos, that I'll send to the list first, because
they're easier.

I realize that dumping a whole bunch of patches to the list at once
means you guys not be able to look at them all right away. No worries on
my side.

-- 
Dubiousjim
dubiousjim@gmail.com


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---