Subject: Re: [alpine-devel] Can't build apk-tools

From: Jim Pryor <[email-masked]>
Date: Mon, 17 Jun 2013 07:38:50 -0400

On Mon, Jun 17, 2013 at 11:52:46AM +0300, Timo Teras wrote:
> That's weird. Works here nicely. What gcc/libc you are using?
> 
> It might be due to using 'ld' and not 'gcc' for link. Or mixing object
> files built with different gcc flags. Or gcc spec file mismatching the
> libc build options.
> 
> Is your libc standard, or self-built with different config?

Thanks Timo.

I would have suspected a self-built toolchain and called it out. No, I'm
using the gcc-4.7.3-r6 and libc-0.9.33.2-r22 binary packages from edge
x86.

The only self-built packages I'm aware of on this machine (that are
otherwise available on edge) are:

    busybox
    cryptsetup
    getmail
    less
    lynx
    msmtp
    mutt
    ncurses
    procmail
    rxvt-unicode
    syslinux
    vim
    xkeyboard-config

I can confirm that when I ssh to a pretty vanilla system (tracking
alpine
2.6/x86_64), and do:

    $ git clone git://git.alpinelinux.org/apk-tools
    $ cd apk-tools/
    $ sudo apk add -t apk-make openssl-dev zlib-dev lua-dev
    $ make clean
    $ . /etc/abuild.conf
    $ make

that does work fine, no errors. Wonder what the breaking difference is.

Well, if I figure it out, I'll report. If you have any
ideas/suggestions, I welcome them.

On the problematic machine, changing LD to gcc in the Make.rules file no
longer suffices to fix the issue. I think it used to do so, but I'm not
sure of that---it's been a while since I last did this successfully.

-- 
[email-masked]

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Timo Teras <[email-masked]>
Date: Tue, 18 Jun 2013 08:53:59 +0300

On Mon, 17 Jun 2013 07:38:50 -0400
Jim Pryor <[email-masked]> wrote:

> > It might be due to using 'ld' and not 'gcc' for link. Or mixing
> > object files built with different gcc flags. Or gcc spec file
> > mismatching the libc build options.
> > 
> I would have suspected a self-built toolchain and called it out. No,
> I'm using the gcc-4.7.3-r6 and libc-0.9.33.2-r22 binary packages from
> edge x86.
> 
> On the problematic machine, changing LD to gcc in the Make.rules file
> no longer suffices to fix the issue. I think it used to do so, but
> I'm not sure of that---it's been a while since I last did this
> successfully.

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

- Timo

---

---

From: Dubiousjim <[email-masked]>
Date: Wed, 26 Jun 2013 17:28:43 -0400

> installed. You could try "apk audit --system /usr/lib/*libc*" and/or

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
[email-masked]

---

---

From: Timo Teras <[email-masked]>
Date: Thu, 27 Jun 2013 09:39:17 +0300

On Wed, 26 Jun 2013 17:28:43 -0400
Dubiousjim <[email-masked]> wrote:

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

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

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

> means you guys not be able to look at them all right away. No worries
> on my side.

Cool.

Thanks,
 Timo

---

---

From: Dubiousjim <[email-masked]>
Date: Thu, 27 Jun 2013 03:47:14 -0400

> those - and when you remove it, the bb install recreates the symlink

Yeah, I thought I saw a problem that went beyond busybox though.

But never mind, this is just more of my stupidity. `apk info -e` operates on
packages not on files. I had momentarily thought it worked like
`apk info -W path/to/file 2>/dev/null` actually works.

I'm batting rather idiot today... At least doing it out loud leads to
the mistakes eventually getting discovered.

-- 
Dubiousjim
[email-masked]

---