| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2166.1 | Re: build question take II | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Mar 27 1996 16:42 | 21 |
| Date Of Receipt: 21-MAR-1996 16:49:20.35
From: SMURF::FLUME::"[email protected]"
To: buildhelp [email protected]
CC:
Subj: Re: build question take II
Mike,
Yes the OS builds do some simple parallel building to get them done faster
by building a specific set of libraries that the rest of the build needs
and then fanning out to build many things at once.
It should build the ccs libraries first, only those with EXP references in
the Makefiles placing them in the exports directory, and then all the rest
of the os tree during another phase of the build.
If something is out of order for a top level build it should be added into
the EXP list so it gets built before nonEXP items that might need it.
Sean
|
| 2166.2 | Re: build question take II | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Mar 27 1996 16:43 | 52 |
| Date Of Receipt: 21-MAR-1996 16:52:40.06
From: SMURF::FLUME::"[email protected]" "Grant Van Dyck 21-Mar-1996 1649"
To: [email protected]
CC: [email protected]
Subj: Re: build question take II
| I still havn't gotten any response to this question.
| Is someone looking into this?
|
| Mike
|
| = To: buildhelp
| = Subject: build question
| = Date: Tue, 19 Mar 96 12:35:21 -0500
| = From: schloss
| = X-Mts: smtp
| =
| = I am running into a small problem and perhaps someone can explain
| = what I am seeing. As part of the LSM project we are creating a new
| = library, both shared and non-shared. A top down build of the entire
| = source tree causes the shared version to be built before the non-shared
| = version. Unfortunately, the shared version depends upon the non-shared
| = version so one is found somewhere in the backing-tree/shared-sandbox.
| = Is this a known issue? It looks to me like the PTOS nightly tree is
| = not built from a top-level build but is in fact built in a number of
| = steps with usr/ccs/lib being explicitly built before usr/shlib. Is
| = this correct?
The nightly build has a multi-pass approach - several portions being built
simultaneously, which is the case for shlib and ccs/lib - they build in
parallel.
At the end the process goes back for one quick top-down run - to ensure all
holes/dependencies are accounted for.
In this phase (logged in final_pass.log) it shows that ccs/lib is built BEFORE
shlib (ie. top-down build order is ccs/lib, shlib).
| Does a clean (after removing obj and export trees)
| = top-down build risk getting stale shared libraries, or am I
| = misunderstanding something about the process?
Not sure I understand this question, how would they be "stale"?
--
-Grant
|
| 2166.3 | Re: build question take II | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Mar 27 1996 16:57 | 72 |
| Date Of Receipt: 22-MAR-1996 11:37:41.78
From: SMURF::FLUME::"[email protected]" "John Flanagan USG Test Johnf Tools Group 22-Mar-1996 1134"
To: "Grant Van Dyck" <[email protected]>
CC: [email protected], [email protected]
Subj: Re: build question take II
I think I know what's going on here.
Make uses the folling passes rules to determine what order to traverse
the tree during a top down build:
_PASS_FIRST_TAGS_=EXPINC
_PASS_SECOND_TAGS_=EXPLIBC EXPCRT0 EXPLIBLD
_PASS_THIRD_TAGS_=EXPLOADER
_PASS_FOURTH_TAGS_=${NO_SHARED_LIBRARIES?:EXPSHLIB}
_PASS_FIFTH_TAGS_=EXPLIB
_PASS_BASIC_TAGS_=${SECURITY_ONLY?SECURITY:STANDARD}
#
# These list the variables used to define subdirectories to recurse into
#
_EXPINC_SUBDIRS_=${EXPINC_SUBDIRS}
_EXPLIBC_SUBDIRS_=${EXPLIBC_SUBDIRS}
_EXPCRT0_SUBDIRS_=${EXPCRT0_SUBDIRS}
_EXPLIBLD_SUBDIRS_=${EXPLIBLD_SUBDIRS}
_EXPLOADER_SUBDIRS_=${EXPLOADER_SUBDIRS}
_EXPSHLIB_SUBDIRS_=${EXPSHLIB_SUBDIRS}
_EXPLIB_SUBDIRS_=${EXPLIB_SUBDIRS}
_SECURITY_SUBDIRS_=${SEC_SUBDIRS}
_STANDARD_SUBDIRS_=${SUBDIRS}
Note that following the straight SUDIRS rule is at the bottom of the
pecking order. If you look at the usr/Makefile, you'll see the
following rules:
EXPINC_SUBDIRS = include s5 shlib 32bit
EXPLIBC_SUBDIRS = ccs
EXPSHLIB_SUBDIRS = shlib
EXPLIB_SUBDIRS = ccs
This means that when you sit in /usr and type build, the order is:
1) usr/include
2) usr/s5
3) usr/shlib !!!!
4) usr/32bit
5) usr/ccs
I think we need to look at this ordering a little closer and possibly
move "shlib" out of the EXPINC_SUDIRS rule. In fact, that would fix
this problem.
John
--
______________________________________________________________________
John Flanagan enet: [email protected]
MS: ZKO3-3/W20 decnet: flume::johnf
USG Release Engineering (603) 881-1719
110 Spitbrook Road (DTN) 381-1719
Nashua, NH
______________________________________________________________________
|
| 2166.4 | Re: build question take II | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Mar 27 1996 16:59 | 61 |
| Date Of Receipt: 22-MAR-1996 11:52:05.72
From: SMURF::FLUME::"[email protected]" "John Flanagan USG Test Johnf Tools Group 22-Mar-1996 1148"
To: John Flanagan - UNIX Systems Group <[email protected]>
CC: "Grant Van Dyck" <[email protected]>,
[email protected], [email protected],
[email protected]
Subj: Re: build question take II
And....
The reason that the build of libmsfs.so fails is due to its Makefile.
libmsfs.so assumes that the .a is built and pulls it in on the LD line.
Ouch! This Makefile needs to be written so that libmsfs.so can build
on its own. That's how most of the other libraries work. They can
build without the .a already being built.
Mike, who owns the usr/shlib/libmsfs Makefile?
John
ps, here's the libmsfs.so Makefile:
VPATH = ${MAKETOP}/usr/ccs/lib/libmsfs
EXPSHLIB_TARGETS = export_../usr/shlib/libmsfs.so
LIBMSFS = `genloc /obj/${machine}/usr/ccs/lib/libmsfs/libmsfs.a
`
SHARED_LIBRARIES = libmsfs.so
LDFLAGS = -all ${LIBMSFS} -none -error_unresolved \
-expect_unresolved task_threads \
-expect_unresolved task_info \
-expect_unresolved thread_info
LIBS = -hidden -llmf -lc
UPD_FILES = libmsfs.so
ILIST = libmsfs.so
IDIR = /shlib/
IMODE = 644
NOSTRIP =
--
______________________________________________________________________
John Flanagan enet: [email protected]
MS: ZKO3-3/W20 decnet: flume::johnf
USG Release Engineering (603) 881-1719
110 Spitbrook Road (DTN) 381-1719
Nashua, NH
______________________________________________________________________
|
| 2166.5 | Re: build question take II | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Mar 27 1996 17:01 | 27 |
| Date Of Receipt: 22-MAR-1996 12:17:48.42
From: SMURF::FLUME::"[email protected]" "Mike Schloss usg 22-Mar-1996 1214"
To: John Flanagan - UNIX Systems Group <[email protected]>
CC: "Grant Van Dyck" <[email protected]>,
[email protected]
Subj: Re: build question take II
> The reason that the build of libmsfs.so fails is due to its Makefile.
> libmsfs.so assumes that the .a is built and pulls it in on the LD line.
> Ouch! This Makefile needs to be written so that libmsfs.so can build
> on its own. That's how most of the other libraries work. They can
> build without the .a already being built.
>
> Mike, who owns the usr/shlib/libmsfs Makefile?
John Saywell (AdvFS) owns libmsfs but I think that you may be missing
something else here. This was the first library I looked at. I think
that someone should go through all the shlib makefiles and see how they
derive their obj files.
I am not sure that this is the "right" think to do in any case. What
is wrong with making .SOs depend on .As? As long as they get built in
the correct order isn't it more efficient to only build an object once?
Mike
|
| 2166.6 | Re: build question take II | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Mar 27 1996 17:03 | 33 |
| Date Of Receipt: 22-MAR-1996 12:34:54.02
From: SMURF::FLUME::"[email protected]" "John Flanagan USG Test Johnf Tools Group 22-Mar-1996 1231"
To: [email protected]
CC: John Flanagan - UNIX Systems Group <[email protected]>,
"Grant Van Dyck" <[email protected]>,
[email protected]
Subj: Re: build question take II
>>I am not sure that this is the "right" think to do in any case. What
>>is wrong with making .SOs depend on .As? As long as they get built in
>>the correct order isn't it more efficient to only build an object once?
The assumption to date has been that they can build independently. I think
we probably need to review this in post-Platinum releases; Whatever happens,
we need to be consistent; and right now this library is one of the very
few that build this way.
John
--
______________________________________________________________________
John Flanagan enet: [email protected]
MS: ZKO3-3/W20 decnet: flume::johnf
USG Release Engineering (603) 881-1719
110 Spitbrook Road (DTN) 381-1719
Nashua, NH
______________________________________________________________________
|
| 2166.7 | Re: build question take II | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Mar 27 1996 17:05 | 23 |
| Date Of Receipt: 22-MAR-1996 12:46:52.64
From: SMURF::FLUME::"[email protected]" "Mike Schloss usg 22-Mar-1996 1243"
To: John Flanagan - UNIX Systems Group <[email protected]>
CC: "Grant Van Dyck" <[email protected]>,
[email protected]
Subj: Re: build question take II
>> I am not sure that this is the "right" think to do in any case. What
>> is wrong with making .SOs depend on .As? As long as they get built in
>> the correct order isn't it more efficient to only build an object once?
> The assumption to date has been that they can build independently. I think
> we probably need to review this in post-Platinum releases; Whatever happens,
> we need to be consistent; and right now this library is one of the very
> few that build this way.
OK, but I would check out libc, libcomplex, libcxx, libfilesys, libm,
libmsfs, libots, libtask, and libvxvm first. A quick glance (grep) of
the Makefiles show that these files all make some refernce to libfoo.a
Mike
|