LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Linux From Scratch
User Name
Password
Linux From Scratch This 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

Reply
 
LinkBack Search this Thread
Old 07-26-2011, 03:53 AM   #1
Marlino
LQ Newbie
 
Registered: Jul 2011
Location: Germany
Distribution: W2k, LFS
Posts: 17

Rep: Reputation: 2
segfault in ld-2.14.so running alsa-utils


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
 
Old 07-26-2011, 03:41 PM   #2
Aky^
LQ Newbie
 
Registered: Jul 2011
Distribution: LFS, Slack
Posts: 7

Rep: Reputation: 0
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
 
Old 07-26-2011, 04:43 PM   #3
Marlino
LQ Newbie
 
Registered: Jul 2011
Location: Germany
Distribution: W2k, LFS
Posts: 17

Original Poster
Rep: Reputation: 2
Post

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
 
Old 07-27-2011, 04:39 AM   #4
Aky^
LQ Newbie
 
Registered: Jul 2011
Distribution: LFS, Slack
Posts: 7

Rep: Reputation: 0
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.
 
Old 07-27-2011, 09:00 AM   #5
Marlino
LQ Newbie
 
Registered: Jul 2011
Location: Germany
Distribution: W2k, LFS
Posts: 17

Original Poster
Rep: Reputation: 2
Question

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.)
 
Old 07-28-2011, 10:05 AM   #6
Marlino
LQ Newbie
 
Registered: Jul 2011
Location: Germany
Distribution: W2k, LFS
Posts: 17

Original Poster
Rep: Reputation: 2
Question

I installed gdb-7.3 as per the instruction from
wiki.linuxfromscratch.org/blfs/wiki/OtherProgrammingTools
(with ... make -C gdb install not to overwrite binutils files)

Now, I find gdb has fixed the aplay problem.

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

Would this hint to a solution?
 
Old 07-29-2011, 03:26 AM   #7
Marlino
LQ Newbie
 
Registered: Jul 2011
Location: Germany
Distribution: W2k, LFS
Posts: 17

Original Poster
Rep: Reputation: 2
Unhappy

Quote:
Originally Posted by Marlino
Now, I find gdb has fixed the aplay problem.
Sadly, this is not really the case.

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
 
Old 07-29-2011, 07:23 PM   #8
Marlino
LQ Newbie
 
Registered: Jul 2011
Location: Germany
Distribution: W2k, LFS
Posts: 17

Original Poster
Rep: Reputation: 2
Lightbulb

Something is not perfect with glibc[-2.14].

I just took some "hard way" learning experiences:
  • 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?

Code:
ls -l /lib
...
drwxr-xr-x 7 root root    4096 22. Jul 14:22 kbd
-rwxr-xr-x 1 root root  671578 30. Jul 00:40 ld-2.12.2.so
-rwxr-xr-x 1 root root  663528 29. Jul 22:37 ld-2.13.so
-rwxr-xr-x 1 root root  695884 19. Jul 21:42 ld-2.14.so
lrwxrwxrwx 1 root root      10 30. Jul 00:41 ld-linux.so.2 -> ld-2.14.so
-rwxr-xr-x 1 root root   57244 30. Jul 00:39 libanl-2.12.2.so
-rwxr-xr-x 1 root root   57588 29. Jul 22:35 libanl-2.13.so
-rwxr-xr-x 1 root root   57596 19. Jul 21:40 libanl-2.14.so
lrwxrwxrwx 1 root root      14 30. Jul 00:41 libanl.so.1 -> libanl-2.14.so
lrwxrwxrwx 1 root root      17 21. Jul 21:21 libblkid.so.1 -> libblkid.so.1.1.0
...
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?

(Preferably helpful) feedback is welcome.
 
Old 07-30-2011, 11:01 AM   #9
Marlino
LQ Newbie
 
Registered: Jul 2011
Location: Germany
Distribution: W2k, LFS
Posts: 17

Original Poster
Rep: Reputation: 2
Talking a linux system kill switch exposed

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.

Now, for the system disabling part:
Code:
ls -l libc*
-rwxr-xr-x 1 root root 8642357 30. Jul 00:40 libc-2.12.2.so
-rwxr-xr-x 1 root root 8691121 29. Jul 22:37 libc-2.13.so
-rwxr-xr-x 1 root root 8863029 19. Jul 21:42 libc-2.14.so
...
lrwxrwxrwx 1 root root      12 30. Jul 16:27 libc.so.6 -> libc-2.14.so
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. :-)
 
