Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I just built LFS-SVN-20110717,
added a few things from blfs
and now wanted to install alsa.
I first tried using alsa-lib-1.0.24.1
-> installed without problems
and alsa-utils-1.0.24.2
-> 'make' showed, that it required xmlto
-> I tried using the alsa-utils-1.0.21-no_xmlto-1.patch
from blfs.
-> This worked only partially, but compilation
and installation was possible then.
Running speaker-test however gave me a sefault:
Quote:
segfault at 3434375a ip b77ddc2d sp bff76a4c error 4 in ld-2.14.so[b77d4000+20000] Speicherzugriffsfehler
I got the same segfault trying to run aplay.
-> I deinstalled alsa-utils-1.0.24.2 and alsa-lib-1.0.24.1
using 'make uninstall'.
-> No error.
-> Tried the same with alsa-lib-1.0.21 and alsa-utils-1.0.21
exactly as described in blfs.
The patch worked completely (with a little offset),
no problems compiling and installing.
-> same segfault as above trying speaker-test or aplay.
What is wrong with this?
How can I fix it?
I did not find anything that helped me
using google yet.
Last edited by Marlino; 07-26-2011 at 03:55 AM.
Reason: Typing error in title
I'm running into the same problem... after upgrading glibc to 2.14 (without the LFS patch, it did compile with gcc-4.5.1).
At first I noticed mplayer would crash when attempting to output thru alsa or oss (oss emulated by alsa on my system) but not when outputting thru libsdl.
Also aplay crashes with a very similar message.
This makes me think that the error-triggering code lays somewhere in alsa-lib. I've upgraded to the latest alsa libs and utils, without solving anything :-( Tried switching back from kernel 3.0.0 to 2.6.39... still no luck. The interesting thing is that
Quote:
mpg123 -o alsa filename
does play w/o any troubles.
If it helps, I'm running a pure-64bit system built from scratch. Any ideas are welcome.
Last edited by Aky^; 07-27-2011 at 04:11 AM.
Reason: corrected gcc version
Mine is a 32bit system X86 (Athlon?).
I built lfs exactly as the book said,
so I must have applied all the patches
even though, I have no very vivid recall of this glibc patch.
Linux-2.6.39.3 was the only kernel I used with the system in question.
I suspect it could be some bug in glibc or something that made
it kind of incompatible with alsa.
I'm rather ill prepared / ignorant / inexperienced
to investigate such a thing on my own.
But I did not strip the debugging symbols yet
and could possibly help that way,
if someone would be willing to do some serious tutoring with me. ;-)
I'm kind of hoping that, it could only be a small part of glibc
and therefore not require a complete new build of it. ;-)
Edit:
@Aky^: what version of glibc, did you use before this upgrade?
Last edited by Marlino; 07-26-2011 at 04:52 PM.
Reason: Supplemented a related question
The glibc I've been using before is 2.11.2, and aplay (1.0.22) and everything else alsa-related used to work. One more thing seems to be pointing towards glibc as the guilty one here: been running aplay thru gdb and I've got this:
Code:
Starting program: /opt/devel/packages/base/_audio/alsa/alsa-utils-1.0.24.2/aplay/aplay
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7de46a7 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
(gdb) backtrace
#0 0x00007ffff7de46a7 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#1 0x00007ffff7de5192 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#2 0x00007ffff722eb9a in do_sym () from /lib64/libc.so.6
#3 0x00007ffff74b2014 in dlsym_doit () from /lib64/libdl.so.2
#4 0x00007ffff7de99e6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff74b24fc in _dlerror_run () from /lib64/libdl.so.2
#6 0x00007ffff74b206a in dlsym () from /lib64/libdl.so.2
#7 0x00007ffff790b5b3 in snd_dlsym_verify () from /usr/lib64/libasound.so.2
#8 0x00007ffff790b69d in snd_dlsym () from /usr/lib64/libasound.so.2
#9 0x00007ffff79064d8 in _snd_config_evaluate () from /usr/lib64/libasound.so.2
#10 0x00007ffff7902ce1 in snd_config_walk () from /usr/lib64/libasound.so.2
#11 0x00007ffff7902e04 in snd_config_walk () from /usr/lib64/libasound.so.2
#12 0x00007ffff7905931 in snd_config_expand () from /usr/lib64/libasound.so.2
#13 0x00007ffff79062af in snd_config_search_definition () from /usr/lib64/libasound.so.2
#14 0x00007ffff7925bec in snd_pcm_open () from /usr/lib64/libasound.so.2
#15 0x000000000040502c in main ()
(gdb)
Digging into the glibc changelog, there's been a couple of changes to the do_lookup_x() function, since version 2.13, maybe we should file a bug with redhat?
I'm tempted to rule out the kernel version as being the problem, as the only kernel header included from aplay.c is something which should be invariant for a given CPU architecture (little-endian for us):
Code:
#include <asm/byteorder.h>
I'm also tempted to rule out the alsa version, since upgrading 1.0.22 > 1.0.24.1 didn't change anything.
I would have liked to check that issue with gdb myself.
(And post the results)
But I can't find it.
Code:
$ whereis gdb
gdb: /usr/share/gdb
/usr/share/gdb really is a directory.
I didn't find it in /tool/... either.
I thought it was somehow contained in the lfs
base installation, but it seems not.
There is no entry of gdb in the blfs index either.
OK - I did find it mentioned on the page
about "Other Programming Tools" in blfs.
It is/was kind of hard for me to envision,
that gdb would be a package of its own,
not contained with gcc or somehow installed with lfs/blfs anyways,
as I am/was very convinced otherwise.
I guess, I'll get to installing and using it sometime later on,
when I get back to the other system again...
(No promise about the when yet.)
aplay now works without segfault!
But speaker-test still does segfault.
Maybe I should have installed gdb without the -C switch
and it would have repaired the speaker-test problem as well. ;-)
I uninstalled alsa-*-1.0.21 again and went back to alsa-*-1.0.24*
and got the same behavior.
aplay works:
Code:
$ gdb aplay
...
(gdb) run wasmach.wav
Starting program: /usr/bin/aplay wasmach.wav
[Thread debugging using libthread_db enabled]
Playing WAVE 'wasmach.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono
[Inferior 1 (process 27195) exited normally]
(gdb)
before installing gdb I called aplay without any parameters and it segfaulted.
I was kind of wondering, why nothing would happen, when I tried to run it that way via gdb -
until I found out, the segfault was gone. ;-)
speaker-test still segfaults:
Code:
$ gdb speaker-test
...
(gdb) run
Starting program: /usr/bin/speaker-test
[Thread debugging using libthread_db enabled]
speaker-test 1.0.21
Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Program received signal SIGSEGV, Segmentation fault.
0xb7fe7c2d in do_lookup_x (new_hash=960564692, old_hash=0xbffff2dc,
result=0xbffff2c4, scope=0xb7fdc68c, i=0, flags=2, skip=0x0,
undef_map=0xb7fdc530) at dl-lookup.c:98
98 dl-lookup.c: No such file or directory.
in dl-lookup.c
(gdb)
only minor differences with version 1.0.24..
Code:
$ gdb speaker-test
...
(gdb) run
Starting program: /usr/bin/speaker-test
[Thread debugging using libthread_db enabled]
speaker-test 1.0.24.2
Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Program received signal SIGSEGV, Segmentation fault.
0xb7fe7c2d in do_lookup_x (new_hash=960564692, old_hash=0xbffff24c,
result=0xbffff234, scope=0xb7fdc68c, i=0, flags=2, skip=0x0,
undef_map=0xb7fdc530) at dl-lookup.c:98
98 dl-lookup.c: No such file or directory.
in dl-lookup.c
(gdb)
Does anyone know what that really means?
Why is there "dl-lookup.c: No such file or directory"?
Based on that assumption I continued building the system.
-> No problems compiling, and installing.
Mostly audio related tools.
Even the test suites run OK.
ogg123 seemed to work,
play (from sox) segfaults when used with parameters
(not when called without).
aplay apparently works, when I do:
Code:
LC_ALL=
LANG=c
otherwise it segfaults.
(even when called without parameters)
I set LC_ALL and LANG as above, so I would get generic,
English feedback for posting.
So it was probably that circumstances that led me
to think gdb fixed the "aplay problem".
Some more output:
Code:
$ aplay
[25373.020359] aplay[18521]: segfault at 3434375a ip b7765c2d sp bf8b040c error
4 in ld-2.14.so[b775c000+20000]
Speicherzugriffsfehler
Code:
$ gdb aplay
...
(gdb) run wasmach.wav
Starting program: /usr/bin/aplay wasmach.wav
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0xb7fe7c2d in do_lookup_x (new_hash=960564692, old_hash=0xbffff42c,
result=0xbffff414, scope=0xb7fdc68c, i=0, flags=2, skip=0x0,
undef_map=0xb7fdc530) at dl-lookup.c:98
98 dl-lookup.c: No such file or directory.
in dl-lookup.c
(gdb) backtrace
#0 0xb7fe7c2d in do_lookup_x (new_hash=960564692, old_hash=0xbffff42c,
result=0xbffff414, scope=0xb7fdc68c, i=0, flags=2, skip=0x0,
undef_map=0xb7fdc530) at dl-lookup.c:98
#1 0xb7fe84f6 in _dl_lookup_symbol_x (
undef_name=0xbffff680 "_snd_config_hook_load_for_all_cards_dlsym_config_hook_001", undef_map=0xb7fdc530, ref=0xbffff4c0, symbol_scope=0xb7fdc700,
version=0x0, type_class=0, flags=2, skip_map=0x0) at dl-lookup.c:739
#2 0xb7e03f58 in do_sym (handle=0xb7fdc530,
name=0xbffff680 "_snd_config_hook_load_for_all_cards_dlsym_config_hook_001", who=<optimized out>, vers=0x0, flags=2) at dl-sym.c:177
#3 0xb7e04407 in _dl_sym (handle=<optimized out>, name=<optimized out>,
who=<optimized out>) at dl-sym.c:283
#4 0xb7e98d46 in dlsym_doit (a=0xbffff63c) at dlsym.c:51
#5 0xb7fed670 in _dl_catch_error (objname=0x80560f4, errstring=0x80560f8,
mallocedp=0x80560f0, operate=0xb7e98d20 <dlsym_doit>, args=0xbffff63c)
at dl-error.c:178
#6 0xb7e9937a in _dlerror_run (operate=0xb7e98d20 <dlsym_doit>,
args=0xbffff63c) at dlerror.c:164
#7 0xb7e98dc4 in __dlsym (handle=0xb7fdc530,
name=0xbffff680 "_snd_config_hook_load_for_all_cards_dlsym_config_hook_001") at dlsym.c:71
#8 0xb7ef1ef7 in snd_dlsym_verify () from /usr/lib/libasound.so.2
#9 0xb7ef1f8a in snd_dlsym () from /usr/lib/libasound.so.2
#10 0xb7eea7c7 in snd_config_hooks_call () from /usr/lib/libasound.so.2
---Type <return> to continue, or q <return> to quit---
#11 0xb7eeaa7d in snd_config_hooks () from /usr/lib/libasound.so.2
#12 0xb7eea002 in snd_config_searcha_hooks () from /usr/lib/libasound.so.2
#13 0xb7eea200 in snd1_config_search_alias_hooks ()
from /usr/lib/libasound.so.2
#14 0xb7eedccd in snd_config_search_definition () from /usr/lib/libasound.so.2
#15 0xb7f12acc in snd_pcm_open_noupdate () from /usr/lib/libasound.so.2
#16 0xb7f12c4d in snd_pcm_open () from /usr/lib/libasound.so.2
#17 0x080507ea in main (argc=0, argv=0xb7e85c7f) at aplay.c:658
(gdb)
Code:
$ gdb play
...
(gdb) run wasmach.wav
Starting program: /usr/bin/play wasmach.wav
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0xb7fe7c2d in do_lookup_x (new_hash=960564692, old_hash=0xbffff2ac,
result=0xbffff294, scope=0xb7ed4174, i=0, flags=2, skip=0x0,
undef_map=0xb7ed4018) at dl-lookup.c:98
98 dl-lookup.c: No such file or directory.
in dl-lookup.c
(gdb)
Any help for understanding and fixing the problem would be greatly appreciated!
Last edited by Marlino; 07-29-2011 at 03:29 AM.
Reason: corrected possibly misleading typing error
Compared do_lookup_x in dl-lookup.c of the last few releases of glibc,
didn't find a difference there. That would have been too easy
and probably not have been overlooked be the developers,
but it seemed worth a try.
Installed glibc-2.13
-> saw aplay and play segfault
Installed glibc-2.12.2
-> still saw aplay and play segfault
-> got suspicious ...
Now I realized that the situation to be observed
was a little too equal to the one observed in the beginning. ;-)
Code:
$ aplay
[19248.481558] aplay[1255]: segfault at 3434375a ip b78aec2d sp bfcc256c
error 4 in ld-2.14.so[b78a5000+20000]
Speicherzugriffsfehler
Did I see "ld-2.14.so" ?
Shouldn't that be something like "ld-2.12.2.so", if at all?
The "installations" of glibc-{2.13,2.12.2} made(?) links pointing to libraries from another version of glibc! - wtf
Just in case, there is something, I should have read, that says glibc installation
would behave that way (and maybe there is such and such a switch to change that),
someone please point me to that!
It is easily possible, that I have overlooked such,
but I find such behavior very counter intuitive and NOT useful.
(If there is no *good* reason for it.)
Now
Code:
ln -svf ld-2.13.so /lib/ld-linux.so.2
suddenly made play and aplay work normally.
So the bug is probably in glibc-2.14!
Quote:
Originally Posted by Aky^
maybe we should file a bug with redhat?
I believe, you certainly are right about, that a bug report should be filed.
What I am confused about, is that I would never have gotten the idea,
that readhat was the maintainer of glibc...
I still do have a need for tips about how to really, cleanly
go to another version of glibc!
Obviously the installation instructions in lfs do not cover setting those
links in /lib (/usr/lib ? and where else ?),
as lfs is designed for the initial installation.
???
Can I now just change those links pointing to *-2.14.* libraries
to shift the glibc-version?
I would kind of like that idea,
but how not to overlook something here?
I doubt that I could just uninstall the current version of glibc?
Or maybe that would solve it and point the links to the newest
remaining version of glibc?
How to disable a linux system in on quick and easy command. ;-)
I'll describe it for the conditions prepared earlier as mentioned above.
It should not be to difficult to come up with a similar "solution",
that does not require such preparation. ;-) :-) ;-)
Glancing through the docs... that came with the glibc source package,
I came across ways how to detect, what version of glibc is currently installed on the system:
A) Excecute
Code:
/lib/libc.so.6
This will output some infos about the current glibc-version
along with copyright and such.
But might not work on all systems.
B) Compile and run a small program
(translated to the lfs way, to make it more comfortable):
Code:
# create c source code:
cat > glibc-version-check.c << "EOF"
#include <stdio.h>
#include <gnu/libc-version.h>
int main (void) { puts (gnu_get_libc_version ()); return 0; }
EOF
# compile it:
gcc -o glibc-version-check glibc-version-check.c
# run it to get your current glibc-version displayed:
./glibc-version-check
This will only output the short string of the glibc-version itself,
such as "2.14" in the case of the system used above.
This should work on all systems.
I even found, that I could use that same executable file on my other system as well
and it worked to show the correct glibc-version for that system.
This gave me the idea to check whether I would get a different output
for the version, if I pointed libc.so.6 to libc-2.13.so.
I already felt, that this would probably mean trouble
and planed to change it back to its current target asap.
So I entered, what I now know as the "system kill switch":
Code:
ln -svf libc-2.13.so /lib/libc.so.6
Thereafter E V E R Y T H I N G, I tried to run on that system
resulted in a segfault!
I could not log out or shutdown the system.
I could change to another virtual tty, but had the same situation everywhere.
Not even <Ctrl>+<Alt>+<Del> did anything else but segfault.
However the computers reset switch still worked. lol
What this wanted to teach me, probably was,
that you could not change the glibc-version of a system,
without rebuilding it, or some very similar lesson.
Still, I seem to be able to utilize "ld-linux.so.2 -> ld-2.13.so"
in a glibc-2.14 system and thereby get rid of the problems mentioned above. :-)
You should be able to fix your system if you can boot from another partition (or a live cd) and fix the symbolic link from there. This is an interesting thread with some good detection work. I hadn't noticed that aplay and speaker-test were segfaulting 'cos other audio applications are working normally.
Been trying to pinpoint the exact commit after which the breakage occured, but after trying out a few snapshots from sourceware's git, they all exhibit the same bug... and since I don't have enough time to build, install and test tens of snapshots, I ended up reverting to glibc-2.13.
So for now I'll just enjoy a working do_lookup_x() and hope that 2.15 will fix this.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.