-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xplat: Make shared library usage requirements more reasonable #1811
Comments
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:
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();
`` |
This provides a solution to issue chakra-core#1811, but this also breaks the ch utility in the process.
There is no reason for xplat to have this function be non-reentrant. This also reduces the number of code changes in issue chakra-core#1811 since this change fixes the issue with running ch.
There is no reason for xplat to have this function be non-reentrant. This also reduces the number of code changes in issue chakra-core#1811 since this change fixes the issue with running ch.
There is no reason for xplat to have this function be non-reentrant. This also reduces the number of code changes in issue chakra-core#1811 since this change fixes the issue with running ch. v2: use ifdef, since this call is ran on windows.
There is no reason for xplat to have this function be non-reentrant. This also reduces the number of code changes in issue chakra-core#1811 since this change fixes the issue with running ch. v2: use ifdef, since this call is ran on windows.
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. |
#2200 fixed this issue. Closing for now. |
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.The text was updated successfully, but these errors were encountered: