<basshelal[m]>
I know from experience that getting a GNU/Unix environment on Windows can either be really easy or really goddamn convoluted
<basshelal[m]>
demon36: Actually please do write how you got the build running on Windows if you can, ideally in a github repo or gist, so that if we have to do it later and run into problems we at least know how to get something working.
<basshelal[m]>
<headius> "ok M1 mac is up and running, so..." <- headius: Can aarch64 darwin build for x86_64 darwin or do you have to do that whole fat binary nonsense?
sagax has quit [Excess Flood]
RobertNicholas[m has quit [Quit: You have been idle for 30+ days]
GGibson[m] has quit [Quit: You have been idle for 30+ days]
<demon36[m]>
sure will do that
<demon36[m]>
headius PR tests pass in my local env but fail in CI, guessing its caused by using system provided libjffi which lack the recently added methods, log does not seem to be available
MatrixTravelerbo has quit [Quit: Bridge terminating on SIGTERM]
ahorek[m] has quit [Quit: Bridge terminating on SIGTERM]
lopex[m] has quit [Quit: Bridge terminating on SIGTERM]
enebo[m] has quit [Quit: Bridge terminating on SIGTERM]
ChrisSeatonGitte has quit [Quit: Bridge terminating on SIGTERM]
BlaneDabneyGitte has quit [Quit: Bridge terminating on SIGTERM]
XavierNoriaGitte has quit [Quit: Bridge terminating on SIGTERM]
JesseChavezGitte has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m] has quit [Quit: Bridge terminating on SIGTERM]
byteit101[m] has quit [Quit: Bridge terminating on SIGTERM]
OlleJonssonGitte has quit [Quit: Bridge terminating on SIGTERM]
JulesIvanicGitte has quit [Quit: Bridge terminating on SIGTERM]
liamwhiteGitter[ has quit [Quit: Bridge terminating on SIGTERM]
kares[m] has quit [Quit: Bridge terminating on SIGTERM]
CharlesOliverNut has quit [Quit: Bridge terminating on SIGTERM]
danieljrubyquest has quit [Quit: Bridge terminating on SIGTERM]
fzakaria[m] has quit [Quit: Bridge terminating on SIGTERM]
MattPattersonGit has quit [Quit: Bridge terminating on SIGTERM]
MarcinMielyskiGi has quit [Quit: Bridge terminating on SIGTERM]
rebelwarrior[m] has quit [Quit: Bridge terminating on SIGTERM]
RomainManni-Buca has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m]1 has quit [Quit: Bridge terminating on SIGTERM]
headius has quit [Quit: Bridge terminating on SIGTERM]
UweKuboschGitter has quit [Quit: Bridge terminating on SIGTERM]
jrgriffiniii[m] has quit [Quit: Bridge terminating on SIGTERM]
JasonvanZyl[m] has quit [Quit: Bridge terminating on SIGTERM]
FlorianDoubletGi has quit [Quit: Bridge terminating on SIGTERM]
kalenp[m] has quit [Quit: Bridge terminating on SIGTERM]
basshelal[m] has quit [Quit: Bridge terminating on SIGTERM]
KarolBucekGitter has quit [Quit: Bridge terminating on SIGTERM]
kai[m]1 has quit [Quit: Bridge terminating on SIGTERM]
demon36[m] has quit [Quit: Bridge terminating on SIGTERM]
lopex has joined #jruby
ahorek[m] has joined #jruby
enebo[m] has joined #jruby
kai[m]1 has joined #jruby
MatrixTravelerbo has joined #jruby
lopex[m] has joined #jruby
CharlesOliverNut has joined #jruby
jrgriffiniii[m] has joined #jruby
JesseChavezGitte has joined #jruby
KarolBucekGitter has joined #jruby
OlleJonssonGitte has joined #jruby
liamwhiteGitter[ has joined #jruby
rebelwarrior[m] has joined #jruby
XavierNoriaGitte has joined #jruby
fzakaria[m] has joined #jruby
MarcinMielyskiGi has joined #jruby
JulesIvanicGitte has joined #jruby
FlorianDoubletGi has joined #jruby
byteit101[m] has joined #jruby
kalenp[m] has joined #jruby
MattPattersonGit has joined #jruby
BlaneDabneyGitte has joined #jruby
basshelal[m] has joined #jruby
kares[m] has joined #jruby
danieljrubyquest has joined #jruby
JasonvanZyl[m] has joined #jruby
UweKuboschGitter has joined #jruby
ChrisSeatonGitte has joined #jruby
TimGitter[m] has joined #jruby
demon36[m] has joined #jruby
RomainManni-Buca has joined #jruby
headius has joined #jruby
TimGitter[m]1 has joined #jruby
<headius>
Yeah that is what I figured too. Will look into it today
<headius>
basshelal: I believe it is possible to build for either aarch64 or x86_64 but jffi currently is shipping a fat binary that does both and I don't see an issue with that
<headius>
demon36: I need to spin some releases of jnr stuff in advance of the JRuby 9.3 release... I think it would be best to branch off before your jni-heavy null-terminator code since that is not critical for JRuby and then we can focus efforts on master toward improving the native build situation
<headius>
enebo: seem reasonable to you as well?
<enebo[m]>
headius: yeah
<headius>
the fire will be lit to get the jffi native build more manageable but we will have a branch for the 1.3 series that is not too different from what we have in JRuby now
<enebo[m]>
headius: so you also mean main branch will end up being a new major since it may make larger changes
<headius>
actually I misspoke, this will affect jnr-ffi because demon36 original fix was to do everything for null terminators from java
<headius>
the problem with that logic is that it calls out to jni once to get strlen and then calls again to get the contents plus appropriate length null terminator
<headius>
the binary changes coming in jffi will do that in one shot but we need to be able to evolve the binary more easily
<headius>
so jnr-ffi could be released with or without that fix since I don't think it affects JRuby
<enebo[m]>
so that is better I guess than branching if it really doesn't affect us
<headius>
I will confirm that and ship with demon36 change if it is benign to us
<enebo[m]>
I guess ultimately if this change is really just a fix then branching perhaps only makes sense in if it affects us (maybe) right before a release
<headius>
it is a fix but adds overhead to string-reading operations due to the extra call
<headius>
but I am unsure if we use this call the way that is affected... that's what I will check
<enebo[m]>
ok
<enebo[m]>
lunch
<headius>
hah ok, it never merged anyway... I forgot the PR was never green because of a missing import and then demon36 discovered the overhead
<headius>
so this is a non-issue for update releases today
<headius>
I will review issues and PRs for all jnr and push updates
<headius>
basshelal: you seem to have concerns like I do about fzakaria removal of the default paths... where do we stand on this?
<headius>
perhaps it is safest to release without that PR while we discuss
<basshelal[m]>
I agree with fzakaria but I hate that Darwin doesn't have any way to configure lib paths in an elegant way like GNU/Linux does with `/etc/ld.so.conf`
<basshelal[m]>
I was thinking of something else though that kind of keeps both, kind of like soft coded values.
<basshelal[m]>
Basically have a `Unix` platform and add a method there like `traditionalLibPaths()` or something of the sort that will return a list of these paths, subclasses like `Darwin` or `BSD` can choose to reimplement.
<basshelal[m]>
This keeps the purity while also keeping a sane fallback
<basshelal[m]>
In the path searching code we remove the hardcoding, so keep fzakaria 's change, but now user's can access these Unix paths when they load or search for libraries by adding that list in the additional paths.
<basshelal[m]>
These paths are `/usr/local/lib` `/usr/lib` `/lib/` and some other friends I think
<headius>
so what I am getting is that we still have a bit of discussion before we nuke the hardcoded paths
<headius>
I did have concerns about wiping them out with zero fallback
<headius>
having some Platform-level traditional default paths seems like a good idea, and perhaps an option that can be set to ignore all default paths
<headius>
fzakaria: when you are around ping us so we can chat a bit more... I will proceed with a 1.3.5 release that does not include your change but I think we are close
<basshelal[m]>
Yeah I was thinking of an option or something like that
<basshelal[m]>
Oh, do try running
<basshelal[m]>
```
<basshelal[m]>
```
<basshelal[m]>
oops
<basshelal[m]>
java -XshowSettings:properties
<headius>
you are right I do not see traditional paths
<basshelal[m]>
on your macOS and show us what you get, I'm still wary I'm doing something wrong
<basshelal[m]>
well it's not reliable that's for sure
<basshelal[m]>
if you even install any dylibs from homebrew chances are they'll go into one of the traditional unix paths
<basshelal[m]>
That's why I did this, because libjack wasn't being detected
<headius>
so we know at least openjdk/hotspot on Darwin does not include traditional paths, that is reason enough for me to reexamine the removal
<headius>
I could be convinced that the remaining library-search logic is rock solid but I am not there yet
<basshelal[m]>
Well let's wait to see what fzakaria has to say, don't merge for now, but the final call is always yours
<headius>
yeah no merge, I will spin 1.3.5 without it
<headius>
if we sort this out it could go into JRuby 9.3.1, that's not a big issue
<fzakaria[m]>
hi.
<fzakaria[m]>
I added some more comments to the PR
<headius>
fzakaria: darwin is dumb
<basshelal[m]>
hello 😊
<headius>
looking at your comments
<fzakaria[m]>
tbh -- I don't think I ever see a case for something being hardcoded when Java itself is configured through system properties already with sane defaults.
<headius>
ok I think we are on the same page... just needs more hardening before we merge but only because Darwin (that we know of) is kinda goofy
<headius>
yeah but just running java without extra properties it is not giving any standard paths
<fzakaria[m]>
This also seems to be tailoring to something maybe Homebrew is doing.
<headius>
arguably it should, but there may be a reason they do not
<headius>
basshelal: does your java.library.path also include `.`?
<basshelal[m]>
headius: yes on both JVMs, I didn't think too much of it
<headius>
basshelal: seems like having `.` in PATH which is generally not a good (i.e. insecure) thing to do
<headius>
someone just has to drop a malicious library in . and then you might load something you didn't expect
<headius>
fzakaria: yeah I can't explain that
<headius>
that clearly is not the only source for `java.library.path` but in this case it doesn't seem to be observed at all
<fzakaria[m]>
I'm not sure how you both got your JDK or who built it --
<fzakaria[m]>
AdoptOpenJDK offers prebuilt binaries you can download and try.
<basshelal[m]>
headius: `.` being like the current dir where the jvm is located right?
<fzakaria[m]>
(I would offer to help but I don't have MacOS)
<headius>
FWIW my `man ld` does not include the list in that comment, but it does mention that it will default to trying /usr/lib and /usr/local/lib
<fzakaria[m]>
it's a macro so conceivably someone could have set it on the g++ arg
<headius>
Search paths
<headius>
ld maintains a list of directories to search for a library or framework to use. The default library search path is /usr/lib then /usr/local/lib.
<headius>
I do not know whether this is at play here or not
<headius>
basshelal: `.` as in `user.dir`
<basshelal[m]>
So theoretically `dlopen` does go through those 2?
<headius>
so whereever you are running from it might search that dir for libraries when loading
<headius>
basshelal: yeah that is what I am wondering
<headius>
if they did this because dlopen will check those paths anyway on Darwin this may be a non-issue (but still weird)
<headius>
not sure it helps us though because we want to find the actual path to libraries and would need our own (i.e. hardcoded) /usr/lib and /usr/local/lib to do it
<headius>
we don't just defer to dlopen to do the search
<fzakaria[m]>
To move this forward -- should i just change the `if condition` to Darwin and open a new issue?
<basshelal[m]>
To quickly solve your issue yeah I'd say that would work, but we need to properly tackle this
<headius>
agreed
<headius>
I would be fine merging this if we excluded Darwin for now, but it seems like a half-measure
<basshelal[m]>
It is, but if it helps NixOS and doesn't harm GNU/Linux now we can merge it and then continue on a better fix
<basshelal[m]>
Is my proposed fix not viable? headius
<headius>
I tweeted a question about this and can escalate to openjdk folks at Red Hat but I do not know who maintains the Darwin port right now
<headius>
basshelal: no I meant I agree your proposed fix would be fine if it works for fzakaria
<headius>
fzakaria: if we shipped 9.3 without changing this at all does that impact you?
<fzakaria[m]>
(afk 5 mins)
<fzakaria[m]>
(back)
<fzakaria[m]>
I'm in no rush to merge it for this release as long as there's an opportunity within something reasonable to get another chance to merge.
<fzakaria[m]>
(not 1+ year out between releases)
<headius>
ooo RHEL folks finally reviewed my posix_spawn PR
<headius>
fzakaria: we expect 9.3.1 will be needed **very** soon after 9.3
<fzakaria[m]>
Shouldnt you have priority for RHEL review being a RH employee ? O.o
<headius>
we just want to get it out the door
<headius>
hah well RHEL is pretty tightly controlled and I am just a lowly JVM language guy 😀
<headius>
fzakaria basshelal: then for simplicity I will not merge this until we agree on a good answer for the Darwin problem and we will ship 9.3 without it
<fzakaria[m]>
Good luck with the release :)
<headius>
thanks! need to address these few posix_spawn comments and then I think everything is up to date