[erlang-patches] Tiny patch to inet_drv.c for Solaris Open Indiana and Illumos

Raimo Niskanen <>
Fri Nov 25 15:00:56 CET 2011


On Fri, Nov 25, 2011 at 07:15:20AM +0100, Trond Norbye wrote:
> On Thu, Nov 24, 2011 at 6:07 PM, Raimo Niskanen
> <> wrote:
> >
> > I have three problems:
> > 1. On my machine (the only I found with libdlpi (we have not installed
> >  an OpenIndiana box yet)) there is no /lib/libdlpi.so and
> >  /lib/64/libdlpi.so symlinks to the corresponding *.so.1 files
> >  so the linking always fails. I suspect it is an installation issue
> >  so I did the symlinks by hand.
> >    $ uname -a
> >    SunOS fenris 5.10 Generic_142909-17 sun4u sparc SUNW,Sun-Fire-V245
> >  Does this seem reasonable?
> 
> Yes, I just looked at my Solaris 10 box, and it is missing the link
> from: libdlpi.so -> libdlpi.so.1, so one needs to manually create that
> until Sun^H^H^HOracle fix that. (I guess I could add a test for this
> in configure and notify the user if this is the case..)

A theory was suggested here and that is that the *.so.* files satisfy
runtime dependencies and the *.so files are needed for linking against,
so there might be some in the Linux world know as *-devel package(s) missing.

:
> > 3. When I run it does not succeed in finding the hwaddr. Truss shows this:
> >  4146/6:         so_socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP, "", SOV_XPG4_2) = 7
> >  4146/6:         fcntl(7, F_GETFL)                               = 2
> >  4146/6:         fcntl(7, F_SETFL, FWRITE|FNONBLOCK)             = 0
> >  4146/6:         setsockopt(7, SOL_SOCKET, SO_RCVBUF, 0xFEAF9C2C, 4, SOV_DEFAULT) = 0
> >  4146/6:         bind(7, 0xFEAFA020, 16, SOV_XPG4_2)             = 0
> >  4146/6:         getsockname(7, 0xFEAFA020, 0xFEAFAC00, SOV_DEFAULT) = 0
> >  4146/6:         open("/dev/bge0", O_RDWR)                       Err#13 EACCES [net_rawaccess]
> >  4146/6:         open("/devices/pseudo/:bge0", O_RDWR)    Err#2 ENOENT
> >  4146/6:         open("/dev/bge", O_RDWR)                        Err#13 EACCES [net_rawaccess]
> >  4146/6:         open("/devices/pseudo/:bge", O_RDWR)     Err#13 EACCES [net_rawaccess]
> >  Is there some nasty configuration I have missed to do?
> 
> Obtaining the mac address is considered a "privileged" operation as I
> pointed out in my original email. You can verify this by running:
> ifconfig -a as a normal user, and then as a privileged user. The
> normal user will only see:
> 
> bge0: flags=2004841<UP,RUNNING,MULTICAST,DHCP,IPv6> mtu 1500 index 2
>         inet6 fe80::203:baff:fec8:b13d/10
> 
> whereas the privileged shell will give you:
> bge0: flags=2004841<UP,RUNNING,MULTICAST,DHCP,IPv6> mtu 1500 index 2
>         inet6 fe80::203:baff:fec8:b13d/10
>         ether 0:3:ba:c8:b1:3d
> 
> Your truss output also points out that you don't have access (missing
> net_rawaccess). Try adding the privilege to beam and see what happens

Sorry I did not go back and read your original email this time...
This is an old privilege property of Solaris making it hard for our
daily builds and tests.

> 
> pfexec ppriv -s EIP+net_rawaccess <pid of beam>

Excellent! That works like a charm.

