Maneage - Bugs: bug #58353, bsd/unistd.h configure fails
You are not allowed to post comments on this tracker with your current authentication level.
bug #58353: bsd/unistd.h configure fails
Submitter: | Boud Roukema <boud> | ||
Submitted: | Mon 11 May 2020 04:15:59 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Closed |
Wed 13 May 2020 05:58:34 PM UTC, comment #5: |
Boud Roukema <boud> |
Tue 12 May 2020 10:45:39 PM UTC, comment #4: That is very strange! I just done a clean build and looking at the output of '--check-config', I see that isl was built in 1.5 minutes!
|
Mohammad Akhlaghi <makhlaghi> |
Tue 12 May 2020 06:04:34 PM UTC, comment #3: A clean build on one machine bypasses this problem, but took 11 hours:
|
Boud Roukema <boud> |
Mon 11 May 2020 09:03:10 PM UTC, comment #2: Is this on a new system? These are pretty low-level tools and were successfully built in your previous trials of Maneage, so given that we haven't changed anything basic, I am a little confused why they have crashed now.
|
Mohammad Akhlaghi <makhlaghi> |
Mon 11 May 2020 04:21:01 PM UTC, comment #1: The log is at: this framadrop URL. |
Boud Roukema <boud> |
Mon 11 May 2020 04:15:59 PM UTC, original submission:
DESCRIPTION:
so there seems to be a mix of libbsd's own versions of files and the host system's choices of files being successively included.
|
Boud Roukema <boud> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-05-13 | boud | Open/Closed | Open | Closed | |
2020-05-12 | boud | Severity | 5 - Blocker | 3 - Normal |
Powered by Savane 3.13-f8d8.
Corresponding source code
I did separate clean builds on commits:
All three builds finished fine. No sign of anything unusual with isl.
So I consider the revised bug to be irreproducible.
I still have a system in the state the reproduces the original bug; I'll try doing a clean build there too. But I think it's safe to close this bug for now. I'll re-open it if needed.
I agree that some sort of hardware hibernation type effect would have to explain the apparent 10-hour isl compile, which is irrelevant here.