Skip to content
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

Closed
KevinLucidyne opened this issue Sep 22, 2016 · 8 comments · Fixed by #651
Closed
Milestone

Comments

@KevinLucidyne
Copy link

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.

@concretevitamin
Copy link

+1!

1 similar comment
@konstan
Copy link

konstan commented Mar 27, 2019

+1!

@debamax
Copy link

debamax commented Aug 19, 2020

+1! 🙏

@OasisArtisan
Copy link

This is still an issue but with a fairly easy work around. (Unless I'm missing something obvious)

We just need access to
bool IsGoogleLoggingInitialized();
Which is defined in the glog/src/utilities.h

So just define the following in your own code.

namespace google {
  namespace glog_internal_namespace_ {
    extern bool IsGoogleLoggingInitialized();
  }
  const auto& IsGoogleLoggingInitialized = glog_internal_namespace_::IsGoogleLoggingInitialized;
}

The linker should take care of linking the symbol to its implementation in glog.

So now you can simply use the function as google::IsGoogleLoggingInitialized()

Cheers.

@sergiud sergiud closed this as completed Mar 30, 2021
@sergiud sergiud mentioned this issue May 6, 2021
@xkszltl
Copy link
Contributor

xkszltl commented May 12, 2021

@sergiud
So how's the issue closed in 0.5?
Even worse, seems the ::google::glog_internal_namespace_::IsGoogleLoggingInitialized() is now a hidden symbol, the redecl hack won't work any more.

@sergiud
Copy link
Collaborator

sergiud commented May 12, 2021

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.

@xkszltl
Copy link
Contributor

xkszltl commented May 12, 2021

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.
How about we simply alias it to a public API?

@sergiud
Copy link
Collaborator

sergiud commented May 12, 2021

Sure, go ahead.

xkszltl added a commit to xkszltl/glog that referenced this issue May 13, 2021
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
xkszltl added a commit to xkszltl/glog that referenced this issue May 13, 2021
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
xkszltl added a commit to xkszltl/glog that referenced this issue May 13, 2021
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
xkszltl added a commit to xkszltl/glog that referenced this issue May 13, 2021
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
xkszltl added a commit to xkszltl/glog that referenced this issue May 13, 2021
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
xkszltl added a commit to xkszltl/glog that referenced this issue May 14, 2021
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
@sergiud sergiud added this to the 0.6 milestone May 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants