xplat: Make shared library usage requirements more reasonable

[obastemur]

At the moment, ChakraCore shared library on xplat requires an explicit call to DllMain.
This is not practical for 3rd party apps using ChakraCore.

A potential solution may benefit static library xplat mechanism. Please keep in mind, we need to consider command line args/flags handling for SO separately.

[kphillisjr]

I believe the best solution would be to use the constructor and destructor attributes. These can be prioritized, and offer a beginning solution to this issue.

// Beginning of file
void SharedLibraryEntry() __attribute__((constructor));
void SharedLibraryExit() __attribute__((constructor));

// Somewhere later.
void SharedLibraryEntry()
{
    // TODO: Library initialization. This is called before Main.
}

void SharedLibraryExit()
{
    //TODO: Library Cleanup/Finalization. This is called after Main, or on unload.
}

/* This will result in following run order...
SharedLibraryEntry() 
main()
SharedLibraryExit()
*/

Also as a side note you can prioritize the constructor/destructor. The major part of that is that for constructors the lower number gets ran first, and on destructors the higher number is ran first. An example is as follows...

void SharedLibraryEntryA() __attribute__((constructor(1)));
void SharedLibraryExitA() __attribute__((destructor(1)));
void SharedLibraryEntryB() __attribute__((constructor(2)));
void SharedLibraryExitB() __attribute__((destructor(2)));
void SharedLibraryEntryC() __attribute__((constructor(3)));
void SharedLibraryExitC() __attribute__((destructor(3)));

With the above declarations you will get the Following run order:

// Run Order:
SharedLibraryEntryA() // 1
SharedLibraryEntryB() // 2
SharedLibraryEntryC() // 3
Main()
SharedLibraryExitC() // 3
SharedLibraryExitB() // 2
SharedLibraryExitA()// 1

Edit: It appears that the above code happens before the process even has thread local storage available. This means that some variables are not able to be resolved due to this. A quick fix would be to add two more API calls to the ChakraCore base library. These calls are particularly useful for programs that statically link ChakraCore on windows.

 /* Initialize ChakraCore Library */
JsInitializeLibrary(); 

/* run Hello world in this section for example */

/* Clean-up for ChakraCore Library */
JsFinalizeLibrary();

``

[kphillisjr]

I submitted a pull request that provides a highly usable fix for this bug under #2124. The only dependency is that pull request #2111 be applied first. The reason for this is that I have already patched the ChakraCore samples to take advantage of pull request #2111, and these samples require pull request #2124 to run properly. The changes for the ChakraCore Samples are located at GitHub: kphillisjr/Chakra-Samples at samples_cmake_v3.

[obastemur]

#2200 fixed this issue. Closing for now.