Old 08-01-2011, 10:32 AM   #10
Andrew Benton
Senior Member
 
Registered: Aug 2003
Location: Birkenhead/Britain
Distribution: Linux From Scratch
Posts: 2,073

Rep: Reputation: 64
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.

If anyone files a bug about this could they post a link to it in this thread please

Last edited by Andrew Benton; 08-01-2011 at 10:35 AM. Reason: bit about filing bugs
 
Old 08-01-2011, 11:47 AM   #11
Marlino
LQ Newbie
 
Registered: Jul 2011
Location: Germany
Distribution: W2k, LFS
Posts: 17

Original Poster
Rep: Reputation: 2
Smile

Thanks for your kind feedback, Andrew. :-)

Quote:
Originally Posted by Andrew Benton
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.
Yes, I already did so.
This was rather obvious to me.

In fact, I had to use a (knoppix) live cd to build my new LFS system
as my old system was too old and did not meet the system requirements.

But I used the old system to fix that link issue,
as it is way faster and more comfortable than the live cd.

What (audio) apps segfault under what detailed circumstances
with glibc-2.14, seems not entirely obvious to me.

play (from sox) also segfaulted.
aplay did not segfault, if using some special environment settings. (see above)


If I'd be building a new LFS system,
I'd rather use glibc-2.13 than glibc-2.14!


Quote:
Originally Posted by Andrew Benton
If anyone files a bug about this could they post a link to it in this thread please
I agree, this seems to be a good idea.
 
Old 08-02-2011, 04:25 AM   #12
Aky^
LQ Newbie
 
Registered: Jul 2011
Distribution: LFS, Slack
Posts: 7

Rep: Reputation: 0
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.

cheers!
 
Old 08-02-2011, 11:38 PM   #13
Marlino
LQ Newbie
 
Registered: Jul 2011
Location: Germany
Distribution: W2k, LFS
Posts: 17

Original Poster
Rep: Reputation: 2
Unhappy

Now I ran into the limits of this setup (glibc-2.14 using ld-2.13.so):

Trying to install openssl-1.0.0d, configure produced a segfault in ld-2.13.so!

I could set /lib/ld-linux.so.2 back to ld-2.14.so and I could configure ...
and install it without problems.

Then I set ld-linux.so.2 back to ld-2.13.so again.

The commandline tool openssl seemed to work this way.

So I compiled links with ssl support.

Now, when I point links to an https site, I get a segault in ld-2.13.so!

I can make links work with https sites, by switching back to ld-2.14.so.

This way, I would need a tool to dynamically select to version of the
dynamic linker used, depending on the program that will use it.


Did anyone get such things to work with glibc-2.13?

@Aky^: You seem to have a way of completely/cleanly reverting to glibc-2.13.
How can this be achieved?
 
Old 08-04-2011, 06:15 AM   #14
Andrew Benton
Senior Member
 
Registered: Aug 2003
Location: Birkenhead/Britain
Distribution: Linux From Scratch
Posts: 2,073

Rep: Reputation: 64
Quote:
Originally Posted by Aky^ View Post
hope that 2.15 will fix this.
Bad news, I've just rebuilt with current glibc git head and the problem remains
 
Old 08-14-2011, 03:49 PM   #15
Marlino
LQ Newbie
 
Registered: Jul 2011
Location: Germany
Distribution: W2k, LFS
Posts: 17

Original Poster
Rep: Reputation: 2
Arrow

I rebuilt an LFS system using glibc-2.13, Linux-2.6.39.4.

So far, I did not encounter any major problems.

Alsa, as well as Openssl could be built and worked
without any segmentation errors. :-)

Last edited by Marlino; 08-14-2011 at 03:50 PM. Reason: Making the [grammar] a little smother. ;-)
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] alsa 1.0.24 utils issue nova49 Slackware 7 03-19-2011 06:17 PM
alsa-utils for freebsd? aquaboot *BSD 4 12-08-2007 04:45 PM
broke gentoo after installing alsa-driver & alsa-utils snakeo2 Linux - Newbie 1 01-26-2006 08:05 AM
[ALSA 1.0.9b-4] No more sound, no more alsa-utils package Creak Debian 5 08-18-2005 04:22 PM
alsa-utils conflicts with alsa-lib sloik2000 Linux - Software 0 07-09-2005 08:50 AM


All times are GMT -5. The time now is 11:56 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration