rmustacc: (just in case you have any thoughts on this)... the sff page a2 values have a few dependencies on values from page a0 for interpretation (which causes some challenges with the current libsff api) for SFPs at least.. qsfp has potentially different challenges...

just to mess around a bit with the data (i.e. I'm not convinced this is the way to go)... I just changed things slightly to optionally allow an existing nvlist_t to be passed back into the libsff_parse() so it can get the values from page a0 (if an nvlist was passed in and it contained the resulting keys from parsing page a0)

(additional data for qsfps would require writing to the transceiver if I'm reading things correctly, so that's a whole other deal, questions, etc, so avoiding that for now)

out of curiosity, has anyone tried to build the latest influxdb (the new rust version) on illumos?

(tried recently)

last time I tried, it required a fair amount of uhm.. persuasion, and the resulting binaries were absolutely massive (> 1GB -- the release binaries)... wondering if things have changed/improved any..

A Influxdb IPS pkg manager package from the OI repositories would be nice.

The mongodb IPS package is outdated and can't be installed.

On OI.

root@openindiana ~ # pkg list -a | grep influx -> Empty.

last time I tried, it was largely dependency issues from what I recall..

Aedil: Looking forward to your packages :)

Aedil, there are influx-cli-2.3.0 and influxdb-1.8.4nb39 , says pkgin with pkgsrc package manager on SmartOS . You can take a look there for maybe porting to IPS. Maybe upgrade that to latest and port

Maybe I can contribute a IPS package in future. But right now I am not educated enough to do that.

Aedil: docs.openindiana.org/dev/userland and the pkgmogrify manpage and all things start falling into place :)

alanc did you or somebody from the solaris team at some point add full 64bit symboltables or other work to support large PIC code like rustc? Something like GOT22?

toasterson: Thank you for your information.

toasterson: that question doesn't make sense

the only GOT22 I know of is a SPARC relocation with a marginally larger displacement than usual

which I assume is what you mean because "large pic"

but it's been supported for ever?

richlowe: I think I am still not quite read up on the details exactly. But basically Klaus and I managed to trigger a linker error while cross-compiling to sparc namely (.text+0x70): relocation truncated to fit: R_SPARC_GOT13 against symbol `___Argv' defined in .bss section in /opt/illumos//sysroot/usr/lib/sparcv9/crt1.o using sunstudio compiler made this pass but that seems like a bad idea since after that we trigger alignment issues.

right, that would probably want the got22 relocation from a larger model

ah, but it's the crt, so probably you need to explicitly go do that

How would we do that? :)

probably need to build common-crt.o etc with the large model

does x86 already do that in the makefiles?

i can't recall if i've asked, but would there be interest in adding an option to SMF (really svc.startd) to control the timestamp format used in svc logs (e.g. use ISO timestamp format) ?

toasterson: I don't think x86 needs a larger model

jbk: I always love an ISO format timestamp

richlowe: ah, ok so how does one enable that larger model on SPARC?

certainly not anything I did nor remember hearing about

-mcmodel=large maybe?

I dunno, the GCC manual will

just tried the influx stuff again..

and yeah, the bespoke way of building C stuff with rust is breaking on omnios

why bespoke can be so bad

tbh, i don't think i've ever seen it work on illumos, but probably don't do enough

(where cargo tries to build C stuff with custom rust code)

Aedil, would be fun maybe upgrading influxdb package on SmartOS and use that later. Besides, you can bootstrap pkgsrc on other illumos distro and happily use pkgsrc packages, too. I used to do that for years. See Standard and then, Standard(upgrade) , pkgsrc.smartos.org/install-on-illumos

(yeah, now I remember.. some crate is trying to use protobufs, but to get the standard definitions, flags need to be passed to protoc, but since they use build.rs (basically a rust program that's compiled and then run to build things, it has no provision for passing that down (short of modifying the program)

(vs being able to override/supplement things with make)

jbk: most of it is using standardized crates now still bespoke to the language but manageable. usually there are variables to make it use prebuilt versions and set okg_config paths etc.

nikolam: Thank you. I will have a look at that HOWTO.

richlowe: does that -mcmodel=large even work on a file like mach-crt1.S ? would that not need manual adjustment?

no, but it's probably crt-common.c that needs it

yeah, i'm not seeing anythig.. though i suppose a question is should protoc implicitly be searching where the 'built-in/default' definitions are

e.g. like how gcc implicitly has -I/usr/include unless told otherwise

richlowe: thanks found where I need to put C_BIGPICFLAGS :)

jbk: protoc has it's own way of finding things. Last time I tried protoc it just kinda worked on OpenIndiana. Whats the error that you get?

so digging further

where is protoc installed on openindiana?

/usr/bin ?

actually that might not matter...

that's the problem

it _is_ in fact supposed to look at (to borrow our linker's nomenclature) $ORIGIN/../include

by default for .proto files

and that's how it's adding that path

so on illumos, we don't get that added

of course, if you explicitly add -I/usr/include or whatever

it's fine

assuming you can easily do that

jbk: it's in /usr/bin/protoc

what path do you need to add for protoc files?

so teh fix is to make that work

we have proto files under usr/include/google/protobuf/wrappers.proto for example

yes, and on omni, that's all under /opt/ooce

and because that code I pasted fails on illumos, it won't find those unless you explictly tell it to

(which isn't always easy)

I mean, interacting with google can be unpleasant, but it seems like fixing protoc is the way?

because it's several levels deep in some dependency of a build

yeah

having waded through the C++ to figure out it was supposed to do that (not really documented)

i'm going to put up some PRs and patches

Yeah there is only really -I that you can append to the protoc call as argument

is it the tonic or prost crates?

jbk: I feel like Oracle added some timestamp improvements to their SMF already; might be worth looking to see if it's worth being compatible

jbk: if it's either tonic or prost than you can set export PROTOC_INCLUDE=/opt/ooce/include just for this case before cargo build

jclulow: I see $SMF_SVCS_DATE_FMT (for svcs) but nothing else (though if anyone is aware of anything else, yeah -- no need to be different if there's not a good reason)