Re: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472]
Hello Ian,
when I add in gcc/go/config-lang.in the line
boot_language=yes
then on stage3 x86_64-pc-linux-gnu/libbacktrace is compiled before
x86_64-pc-linux-gnu/libgo and this error is gone.
But then Makefile.def has
target_modules = { module= libatomic; bootstrap=true; lib_path=.libs; };
and in x86_64-pc-linux-gnu libatomic is not compiled before
x86_64-pc-linux-gnu/libgo . Linking the latter fails
make[2]: Entering directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo'
/bin/sh ./libtool --tag=CC --mode=link /git/gcc/build/./gcc/xgcc
-B/git/gcc/build/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ …long text…
golang.org/x/sys/cpu_gccgo_x86.lo ../libbacktrace/libbacktrace.la
../libatomic/libatomic_convenience.la ../libffi/libffi_convenience.la -lpthread
-lm
./libtool: line 5195: cd: ../libatomic/.libs: No such file or directory
libtool: link: cannot determine absolute directory name of `../libatomic/.libs'
So either lib_path=.libs interferes (when gcc/go/config-lang.in contains
“boot_language=yes”), I have made the semi-serial build, trying to save a lot
of time waiting to get on stage3, somehow wrong, or libatomic must be mentioned
in gcc/go/config-lang.in . I have the feeling that ./configure
--enable-langugage=all works, because gcc/d/config-lang.in contains
boot_language=yes, and then in some way libphobos or d depend on libatomic.
That said bootstrap=true might only be relevant when boot_langugages=yes is
present.
In addition gcc/go/config-lang.in:boot_language=yes implies that on stage2
(thus in prev-x86_64-pc-linux-gnu/) libbacktrace is built, which I do not want
this, as libbacktrace is needed only by libgo on stage3.
Can someone explain, why is libbacktrace built once in the built-root, as
stage1-libbacktrace, prev-libbacktrace and libbacktrace (for stage3) and once
again in stage1-x86_64-pc-linux-gnu/libbacktrace,
prev-x86_64-pc-linux-gnu/libbacktrace/ and in x86_64-pc-linux-gnu/libbacktrace
? My precise question is why libbacktrace is built once in the build-root
directory and once in the x86_64-pc-linux-gnu directory?
Kind regards Дилян
Am 26. März 2024 16:37:40 UTC schrieb Ian Lance Taylor :
>On Tue, Mar 26, 2024 at 9:33 AM Дилян Палаузов
> wrote:
>>
>> Makefile.def contains already:
>>
>> host_modules= { module= libbacktrace; bootstrap=true; }; // since eff02e4f84
>> - "libbacktrace/: * Initial implementation" year 2012
>>
>> host_modules= { module= libcpp; bootstrap=true; }; // since 4f4e53dd8517c0b2
>> - year 2004
>
>Yes. I was just trying to answer your question.
>
>Ian
>
>> Am 25. März 2024 23:59:52 UTC schrieb Ian Lance Taylor :
>>>
>>> On Sat, Mar 23, 2024 at 4:32 AM Дилян Палаузов
>>> wrote:
>>>>
>>>>
>>>> Can the build experts say what needs to be changed? The dependencies I
>>>> added are missing in the build configuration (@if gcc-bootstrap).
>>>>
>>>> I cannot say if libbacktrace should or should not be a bootstrap=true
>>>> module.
>>>
>>>
>>> I don't count as a build expert these days, but since GCC itself links
>>> against libbacktrace, my understanding is that the libbacktrace
>>> host_module should be bootstrap=true, just like, say, libcpp.
>>>
>>> Ian
Re: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472]
Hello Ian,
Makefile.def contains already:
host_modules= { module= libbacktrace; bootstrap=true; }; // since eff02e4f84 -
"libbacktrace/: * Initial implementation" year 2012
host_modules= { module= libcpp; bootstrap=true; }; // since 4f4e53dd8517c0b2 -
year 2004
Greetings
Дилян
Am 25. März 2024 23:59:52 UTC schrieb Ian Lance Taylor :
>On Sat, Mar 23, 2024 at 4:32 AM Дилян Палаузов
> wrote:
>>
>> Can the build experts say what needs to be changed? The dependencies I
>> added are missing in the build configuration (@if gcc-bootstrap).
>>
>> I cannot say if libbacktrace should or should not be a bootstrap=true module.
>
>I don't count as a build expert these days, but since GCC itself links
>against libbacktrace, my understanding is that the libbacktrace
>host_module should be bootstrap=true, just like, say, libcpp.
>
>Ian
Re: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472]
Hello,
Can the build experts say what needs to be changed? The dependencies I added
are missing in the build configuration (@if gcc-bootstrap).
I cannot say if libbacktrace should or should not be a bootstrap=true module.
If there are no better patches, I kindly ask to integrate this patch with a
comment, indicating the quality of the patch. The change proposed by me does
fix PR106472.
Kind regards
Дилян
-Original Message-
From: Jakub Jelinek
Reply-To: Jakub Jelinek
To: Дилян Палаузов , Paolo Bonzini
, Nathanael Nerode , Alexandre Oliva
, Ralf Wildenhues , Ian Lance
Taylor
Cc: gcc-patches@gcc.gnu.org
Subject: Re: No rule to make target '../libbacktrace/libbacktrace.la', needed
by 'libgo.la'. [PR106472]
Date: 03/13/2024 10:13:37 AM
On Wed, Mar 13, 2024 at 07:37:26AM +0100, Дилян Палаузов wrote:
> Non-parallel build can fail, depending on the ./configure parameters -
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 .
>
> The change below does fix the problem.
CCing build system maintainers and the Go maintainer.
While the first Makefile.tpl hunk looks obviously ok, the others look
completely wrong to me.
There is nothing special about libgo vs. libbacktrace/libatomic
compared to any other target library which is not bootstrapped vs. any
of its dependencies which are in the bootstrapped set.
So, Makefile.tpl shouldn't hardcode such dependencies.
The
all-target-libgo: maybe-all-target-libbacktrace
all-target-libgo: maybe-all-target-libatomic
dependencies which are in Makefile.in already are I believe intentionally
guarded with
@unless gcc-bootstrap
because when bootstrapping, there are the
all-target-libgo: stage_current
configure-target-libgo: stage_last
dependencies instead plus there is always
all-target-libgo: configure-target-libgo
and stage_last should I believe ensure that everything is bootstrapped,
gcc as well as the bootstrapped target libraries like libbacktrace or
libatomic.
Now, if those are built only sometimes depending on configured languages
- I see
grep 'lib\(backtrace\|atomic\)' gcc/*/config-lang.in
gcc/ada/gcc-interface/config-lang.in
gcc/d/config-lang.in:phobos_target_deps="target-zlib target-libbacktrace"
gcc/fortran/config-lang.in:target_libs="target-libgfortran target-libbacktrace"
gcc/go/config-lang.in:target_libs="target-libgo target-libffi
target-libbacktrace"
then perhaps Makefile.def should know that it is not a bootstrap=true module
target_modules = { module= libbacktrace; bootstrap=true; };
unconditionally and arrange for the dependencies between non-bootstrap
target modules and these maybe ones to be emitted even if gcc-bootstrap.
> I do not understand the build system to say, that this is the best approach,
> so if there are questions I might or might not be able to answer them.
>
> I tried different things, this worked on the releases/gcc-13 branch. On the
> master branch last weekend the problem was that stage2 and stage3 results
> are not equal, so I have not verified this change there. depend= in
> Makefile.def seem to have only effect if bootstrapping is involved and
> gcc/go/config-lang.in does not have boot_language=yes . The lines below are
> present in the Makefile.in:@unless gcc-bootstrap snippet. Actually I think
> ./configure --enable-languages=all and then serial build work, because this
> implied D and it does imply bootstrapping for libbacktrace and libatomic. I
> also do not want to invest much more time on this.
>
> I do not know, if 2×`maybe-` is necessary.
>
>
> diff --git a/Makefile.in b/Makefile.in
> index 06a9398e172..236e5cda942 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -66481,6 +66481,7 @@ configure-target-libgfortran:
> maybe-all-target-libquadmath
>
>
> @if gcc-bootstrap
> +all-target-libgo: maybe-all-target-libbacktrace maybe-all-target-libatomic
> configure-gnattools: stage_last
> configure-libcc1: stage_last
> configure-c++tools: stage_last
> diff --git a/Makefile.tpl b/Makefile.tpl
> index dfbd74b68f8..98160c7626b 100644
> --- a/Makefile.tpl
> +++ b/Makefile.tpl
> @@ -1952,7 +1952,7 @@ configure-target-[+module+]: maybe-all-gcc[+
> (define dep-maybe (lambda ()
> (if (exist? "hard") "" "maybe-")))
>
> - ;; dep-kind returns returns "prebootstrap" for configure or build
> + ;; dep-kind returns "prebootstrap" for configure or build
> ;; dependencies of bootstrapped modules on a build module
> ;; (e.g. all-gcc on all-build-bison); "normal" if the dependency is
> ;; on an "install" target, or if the dependence module is not
> @@ -2017,6 +2017,7 @@ configure-target-[+module+]: maybe-all-gcc[+
> [+ ESAC +][+ ENDFOR dependencies +]
>
> @if gcc-bootstrap
> +all-target-libgo: maybe-all-target-libbacktrace maybe-all-target-libatomic
> [+ FOR dependencies +][+ CASE (dep-kind) +]
> [+ == "postbootstrap" +][+ (make-postboot-dep) +][+ ESAC +][+
> ENDFOR dependencies +]@endif gcc-bootstrap
>
Jakub
No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472]
Non-parallel build can fail, depending on the ./configure parameters - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 . The change below does fix the problem. I do not understand the build system to say, that this is the best approach, so if there are questions I might or might not be able to answer them. I tried different things, this worked on the releases/gcc-13 branch. On the master branch last weekend the problem was that stage2 and stage3 results are not equal, so I have not verified this change there. depend= in Makefile.def seem to have only effect if bootstrapping is involved and gcc/go/config-lang.in does not have boot_language=yes . The lines below are present in the Makefile.in:@unless gcc-bootstrap snippet. Actually I think ./configure --enable-languages=all and then serial build work, because this implied D and it does imply bootstrapping for libbacktrace and libatomic. I also do not want to invest much more time on this. I do not know, if 2×`maybe-` is necessary. diff --git a/Makefile.in b/Makefile.in index 06a9398e172..236e5cda942 100644 --- a/Makefile.in +++ b/Makefile.in @@ -66481,6 +66481,7 @@ configure-target-libgfortran: maybe-all-target-libquadmath @if gcc-bootstrap +all-target-libgo: maybe-all-target-libbacktrace maybe-all-target-libatomic configure-gnattools: stage_last configure-libcc1: stage_last configure-c++tools: stage_last diff --git a/Makefile.tpl b/Makefile.tpl index dfbd74b68f8..98160c7626b 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -1952,7 +1952,7 @@ configure-target-[+module+]: maybe-all-gcc[+ (define dep-maybe (lambda () (if (exist? "hard") "" "maybe-"))) - ;; dep-kind returns returns "prebootstrap" for configure or build + ;; dep-kind returns "prebootstrap" for configure or build ;; dependencies of bootstrapped modules on a build module ;; (e.g. all-gcc on all-build-bison); "normal" if the dependency is ;; on an "install" target, or if the dependence module is not @@ -2017,6 +2017,7 @@ configure-target-[+module+]: maybe-all-gcc[+ [+ ESAC +][+ ENDFOR dependencies +] @if gcc-bootstrap +all-target-libgo: maybe-all-target-libbacktrace maybe-all-target-libatomic [+ FOR dependencies +][+ CASE (dep-kind) +] [+ == "postbootstrap" +][+ (make-postboot-dep) +][+ ESAC +][+ ENDFOR dependencies +]@endif gcc-bootstrap
Re: Make clear, when contributions will be ignored
Hello Segher, On Sun, 2019-02-17 at 13:09 -0600, Segher Boessenkool wrote: > On Sun, Feb 17, 2019 at 04:59:40PM +0000, Дилян Палаузов wrote: > > My point is to reorgnize the approach in such a way, that sending reminders > > gets irrelevant (has no impact) and > > therefore not necessary. > > > > Currently priority is given to submitters who send reminders, irrespective > > of the properties a patch has. > > No, that is not true for many reviewers. It is however true that patches > that are *not* pinged (say, once a week) often are forgotten, or the > maintainer assumes the patch is not wanted anymore, etc. The assumption that an unpinged patch is not wanted any more is obviously wrong. The assumption shall be, that people who do not send reminders have not read, that they are supposed to send reminers, as these people assume that sending reminders makes no difference. If this is not true for many reviewers, why does sending reminder then make a difference and the webpage advices to send reminders? To sum up, sending a reminder on a subject and the subject (patch being good/bad/excellent/inappropriate/messy) are two different things. I am talking here about the necessity for sending reminders, irrespective of the subject/properties a patch has. Regards Дилян
Re: Make clear, when contributions will be ignored
Hello Segher, your prompt answer is appreciated. As a matter of fact patches are not reviewed for whatever reason in reasonable time. My point is to reorgnize the approach in such a way, that sending reminders gets irrelevant (has no impact) and therefore not necessary. Currently priority is given to submitters who send reminders, irrespective of the properties a patch has. Regards Дилян On Mon, 2019-02-11 at 10:22 -0600, Segher Boessenkool wrote: > On Mon, Feb 11, 2019 at 02:16:27PM +0000, Дилян Палаузов wrote: > > Hello Segher, > > > > my question was how do you propose to proceed, so that a > > no-reminders-for-patches-are-necessary-state is reached. > > > > There is no relation with having infinite time or dealing with high-cost > > low-profit patches. > > > > Previously I raised the quesion, whether automating the process for sending > > reminders, is a good idea. This saves time > > of people to write reminders. > > But that would be "optimising" exactly the wrong thing! The choke point is > patch review. So you should make it easier to review a patch, instead of > making it easier to send in more patches. Your complaint is that many > patches are sent in but then not reviewed, or not reviewed for a long while, > after all. > > Easy to review patches are of course first and foremost patches that do the > correct thing. But also they need to clearly say what they fix (and how), > how the patch was tested, and they should often contain testcases for the > testsuite. Easy to review patches usually use the same style and > presentation as all other easy to review patches. > > > Segher
Re: Make clear, when contributions will be ignored
Hello Segher, my question was how do you propose to proceed, so that a no-reminders-for-patches-are-necessary-state is reached. There is no relation with having infinite time or dealing with high-cost low-profit patches. Previously I raised the quesion, whether automating the process for sending reminders, is a good idea. This saves time of people to write reminders. Greetings Дилян On Mon, 2019-02-11 at 07:57 -0600, Segher Boessenkool wrote: > On Mon, Feb 11, 2019 at 12:44:31PM +0000, Дилян Палаузов wrote: > > -- at https://www.gnu.org/software/gcc/contribute.html is written “If you > > do not receive a response to a patch that you > > have submitted within two weeks or so, it may be a good idea to chase it by > > sending a follow-up email to the same > > list(s).” > > That is about patches. Not about bugzilla. Sending reminders for bugzilla > reports is useless and annoying. Sending reminders for patches however is > necessary, the way our development works currently. It isn't clear any > change to procedures would help at all, since the fundamental problems need > to be attacked to make any progress. Maintainers do not have infinite time, > and there is no incentive to deal with high-cost low-profit patches. > > > Segher
Re: Make clear, when contributions will be ignored
Hello Segher, the current procdure is: -- write at https://gcc.gnu.org/bugzilla/ -- read an answer, that the update shall be posted to gcc-patches -- subscribe to gcc-patches, post the change and wait for an answer. This waiting is not for free. There are a lot of emails, for the person might not be interested, but only waits for a reply on the own email. So after some time, I made filters sorting the emails from the mailing list, in order to make the waiting cheaper. -- at https://www.gnu.org/software/gcc/contribute.html is written “If you do not receive a response to a patch that you have submitted within two weeks or so, it may be a good idea to chase it by sending a follow-up email to the same list(s).” Because it is written that reminders are..., I have sent a reminder. > > If yes, how do you propose to proceed, so that a > > no-reminders-are-necessary-state is reached? > > Keep things as is? Reminders already are not necessary. > This statement does not align with the aforementioned webpage. The optimal way will be, if a bug/patch is filled in bugzilla and nothing more is necessary from the reporter. Postgres sends bugs collected over website over a mailing list. Regards Дилян On Sun, 2019-02-10 at 14:56 -0600, Segher Boessenkool wrote: > Hi Dilyan, > > On Sun, Feb 10, 2019 at 02:45:02PM +, Дилян Палаузов wrote: > > Do you share the opinion, that whatever can be done after receiving a > > reminder, can be arranged also without reminder? > > Yes. When people have time for it, they can trivially check what PRs are > still open that they are involved in. > > > If yes, how do you propose to proceed, so that a > > no-reminders-are-necessary-state is reached? > > Keep things as is? Reminders already are not necessary. > > If you want more attention given to the bugs you are involved in, you can > hire people to do that, or file reports for more interesting bugs, or make > your bug reports easier to work with. > > Since GCC has one major release every year, handling less urgent bugs can > take up to a year as well. > > > I read in the answer of Segher, that the purpose of reminding is not only > > to ping, but also to filter the ones who are > > pernetrant and sending manually reminders is the means to verify, that the > > persons really want to make progress. It was > > certainly not intentionally meant this way, but this is a possible reading. > > The point is that automated reminders for PRs *are spam*. > > > Segher
Re: Make clear, when contributions will be ignored
Hello, thanks to Serger and Joseph for the feedback. Acting primary upon reminders is a general phenomenon in the society, nothing specific to software teams. Think on public administration: it acts sometimes much more collaboratively, if a public/private/famous media reports on the workflows of the public administration. Public administration also reacts sometimes only, if reminders are sent. Not surprizing is, that talking with a public administration, about their policy on acting only after receiving a reminder, leads to nowhere, as making progress on this discussion with such an administration, needs a lot of reminders. In summary, such public administrations insist on their right to receive reminders before acting. Do you share the opinion, that whatever can be done after receiving a reminder, can be arranged also without reminder? If yes, how do you propose to proceed, so that a no-reminders-are-necessary-state is reached? I read in the answer of Segher, that the purpose of reminding is not only to ping, but also to filter the ones who are pernetrant and sending manually reminders is the means to verify, that the persons really want to make progress. It was certainly not intentionally meant this way, but this is a possible reading. Let me repeat, that the topic is not anyhow GCC specific, nor do I offend the society anyhow. To make things better, first the causes for the current state have to be understood. Raising the topic on GNU Tools Cauldron is a very good idea, but it likely approaches less people than on this mailing list, I am not that much inside the GCC processes and I do not know, whether I can visit the next meeting. Regards Дилян On Wed, 2019-02-06 at 06:44 -0600, Segher Boessenkool wrote: > On Fri, Dec 07, 2018 at 10:55:11AM +0000, Дилян Палаузов wrote: > > will it help, if Bugzilla is reprogrammed to send automatically weekly > > reminders on all patches, that are not integrated yet? > > No, that will not help. > > If an interested party sends a friendly ping, that is of course welcome. > But automated pings are spam: unwanted bulk mail. > > > The patch I proposed on 27th Oct was first submitted towards GDB and > > then I was told to send it to GCC. Here I was told to sent it to GDB. > > What shall happen to quit the loop? > > You can cc: both sides of the discussion. Either also gdb-patches, or also > whoever told you to send it to GCC instead, or both. And include a link to > the mailing list archive of your thread on gdb-patches in your mail to > gcc-patches, so that all parties can see the relevant context. Make it > easy for people to help you! > > > Segher
Re: Make clear, when contributions will be ignored
Hello, the current way to come forward is to send biweekly manual reminders. Will it help, if bugzilla is tweaked to send reminders every two weeks for ready-patches? This also has the advantage, that people will not have to once update a patch in BZ and then send it over gcc-patches. Regards Дилян On Fri, 2018-12-07 at 10:55 +, Дилян Палаузов wrote: > Hello, > > will it help, if Bugzilla is reprogrammed to send automatically weekly > reminders on all patches, that are not integrated yet? > > Will lt help, if I hire myself to integrate the patch, or shall I > rather hire somebody to send reminders? > > If something can be done after sending a reminder, then it can be > arranged also without reminders. In particular, dealing with reminders > is avoidable extra work. > > Whether people are paid or not, does not change on the subject very > much. I have experienced organizations, where people are not paid and > they manage to tackle everything. I have seen organizations where > people are paid and they do not get the management right. > > I am not speaking about having some strict time to get a response, but > rather to ensure an answer in reasonable time. No answer in reasonable > time is the same as ignorance — the subject of this thread. > > The patch I proposed on 27th Oct was first submitted towards GDB and > then I was told to send it to GCC. Here I was told to sent it to GDB. > What shall happen to quit the loop? > > In any case, if the common aim is to have a system where contributions > do not get lost, then I’m sure the workflows can be adjusted to achieve > this aim. > > Regards > Дилян > > > On Wed, 2018-12-05 at 17:37 +, Joseph Myers wrote: > > On Wed, 5 Dec 2018, Segher Boessenkool wrote: > > > > > Patches are usually ignored because everyone thinks someone else will > > > handle it. > > > > And in this case, it looks like this patch would best be reviewed first in > > the GDB context - then once committed to binutils-gdb, the committer could > > post to gcc-patches (CC:ing build system maintainers) requesting a commit > > to GCC if they don't have write access to GCC themselves. I consider > > synchronizing changes to such top-level files in either direction to be > > obvious and not to need a separate review. > >
Substitute all "the the" with "the"
… by applying sed -i "s/the the/the/" `git grep -l "the the"`
+reminder+ Re: Make clear, when contributions will be ignored
Hello, what shall happen, so that no reminders are necessary to move things forward? Why does sending a reminder make a difference and are only penetrant persons blessed? Regards Дилян On Fri, 2018-12-07 at 10:55 +, Дилян Палаузов wrote: > Hello, > > will it help, if Bugzilla is reprogrammed to send automatically weekly > reminders on all patches, that are not integrated yet? > > Will lt help, if I hire myself to integrate the patch, or shall I > rather hire somebody to send reminders? > > If something can be done after sending a reminder, then it can be > arranged also without reminders. In particular, dealing with reminders > is avoidable extra work. > > Whether people are paid or not, does not change on the subject very > much. I have experienced organizations, where people are not paid and > they manage to tackle everything. I have seen organizations where > people are paid and they do not get the management right. > > I am not speaking about having some strict time to get a response, but > rather to ensure an answer in reasonable time. No answer in reasonable > time is the same as ignorance — the subject of this thread. > > The patch I proposed on 27th Oct was first submitted towards GDB and > then I was told to send it to GCC. Here I was told to sent it to GDB. > What shall happen to quit the loop? > > In any case, if the common aim is to have a system where contributions > do not get lost, then I’m sure the workflows can be adjusted to achieve > this aim. > > Regards > Дилян > > > On Wed, 2018-12-05 at 17:37 +, Joseph Myers wrote: > > On Wed, 5 Dec 2018, Segher Boessenkool wrote: > > > > > Patches are usually ignored because everyone thinks someone else will > > > handle it. > > > > And in this case, it looks like this patch would best be reviewed first in > > the GDB context - then once committed to binutils-gdb, the committer could > > post to gcc-patches (CC:ing build system maintainers) requesting a commit > > to GCC if they don't have write access to GCC themselves. I consider > > synchronizing changes to such top-level files in either direction to be > > obvious and not to need a separate review. > >
Re: Make clear, when contributions will be ignored
Hello, will it help, if Bugzilla is reprogrammed to send automatically weekly reminders on all patches, that are not integrated yet? Will lt help, if I hire myself to integrate the patch, or shall I rather hire somebody to send reminders? If something can be done after sending a reminder, then it can be arranged also without reminders. In particular, dealing with reminders is avoidable extra work. Whether people are paid or not, does not change on the subject very much. I have experienced organizations, where people are not paid and they manage to tackle everything. I have seen organizations where people are paid and they do not get the management right. I am not speaking about having some strict time to get a response, but rather to ensure an answer in reasonable time. No answer in reasonable time is the same as ignorance — the subject of this thread. The patch I proposed on 27th Oct was first submitted towards GDB and then I was told to send it to GCC. Here I was told to sent it to GDB. What shall happen to quit the loop? In any case, if the common aim is to have a system where contributions do not get lost, then I’m sure the workflows can be adjusted to achieve this aim. Regards Дилян On Wed, 2018-12-05 at 17:37 +, Joseph Myers wrote: > On Wed, 5 Dec 2018, Segher Boessenkool wrote: > > > Patches are usually ignored because everyone thinks someone else will > > handle it. > > And in this case, it looks like this patch would best be reviewed first in > the GDB context - then once committed to binutils-gdb, the committer could > post to gcc-patches (CC:ing build system maintainers) requesting a commit > to GCC if they don't have write access to GCC themselves. I consider > synchronizing changes to such top-level files in either direction to be > obvious and not to need a separate review. >
Make claer, when contributions will be ignored
Hello, on 27th October I sent to gcc-patches a mail with the subject “Don’t build gdb/readline/libreadline.a, when --with-system-readline is supplied” and on 14th November I sent a reminder. I got no answer. Before sending the emails I filled a bugzilla ticket. Can you please make it clear, when contributions will be ignored, or agree on some procedures, where all contributions are handled in reasonable time withot reminders, in a way that the processes work reliably. If it is unclear, when work made by others will be neglected, and it is not foreseenable when, then state this clearly this uncertainty. If somebody does not feel comfortable with such a statent, then make something to make the statement superfluous. Regards Дилян
+reminder+ Don’t build gdb/readline/libreadline.a, when --with-system-readline is supplied
Forwarded Message From: Дилян Палаузов To: gcc-patches@gcc.gnu.org Subject: Don’t build gdb/readline/libreadline.a, when --with-system- readline is supplied Date: Sat, 27 Oct 2018 19:53:44 + Building GDB always builds the bundled libreadline.a, even if use of the libreadline installed on the system was requested with --with- system-readline. The change below is for binutils-gdb’s/configure.ac, which is maintained by gcc. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87741 [GCC] and https://sourceware.org/bugzilla/show_bug.cgi?id=18632 [GDB] for details. diff --git a/configure.ac b/configure.ac --- a/configure.ac +++ b/configure.ac @@ -253,6 +253,12 @@ if test x$with_system_zlib = xyes ; then noconfigdirs="$noconfigdirs zlib" fi +# Don't compile the bundled readline/libreadline.a in gdb-binutils if +# --with-system-readline is provided. +if test x$with_system_readline = xyes ; then + noconfigdirs="$noconfigdirs readline" +fi + # some tools are so dependent upon X11 that if we're not building with X, # it's not even worth trying to configure, much less build, that tool.
Don’t build gdb/readline/libreadline.a, when --with-system-readline is supplied
Building GDB always builds the bundles libreadline.a, even if use of the libreadline installed on the system was requested with --with- system-readline. The change below is for binutils-gdb’s/configure.ac, which is maintained by gcc. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87741 [GCC] and https://sourceware.org/bugzilla/show_bug.cgi?id=18632 [GDB] for details. diff --git a/configure.ac b/configure.ac --- a/configure.ac +++ b/configure.ac @@ -253,6 +253,12 @@ if test x$with_system_zlib = xyes ; then noconfigdirs="$noconfigdirs zlib" fi +# Don't compile the bundled readline/libreadline.a in gdb-binutils if +# --with-system-readline is provided. +if test x$with_system_readline = xyes ; then + noconfigdirs="$noconfigdirs readline" +fi + # some tools are so dependent upon X11 that if we're not building with X, # it's not even worth trying to configure, much less build, that tool.
