X-Original-To: alpine-devel@lists.alpinelinux.org
Delivered-To: alpine-devel@mail.alpinelinux.org
Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by mail.alpinelinux.org (Postfix) with ESMTPS id 18F0CDC008C
	for <alpine-devel@lists.alpinelinux.org>; Thu, 27 Jun 2013 06:39:10 +0000 (UTC)
Received: by mail-bk0-f48.google.com with SMTP id jf17so105095bkc.7
        for <alpine-devel@lists.alpinelinux.org>; Wed, 26 Jun 2013 23:39:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=sender:date:from:to:cc:subject:message-id:in-reply-to:references
         :x-mailer:mime-version:content-type:content-transfer-encoding;
        bh=B47mUYE3s/G8OeX0ISTwz4bBS5b7c/h/rm9IjKCnk5o=;
        b=Hf5wz2ZzrWJJy6htCrEBraiOxna+ACwaPn+f/q9DsxwPqXOZvdVK5Ov3LhPnAqJGoY
         +ZfP98v+mvtsHhg1UJ4xbUZrlwfzEk1afgp/Z18Dww6sIN+fIuCWG4vdk2YME19q07Ar
         9DzUpyEY4xW3lnc/CH1Z085vEy8nc67Cf4FY6Ik+92CE/MeuOVlJSeRBItzw9vmCW6/4
         UnjBRMqoGpML6/IjHsLXpzFdt7snmfJKHSGQJCziCouZnxyj3F8F338zmky1JnRZDHTs
         bisfOmUx1w+c9+zRPS8V9ebDdl5Pk9R3X4BIEqCqDchvCLvdGHKVyBmebZhyk9Y1wd89
         bSsA==
X-Received: by 10.204.65.137 with SMTP id j9mr976822bki.55.1372315149342;
        Wed, 26 Jun 2013 23:39:09 -0700 (PDT)
Received: from vostro ([83.145.235.199])
        by mx.google.com with ESMTPSA id kz11sm259098bkb.11.2013.06.26.23.39.08
        for <multiple recipients>
        (version=TLSv1.2 cipher=RC4-SHA bits=128/128);
        Wed, 26 Jun 2013 23:39:09 -0700 (PDT)
Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Thu, 27 Jun 2013 09:39:17 +0300
From: Timo Teras <timo.teras@iki.fi>
To: Dubiousjim <lists+alpine-devel@jimpryor.net>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Can't build apk-tools
Message-ID: <20130627093917.00014ea3@vostro>
In-Reply-To: <20130626212843.GA18572@zen>
References: <1371469130.31289.140661244826657.5DE65BF9@webmail.messagingengine.com>
	<20130618085359.78d9215d@vostro>
	<20130626212843.GA18572@zen>
X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.17; i686-pc-linux-gnu)
X-Mailinglist: alpine-devel
Precedence: list
List-Id: Alpine Development <alpine-devel.lists.alpinelinux.org>
List-Unsubscribe: 
	<mailto:alpine-devel+unsubscribe@lists.alpinelinux.org?subject=unsubscribe>
List-Post: <mailto:alpine-devel@lists.alpinelinux.org>
List-Help: <mailto:alpine-devel+help@lists.alpinelinux.org?subject=help>
List-Subscribe: 
	<mailto:alpine-devel+subscribe@lists.alpinelinux.org?subject=subscribe>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 26 Jun 2013 17:28:43 -0400
Dubiousjim <lists+alpine-devel@jimpryor.net> wrote:

> 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.

Ah, that explains it. :)

>[snip]
> 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 {} \;

Not all symlinks are owned. They get owned by a package only if
the .apk file contained the symlink. One notable misuser is busybox,
that uses busybox -s --install via triggers to install it's symlinks.
When you install the utility providing the real command it overwrites
those - and when you remove it, the bb install recreates the symlink
back to bb.

One option would be to read the symlink target and print the owner of
it. Or come up with some kind of 'alternatives' system such as Debian.

> 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.

Sure. Will be glad to apply those. Most of apk-tools work for now is
done. Planning to tag new release soon.

> 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.

Cool.

Thanks,
 Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---