ping?

pong

Okay, Had some odd IRC connection weirdness. All better now.

jperkin: Thank for the VBox settings

danmcd: Thank you for taking time answering the question

hi

i hope you can help me with this, i'm trying to create an overlay device using dladm but it return a varpd error, pastebin.com/RgxGywFF

am i doing anything wrong ?

@psarria anything interesting in varpd's log? ( e.g. "tail `svcs -L varpd`" )

Your dladm for some reason couldn't door-call to varpd. Which is odd.

ret = door_call(client->vcl_doorfd, &darg);

that literally returned EBADF. I wonder if your dladm(8) invocation kicked off the varpd service (which it can do) but it wasn't fully up before it tried to speak to varpd?

Try the dladm again now that varpd is up?

(If you've a slower machine @psarria, that could explain it.)

btw. I just configured keepalived on two bhyve instances in triton (which I created via adminui with mac- and ip-address-spoofing capabilities) - then I reserved a public IP, which I used as the service ip in the keepalived config. and it just worked - failover works flawless

danmcd, thanks a lot for your time, it seems like the dladm create-overlay command generates varpd process core dump, pastebin.com/afRQ2S6q

danmcd, the machine is a empty smartos system doing nothing with 32GB ram and a xeon E3-1271 v3 @ 3.60GHz, it doesn't have any zones

danmcd, i want to think this test machine is enough for this

I'd like the coredump please. I'd also like the revision of the PI you're using. varpd dumping core is a reason you'd get EBADF and I'd like to see the core.

jperkin, I seem to be too pkgsrc-impaired to find the magic to get the link of unbound to ask for xnet before socket. When you get done quelling percona, I would appreciate a look at the sendmsg / xpg4 thoughts.

pjustice: what do you want to do?

Make unbound work. :)

(It's having -lsocket vs -lxnet sendmsg() issues that danmcd thinks are related to the decisions around xpg4_2, sockets, etc.

)

Unbound 1.18 appears to use sendmsg & ancillary data w/o linking to libxnet or at least #define _XPG_2.

linking with `... -lsocket ... -lxnet ...` doesn'

This makes sendmsg() fail with EINVAL as modern ancillary data isn't supported by stock (SunOS 4, 4.3BSD) sockets. :upside-down:

t seem to fix it.

Oh you tried this?

Put -lxnet before or instead of -lsocket.

I tried forcing the extra library in, but I can't seem to get it to be in the LIBS list before -lsocket

because that was my understanding, must be before

Wait.

You actually DO need preprocessor magic. Try this:

-D_XOPEN_SOURCE=600 -D__EXTENSIONS__

(In addition to -lxnet, regardless of order.)

Hmm, good point. But there's still the question of how to bludgeon pkgsrc into doing this.

There's no CFLAGS you can tweak in a makefile?

or CPPFLAGS ?

i think so, though jperkin probably knows the exact syntax for pkgsrc

there's probably illumos-specific examples lurking in there somewhere

like CPPFLAGS.xxxx += -D_XOPEN_SOURCE=600 -D__EXTENSIONS__

just not sure if xxxx should be 'illumos' 'sunos' or something else

though having build problems because __EXTENSIONS__ isn't default reminded me to check

i was trying to build influxdb iox on illumos

and got stuck because croaring-rs won't build because of that

though I think all the fixes have finally filtered through

(they take a snapshot of the c source, include it in the rust repo, then build it with the rust wrappers)

Ok, with enough slimepatching, I got the pkgsrc build to include the CPPFLAGS. That plus -lxnet in the wrong order isn't enough.

pjustice: you can use BUILDLINK_TRANSFORM to change -lsocket into -lxnet -lsocket

try: BUILDLINK_TRANSFORM+= l:socket:xnet:socket

danke!

Ok, I didn't do anything elegant to get here, but with some hackery I got pkgsrc to do a build with the above defs and linking xnet before socket:

libtool: link: gcc -Wl,-rpath -Wl,/opt/local/lib -Wl,-rpath -Wl,/opt/local/lib -I. -I/home/pbulk/build/net/unbound/work/.buildlink/include -D_XOPEN_SOURCE=600 -D__EXTENSIONS__ -DSRCDIR=. -pipe -O2 -msave-args -fno-aggressive-loop-optimizations -std=c99 -D_REENTRANT -Wl,-rpath -Wl,/opt/local/gcc12/lib/gcc/x86_64-sun-solaris2.11/12.2.0 -Wl,-rpath -Wl,/opt/local/lib -o .libs/unbound-anchor

.libs/unbound-anchor.o ...

... .libs/parseutil.o -L/opt/local/gcc12/lib/gcc/x86_64-sun-solaris2.11/12.2.0 -L/home/pbulk/build/net/unbound/work/.buildlink/lib ./.libs/libunbound.so /home/pbulk/build/net/unbound/work/.buildlink/lib/libexpat.so -lm -lssl -lxnet /home/pbulk/build/net/unbound/work/.buildlink/lib/libevent.so -lsendfile -lnsl -lresolv -lpthread -lrt -lsocket -lcrypto ...

... /home/pbulk/build/net/unbound/work/.buildlink/lib/libnghttp2.so /home/pbulk/build/net/unbound/work/.buildlink/lib/libiconv.so -R/opt/local/lib -R/home/pbulk/build/net/unbound/work/.buildlink/lib

...

No j

No joy.

the transform isn't visible in the normal build output

only in the work.log

I just hacked LIBS and CPPFLAGS in the Makefile.in. The compiles did include the defs, and the links did include the -lxnet before -lsocket (I just grabbed the last line for above, so it's not the daemon, but the commands for all the links are pretty much the same other than which .o files are linked, and the name of the output file.)