| 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... :) |
Archives