Bug #3087
openlibuuid has a lot of dependencies
0%
Description
libuuid has a lot of dependencies through libdlpi.so:
# ldd /lib/libuuid.so libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libc.so.1 => /lib/libc.so.1 libdlpi.so.1 => /lib/libdlpi.so.1 libmp.so.2 => /lib/libmp.so.2 libmd.so.1 => /lib/libmd.so.1 libinetutil.so.1 => /lib/libinetutil.so.1 libdladm.so.1 => /lib/libdladm.so.1 libdevinfo.so.1 => /lib/libdevinfo.so.1 libscf.so.1 => /lib/libscf.so.1 librcm.so.1 => /lib/librcm.so.1 libnvpair.so.1 => /lib/libnvpair.so.1 libexacct.so.1 => /usr/lib/libexacct.so.1 libkstat.so.1 => /lib/libkstat.so.1 libcurses.so.1 => /lib/libcurses.so.1 libpool.so.1 => /usr/lib/libpool.so.1 libsec.so.1 => /lib/libsec.so.1 libgen.so.1 => /lib/libgen.so.1 libuutil.so.1 => /lib/libuutil.so.1 libsmbios.so.1 => /usr/lib/libsmbios.so.1 libxml2.so.2 => /lib/libxml2.so.2 libavl.so.1 => /lib/libavl.so.1 libidmap.so.1 => /usr/lib/libidmap.so.1 libpthread.so.1 => /lib/libpthread.so.1 libz.so.1 => /lib/libz.so.1 libm.so.2 => /lib/libm.so.2
Please, note: libsmbios.so.1, libxml2.so.2, libcurses.so.1, libscf.so.1.
This libuuid should be rewritten to avoid those dependencies.
Linux's libuuid depends only on libc.
Related issues
Updated by Rich Lowe almost 10 years ago
libuuid is not the problem, libdlpi (and others) are, as you point out. Fix them, if anything.
Updated by Igor Pashev almost 10 years ago
Rich Lowe wrote:
libuuid is not the problem, libdlpi (and others) are, as you point out. Fix them, if anything.
I think libuuid should not depend on libdlpi.
Updated by Rich Lowe almost 10 years ago
The UUID spec requires us to know things that require libdlpi, if I recall correctly.
But look, the root of the problem is is not libuuid! it's not libdlpi!
The real problem library is libdladm, because of the complete misarchitecture of that library.
Updated by Gordon Ross almost 10 years ago
Here's a much more useful bit of output, for any given library:
$ elfdump -d /lib/libuuid.so.1 |grep NEEDED [1] NEEDED 0x355 libsocket.so.1 [3] NEEDED 0x36d libnsl.so.1 [4] NEEDED 0x379 libc.so.1 [6] NEEDED 0x3b7 libdlpi.so.1 $ elfdump -d /lib/libdlpi.so.1 |grep NEEDED [0] NEEDED 0x41e libc.so.1 [2] NEEDED 0x447 libinetutil.so.1 [4] NEEDED 0x468 libdladm.so.1 $ elfdump -d /lib/libdladm.so.1 |grep NEEDED [1] NEEDED 0x3989 libdevinfo.so.1 [2] NEEDED 0x39a2 libc.so.1 [4] NEEDED 0x39e8 libinetutil.so.1 [6] NEEDED 0x39f9 libsocket.so.1 [8] NEEDED 0x3a21 libscf.so.1 [10] NEEDED 0x3a2d librcm.so.1 [12] NEEDED 0x3a39 libnvpair.so.1 [14] NEEDED 0x3a48 libexacct.so.1 [16] NEEDED 0x3a60 libnsl.so.1 [18] NEEDED 0x3a75 libkstat.so.1 [20] NEEDED 0x3a83 libcurses.so.1 [22] NEEDED 0x3a92 libpool.so.1
Yeah, libdladm looks bad.
Maybe try to make libdlapi not depend on libdladm?
Updated by Garrett D'Amore over 9 years ago
libdlpi is probably trying to do "pure" DLPI. Which is actually a pretty evil way of getting MAC addresses... its old STREAMs stuff.
Right now libdlpi is using libdladm to find/iterate over all data link interfaces. It also (bizarrely) uses libdladm to verify that the link is not a style 1 provider. (This is one of the more stupid things I've seen. There is no reason to restrict style 1 -- in fact style 1 interfaces are IMO far preferable to style 2.... style 2 has the old race with dynamic reconfiguration for example.)
Both of those could easily be replaced -- probably with just an hour or so of coding.
But my bigger question is this: why do you care? libdladm (and hence its dependents) are necessary for a regular working system. You can't configure certain types of networking without it. So why would you ever not want to have it on your system?
Updated by Garrett D'Amore over 9 years ago
Actually reading libuuid, it tries to get the ethernet address via arp first. Which is far better.
libdlpi interfaces are only available to root (or users with appropriate rights to access low level devices directly). Whoever thought wiring this in this way was a good idea was nuts.
This is only used in generating version 1 UUIDs. Version 4 work differently.
A probably better way to generate these would be to take the SMBIOS UUID information, and parse out the ethernet/MAC address from it. This is just copying certain bytes from the SMBIOS UUID. On SPARC we can't use SMBIOS, but could instead use the hostid which is pretty much guaranteed to be unique without having to resort to grunging through all mac addresses.
Updated by Richard PALO over 9 years ago
Garrett D'Amore wrote:
Actually reading libuuid, ...
...
A probably better way to generate these would be to take the SMBIOS UUID information, and parse out the ethernet/MAC address from it. This is just copying certain bytes from the SMBIOS UUID. On SPARC we can't use SMBIOS, but could instead use the hostid which is pretty much guaranteed to be unique without having to resort to grunging through all mac addresses.
please bear in mind that there a still a number of pre, or non compliant, SMBIOS 2.3 X86 systems out there
~$ smbios smbios: failed to load SMBIOS: System does not export an SMBIOS table
BTW, the pkgsrc version of libuuid (which I believe is base upon linux libuuid) has these dependencies:
richard@devzone:~/src/pkgsrc/devel/libuuid$ ldd -d /opt/pkg/lib/libuuid.so libnsl.so.1 => /lib/64/libnsl.so.1 libsocket.so.1 => /lib/64/libsocket.so.1 libgcc_s.so.1 => /opt/pkg/gcc47/lib/amd64/libgcc_s.so.1 libc.so.1 => /lib/64/libc.so.1 libmp.so.2 => /lib/64/libmp.so.2 libmd.so.1 => /lib/64/libmd.so.1 libm.so.2 => /lib/64/libm.so.2
Updated by Rich Lowe over 9 years ago
> A probably better way to generate these would be to take the SMBIOS UUID information, and parse out the ethernet/MAC address from it. This is just copying certain bytes from the SMBIOS UUID. On SPARC we can't use SMBIOS, but could instead use the hostid which is pretty much guaranteed to be unique without having to resort to grunging through all mac addresses.
You shouldn't use smbios on x86 either. A pretty large number of systems have badly implemented SMBIOS with non-unique UUIDs (and wide, and varied, further amounts of breakage).
-- Rich
Updated by Gordon Ross almost 3 years ago
- Status changed from New to In Progress
- Assignee changed from Alexander Eremin to Gordon Ross
Updated by Gordon Ross almost 3 years ago
Actually, there's a much, much simpler way to fix this, which is to use code like almost all the other libuuid implementations do, using ioctl calls to get the list of interfaces and the h/w address for each. For example, this code:
https://github.com/cloudbase/libuuid/blob/master/gen_uuid.c
There's really no need to link with libdlpi, and no need to get fancy trying to get a unique system ID.
See the comments in get_ethernet_address about why it's OK for that to fail.