Confirm how dynamically built `ch` binary looks for the library

[ZHOUYue67]

It seems to me that, under Linux/macOS, dynamically built ch binary will only looks for the dynamic library (libChakraCore.so/libChakraCore.dylib) under the same directory as the binary itself.

However, Linux/macOS usually put binaries and libraries under different directories (bin and lib).

If that's the case, when packaging ChakraCore for Linux and macOS, we have to build two times in order to get the dynamic library and a usable (statically built) ch binary.

I provide patches to build scripts for ArchLinux and Homebrew (macOS):

1. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=chakracore (line 21-22)
2. https://github.com/MikeChou/homebrew-core/blob/5823ffee6bafe925a8bc2ab53f500ae6489542f4/Formula/chakra.rb#L29-L30

If ch can look for the dynamic library according to the environment vairable LD_LIBRARY_PATH or some other standard mechanism, there will be no need to build the binary a second time for this purpose alone, hence will save time and disk space.

[jackhorton]

Sorry for the silence here! I took a quick browse and it looks like we make the same assumptions on posix as we do on Windows here, and windows has historically always had Chakra(Core).dll sitting next to the host in the same folder.

I am not sure what the right fix is -- looking at http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html, perhaps we should have CMake and/or build.sh set -rpath by default during development with a way to turn it off and take out the code that manually loads libchakracore.so in ch? We call PAL's version of LoadLibraryExA which is effectively equal to dlopen, and it seems like if we just passed the soname and not the full path to the so to dlopen, it would search LD_LIBRARY_PATH, which should work for your case. With that being said, I would have to play with it some more to figure out if that breaks anything else.

@digitalinfinity Do you know if this decision was intentional?

[ZHOUYue67]

@jackhorton

Thanks for your reply.

To my understanding, dynamically built ch binary is currently not direct-linked to the dynamic library libChakraCore.dll/so/dylib, and will use dlopen API (or something equivalent) to explicitly and programmatically load it instead. For example, ch -v will run successfully even when the dynamic library is not present.

Is this behavior intentionally designed? Any functionality depends on this?

If there's no special need to this dynamic loading behavior, at least under Linux, usually programs will choose to dynamically link to .so when building, and will use the /lib/ld-linux.so.X mechanism (described in the link you provided above) to load the library automatically when programs launch, no explicit dlopen call needed. If linked .so files are not present, the programs will fail to run. dlopen API should be used if you want to implement dynamic module (un)loading without program relaunch.

Under linux, in a terminal shell, run:

bash -c "ldd `which ch`"

Output is a list of all the .so files linked to ch binary when building. libChakraCore.so is not in the list currently, as expected.

[jackhorton]

If I had to guess, it would be that we were emulating the behavior of ch on windows, which probably was emulating the behavior of jshost (our internal host for ChakraFull), which probably had some legacy reason for doing this. I know we also do things in DllMain() and load test hooks, which may also be related. I will defer to Hitesh (or possibly @obastemur ?) on what the rationale was here.

[obastemur]

As @jackhorton said, the intention was to make it similar to what we have on Windows to reduce the effort and future complexity.

The necessary change there may not be trivial but no rocket science either. I'm not sure what others would say but; If you think it's gonna pay off and want to contribute it then go ahead and do it under a new build option. i.e. build.sh --no-dlopen.... <-requires better naming here.

[rhuanjl]

@ppenzin this is an interesting discussion on the point I raised in #6581 on how ch uses chakracore - unless you build CC static it's runtime linked hence all the machinery about extracting symbols from the library at runtime.