Project

General

Profile

Bug #3087

libuuid has a lot of dependencies

Added by Igor Pashev about 7 years ago. Updated about 4 years ago.

Status:
New
Priority:
Normal
Category:
-
Start date:
2012-08-17
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

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

Has duplicate illumos gate - Bug #4007: libuuid should not infect binaries with so many link dependenciesClosed2013-08-07

Actions

History

#1

Updated by Rich Lowe about 7 years ago

libuuid is not the problem, libdlpi (and others) are, as you point out. Fix them, if anything.

#2

Updated by Igor Pashev about 7 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.

#3

Updated by Rich Lowe about 7 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.

#4

Updated by Gordon Ross about 7 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?

#5

Updated by Garrett D'Amore almost 7 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?

#6

Updated by Garrett D'Amore almost 7 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.

#7

Updated by Richard PALO almost 7 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

#8

Updated by Rich Lowe almost 7 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

#9

Updated by Alexander Eremin about 4 years ago

  • Assignee set to Alexander Eremin

Also available in: Atom PDF