:
> 
> I rewrote that block to a bit more "autoconf" like way and added a
> test for the missing symbolic links:
> 
> AS_IF([test $ac_cv_lib_dlpi_dlpi_open = no ],
>       [ dnl Try again now with -L/lib (or ditto 64) as argument to linker since
>         dnl gcc makes ld ignore the crle configured linker default paths
>         save_ldflags="$LDFLAGS"
>         AS_IF([test "x$ac_cv_sizeof_void_p" = "x8"],
>               [
>                  AS_IF([ test -d "/lib64" ],
>                        [ LDFLAGS="-L/lib64 -R/lib64 $LDFLAGS"],
>                        [ AS_IF([test -d "/lib/64"],
>                                [ dnl It looks like solaris 10 is missing some
>                                  dnl links.. let be helpful and notify the
>                                  dnl user if that's the case
>                                  AS_IF([test -f /lib/64/libdlpi.so.1
> -a ! -h /lib/64/libdlpi.so],
>                                        [AC_MSG_ERROR(
> [Your Solaris installation is missing a symbolic link. Please execute
> the following command:
> # ln -s libdlpi.so.1 /lib/64/libdlpi.so
> ])])
>                                  LDFLAGS="-L/lib/64 -R/lib/64 $LDFLAGS"],
>                                [ LDFLAGS="-L/lib -R/lib $LDFLAGS"])])
>               ], [
>                   AS_IF([test -f /lib/libdlpi.so.1 -a ! -h /lib/libdlpi.so],
>                         [AC_MSG_ERROR([
> Your Solaris installation is missing a symbolic link. Please execute
> the following command:
> # ln -s libdlpi.so.1 /lib/libdlpi.so
> ])])
>                  LDFLAGS="-L/lib -R/lib $LDFLAGS"
>               ])
>         unset -v ac_cv_lib_dlpi_dlpi_open
>         AC_MSG_NOTICE([Extend the search to include /lib])
>         AC_CHECK_LIB(dlpi, dlpi_open)
>         AS_IF([test $ac_cv_lib_dlpi_dlpi_open = no],
>               [ LDFLAGS="$save_ldflags" ])
>      ])

Nice, but our minimal autoconf version is 2.59 and I can not find the AS_* macros
in that documentation, so it will have to be the old fashion way...
Here it is again reworked with your additions above:

AC_CHECK_LIB(dlpi, dlpi_open)
if test $ac_cv_lib_dlpi_dlpi_open = no; then
   unset -v ac_cv_lib_dlpi_dlpi_open
   dnl Try again now with -L/lib (or ditto 64) as argument to linker since
   dnl gcc makes /usr/ccs/bin/ld ignore the crle configured linker default paths
   dnl typically causing dlpi not being found on Solaris et.al
   save_ldflags="$LDFLAGS"
   try_dlpi_lib=/lib
   if test "x$ac_cv_sizeof_void_p" = "x8"; then
      if test -d /lib64; then
      	 try_dlpi_lib=/lib64
      elif test -d /lib/64; then
      	 try_dlpi_lib=/lib/64
      fi
   fi
   if test ! -f $try_dlpi_lib/libdlpi.so && test -f $try_dlpi_lib/libdlpi.so.1; then
      dnl It looks like there is a missing symlink
      dnl - let's be helpful and notify the user
      dnl NOTE this help is far from perfect e.g if there would be no
      dnl *.so.1 but a *.so.1.123 or *.so.2 this will be no help
      AC_MSG_ERROR(
	[Your OS installation is missing a symbolic link.
	Maybe it lacks some development package(s)...
	It can anyhow be fixed with the following command:
	# ln -s libdlpi.so.1 $try_dlpi_lib/libdlpi.so
	])
   fi
   LDFLAGS="-L$try_dlpi_lib -R$try_dlpi_lib $LDFLAGS"
   unset -v try_dlpi_lib
   AC_MSG_NOTICE([Extending the search to include /lib])
   AC_CHECK_LIB(dlpi, dlpi_open)
   if test $ac_cv_lib_dlpi_dlpi_open = no; then
      LDFLAGS="$save_ldflags"
   fi
   unset -v save_ldflags
fi

> 
> 
> Cheers,
> 
> Trond
> _______________________________________________
> erlang-patches mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-patches

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB


More information about the erlang-patches mailing list