[OmniOS-discuss] Building developer/make fails for unresolved dependencies

[Jim Klimov]

14 сентября 2014 г. 3:41:36 CEST, Dan Vatca <dan at syneto.net> пишет:
>Yes, it does it sometimes even when I run ./build.sh -bpil.
>This is very odd, as it seems to be failing randomly on successive
>runs.
>And given it takes around 30s on my machine, I ran it a lot of times
>just
>too see if there is a pattern.
>I tried running it with REMOVE_PREVIOUS=1 and it still sometimes fails.
>When it fails, it seems that it does not have this file:
>usr/lib/svr4.make
>(or can read it?). And it fails because the hardlinks point nowhere.
>Could
>it be a race condition where the file is not yet created? Seems far
>fetched, but will take a look at that shortly. Now I really have to get
>some sleep ...
>
>
>On Sun, Sep 14, 2014 at 12:16 AM, Dan McDonald <danmcd at omniti.com>
>wrote:
>
>>
>> On Sep 13, 2014, at 2:49 PM, Dan Vatca <dan at syneto.net> wrote:
>>
>> >
>> > There is the local.mog transform that must work to drop those
>> dependencies, but for some reason, it keeps failing when it runs
>through
>> build all.
>> > Any idea on what I'm missing?
>>
>> I honestly am not sure.  If you "cd make ; ./build.sh -bpil" what
>does it
>> do?
>>
>> I'm also curious what "buildctl list-build" says?  It sorts based
>solely
>> on bash's associative array sorting.  Maybe the default bash sorts
>one way,
>> and your bash (did you compile it oddly?) another way?
>>
>> Dan
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

Just in case, are you building on a local or an nfs-mounted filesystem? I've had issues with the latter due to nontrivial times and non-atomic operations to update the fs metadata (or the client's view of it) so compiled objects are not always seen when expected for the next step. Still, a parallel make over nfs followed by a sequential one to cover up the loose ends is usually faster than sequential all the way (at least with an nfs server which has no ddr zil ;) )
Also, some tools like yacc/lex/bison might use the same filename for all outputs, and i've had parallel builds fail due to that - and had to sequentialize those sections. That's not illumos specific, but experience from a number of open-soirce projects (many different OS releases as compute nodes use the same homedir with sources over nfs).
HTH,
Jim
--
Typos courtesy of K-9 Mail on my Samsung Android