feat(symbolize): Symbolize detection support HAVE_LINK_H

[hcoona]

link.h is usually provided by glibc. Current implementation of symbolize can work on link.h. Enhance the symbolize detection logic to support link.h, AKA. define HAVE_SYMBOLIZE if defined(HAVE_LINK_H).

This PR close #1084 and supersede #1085.

There's a few discussion in #1085 about why make changes in src/symbolize.h instead of bazel/glog.bzl. My justification is that this is an enhancement to symbolize detection logic rather than an alignment between bazel and cmake build systems. link.h can provide us ElfW thus can support our implementation.

I would like to open a separate issue if we still want to discuss whether we should define HAVE_SYMBOLIZE in bazel/glog.bzl.

[sergiud]

Thanks for the PR. However, my comment from #1085 still stands as I do not want to rely on assumptions but rather use the build system to detect (or specify, in Bazel case) the feature availability. This also allows to keep the preprocessor logic (which is not straightforward to debug) simple.

[hcoona]

Thanks for the PR. However, my comment from #1085 still stands as I do not want to rely on assumptions but rather use the build system to detect (or specify, in Bazel case) the feature availability. This also allows to keep the preprocessor logic (which is not straightforward to debug) simple.

@sergiud I understand your opinion. To further discuss the difference in our views, we need to define the boundaries of the problem, i.e., what kind of functionality should be detected and provided by the build system, and what kind of functionality should be detected by the macro system.

I believe my change is brief and simple to understand. We have detected HAVE_ELF_H with the preprocessor, why can't we detect HAVE_LINK_H?

I would like you to provide further information to help me understand on what principles we should base our decision on this issue.

[sergiud]

I provided a very clear explanation why the detection should be performed by the build system and not by the preprocessor. What information are you missing exactly?

Also, I do not understand why do you keep pushing for a preprocessor based solution? Why can't you update the Bazel files instead?

[hcoona]

I provided a very clear explanation why the detection should be performed by the build system and not by the preprocessor. What information are you missing exactly?

Also, I do not understand why do you keep pushing for a preprocessor based solution? Why can't you update the Bazel files instead?

@sergiud I feel you are annoyed about the discussion. I agree we shouldn't waste too much time on quite "simple" problem. However, at least 2 warm community contributors are confused in this problem, so I think it's not trivial.

I totally understand you prefer to solve the problem by build system rather than by the preprocessor. And I believe I understand your justification. (But I don't think re-implement the detection logic in each build systems with each build system specific DSL are even better than implement it in the preprocessor.)

What confused me are

1. We do have had 2 approaches to detect HAVE_SYMBOLIZE.
2. Current implementation of glog in bazel build system do nothing on detecting HAVE_SYMBOLIZE. It totally rely on the preprocessor.

Now, I want to enhance the detection logic, where should be the correct place? What kind of functionality should be detected and provided by the build system, and what kind of functionality should be detected by the macro system? These questions are exactly what I was asking for.

If the rule is we stop adding any logic to the preprocessor and gradually move all (this detection) logic from the preprocessor to the build system, I would happily follow it.

I mean I never aware of that your are announcing a new rule, are you?

[sergiud]

You keep ignoring my reasoning for implementing the logic using the build system instead of the preprocessor which is why the discussion is not moving forward.

To add to my previous comments:

1. Your proposed fix for symbolization detection using the preprocessor is insufficient. It is both inconsistent to the CMake approach and solves the problem only partially by relying on assumptions.
2. The issue is present in Bazel builds only but not those built using CMake. Hence, the fix should be limited to Bazel files only.
3. glog moved away from using preprocessor logic in recent releases because this approach is error prone. Contributions are expected to follow the methodology for consistency reasons. There is no announcement necessary for this specific design decision.

Now, I want to enhance the detection logic, where should be the correct place?

I already answered this question here. Please limit the modifications to Bazel files only.

What kind of functionality should be detected and provided by the build system, and what kind of functionality should be detected by the macro system?

This question is irrelevant for solving this specific problem. In general, however, there must be a good reason for using the preprocessor instead of the build system.

[hcoona]

Thanks for your clarification. You have made a design decision but nobody in the community know about it. You said you prefer to put the detection logic in build system but the community didn't know it had been settled without any room for a further discussion. I would rather you just say that we have made a rule, just follow the rule to keep consistency.

I would submit a new PR with the 2 changes:

1. Add HAVE_SYMBOLIZE for linux only opts in bazel/glog.bzl.
2. Add comments to stop people adding new changes to the preprocessor of HAVE_SYMBOLIZE detection

Let me know if you have any concerns.

[sergiud]

You have made a design decision but nobody in the community know about it.

Given this is your first contribution to glog, I don't believe you are in the position to speak on behalf of the community.

You said you prefer to put the detection logic in build system but the community didn't know it had been settled without any room for a further discussion. I would rather you just say that we have made a rule, just follow the rule to keep consistency.

You seem to have an attitude problem. I don't appreciate neither your baseless accusations nor your attempts of twisting of my words. I'm asking you to keep the discussions civilized and limited to technical problems only, refraining from any personal attacks. Your behavior will not be tolerated. You have been warned.

[hcoona]

@sergiud , I apologize if my previous messages came across as confrontational. It was never my intention to offend or misrepresent your viewpoints. I recognize there may have been some gaps in our communication, and there are aspects of the project’s background and the discussions that I am not fully aware of, which may have led to a lack of common understanding.

I truly value a harmonious work environment and am committed to improving how I communicate, ensuring it's based on well-substantiated facts rather than assumptions. I appreciate your patience and guidance as we work through this issue, and I am keen to adapt my approach to align better with the project’s methodologies and expectations. Thank you for addressing these concerns directly, and I look forward to making a constructive contribution moving forward.

[sergiud]

Thank you. Let's move forward with #1116.