[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: future of libfreebsd



Petr Salinger a écrit :
> It would be nice to confirm my expectation.
> It depends how costly it is.
> 

Here is te list:

* afuse
  linked with libfreebsd0 without reasons (through libfuse2 ?)

* consolekit
  sysctlnametomib
  devname

* curlftpfs
  linked with libfreebsd0 without reasons (through libfuse2 ?)

* freebsd-net-tools
  link_ntoa
  link_addr

* freebsd-utils
  devname
  sysctlnametomib

* fuse-convmvfs
  linked with libfreebsd0 without reasons (through libfuse2 ?)

* fusedav
  linked with libfreebsd0 without reasons (through libfuse2 ?)

* gphotofs
  linked with libfreebsd0 without reasons (through libfuse2 ?)

* kldutils
  sysctlnametomib

* libfuse2
  sysctlbyname (instead of the libc version ?)
  devname_r

* libgtop2-7
  sysctlbyname (instead of the libc version ?)

* libkvm0
  sysctlbyname (instead of the libc version)
  getbootfile
  devname
  sysctlnametomib

* mhddfs
  linked with libfreebsd0 without reasons (through libfuse2 ?)

* miredo
  devname_r

* python-fuse
  linked with libfreebsd0 without reasons (through libfuse2 ?)

* qemu
  devname

* rofs
  linked with libfreebsd0 without reasons (through libfuse2 ?)

* sshfs
  linked with libfreebsd0 without reasons (through libfuse2 ?)


In short with devname/devname_r/sysctlnametomib in glibc 2.10,
libfreebsd0 is only needed for freebsd-net-tools and libkvm0. We should
probably migrate the remaining symbols here.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: