1 |
On 2013-12-30 6:30 AM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
2 |
> To see what's going on, run ldd on: |
3 |
> |
4 |
> /usr/lib64/apache2/modules/libphp5.s |
5 |
|
6 |
Result: |
7 |
|
8 |
> # ldd /usr/lib64/apache2/modules/libphp5.so |
9 |
> ldd: warning: you do not have execution permission for `/usr/lib64/apache2/modules/libphp5.so' |
10 |
> linux-vdso.so.1 (0x00007fffc3cbf000) |
11 |
> libc-client.so.1 => /usr//lib64/libc-client.so.1 (0x00007f279599d000) |
12 |
> libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f279577b000) |
13 |
> libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f2795535000) |
14 |
> libaspell.so.15 => /usr//lib64/libaspell.so.15 (0x00007f2795263000) |
15 |
> libm.so.6 => /lib64/libm.so.6 (0x00007f2794f69000) |
16 |
> libssl.so.1.0.0 => /usr//lib64/libssl.so.1.0.0 (0x00007f2794cff000) |
17 |
> libcrypto.so.1.0.0 => /usr//lib64/libcrypto.so.1.0.0 (0x00007f279491a000) |
18 |
> libz.so.1 => /lib64/libz.so.1 (0x00007f2794703000) |
19 |
> libmcrypt.so.4 => /usr//lib64/libmcrypt.so.4 (0x00007f27944d1000) |
20 |
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f27942cd000) |
21 |
> libonig.so.2 => /usr//lib64/libonig.so.2 (0x00007f2794062000) |
22 |
> libt1.so.5 => /usr//lib64/libt1.so.5 (0x00007f2793e03000) |
23 |
> libfreetype.so.6 => /usr//lib64/libfreetype.so.6 (0x00007f2793b64000) |
24 |
> libpng15.so.15 => /usr//lib64/libpng15.so.15 (0x00007f2793939000) |
25 |
> libjpeg.so.8 => /usr//lib64/libjpeg.so.8 (0x00007f27936e4000) |
26 |
> libdb-4.8.so => /usr//lib64/libdb-4.8.so (0x00007f279336a000) |
27 |
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f279314c000) |
28 |
> libgdbm.so.3 => /usr//lib64/libgdbm.so.3 (0x00007f2792f46000) |
29 |
> libcurl.so.4 => /usr//lib64/libcurl.so.4 (0x00007f2792ceb000) |
30 |
> libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f2792ada000) |
31 |
> libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f2792873000) |
32 |
> libxml2.so.2 => /usr//lib64/libxml2.so.2 (0x00007f2792512000) |
33 |
> libmysqlclient.so.16 => /usr/lib64/mysql/libmysqlclient.so.16 (0x00007f279218b000) |
34 |
> libnetsnmp.so.30 => /usr//lib64/libnetsnmp.so.30 (0x00007f2791eb0000) |
35 |
> libc.so.6 => /lib64/libc.so.6 (0x00007f2791b0a000) |
36 |
> libpam.so.0 => /lib64/libpam.so.0 (0x00007f27918fb000) |
37 |
> libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f27916d8000) |
38 |
> libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 (0x00007f27913d3000) |
39 |
> /lib64/ld-linux-x86-64.so.2 (0x00007f279681b000) |
40 |
> librt.so.1 => /lib64/librt.so.1 (0x00007f27911ca000) |
41 |
> libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f2790f95000) |
42 |
> libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0x00007f2790d7e000) |
43 |
|
44 |
and |
45 |
|
46 |
> /usr//lib64/libcurl.so.4 |
47 |
|
48 |
> # ldd /usr//lib64/libcurl.so.4 |
49 |
> linux-vdso.so.1 (0x00007fffa7bff000) |
50 |
> libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007f510232b000) |
51 |
> libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f5101f46000) |
52 |
> libz.so.1 => /lib64/libz.so.1 (0x00007f5101d2f000) |
53 |
> librt.so.1 => /lib64/librt.so.1 (0x00007f5101b27000) |
54 |
> libc.so.6 => /lib64/libc.so.6 (0x00007f5101781000) |
55 |
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f510157c000) |
56 |
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f510135f000) |
57 |
> /lib64/ld-linux-x86-64.so.2 (0x00007f51027fb000) |
58 |
|
59 |
Doesn't mean anything to me though... ;) |
60 |
|
61 |
> preserved-rebuild should just take care of all this automagically. |
62 |
> Do you have preserve-libs in FEATURES? |
63 |
|
64 |
Nope... is this now recommended? Is it the default on new installs? |
65 |
|
66 |
> Do a pretend run of revdep-rebuild. I'll bet you end up rebuilding curl |
67 |
> and/or php, but not apache. |
68 |
|
69 |
Actually, I did that right after the updates and it didn't recommend |
70 |
anything (I always do revdep-rebuild -p after any system updates like |
71 |
gcc, glib/c, etc)... |
72 |
|
73 |
> Apache is unlikely to be at fault, it loads a dynamic module and use it, |
74 |
> that module either works or it doesn't. |
75 |
|
76 |
Ok... so, the question is still why did it die? |
77 |
|
78 |
This happened by the way when the logs were rotated by logrotate. Maybe |
79 |
that is significant? |
80 |
|
81 |
>> The GCC Upgrade guide is a bit outdated (still referring to gcc 3.4 and |
82 |
>> 4.1, with no mention of newer versions, so I wasn't sure if that was |
83 |
>> still necessary... |
84 |
|
85 |
> According to the posted error, this has nothing to do with compiler |
86 |
> versions, it is linker errors related to glibc |
87 |
> |
88 |
> You do not have to rebuild system, world or the known universe. You only |
89 |
> have to do that when the a gcc upgrade changes the data format on-disk |
90 |
> that the C++ compiler generates. That has not happened here. |
91 |
> |
92 |
> There's an insane amounts of FUD around about rebuilding gcc, all of it |
93 |
> originating from ricers without a clue. You run strictly stable-only so |
94 |
> never fear, if a gcc upgrade required a world rebuild you would have |
95 |
> already been subjected to 12-month long threads about it right here on |
96 |
> this list |
97 |
|
98 |
I know, and the GCC upgrade guide is pretty clear on that point, and |
99 |
since I didn't say anything about rebuilding anything other than |
100 |
sys-devel/libtool, which it does specifically mention, I'm not sure why |
101 |
you brought that up in this context. |
102 |
|
103 |
I just did it (rebuilt libtool) anyway, maybe I should do the same for |
104 |
curl and/or php... |
105 |
|
106 |
No worries, apache is only used for local admin stuff anyway, so it |
107 |
isn't like anyone other than me will notice if it dies... :) |