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

[Heiko Z. <he...@zu...>]

Hey,

I did a quick test about going to glibc 2.14.1.
Unfortunately a lot of things are breaking, so this is not really an option
since I don't want to delay the 1.6 release any further.

Hopefully you'll find a better solution to the issue.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

> -----Original Message-----
> From: Andrzej Odyniec [mailto:an...@ma...]
> Sent: Friday, February 17, 2012 9:41 AM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Problem with mount.cifs
> 
> 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
> 
>
----------------------------------------------------------------------------
--
> Virtualization & Cloud Management Using Capacity Planning Cloud computing
> makes use of virtualization - but cloud computing also focuses on allowing
> computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop