problem with Makefile.in generation in lingomp

problem with Makefile.in generation in lingomp

[Mohamed Atef]

Hello,
   I downloaded the last version of the repo, but when I try to
autoreconf
in libgomp/
i get this error "plugin/Makefrag.am:29: error: libgomp_la_LIBADD must be
set with '=' before using '+='"
line 29 in libgomp/plugin/Makefrag.am has
"libgomp_la_LIBADD += $(DL_LIBS)"
I removed this line and "autoreconf" worked fine.
Do I miss some packages?

Mohamed

Re: problem with Makefile.in generation in lingomp

[Jakub Jelinek]

On Fri, May 20, 2022 at 11:25:59AM +0200, Mohamed Atef wrote:
>    I downloaded the last version of the repo, but when I try to
> autoreconf
> in libgomp/
> i get this error "plugin/Makefrag.am:29: error: libgomp_la_LIBADD must be
> set with '=' before using '+='"
> line 29 in libgomp/plugin/Makefrag.am has
> "libgomp_la_LIBADD += $(DL_LIBS)"
> I removed this line and "autoreconf" worked fine.
> Do I miss some packages?

Are you using automake 1.15.1 that should be used?

Anyway, the error seems to be incorrect,
libgomp_la_LIBADD is set in libgomp/Makefile as
libgomp_la_LIBADD =
before
include $(top_srcdir)/plugin/Makefrag.am
a few lines later.

	Jakub

Re: problem with Makefile.in generation in lingomp

[Mohamed Atef]

I use 1.15.1.
This is the link to the line I mentioned.
https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29


On Fri, May 20, 2022 at 11:40 AM Jakub Jelinek <jakub@redhat.com> wrote:

> On Fri, May 20, 2022 at 11:25:59AM +0200, Mohamed Atef wrote:
> >    I downloaded the last version of the repo, but when I try to
> > autoreconf
> > in libgomp/
> > i get this error "plugin/Makefrag.am:29: error: libgomp_la_LIBADD must be
> > set with '=' before using '+='"
> > line 29 in libgomp/plugin/Makefrag.am has
> > "libgomp_la_LIBADD += $(DL_LIBS)"
> > I removed this line and "autoreconf" worked fine.
> > Do I miss some packages?
>
> Are you using automake 1.15.1 that should be used?
>
> Anyway, the error seems to be incorrect,
> libgomp_la_LIBADD is set in libgomp/Makefile as
> libgomp_la_LIBADD =
> before
> include $(top_srcdir)/plugin/Makefrag.am
> a few lines later.
>
>         Jakub
>
>

Re: problem with Makefile.in generation in lingomp

[Jakub Jelinek]

On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
> I use 1.15.1.
> This is the link to the line I mentioned.
> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29

You shouldn't be running autoreconf, just automake to regenerate
Makefile.in, and when I run it, it certainly doesn't emit that error.

Anyway, can you explain the
https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
commit?  That makes the branch quite useless.
The point is that all commits pushed to gcc trunk have to have proper
ChangeLog in the commit log to describe the actual changes in that commit.
Commits aren't allowed to be pushed there unless they satisfy the checking.
On development branches this isn't checked on commits, but if those
branches are meant to be usable for commits to trunk later, they need to
follow those rules (as I said, git gcc-verify should check it).
I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
could, you've used the same ChangeLog entry but that doesn't describe
the changes you've done in that commit, you've reverted some Makefile.am
changes (why?), removed the FSF Copyright lines (that is ok but it should
have been replaced by the Copyright The GNU Toolchain Authors. line in that
case), but the ChangeLog then would need to describe those changes.

	Jakub

Re: problem with Makefile.in generation in lingomp

[Jakub Jelinek]

On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
> I use 1.15.1.
> This is the link to the line I mentioned.
> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29

You shouldn't be running autoreconf, just automake to regenerate
Makefile.in, and when I run it, it certainly doesn't emit that error.

