[erlang-patches] Tiny patch to inet_drv.c for Solaris Open Indiana and Illumos
Raimo Niskanen
raimo+erlang-patches@REDACTED
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
> <raimo+erlang-patches@REDACTED> 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/clone@REDACTED:bge0", O_RDWR) Err#2 ENOENT
> > 4146/6: open("/dev/bge", O_RDWR) Err#13 EACCES [net_rawaccess]
> > 4146/6: open("/devices/pseudo/clone@REDACTED: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
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
More information about the erlang-patches
mailing list