* hm, libc crashes loading libc
@ 2012-06-01 22:18 aep
2012-06-01 22:59 ` aep
2012-06-02 4:03 ` Rich Felker
0 siblings, 2 replies; 9+ messages in thread
From: aep @ 2012-06-01 22:18 UTC (permalink / raw)
To: musl
with git 9ea20dcbaafe790bb034adadf05698088a2f9fab
this stuff scares me, so i'll just dump the relevant information,
hoping someone knows what to do with it.
aep@nightbringer: /tmp echo "int main() {} " | musl-gcc -x c++ -
aep@nightbringer: /tmp ./a.out
zsh: segmentation fault ./a.out
#0 find_sym (dso=0x7ffff7ff8a00, s=s@entry=0x7ffff7d7801d "__cgt",
need_def=0) at src/ldso/dynlink.c:131
#1 0x00007ffff7d811a0 in do_relocs (dso=0x7ffff7ff8a00,
strings=0x7ffff7d74d50 "", syms=0x7ffff7d6bdc8, rel_size=624,
rel=0x7ffff7d786e8, base=0x7ffff7d69000 "\177ELF\002\001\001",
stride=<optimized out>) at src/ldso/dynlink.c:161
#2 reloc_all (p=p@entry=0x7ffff7ff8a80) at src/ldso/dynlink.c:481
#3 0x00007ffff7d82667 in __dynlink (argc=<optimized out>,
argv=<optimized out>) at src/ldso/dynlink.c:643
#4 0x00007ffff7d831e2 in _start () at src/ldso/x86_64/start.s:6
#5 0x0000000000000001 in ?? ()
#6 0x00007fffffffe77e in ?? ()
#7 0x0000000000000000 in ?? ()
reakpoint 1, reloc_all (p=p@entry=0x7ffff7ff8a80) at
src/ldso/dynlink.c:472
472 {
(gdb) print p
$1 = (struct dso *) 0x7ffff7ff8a80
(gdb) p p->name
$3 = 0x7ffff7dcc012 "libc.so"
(gdb) step
Program received signal SIGSEGV, Segmentation fault.
find_sym (dso=0x7ffff7ff8a00, s=s@entry=0x7ffff7d7801d "__cgt",
need_def=0) at src/ldso/dynlink.c:131
131 sym = lookup(s, h, dso->syms, dso->hashtab, dso->strings);
(gdb) print dso
$2 = (struct dso *) 0x7ffff7ff8a00
(gdb) step
lookup (strings=0x400308 "", hashtab=0x0, syms=0x400278, h=6642148,
s=0x7ffff7d7801d "__cgt") at src/ldso/dynlink.c:111
111 for (i=hashtab[2+h%hashtab[0]]; i; i=hashtab[2+hashtab[0]+i]) {
(gdb) step
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)
hashtab=0x0 sounds wrong, but how did it become zero?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hm, libc crashes loading libc
2012-06-01 22:18 hm, libc crashes loading libc aep
@ 2012-06-01 22:59 ` aep
2012-06-02 4:03 ` Rich Felker
1 sibling, 0 replies; 9+ messages in thread
From: aep @ 2012-06-01 22:59 UTC (permalink / raw)
To: musl
On Sat, 02 Jun 2012 00:18:55 +0200, aep wrote:
> with git 9ea20dcbaafe790bb034adadf05698088a2f9fab
>
> this stuff scares me, so i'll just dump the relevant information,
> hoping someone knows what to do with it.
nsz also sayd this was relevant:
the symbol is a weak symbol which is supposed to be overriden by some
vdso (he said dalias will know ;)
aep@nightbringer: ~/proj/musl nm /usr/local/musl/lib/libc.so | grep
__cgt
000000000028f750 D __cgt
he made me remove that symbol from musl and we got further to a crash
looking up __daylight.
aep@nightbringer: ~/proj/musl nm /usr/local/musl/lib/libc.so | grep
__daylight
0000000000295d20 B __daylight
aep@nightbringer: ~/proj/musl readelf --file-header --program-headers
--sections --relocs --dynamic --notes /usr/local/musl/lib/libc.so
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x1a1d4
Start of program headers: 64 (bytes into file)
Start of section headers: 3017248 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 6
Size of section headers: 64 (bytes)
Number of section headers: 27
Section header string table index: 24
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .note.gnu.build-i NOTE 0000000000000190 00000190
0000000000000024 0000000000000000 A 0 0 4
[ 2] .gnu.hash GNU_HASH 00000000000001b8 000001b8
0000000000002c10 0000000000000000 A 3 0 8
[ 3] .dynsym DYNSYM 0000000000002dc8 00002dc8
0000000000008f88 0000000000000018 A 4 2 8
[ 4] .dynstr STRTAB 000000000000bd50 0000bd50
0000000000003572 0000000000000000 A 0 0 1
[ 5] .rela.dyn RELA 000000000000f2c8 0000f2c8
0000000000000690 0000000000000018 A 3 0 8
[ 6] .text PROGBITS 000000000000f960 0000f960
0000000000050176 0000000000000000 AX 0 0 16
[ 7] .rodata PROGBITS 000000000005fae0 0005fae0
000000000001f5d0 0000000000000000 A 0 0 32
[ 8] .eh_frame_hdr PROGBITS 000000000007f0b0 0007f0b0
0000000000002d14 0000000000000000 A 0 0 4
[ 9] .eh_frame PROGBITS 0000000000081dc8 00081dc8
000000000000c5a8 0000000000000000 A 0 0 8
[10] .data.rel.ro PROGBITS 000000000028f000 0008f000
0000000000000100 0000000000000000 WA 0 0 32
[11] .dynamic DYNAMIC 000000000028f100 0008f100
00000000000000f0 0000000000000010 WA 4 0 8
[12] .got PROGBITS 000000000028f1f0 0008f1f0
0000000000000128 0000000000000008 WA 0 0 8
[13] .got.plt PROGBITS 000000000028f318 0008f318
0000000000000018 0000000000000008 WA 0 0 8
[14] .data PROGBITS 000000000028f340 0008f340
0000000000000418 0000000000000000 WA 0 0 32
[15] .bss NOBITS 000000000028f760 0008f758
00000000000066d8 0000000000000000 WA 0 0 32
[16] .comment PROGBITS 0000000000000000 0008f758
0000000000000027 0000000000000001 MS 0 0 1
[17] .debug_aranges PROGBITS 0000000000000000 0008f780
000000000000dd90 0000000000000000 0 0 16
[18] .debug_info PROGBITS 0000000000000000 0009d510
00000000000b9ba8 0000000000000000 0 0 1
[19] .debug_abbrev PROGBITS 0000000000000000 001570b8
000000000004772d 0000000000000000 0 0 1
[20] .debug_line PROGBITS 0000000000000000 0019e7e5
00000000000360cc 0000000000000000 0 0 1
[21] .debug_str PROGBITS 0000000000000000 001d48b1
000000000000d005 0000000000000001 MS 0 0 1
[22] .debug_loc PROGBITS 0000000000000000 001e18b6
00000000000e956d 0000000000000000 0 0 1
[23] .debug_ranges PROGBITS 0000000000000000 002cae23
0000000000015af0 0000000000000000 0 0 1
[24] .shstrtab STRTAB 0000000000000000 002e0913
0000000000000109 0000000000000000 0 0 1
[25] .symtab SYMTAB 0000000000000000 002e10e0
00000000000125d0 0000000000000018 26 1605 8
[26] .strtab STRTAB 0000000000000000 002f36b0
0000000000007b85 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
I (info), L (link order), G (group), T (TLS), E (exclude), x
(unknown)
O (extra OS processing required) o (OS specific), p (processor
specific)
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000
0x0000000000000000
0x000000000008e370 0x000000000008e370 R E 200000
LOAD 0x000000000008f000 0x000000000028f000
0x000000000028f000
0x0000000000000758 0x0000000000006e38 RW 200000
DYNAMIC 0x000000000008f100 0x000000000028f100
0x000000000028f100
0x00000000000000f0 0x00000000000000f0 RW 8
NOTE 0x0000000000000190 0x0000000000000190
0x0000000000000190
0x0000000000000024 0x0000000000000024 R 4
GNU_EH_FRAME 0x000000000007f0b0 0x000000000007f0b0
0x000000000007f0b0
0x0000000000002d14 0x0000000000002d14 R 4
GNU_STACK 0x0000000000000000 0x0000000000000000
0x0000000000000000
0x0000000000000000 0x0000000000000000 RWE 8
Section to Segment mapping:
Segment Sections...
00 .note.gnu.build-id .gnu.hash .dynsym .dynstr .rela.dyn .text
.rodata .eh_frame_hdr .eh_frame
01 .data.rel.ro .dynamic .got .got.plt .data .bss
02 .dynamic
03 .note.gnu.build-id
04 .eh_frame_hdr
05
Dynamic section at offset 0x8f100 contains 11 entries:
Tag Type Name/Value
0x000000000000000e (SONAME) Library soname: [libc.so]
0x000000006ffffef5 (GNU_HASH) 0x1b8
0x0000000000000005 (STRTAB) 0xbd50
0x0000000000000006 (SYMTAB) 0x2dc8
0x000000000000000a (STRSZ) 13682 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000007 (RELA) 0xf2c8
0x0000000000000008 (RELASZ) 1680 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffff9 (RELACOUNT) 44
0x0000000000000000 (NULL) 0x0
Relocation section '.rela.dyn' at offset 0xf2c8 contains 70 entries:
Offset Info Type Sym. Value Sym. Name
+ Addend
00000028f008 000000000008 R_X86_64_RELATIVE
000000000007dda0
00000028f018 000000000008 R_X86_64_RELATIVE
0000000000062feb
00000028f028 000000000008 R_X86_64_RELATIVE
000000000007dda2
00000028f038 000000000008 R_X86_64_RELATIVE
000000000007dda4
00000028f048 000000000008 R_X86_64_RELATIVE
000000000007dda6
00000028f058 000000000008 R_X86_64_RELATIVE
000000000007dda8
00000028f068 000000000008 R_X86_64_RELATIVE
000000000007ddaa
00000028f078 000000000008 R_X86_64_RELATIVE
000000000007ddb7
00000028f088 000000000008 R_X86_64_RELATIVE
000000000007ddc5
00000028f098 000000000008 R_X86_64_RELATIVE
000000000007ddd1
00000028f0a8 000000000008 R_X86_64_RELATIVE
000000000007ddde
00000028f0b8 000000000008 R_X86_64_RELATIVE
000000000007ddea
00000028f0d0 000000000008 R_X86_64_RELATIVE
000000000028f4c0
00000028f0d8 000000000008 R_X86_64_RELATIVE
000000000028f4c0
00000028f0e0 000000000008 R_X86_64_RELATIVE
000000000028f5a0
00000028f0e8 000000000008 R_X86_64_RELATIVE
000000000028f5a0
00000028f0f0 000000000008 R_X86_64_RELATIVE
000000000028f680
00000028f0f8 000000000008 R_X86_64_RELATIVE
000000000028f680
00000028f228 000000000008 R_X86_64_RELATIVE
000000000004b320
00000028f230 000000000008 R_X86_64_RELATIVE
000000000005bdfc
00000028f238 000000000008 R_X86_64_RELATIVE
000000000005be29
00000028f260 000000000008 R_X86_64_RELATIVE
000000000004b2e0
00000028f278 000000000008 R_X86_64_RELATIVE
0000000000049fbc
00000028f298 000000000008 R_X86_64_RELATIVE
00000000000179f0
00000028f2a0 000000000008 R_X86_64_RELATIVE
000000000004b180
00000028f2a8 000000000008 R_X86_64_RELATIVE
0000000000049fbc
00000028f2c8 000000000008 R_X86_64_RELATIVE
000000000003d0f0
00000028f300 000000000008 R_X86_64_RELATIVE
000000000004b140
00000028f310 000000000008 R_X86_64_RELATIVE
000000000003d120
00000028f340 000000000008 R_X86_64_RELATIVE
000000000028f9c0
00000028f4a0 000000000008 R_X86_64_RELATIVE
000000000028f424
00000028f4d8 000000000008 R_X86_64_RELATIVE
000000000004b140
00000028f508 000000000008 R_X86_64_RELATIVE
000000000004b320
00000028f510 000000000008 R_X86_64_RELATIVE
000000000004b2e0
00000028f518 000000000008 R_X86_64_RELATIVE
0000000000291108
00000028f5b8 000000000008 R_X86_64_RELATIVE
000000000004b140
00000028f5e0 000000000008 R_X86_64_RELATIVE
000000000004b180
00000028f5f0 000000000008 R_X86_64_RELATIVE
000000000004b2e0
00000028f5f8 000000000008 R_X86_64_RELATIVE
0000000000291128
00000028f698 000000000008 R_X86_64_RELATIVE
000000000004b140
00000028f6c8 000000000008 R_X86_64_RELATIVE
000000000004b4c0
00000028f6d0 000000000008 R_X86_64_RELATIVE
000000000004b2e0
00000028f6d8 000000000008 R_X86_64_RELATIVE
0000000000291548
00000028f750 000000000008 R_X86_64_RELATIVE
000000000005c520
00000028f1f0 053900000006 R_X86_64_GLOB_DAT 000000000028f750 __cgt + 0
00000028f1f8 031e00000006 R_X86_64_GLOB_DAT 0000000000295d20
__daylight + 0
00000028f200 009d00000006 R_X86_64_GLOB_DAT 00000000002919c0
__pthread_tsd_main + 0
00000028f208 041000000006 R_X86_64_GLOB_DAT 000000000028f0f0
__stdout_used + 0
00000028f210 042600000006 R_X86_64_GLOB_DAT 000000000028f0f8 stdout +
0
00000028f218 017f00000006 R_X86_64_GLOB_DAT 0000000000295da0
__stack_chk_guard + 0
00000028f220 048100000006 R_X86_64_GLOB_DAT 0000000000295d10 __tzname
+ 0
00000028f240 048800000006 R_X86_64_GLOB_DAT 0000000000295e10 optarg +
0
00000028f248 05ee00000006 R_X86_64_GLOB_DAT 000000000028f3a0 opterr +
0
00000028f250 022900000006 R_X86_64_GLOB_DAT 000000000028f0e0
__stdin_used + 0
00000028f258 015300000006 R_X86_64_GLOB_DAT 000000000007eca0
__pthread_tsd_size + 0
00000028f268 053f00000006 R_X86_64_GLOB_DAT 0000000000295e30
getdate_err + 0
00000028f270 001500000006 R_X86_64_GLOB_DAT 000000000028f768 __environ
+ 0
00000028f280 046500000006 R_X86_64_GLOB_DAT 0000000000295e28 h_errno +
0
00000028f288 037000000006 R_X86_64_GLOB_DAT 000000000028f768 environ +
0
00000028f290 044200000006 R_X86_64_GLOB_DAT 0000000000295db0 __env_map
+ 0
00000028f2b0 009200000006 R_X86_64_GLOB_DAT 000000000028f3b0 optind +
0
00000028f2b8 016c00000006 R_X86_64_GLOB_DAT 000000000028f0e8 stdin + 0
00000028f2c0 045000000006 R_X86_64_GLOB_DAT 0000000000295e20 linesize
+ 0
00000028f2d0 004f00000006 R_X86_64_GLOB_DAT 000000000028f0d8 stderr +
0
00000028f2d8 006a00000006 R_X86_64_GLOB_DAT 0000000000295d00
__dst_offset + 0
00000028f2e0 02e800000006 R_X86_64_GLOB_DAT 0000000000295e18 optopt +
0
00000028f2e8 03f300000006 R_X86_64_GLOB_DAT 0000000000290598 __signgam
+ 0
00000028f2f0 036600000006 R_X86_64_GLOB_DAT 0000000000295d28
__timezone + 0
00000028f2f8 00fa00000006 R_X86_64_GLOB_DAT 000000000028f3e4 __seed48
+ 0
00000028f308 033c00000006 R_X86_64_GLOB_DAT 000000000028f0d0
__stderr_used + 0
Notes at offset 0x00000190 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID
bitstring)
Build ID: 18e3fb3693ab2c0b2f0870b0f1bff9205061fe5f
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hm, libc crashes loading libc
2012-06-01 22:18 hm, libc crashes loading libc aep
2012-06-01 22:59 ` aep
@ 2012-06-02 4:03 ` Rich Felker
2012-06-02 11:03 ` aep
2012-06-02 13:30 ` aep
1 sibling, 2 replies; 9+ messages in thread
From: Rich Felker @ 2012-06-02 4:03 UTC (permalink / raw)
To: musl
On Sat, Jun 02, 2012 at 12:18:55AM +0200, aep wrote:
> hashtab=0x0 sounds wrong, but how did it become zero?
By GCC 4.7 randomly reordering memory accesses with no rhyme or
reason. As discussed on IRC, this is GCC bug # 52734 and has nothing
to do with musl. Anyone experiencing it and unable to replace the
broken GCC can use the -fno-tree-tail-merge option as a workaround.
Rich
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hm, libc crashes loading libc
2012-06-02 4:03 ` Rich Felker
@ 2012-06-02 11:03 ` aep
2012-06-02 13:30 ` aep
1 sibling, 0 replies; 9+ messages in thread
From: aep @ 2012-06-02 11:03 UTC (permalink / raw)
To: musl
On Sat, 2 Jun 2012 00:03:22 -0400, Rich Felker wrote:
> broken GCC can use the -fno-tree-tail-merge option as a workaround.
that didn't help me. trying clang right now.
it doesnt like the fistpq in src/math/x86_64/llrint.s though.
You might have forgotten to apply this to x86_64?
http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=0e195dfaa4902a73179f7ab296d47f01d3518ad3;hp=952700e8c32f7e81045cd01e1ecb3f7ca3f4c762
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hm, libc crashes loading libc
2012-06-02 4:03 ` Rich Felker
2012-06-02 11:03 ` aep
@ 2012-06-02 13:30 ` aep
2012-06-02 20:32 ` Rich Felker
1 sibling, 1 reply; 9+ messages in thread
From: aep @ 2012-06-02 13:30 UTC (permalink / raw)
To: musl
On Sat, 2 Jun 2012 00:03:22 -0400, Rich Felker wrote:
> On Sat, Jun 02, 2012 at 12:18:55AM +0200, aep wrote:
>> hashtab=0x0 sounds wrong, but how did it become zero?
turns out the problem is that gcc 4.7.0 from archlinux adds
--hash-style=gnu to ld, which musl cannot read.
this fixes it for me:
diff --git a/tools/musl-gcc.specs.sh b/tools/musl-gcc.specs.sh
index 5604685..9353706 100644
--- a/tools/musl-gcc.specs.sh
+++ b/tools/musl-gcc.specs.sh
@@ -25,7 +25,7 @@ libgcc.a%s %:if-exists(libgcc_eh.a%s)
%rename link old_link
*link:
-%(old_link) -dynamic-linker $ldso -nostdlib
+%(old_link) -dynamic-linker $ldso -nostdlib --hash-style=sysv
*esp_link:
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hm, libc crashes loading libc
2012-06-02 13:30 ` aep
@ 2012-06-02 20:32 ` Rich Felker
2012-06-02 21:18 ` aep
0 siblings, 1 reply; 9+ messages in thread
From: Rich Felker @ 2012-06-02 20:32 UTC (permalink / raw)
To: musl
On Sat, Jun 02, 2012 at 03:30:14PM +0200, aep wrote:
> On Sat, 2 Jun 2012 00:03:22 -0400, Rich Felker wrote:
> >On Sat, Jun 02, 2012 at 12:18:55AM +0200, aep wrote:
> >>hashtab=0x0 sounds wrong, but how did it become zero?
>
> turns out the problem is that gcc 4.7.0 from archlinux adds
> --hash-style=gnu to ld, which musl cannot read.
I can look into how much work it would be to add GNU hash support, or
whether it's possible to support linear searching the symbol table
when the hash table is missing...
Rich
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hm, libc crashes loading libc
2012-06-02 20:32 ` Rich Felker
@ 2012-06-02 21:18 ` aep
2012-06-02 21:41 ` Rich Felker
0 siblings, 1 reply; 9+ messages in thread
From: aep @ 2012-06-02 21:18 UTC (permalink / raw)
To: musl
On Sat, 2 Jun 2012 16:32:25 -0400, Rich Felker wrote:
> On Sat, Jun 02, 2012 at 03:30:14PM +0200, aep wrote:
>> turns out the problem is that gcc 4.7.0 from archlinux adds
>> --hash-style=gnu to ld, which musl cannot read.
>
> I can look into how much work it would be to add GNU hash support, or
> whether it's possible to support linear searching the symbol table
> when the hash table is missing...
does hash-style=gnu add any benefit for the target audience? I am
noticing no speed difference for my small C program, but maybe it
becomes interesting when C++ is added to the game.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hm, libc crashes loading libc
2012-06-02 21:18 ` aep
@ 2012-06-02 21:41 ` Rich Felker
2012-06-03 11:27 ` aep
0 siblings, 1 reply; 9+ messages in thread
From: Rich Felker @ 2012-06-02 21:41 UTC (permalink / raw)
To: musl
On Sat, Jun 02, 2012 at 11:18:39PM +0200, aep wrote:
> On Sat, 2 Jun 2012 16:32:25 -0400, Rich Felker wrote:
> >On Sat, Jun 02, 2012 at 03:30:14PM +0200, aep wrote:
> >>turns out the problem is that gcc 4.7.0 from archlinux adds
> >>--hash-style=gnu to ld, which musl cannot read.
> >
> >I can look into how much work it would be to add GNU hash support, or
> >whether it's possible to support linear searching the symbol table
> >when the hash table is missing...
>
>
> does hash-style=gnu add any benefit for the target audience? I am
> noticing no speed difference for my small C program, but maybe it
> becomes interesting when C++ is added to the game.
Like most GNU junk, it's oriented towards the case where N->infinity.
For small values of N (the number of symbols), standard ELF hash table
is going to perform at least as well, maybe even better...
Basically, it was designed for speed up Firefox loading it's ugly .so
files at runtime. The correct fix, since they're all code that's used
by a SINGLE PROGRAM, is to get rid of the .so's and link them into the
main program, but for no rational reason, the Firefox developers
refuse to do this. I suspect it's because their build system is broken
and it's hard for them to test changes to these files without building
them as separate .so's...
Rich
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hm, libc crashes loading libc
2012-06-02 21:41 ` Rich Felker
@ 2012-06-03 11:27 ` aep
0 siblings, 0 replies; 9+ messages in thread
From: aep @ 2012-06-03 11:27 UTC (permalink / raw)
To: musl
On Sat, 2 Jun 2012 17:41:03 -0400, Rich Felker wrote:
> Like most GNU junk, it's oriented towards the case where N->infinity.
C++ is broken in that way, but it's a reality thing. You can't just
make C++ go away.
I think i will run into very _long_ symbol names with clay, does
gnuhash stuff help me there or is it just good for large amounts of
symbols?
> I suspect it's because their build system is broken and it's hard for
> them to test changes to these files without building them as separate
> .so's...
Someone prof wrote a book on how to design your stuff in a modular way,
and all the fresh university students remembered was "have a lot of
DSO's".
Now we've got a lot of non modular DSOs. congratulations. Same with
dbus today.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-06-03 11:27 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-01 22:18 hm, libc crashes loading libc aep
2012-06-01 22:59 ` aep
2012-06-02 4:03 ` Rich Felker
2012-06-02 11:03 ` aep
2012-06-02 13:30 ` aep
2012-06-02 20:32 ` Rich Felker
2012-06-02 21:18 ` aep
2012-06-02 21:41 ` Rich Felker
2012-06-03 11:27 ` aep
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).