Fork me on GitHub
#graalvm
<
2019-06-26
>
sogaiu08:06:11

@borkdude @rahul080327 i have processed more of the dll-loading-related info -- especially the "exceptions" portion (and the short intro before it) in the numpy windows dll doc. there is some terminology that i'll use below which comes from the numpy windows dll doc, so please take a look or ask what something means 🙂 i also have a list of dlls that got used via openjdk in a case where clj-kondo.exe worked -- this is a total of 30 files (https://pastebin.com/Btn66zQA) under 1 MB total in size. likely also necessary would be msvcr100.dll which is under 1 MB. this info was obtained by examining output from dependency walker. other dlls also showed up, so if you want to have a look, i still have dependency walker output from a clj-kondo.exe that worked and one that didn't. i can post them somewhere if needed. for reference, the top-level dll dependencies of clj-kondo.exe appear to be: advapi32.dll, WS2_32.dll, IPHLPAPI.dll, MSVCR100.dll, MSWSOCK.dll, and kernel32.dll -- of these, on the win 10 system here, advapi32.dll, WS2_32.dll, and kernel32.dll show up as "known dlls". iiuc, MSVCR100.dll is from the vs c++ 2010 redistributable. the remaining IPHLPAPI.dll and MSWSOCK.dll, i presume get resolved via c:\windows\system32 in the s3o or similar order. regarding dll-loading, it appears there are broadly 2 paths one might take for implicit loading (i think that's the current case): one either uses side-by-side assemblies, or one doesn't. if one doesn't, it looks like the application is subject to "already-loaded" dlls and "known dlls" without exception (see the numpy windows dll doc). so far it's not clear the "known dlls" would be a problem. the "already-loaded" dlls though, i think this may account for the variable behavior i was observing. haven't replicated this since reading about it though. on the surface it doesn't seem like the kind of set up one would want. if one chooses to use side-by-side assemblies, presumably the path of a private assembly would be taken. although one may be subject to shared assemblies being searched before searching one's own private assemblies, it seems possible that if clj-kondo defines its own pirvate assembly, there shouldn't be any hit in a search of a shared assemblies (assuming one doesn't place something that would hit it there) so finding inappropriate dlls seem unlikely. with what i understand so far, it seems side-by-side assemblies would provide a stabler execution environment. one thing i'm still quite unclear on is the transitive dependencies of dlls on other dlls and whether that's likely to be a problem in this case. i recommend checking out the wikipedia article on dll hell (https://en.wikipedia.org/wiki/DLL_Hell) -- it has a solutions section too.

sogaiu09:06:01

btw, i tried putting those 30 + 1 dlls in a folder w/ clj-kondo.exe downloaded from releases in a w10 vm. launching worked 🙂

lispyclouds09:06:09

Awesome @sogaiu! I think we can go the packaging way!

sogaiu09:06:45

may be so -- still not sure about the side-by-side and transitive thing though

lispyclouds09:06:56

to be able to be define assembly manifests within the graal executable we need some support from the graal compiler i guess

lispyclouds09:06:24

currently i dont know of compiler and/or linker options we can pass to it

sogaiu09:06:27

i wasn't sure -- it looked like may be you could just drop a file in the same folder

lispyclouds09:06:59

yeah that looks like the safe way to go now

lispyclouds09:06:18

till the graal compiler has msvc like options i guess

sogaiu09:06:39

yeah, the graal stuff could use some appropriate changes 🙂

sogaiu09:06:00

may be it's actually a few files -- application manifest + assembly manifest at least

lispyclouds09:06:35

@borkdude do you wanna try the exe + DLLs scoop bundle?

sogaiu09:06:21

may be one or the other of you can replicate first? i am trying one more time here.

lispyclouds09:06:03

we can try on appveyor. thats the actual build env after all

sogaiu09:06:25

ok. i just tried again -- thankfully it worked again 🙂

sogaiu09:06:01

ah, possibly a couple more issues: 1) 32-bit situation might require some different things? 2) didn't test --lint and other options...don't know if that would bring in more dlls -- both powershell core and openjdk had more dlls that might be relevant

lispyclouds09:06:28

