Hi Petr,
Can you please tell us what you need to resolve this bug?
I'm currently unable to do OpenWRT development because of hitting this bug.
Looking at google search results, it seems to be a known issue but looking in the "make" project pages on fsf.org I don't see an upstream tracker for this.
Am I correct in assuming that it's Fedora specific?
Thanks,
-Philip
On 08/31/2013 01:44 AM, Philip Prindeville wrote:
Hi Petr,
Can you please tell us what you need to resolve this bug?
I'm currently unable to do OpenWRT development because of hitting this bug.
Looking at google search results, it seems to be a known issue but looking in the "make" project pages on fsf.org I don't see an upstream tracker for this.
Am I correct in assuming that it's Fedora specific?
Unclear. The test case in the bug report works for me on Fedora 18 x86_64 (and Fedora 19, too).
I suspect that before we can fix this, we need a better test case.
Philip Prindeville philipp_subx@redfish-solutions.com wrote:
Hi Petr,
Can you please tell us what you need to resolve this bug?
I'm currently unable to do OpenWRT development because of hitting this bug.
Looking at google search results, it seems to be a known issue but looking in the "make" project pages on fsf.org I don't see an upstream tracker for this.
Am I correct in assuming that it's Fedora specific?
Thanks,
-Philip
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
I initially passed over this email quickly but I just realized that I ran into this issue as well. You're trying to compile in an NFS mounted directory, right? The problem is that it can't use flock on its lock files. I had to move the openwrt tree to a local filesystem to be able to compile.
On 08/31/2013 01:44 AM, Philip Prindeville wrote:
Hi Petr,
Can you please tell us what you need to resolve this bug?
I'm currently unable to do OpenWRT development because of hitting this bug.
Looking at google search results, it seems to be a known issue but looking in the "make" project pages on fsf.org I don't see an upstream tracker for this.
Am I correct in assuming that it's Fedora specific?
I guess, no. AFAIS, this makefile carries deps on directories.
This is a very old known general limitation of and portability isse with make and one of known "donts".
"Deps on dirs" work on local Linux file systems, but doesn't work on linux nfs and is known to not have worked with local files systems on other *nices.
Ralf
On 09/01/2013 07:10 PM, Ralf Corsepius wrote:
"Deps on dirs" work on local Linux file systems, but doesn't work on linux nfs and is known to not have worked with local files systems on other *nices.
Ugh. Does it really have to be this way? But surely we can provide a better diagnostic.
On 09/02/2013 10:29 AM, Florian Weimer wrote:
On 09/01/2013 07:10 PM, Ralf Corsepius wrote:
"Deps on dirs" work on local Linux file systems, but doesn't work on linux nfs and is known to not have worked with local files systems on other *nices.
Ugh. Does it really have to be this way?
You mean the diagnostics or make's behavior?
All I says "Deps on dirs" have been an issue ever since and are a latent threat to all manually written make rules. I recall automake once (10yrs+ ago?) was affected by this issue, which had caused automake to introduce using deps on ".dirstamp" files.
It's just thanks to the fact, other *nices and other OSes' makes have become less common, which lets people forget about this issue. As long as developers only work with gmake on local filesystems on Linux, they won't ever see trip over this issue.
But surely we can provide a better diagnostic.
Sure ;)
Ralf
Ralf Corsepius wrote:
As long as developers only work with gmake on local filesystems on Linux, they won't ever see trip over this issue.
Actually, the issue here is that it doesn't work on local filesystems. Perhaps similar behavior with remote filesystems is an older issue.
On 09/02/2013 05:06 PM, Andrew Schultz wrote:
Ralf Corsepius wrote:
As long as developers only work with gmake on local filesystems on Linux, they won't ever see trip over this issue.
Actually, the issue here is that it doesn't work on local filesystems. Perhaps similar behavior with remote filesystems is an older issue.
OK, then this would be a different issue.
Ralf
On Sep 2, 2013, at 8:46 AM, Ralf Corsepius rc040203@freenet.de wrote:
On 09/02/2013 10:29 AM, Florian Weimer wrote:
On 09/01/2013 07:10 PM, Ralf Corsepius wrote:
"Deps on dirs" work on local Linux file systems, but doesn't work on linux nfs and is known to not have worked with local files systems on other *nices.
Ugh. Does it really have to be this way?
You mean the diagnostics or make's behavior?
All I says "Deps on dirs" have been an issue ever since and are a latent threat to all manually written make rules. I recall automake once (10yrs+ ago?) was affected by this issue, which had caused automake to introduce using deps on ".dirstamp" files.
It's just thanks to the fact, other *nices and other OSes' makes have become less common, which lets people forget about this issue. As long as developers only work with gmake on local filesystems on Linux, they won't ever see trip over this issue.
Except that I was using a local filesystem, and saw it anyway.
-Philip
But surely we can provide a better diagnostic.
Sure ;)
Ralf
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Ralf Corsepius rc040203@freenet.de writes:
I guess, no. AFAIS, this makefile carries deps on directories.
This is a very old known general limitation of and portability isse with make and one of known "donts".
"Deps on dirs" work on local Linux file systems, but doesn't work on linux nfs and is known to not have worked with local files systems on other *nices.
Apparently, Linux just joined the ranks of "other *nices"--I can reproduce the problem on local filesystems just fine. I didn't know it's a "don't", thanks for pointing this out.
Thanks, PM
On 09/02/2013 01:44 PM, Petr Machata wrote:
Ralf Corsepius rc040203@freenet.de writes:
I guess, no. AFAIS, this makefile carries deps on directories.
This is a very old known general limitation of and portability isse with make and one of known "donts".
"Deps on dirs" work on local Linux file systems, but doesn't work on linux nfs and is known to not have worked with local files systems on other *nices.
Apparently, Linux just joined the ranks of "other *nices"--I can reproduce the problem on local filesystems just fine. I didn't know it's a "don't", thanks for pointing this out.
Well, maybe my recollection was correct. Many years ago, I got burried in "deps on dirs" issues and am avoiding them since then ;)
However, I recall another case, "deps on dirs" often don't work: (massively) "parallel make".
Did you try to build the package single-threaded (make -j1)?
The "old school" automake approach (ca. 20 years old) to avoid such issues was to not use "deps in dirs", but to create dirs as side-effect of files. The "new school" automake approach (ca. 10 years old) to avoid such issue is to use deps on dirstamp-files.
Ralf
Ralf Corsepius rc040203@freenet.de writes:
However, I recall another case, "deps on dirs" often don't work: (massively) "parallel make".
Did you try to build the package single-threaded (make -j1)?
No, it used -j2 (as bug 885474 suggests).
PM.
On Sun, Sep 1, 2013 at 7:10 PM, Ralf Corsepius rc040203@freenet.de wrote:
"Deps on dirs" work on local Linux file systems, but doesn't work on linux nfs and is known to not have worked with local files systems on other *nices.
The obvious question here is way ... what exactly does it try to do which fails?
On Tue, Sep 3, 2013 at 10:37 AM, drago01 drago01@gmail.com wrote:
On Sun, Sep 1, 2013 at 7:10 PM, Ralf Corsepius rc040203@freenet.de wrote:
"Deps on dirs" work on local Linux file systems, but doesn't work on linux nfs and is known to not have worked with local files systems on other *nices.
The obvious question here is way ... what exactly does it try to do which fails?
s/way/why(
devel@lists.stg.fedoraproject.org
-
Andrew Schultz -
drago01 -
Florian Weimer -
Petr Machata -
Philip Prindeville -
Ralf Corsepius -
Samuel Sieb