Re: [Devil-linux-develop] Problem with mount.cifs

[Andrzej O. <an...@ma...>]

Heiko,

> I don't see a reason why the 32bit version should differ from the  
> 64bit, but of course there could always be a problem with a configure  
> script.

I don't see, too.

> Do you think the problem is in the glibc? We could try building with  
> 2.14.1 and see if that fixes the issue.

Yes, I think, but I'm don shure yet. This need some tests or debug.

There is no doubt: mount.cifs before any mounting is making the following:
-- cd to mountpoint directory and after
-- realpath of directory "."

And this error message is preset only in one place: after unsuccesfull realpath.

mount.cifs has no his own realpath (as many packages have), but is using one 
from libc linked dynamically:

> root:/build/tmp# objdump -t cifs-utils-5.3/mount.cifs |grep realpath
> 00000000       F *UND*  00000000              realpath@@GLIBC_2.3

and this version of realpath is needed by mount.cifs.
> root:/build/tmp# objdump -t /lib/libc-2.12.2.so |grep realpath
> 00000000 l    df *ABS*  00000000              realpath_chk.c
> 00037960 l     F .text  00000512              __realpath
> 00108080 l     F .text  00000041              __old_realpath
> 00108080 g     F .text  00000041              realpath@GLIBC_2.0
> 00037960 g     F .text  00000512              realpath@@GLIBC_2.3
> 000e3030 g     F .text  00000038              __realpath_chk

As You remebmer, standardizers changed last argument of realpath, 
disallowing/allowing null pointer. old-realpath disallows this but realpath 
allows. mount.cifs uses null pointer in this place. So realpath@@GLIBC_2.3 
used by mount.cifs in libc points to __realpath. This is correct.

libc-*.so is the only library in system, which has .text for *UND* named 
realpath@@GLIBC_2.3, so problem must be in dynamic linking of this entry or in 
the libc. As for now I'm not sure, where is problem. Error can be in broken 
__realpath binaries (not in __old_realpath), assuming compiler code generator 
error, or in dynamic linker too.

Anyway, in source code, (look at glibc-*/stdlib/canonicalize.c) this error 
(EINVAL) is returned in two places only: in __realpath, when first parameter 
is null and in __old_realpath, when the second parameter is null (this is our 
situation). __old_realpath is cover for __realpath.

If this same binaries of mount.cifs in build system work but in main system -- 
does not --- problem is probably with linked library.

But as you know, there is no certainty.

Best regards

-- 
Andrzej Odyniec