for 1, i think for simplicity and maintenance reasons lets support 64 bit only. for 2 if i understand correctly all the (required and possibly required) DLLs are loaded at launch time. so should be okay i guess

lispyclouds09:06:04

catering to 32bit windows is just an unnecessary headache IMO

lispyclouds09:06:31

but there could be an explicit load call to a DLL which may cause the delayed load, so worth testing

sogaiu10:06:26

makes sense to me :)

borkdude11:06:47

ok, let's only support 64bit. if the appveyor build works in a bare Windows 10 machine, I'm happy (since that's what most people are using as a dev env on Windows I assume). I don't have time to mess around with scoop right now, maybe next weekend or the weekend after

borkdude11:06:48

thanks for figuring this stuff out so far 🙂

lispyclouds11:06:45

I can give this a shot maybe early next week.

borkdude11:06:37

as a first step, we could maybe document which dlls should be copied, and let people verify that this works, and then automate it (using installer or scoop). installer might be the most fancy way 🙂

borkdude11:06:59

but updating via an installer might be more painful? as clj-kondo updates quite frequently

borkdude11:06:09

chocolatey might also work

borkdude11:06:13

maybe including the dlls in the zip on appveyor is a small step? don't know which dlls though

lispyclouds11:06:40

for reference, the top-level dll dependencies of clj-kondo.exe appear to be: advapi32.dll, WS2_32.dll, IPHLPAPI.dll, MSVCR100.dll, MSWSOCK.dll, and kernel32.dll -- of these, on the win 10 system here, advapi32.dll, WS2_32.dll, and kernel32.dll show up as "known dlls".  iiuc, MSVCR100.dll is from the vs c++ 2010 redistributable.  the remaining IPHLPAPI.dll and MSWSOCK.dll, i presume get resolved via c:\windows\system32 in the s3o or similar order.
from @sogaiu

borkdude11:06:27

so these are the only ones missing after installing vs c++ 2010 redist? > the remaining IPHLPAPI.dll and MSWSOCK.dll, i presume get resolved via c:\windows\system32 in the s3o or similar order.

lispyclouds11:06:52

they look like pretty core libs. hopefully they are present on the target systems

borkdude11:06:54

if everything's already present, it doesn't explain the problems that were manifesting?

sogaiu11:06:24

@borkdude just to be clear, the ones via the pastebin link (there are 30) are not in vs c++ redist afaik

sogaiu11:06:44

i'm not sure where they come from, but powershell core 6 and openjdk have them

borkdude11:06:20

maybe this is worth following up in the issue of graal proper? https://github.com/oracle/graal/issues/1407

sogaiu11:06:44

i am thinking to look into where they come from -- just want to rest a bit first 🙂

sogaiu12:06:42

hmm...iiuc,the first reponse at the following seems to suggest distributing those 30 dlls may be not in compliance with some licensing... https://social.msdn.microsoft.com/Forums/en-US/a28331ae-19a3-4a34-b3ba-1e8fd4430375/missing-apimswincore-dlls -- will keep digging

borkdude12:06:02

making a script that downloads them is not the same as packaging right?

lispyclouds12:06:14

yeah but technically we are distributing them via Github releases

lispyclouds12:06:33

as packaged stuff

borkdude12:06:51

via scoop we might be able to download them

lispyclouds12:06:54

yeah then scoop should be the only way of usage then

borkdude13:06:01

or document which dlls users should collect manually, if they want a manual install

sogaiu23:06:22

another data point: https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows -- in the "File information" section, there are files with names that start with: Api-ms-win-

sogaiu23:06:52

some observations: the nirsoft page mostly lists files with l1-1-0 in the names -- there is only one file, api-ms-win-service-management-l2-1-0.dll, that does not have l1-1-0 in its name. in contrast some of the pastebin links don't have l1-1-0 in their names. also ms-win-crt-* are not listed in the nirsoft article.

sogaiu23:06:55

here's a question -- if distribution is not allowed, did oracle get permission to do so for jdk? i think i see these files and other similar ones within my jdk folder.

sogaiu23:06:08

may be it's worth pinging the graal folks about our findings? perhaps they can shed light on the situation.