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.
--
dubiousjim@gmail.com
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Mon, 17 Jun 2013 07:38:50 -0400
Jim Pryor <dubiousjim@gmail.com> wrote:
> 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.
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
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
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
---
On Thu, Jun 27, 2013 at 09:39:17AM +0300, Timo Teras wrote:
> > 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.
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
dubiousjim@gmail.com
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
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
---