-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Allow glog to be queried as to whether or not InitGoogleLogging has been called. #125
Comments
+1! |
1 similar comment
+1! |
+1! 🙏 |
This is still an issue but with a fairly easy work around. (Unless I'm missing something obvious) We just need access to So just define the following in your own code.
The linker should take care of linking the symbol to its implementation in glog. So now you can simply use the function as Cheers. |
@sergiud |
The issue received no activity, hence I closed it. You're welcome provide a PR. Internal declarations are not part of the API and thus can change anytime. Complaining about changes to the internals is not helpful anyway. |
I think this issue is not about complaining change of internal API, but about why it is internal, because without it there's simply no reliable way to init without full control of process lifespan. |
Sure, go ahead. |
Usually library does not have control of the process lifespan. Without this function, it is impossible to init/shutdown reliably. It has been one of the major pain points for years when using glog in libraries. AFAIK 3 workarounds have been used previously: 1. Init without checking. This causes compatiblity issues with other libs using glog. 2. Also provide a init function in library's API. This makes API complicated and stateful, especially for libs that does not mean to stay for the entire life of process. 3. Steal the utility function in internal namespace. Does not work with msvc (due to missing dllexport) or `gcc -fvisibility=hidden`. None of them are perfect, except for the last hack that usually works well on Linux. 0.5.0 changes default visibility to hidden and it does not work anymore. Resolve google#125
Usually library does not have control of the process lifespan. Without this function, it is impossible to init/shutdown reliably. It has been one of the major pain points for years when using glog in libraries. AFAIK 3 workarounds have been used previously: 1. Init without checking. This causes compatiblity issues with other libs using glog. 2. Also provide a init function in library's API. This makes API complicated and stateful, especially for libs that does not mean to stay for the entire life of process. 3. Steal the utility function in internal namespace. Does not work with msvc (due to missing dllexport) or `gcc -fvisibility=hidden`. None of them are perfect, except for the last hack that usually works well on Linux. 0.5.0 changes default visibility to hidden and it does not work anymore. Resolve google#125
Usually library does not have control of the process lifespan. Without this function, it is impossible to init/shutdown reliably. It has been one of the major pain points for years when using glog in libraries. AFAIK 3 workarounds have been used previously: 1. Init without checking. This causes compatiblity issues with other libs using glog. 2. Also provide a init function in library's API. This makes API complicated and stateful, especially for libs that does not mean to stay for the entire life of process. 3. Steal the utility function in internal namespace. Does not work with msvc (due to missing dllexport) or `gcc -fvisibility=hidden`. None of them are perfect, except for the last hack that usually works well on Linux. 0.5.0 changes default visibility to hidden and it does not work anymore. Resolve google#125
Usually library does not have control of the process lifespan. Without this function, it is impossible to init/shutdown reliably. It has been one of the major pain points for years when using glog in libraries. AFAIK 3 workarounds have been used previously: 1. Init without checking. This causes compatiblity issues with other libs using glog. 2. Also provide a init function in library's API. This makes API complicated and stateful, especially for libs that does not mean to stay for the entire life of process. 3. Steal the utility function in internal namespace. Does not work with msvc (due to missing dllexport) or `gcc -fvisibility=hidden`. None of them are perfect, except for the last hack that usually works well on Linux. 0.5.0 changes default visibility to hidden and it does not work anymore. Resolve google#125
Usually library does not have control of the process lifespan. Without this function, it is impossible to init/shutdown reliably. It has been one of the major pain points for years when using glog in libraries. AFAIK 3 workarounds have been used previously: 1. Init without checking. This causes compatiblity issues with other libs using glog. 2. Also provide a init function in library's API. This makes API complicated and stateful, especially for libs that does not mean to stay for the entire life of process. 3. Steal the utility function in internal namespace. Does not work with msvc (due to missing dllexport) or `gcc -fvisibility=hidden`. None of them are perfect, except for the last hack that usually works well on Linux. 0.5.0 changes default visibility to hidden and it does not work anymore. Resolve google#125
Usually library does not have control of the process lifespan. Without this function, it is impossible to init/shutdown reliably. It has been one of the major pain points for years when using glog in libraries. AFAIK 3 workarounds have been used previously: 1. Init without checking. This causes compatiblity issues with other libs using glog. 2. Also provide a init function in library's API. This makes API complicated and stateful, especially for libs that does not mean to stay for the entire life of process. 3. Steal the utility function in internal namespace. Does not work with msvc (due to missing dllexport) or `gcc -fvisibility=hidden`. None of them are perfect, except for the last hack that usually works well on Linux. 0.5.0 changes default visibility to hidden and it does not work anymore. Resolve google#125
If you call InitGoogleLogging twice, then you get a fatal error and the program ends.
However, there is no way to query glog as to whether glog has already been initialized or not. This query is in the glog code (obviously) but it's not exposed in the API. Please make this public.
Here is the use case where this is useful, for me at least.
I'm adding an unmanaged C++ package that uses glog to a managed C# DLL that is in turn dynamically loaded to a C# managed code application but I need to change the glog default behavior. I can't call InitGoogleLogging in the application so instead I have to do the initialization in a nested singleton class in the DLL.
The text was updated successfully, but these errors were encountered: