Ali Bahrami wrote:
>> These all look OK.
>>
>>> usr/src/tools/scripts/check_rtime.pl
>>
>> I'm NOT a Perl guy, I would prefer somebody else reviewed these changes.
>
> I'll have Rod look it over again, and Jim has also examined it in his
> comments.
I don't profess to be a perl expert, but all the changes seem in line with
previous coding practice, so the changes look good to me.
>>> usr/src/tools/scripts/nightly.sh
>>
>> - Do we still care about people running our nightly script on
>> pre-Solaris-9 systems? Maybe, but "ugh." (ref. lines 2959-2965)
>
> No, we don't. I'll consult with Rod and see.
Yes, this is old clutter, that could be removed.
>> - While John Forte was merging NWS bits, I spent a *ton* of time
>> helping him figure out a Makefile problem that was giving him a 32-bit
>> object when it should have been 64-bit. Is the LDDWRONG string (ref.
>> line 2966) actually correct? Because that would have gotten us there
>> MUCH sooner, I suspect. (We fell through this test, but then still
>> hit the next one, about CRLECONF.)
>
> I'm not sure, but I think it covers the case where you have a 32-bit kernel
> that can't run the 64-bit ldd. I'll ask Rod about that too...
This indicates the object under inspection couldn't be executed by ld.so.1
(which is what ldd(1) does to determine dependencies). From check_rtime:
# It's possible this binary can't be executed, ie.
we've
# found a sparc binary while running on an intel system,
# or a sparcv9 binary on a sparcv7/8 system.
if ($Line =~ /wrong class/) {
OutMsg($Ttl++, $RelPath,
"\thas wrong class or data encoding");
I suspect all our build machines today can execute 32 and 64-bit objects, so
unless you somehow get a sparc binary left in an intel build, you're not
going to see this error. Given we build both 32 and 64-bit objects it's
hard to tell when you've built the wrong one.
crle is called upon to create both a 32-bit object cache and a 64-bit object
cache. So, if it's given the wrong file to build a cache it's going to get
upset. For example, let's say you create a 64-bit version of libc, but by
mistake install this in $ROOT/lib. crle is going to be asked to create a
64-bit cache that associates /lib with $ROOT/lib and is going to complain:
chaz 894. crle -64 -c xxxxx -o $ROOT/lib -a /lib/libc.so.1
crle: /lib/libc.so.1: invalid ELF file
crle: configuration file: xxxx: not created
As there's no cache created, all file inspection within $ROOT (via ldd(1))
is going to use dependencies in the base file system - this might not be
sufficient to satisfy the requirements that would be met by the real
dependencies in $ROOT - so more errors may get reported by check_rtime.
Granted, the error probably isn't as obvious as "you've built the wrong
class file" or "you installed the file in the wrong destination dir".
Also note that this test isn't full proof. If you create $ROOT/foo/bar.so
and there is no system /foo/bar.so, crle doesn't reject the requested
redirection.
--
Rod.
