All versions of elfsign prior to the latest in Nevada and S10U have had
serious problems. Unfortunately each fix disclosed further invalid
assumptions about how the sections of an ELF object might be
organized. We had a script in place in RE that recognized the damage
due to 6214106 and shipped the original object unsigned. This same
script avoided the breakage due to 6301500. In retrospect, we should
have enhanced this script when 6283570 was discovered.
-JZ
> From Chris.Quenelle at Sun.COM Tue Oct 4 09:59:07 2005
>
> That was exactly what I wanted to hear!
> Thank you very much, John.
>
> (Sorry for the false alarm, Alan)
>
> Note:
> I assume that the elfsign in S10 FCS was good, and
> that the fix for 6214106 which caused the regression
> got pushed into a patch that ended up on the S10 machine
> that you use for signing. (I assume this since 6214106
> says it was integrated into onnv-B8)
>
> --chris
>
>
> John E. Zolnowsky wrote:
> > The SW Release Engineering signing server is a Solaris 10 machine.
> > The fix for CR 6283570 misaligned ELF64 section heads was
> > integrated into Solaris Nevada, was backported to Solaris 10,
> > and a patch generated around the beginning of September.
> > In the meantime, CR 6301500 Multiple elfsign failures in SPARC &
> > X86 SUNWgcc package was discovered, fixed, backported, and
> > its patch (which include the fix for 6283570) is about to be
> > released. This patch will soon be applied to the signing server,
> > and the signing process will stop breaking new objects.
> > At that time I will scan all Solaris 10 objects for breakage, and
> > instigate patch revisions so any broken objects can be resigned with
> > the fixed signing server.
> > This message posted from opensolaris.org
> > _______________________________________________
> > tools-linking mailing list
> > tools-linking at opensolaris.org
>
