Steve Gonczi wrote: > Looks like there is a missing extern in > usr/src/lib/sun_sas/common/devtree_device_disco.c > > extern scsi_lun_t scsi_lun64_to_lun(scsi_lun64_t lun64); > > The extern above appears in usr/src/lib/libdevid/libdevid.h, > (it looks like it is #included as <libdevid.h>, but I see no evidence > of libdevid.h actually being included) .
libdevid.h is definitely included there, on line 33 http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/sun_sas/common/devtree_device_disco.c#33 http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdevid/libdevid.h has the extern definition of scsi_lun64_to_lun() on line 65, and the function itself is defined at http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/common/devid/devid_scsi.c#1444. > BTW can someone cast some light how an #include statement can silently fail? > I have seen this occasionally, and include file is not found, but there is > no error message, I just > find out indirectly, when things that should be defined go missing. Strange. The #include should work, or not work, but never fail silently. > Also, I see what appears to be a build race when doing a full nightly. Seems > that at the > time the build is trying to link /opt/SUNWspro/bin/cc -o libsun_sas.so.1 ... > The libdevid library is not yet built, so the link step is unable to resolve > the above symbol. > > If I do a single threaded build of the libraries using plain make, it all > works, > (given that I add the extern) > this is only an issue with a multi-threaded build. I am building on an 8 cpu > nehalem box. How high is your dmake maxjobs setting? How are you running the build? We haven't seen this problem on the gate machines, so more information would be handy to have. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