Anyway, can you explain the
https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
commit?  That makes the branch quite useless.
The point is that all commits pushed to gcc trunk have to have proper
ChangeLog in the commit log to describe the actual changes in that commit.
Commits aren't allowed to be pushed there unless they satisfy the checking.
On development branches this isn't checked on commits, but if those
branches are meant to be usable for commits to trunk later, they need to
follow those rules (as I said, git gcc-verify should check it).
I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
could, you've used the same ChangeLog entry but that doesn't describe
the changes you've done in that commit, you've reverted some Makefile.am
changes (why?), removed the FSF Copyright lines (that is ok but it should
have been replaced by the Copyright The GNU Toolchain Authors. line in that
case), but the ChangeLog then would need to describe those changes.

	Jakub

Re: problem with Makefile.in generation in lingomp

[Mohamed Atef]

In fact that's why i downloaded the repo again i forget to modify the
copyright and when i tried to repush but i got an error As my branch is not
updated i wanted delete the branch and create new one and push again.
If you have the authority to remove the last batch please do.

في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٢ م Jakub Jelinek <jakub@redhat.com> كتب:

> On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
> > I use 1.15.1.
> > This is the link to the line I mentioned.
> >
> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
>
> You shouldn't be running autoreconf, just automake to regenerate
> Makefile.in, and when I run it, it certainly doesn't emit that error.
>
> Anyway, can you explain the
> https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
> commit?  That makes the branch quite useless.
> The point is that all commits pushed to gcc trunk have to have proper
> ChangeLog in the commit log to describe the actual changes in that commit.
> Commits aren't allowed to be pushed there unless they satisfy the checking.
> On development branches this isn't checked on commits, but if those
> branches are meant to be usable for commits to trunk later, they need to
> follow those rules (as I said, git gcc-verify should check it).
> I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
> passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
> could, you've used the same ChangeLog entry but that doesn't describe
> the changes you've done in that commit, you've reverted some Makefile.am
> changes (why?), removed the FSF Copyright lines (that is ok but it should
> have been replaced by the Copyright The GNU Toolchain Authors. line in that
> case), but the ChangeLog then would need to describe those changes.
>
>         Jakub
>
>

Re: problem with Makefile.in generation in lingomp

[Mohamed Atef]

I am really sorry.

في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef <mohamedatef1698@gmail.com>
كتب:

> In fact that's why i downloaded the repo again i forget to modify the
> copyright and when i tried to repush but i got an error As my branch is not
> updated i wanted delete the branch and create new one and push again.
> If you have the authority to remove the last batch please do.
>
> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٢ م Jakub Jelinek <jakub@redhat.com> كتب:
>
>> On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
>> > I use 1.15.1.
>> > This is the link to the line I mentioned.
>> >
>> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
>>
>> You shouldn't be running autoreconf, just automake to regenerate
>> Makefile.in, and when I run it, it certainly doesn't emit that error.
>>
>> Anyway, can you explain the
>> https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
>> commit?  That makes the branch quite useless.
>> The point is that all commits pushed to gcc trunk have to have proper
>> ChangeLog in the commit log to describe the actual changes in that commit.
>> Commits aren't allowed to be pushed there unless they satisfy the
>> checking.
>> On development branches this isn't checked on commits, but if those
>> branches are meant to be usable for commits to trunk later, they need to
>> follow those rules (as I said, git gcc-verify should check it).
>> I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
>> passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
>> could, you've used the same ChangeLog entry but that doesn't describe
>> the changes you've done in that commit, you've reverted some Makefile.am
>> changes (why?), removed the FSF Copyright lines (that is ok but it should
>> have been replaced by the Copyright The GNU Toolchain Authors. line in
>> that
>> case), but the ChangeLog then would need to describe those changes.
>>
>>         Jakub
>>
>>

Re: problem with Makefile.in generation in lingomp

[Mohamed Atef]

I cloned he repo again but there is a problem here.
This line is not in the previous repo.
https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29

في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef <mohamedatef1698@gmail.com>
كتب:

