Go to the first, previous, next, last section, table of contents.



버그 알리기

Your bug reports play an essential role in making ld reliable.

Reporting a bug may help you by bringing a solution to your problem, or it may not. But in any case the principal function of a bug report is to help the entire community by making the next version of ld work better. Bug reports are your contribution to the maintenance of ld.

In order for a bug report to serve its purpose, you must include the information that enables us to fix the bug.

버그를 알려주면 ld를 향상시키는데 큰 도움이 된다.

버그를 알려주면 당신의 문제를 해결할 수 있다. 그러나 더 중요하게 다음 ld가 더 잘 작동하여 모든 공동체에 도움이 된다. 당신이 버그를 알려주면 ld에 기여하는 것이다.

버그를 알려주는 것이 이런 목적을 만족하려면 우리가 버그를 고치는데 필요한 정보를 포함해야 한다.

버그를 찾았나요?

If you are not sure whether you have found a bug, here are some guidelines:

버그를 찾았는지 확신이 들지 않다면 다음을 참고하라.



버그를 알리는 방법

A number of companies and individuals offer support for GNU products. If you obtained ld from a support organization, we recommend you contact that organization first.

You can find contact information for many support companies and individuals in the file `etc/SERVICE' in the GNU Emacs distribution.

Otherwise, send bug reports for ld to `bug-binutils@gnu.org'.

많은 회사와 개인이 GNU 제품에 지원을 제공한다. 지원 회사에서 ld를 얻었다면 먼저 그 회사와 연락할 것을 권장한다.

GNU Emacs 소스 파일 `etc/SERVICE'에서 많은 지원 회사와 개인에 대한 연락처를 얻을 수 있다.

그렇지 않으면 `bug-binutils@gnu.org'ld 버그를 보내라.

The fundamental principle of reporting bugs usefully is this: report all the facts. If you are not sure whether to state a fact or leave it out, state it!

Often people omit facts because they think they know what causes the problem and assume that some details do not matter. Thus, you might assume that the name of a symbol you use in an example does not matter. Well, probably it does not, but one cannot be sure. Perhaps the bug is a stray memory reference which happens to fetch from the location where that name is stored in memory; perhaps, if the name were different, the contents of that location would fool the linker into doing the right thing despite the bug. Play it safe and give a specific, complete example. That is the easiest thing for you to do, and the most helpful.

버그를 알리는데 기본적인 규칙은 모든 사실을 알리는 것이다. 무엇을 말해야할지 말하지 않아야할 지가 불확실하면, 그것을 말해라!

흔히 문제를 일으키는 이유를 알고 있다고 생각하고 어떤 부분을 중요하지 않다고 생각하기 때문에 사실을 생략한다. 예를 들어 당신은 심볼 이름이 중요하지 않다고 가정할 수 있다. 그러나 그러지 않을 수 있고, 누구도 확신할 수 없다. 아마도 버그는 메모리에 이름이 저장된 장소에 메모리 참조를 잘못했을 수도 있다. 또, 이름이 다르면 버그에도 불구하고 링커가 올바르게 작동하고 있는 것처럼 보일 수도 있다. 안전하게 완전한 예를 주라. 이는 가장 쉽고 도움이 된다.

Keep in mind that the purpose of a bug report is to enable us to fix the bug if it is new to us. Therefore, always write your bug reports on the assumption that the bug has not been reported previously.

Sometimes people give a few sketchy facts and ask, "Does this ring a bell?" Those bug reports are useless, and we urge everyone to refuse to respond to them except to chide the sender to report bugs properly.

To enable us to fix the bug, you should include all these things:

버그를 알리는 목적이 우리가 모르는 버그를 고치는 것임을 염두하자. 그래서 항상 전에 우리가 그 버그를 모른다고 가정하고 알려주길 바란다.

가끔 간단한 사실만을 주는 경우가 있다. 이런 것은 도움이 안되고, 우리는 모두에서 버그를 올바로 알리라는 것 외의 답장을 거절하라고 말한다.

우리가 버그를 고칠 수 있게 하기 위해 다음을 모두 포함해야 한다.

Here are some things that are not necessary:
다음은 필요하지 않다.


Go to the first, previous, next, last section, table of contents.