-enabled/php5.load: Cannot load
/usr/lib/apache2/modules/libphp5.so into server:
/lib/i686/cmov/libm.so.6: symbol __strtod_nan, version GLIBC_2.0 not
defined in file libc.so.6 with link time reference
(wrapped for better readability).
apparently caused by fix of bug #813187
--
Matus UHLAR
Matus UHLAR - fantomas a écrit :
I just thought that there's no logical reason to reordering addresses if
resolver does not know network topology. So I'd like to know the reason for
reordering. Is it the way how resolver manipulates addresses, so it stores
them in reverse order?
On 02.06.06
On Thu, Jun 01, 2006 at 11:54:59AM +0200, Matus UHLAR - fantomas wrote:
Nothing relies. It's just if you will receive addresses in some order, you
should not reorder them unless you know what order they should be delivered
in (e.g. ordering via RFC3484)
On 02.06.06 14:37, Gabor Gombas
Matus UHLAR - fantomas a écrit :
Nothing relies. It's just if you will receive addresses in some order,
you should not reorder them unless you know what order they should be
delivered in (e.g. ordering via RFC3484)
On 01.06.06 18:30, Aurelien Jarno wrote:
Where have you seen the resolver
On Wed, May 31, 2006 at 11:28:44PM +0200, Matus UHLAR - fantomas wrote:
Searching mailinglists, bug databases did not give me correct answer.
Does glibc sorty/reorder IP addresses gotten from DNS?
Is this fixed in any newer versions of glibc?
On 01.06.06 11:39, Gabor Gombas wrote:
AFAIK
) are
trying to connect the wrong server as first...
Searching mailinglists, bug databases did not give me correct answer.
Does glibc sorty/reorder IP addresses gotten from DNS?
Is this fixed in any newer versions of glibc?
Thank you.
--
Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http
6 matches
Mail list logo