> I am really sorry.
>
> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef <mohamedatef1698@gmail.com>
> كتب:
>
>> In fact that's why i downloaded the repo again i forget to modify the
>> copyright and when i tried to repush but i got an error As my branch is not
>> updated i wanted delete the branch and create new one and push again.
>> If you have the authority to remove the last batch please do.
>>
>> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٢ م Jakub Jelinek <jakub@redhat.com> كتب:
>>
>>> On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
>>> > I use 1.15.1.
>>> > This is the link to the line I mentioned.
>>> >
>>> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
>>>
>>> You shouldn't be running autoreconf, just automake to regenerate
>>> Makefile.in, and when I run it, it certainly doesn't emit that error.
>>>
>>> Anyway, can you explain the
>>> https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
>>> commit?  That makes the branch quite useless.
>>> The point is that all commits pushed to gcc trunk have to have proper
>>> ChangeLog in the commit log to describe the actual changes in that
>>> commit.
>>> Commits aren't allowed to be pushed there unless they satisfy the
>>> checking.
>>> On development branches this isn't checked on commits, but if those
>>> branches are meant to be usable for commits to trunk later, they need to
>>> follow those rules (as I said, git gcc-verify should check it).
>>> I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
>>> passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
>>> could, you've used the same ChangeLog entry but that doesn't describe
>>> the changes you've done in that commit, you've reverted some Makefile.am
>>> changes (why?), removed the FSF Copyright lines (that is ok but it should
>>> have been replaced by the Copyright The GNU Toolchain Authors. line in
>>> that
>>> case), but the ChangeLog then would need to describe those changes.
>>>
>>>         Jakub
>>>
>>>

Re: problem with Makefile.in generation in lingomp

[Mohamed Atef]

The problem is fixed now.
Thanks.
Should i push again with the first change log

في الجمعة، ٢٠ مايو، ٢٠٢٢ ٩:٢٠ م Mohamed Atef <mohamedatef1698@gmail.com>
كتب:

> I cloned he repo again but there is a problem here.
> This line is not in the previous repo.
>
> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
>
> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef <mohamedatef1698@gmail.com>
> كتب:
>
>> I am really sorry.
>>
>> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef <mohamedatef1698@gmail.com>
>> كتب:
>>
>>> In fact that's why i downloaded the repo again i forget to modify the
>>> copyright and when i tried to repush but i got an error As my branch is not
>>> updated i wanted delete the branch and create new one and push again.
>>> If you have the authority to remove the last batch please do.
>>>
>>> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٢ م Jakub Jelinek <jakub@redhat.com> كتب:
>>>
>>>> On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
>>>> > I use 1.15.1.
>>>> > This is the link to the line I mentioned.
>>>> >
>>>> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
>>>>
>>>> You shouldn't be running autoreconf, just automake to regenerate
>>>> Makefile.in, and when I run it, it certainly doesn't emit that error.
>>>>
>>>> Anyway, can you explain the
>>>> https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
>>>> commit?  That makes the branch quite useless.
>>>> The point is that all commits pushed to gcc trunk have to have proper
>>>> ChangeLog in the commit log to describe the actual changes in that
>>>> commit.
>>>> Commits aren't allowed to be pushed there unless they satisfy the
>>>> checking.
>>>> On development branches this isn't checked on commits, but if those
>>>> branches are meant to be usable for commits to trunk later, they need to
>>>> follow those rules (as I said, git gcc-verify should check it).
>>>> I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
>>>> passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
>>>> could, you've used the same ChangeLog entry but that doesn't describe
>>>> the changes you've done in that commit, you've reverted some Makefile.am
>>>> changes (why?), removed the FSF Copyright lines (that is ok but it
>>>> should
>>>> have been replaced by the Copyright The GNU Toolchain Authors. line in
>>>> that
>>>> case), but the ChangeLog then would need to describe those changes.
>>>>
>>>>         Jakub
>>>>
>>>>