Compiling lsof 4.77 for Solaris 10 6/06 (known internally as update 2)

We found a problem compiling lsof 4.77 for Solaris 10 6/06, see this bug:

  6440943 <sys/kstat.h> should include <sys/types32.h>

When you compile lsof with Sun’s compiler you get “syntax error near caddr32_t”. There’s a similar failure for gcc.

The workaround in the bug allows lsof 4.77 to be compiled.

We also found that you have to recompile lsof for Solaris 10 6/06. Versions compiled for Solaris 10, Solaris 10 3/05 and Solaris 10 1/06 don’t work properly. Here’s a diff of the two different outputs:

*** /tmp/1      Mon Jul 10 14:39:32 2006
--- /tmp/2 Mon Jul 10 14:39:38 2006
***************
*** 12,19 ****
nis_cache 195 root 1u VCHR 0,0 4 /devices/pseudo/cn@0:console
nis_cache 195 root 2u VCHR 0,0 4 /devices/pseudo/cn@0:console
nis_cache 195 root 3u VCHR 0,0 4 /devices/pseudo/cn@0:console
! nis_cache 195 root 4u IPv4 0x600012e4c80 0t0 UDP *:65535
nis_cache 195 root 5r DOOR 0t0 54 /var/run/rpc_door/rpc_100029.2 (door to keyserv[178]) (FA:->0x600011fb0c0)
! nis_cache 195 root 6u IPv4 0x60001ffef00 0t0 UDP *:65535
! nis_cache 195 root 7u IPv4 0x60001ffe100 0t0 UDP *:65535
! nis_cache 195 root 8u IPv4 0x6000095adc0 0t524 TCP *:65535 (CLOSE_WAIT)
--- 12,19 ----
nis_cache 195 root 1u VCHR 0,0 4 /devices/pseudo/cn@0:console
nis_cache 195 root 2u VCHR 0,0 4 /devices/pseudo/cn@0:console
nis_cache 195 root 3u VCHR 0,0 4 /devices/pseudo/cn@0:console
! nis_cache 195 root 4u IPv4 0x600012e4c80 0t0 UDP *:32800
nis_cache 195 root 5r DOOR 0t0 54 /var/run/rpc_door/rpc_100029.2 (door to keyserv[178]) (FA:->0x600011fb0c0)
! nis_cache 195 root 6u IPv4 0x60001ffef00 0t0 UDP *:32975
! nis_cache 195 root 7u IPv4 0x60001ffe100 0t0 UDP *:32977
! nis_cache 195 root 8u IPv4 0x6000095adc0 0t524 TCP mach1:32921->mach2:58028 (CLOSE_WAIT)

The UDP and TCP ports are shown incorrectly. I’ve passed this on to the lsof maintainers.

Advertisements
Leave a comment

3 Comments

  1. ux-admin

     /  July 11, 2006

    Why would one even bother compiling a piece of SW that peeks into private kernel interfaces and is always behind, when there is DTrace?
    Sorry, but that’s pretty pointless.

    Reply
  2. Good point – but bear in mind that DTrace is Dynamic Tracing. In other words, we can dynamically trace the operation of the system. Much of what lsof extracts is static state information related to processes and their open files.
    One possible solution to this would be to rewrite lsof to use Compact ANSI-C Type Format (CTF) – symbolic debugging information available in the kernel and user libraries. One way of doing this would be to write it as an mdb module.

    Reply
  3. Mike

     /  July 12, 2006

    lsof has its place. Yes, you can do everything that lsof can do with DTrace, fuser, etc. etc. That’s not the point, though. lsof is a tool that has been around for years and people use it, like it, got used to it. It’s definitely easier to use than writing a D script.
    Btw. even the older versions of lsof (I also tried 4.76) do not compile on Solaris 10 6/06. My work-around was to just add an #include <sys/types32.h> into machine.h.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

  • Sporadic tweets from me

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

  • Tags of interest

  • Categories

%d bloggers like this: