> On 11/23/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > And I know very little about uclibc, so I'd really prefer if somebody > > more familiar with that system would do the report. > > As fuse becomes more and more popular and it is a base component of > the kernel, it should be developed/tested/supported with uclibc, > klibc and glibc taken into account. You are going to see more and > more initramfs or embedded configurations with fuse.
That's great. Still, that doesn't mean, you can't help with reporting bugs for uclibc. The thing is, even if I add the workaround for this to the fuse source, other libraries using versioned symbols will still break. So it would make sense to fix the problem at it's root. And I don't think fixing it means, that uclibc has to support verioned symbols. In my view correct linking to the latest versions of the symbols should be possible without having to bother about symbol versions at all. This is supported by what 'objdump -t' shows: > objdump -t libfuse.so.2.7.1 | grep -w fuse_main_real 00011530 g F .text 00000028 [EMAIL PROTECTED] 000115c0 g F .text 00000028 [EMAIL PROTECTED] 000115f0 g F .text 00000027 fuse_main_real See, the _latest_ version is without '@'. So if I'm not mistaken, all the dynamic linker has to do is find the symbol without the added version, link with that, and everything should be fine. If it doesn't do that, there's a bug somewhere. > > It's basically mandatory for "normal" usage. People don't want their > > apps to break just because they upgraded a library. > > For source based distributions such as Gentoo, source based RPMs and > DEBs, you don't need this at all... As you always compile/recompile > the packages for the last interface. But 99% of the world uses binary distros, and even on source distros, you might have programs which are not prepackaged, and don't integrate with the rebuilding infrastructure. > So making the library as small as possible is also a goal. I think the overhead is insignificant. > There are older simpler ways to keep your ABI, such as the old plain > don't change the interface, only add new functions way. Which would not really address the bloat issue, and would make porting applications from one version to the next more difficult. But yes, it would at least not have any issues with symbol versioning. Miklos ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
