Project

General

Profile

Actions

Bug #9692

closed

libvscan has bad _msg dependency

Added by Jason King about 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
lib - userland libraries
Start date:
2018-08-02
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:
External Bug:

Description

Upstream of Joyent OS-7100:

(I'm just including Robert's analysis as it's where we finally got to the bottom of the issue)

The problem here is a little involved, but ultimately straightforward. Let's take this apart starting in libvscan and go from there.
Starting in libvscan, when one run runs dmake _msg there are a few issues. The first is that while the target is normally just:

_msg:   $(MSGDOMAINPOFILE)

There is an additional dep on _msg as part of the general SUBDIRS statement. However, this itself is problematic. Because while _msg is in the SUBDIRS list, there is no rule to conditionally assign to $(TARGET). This means that when it invokes the rule, it will descend, $(TARGET) will be unset, so it will build the default target which is all. This is seen pretty clearly when one uses -dd to dmake:
   Building i386 because new command
        cd i386; pwd; /home/rm/src/tiresias/proto.strap/usr/bin/dmake
   different from empty old command
   Building i386 because new command longer than old

This is what causes us to always try and build the actual library when we're building messages.
This on its own is not sufficient to cause the build failure seen above. When building the _msg target in $(SRC)/Makefile, it will descend into lib/ and run the target. However, there we explicitly ignore dependencies when running _msg and use the -nodepend variants. As a result it will always descend and because this is in parallel with the other install tasks, it's not hard for us to end up in a situation where due to the earlier bug, and the lack of a link against libnsl due to illumos#9673, that we then fail.

Actions

Also available in: Atom PDF