OpenSolaris

1. Community: OS/Net (ON)
   1. Blogs
   2. Development Process
   3. Developer's Reference
      1. Introduction
      2. Prerequisites
      3. The Source Tree, part 1
      4. The Source Tree, part 2
      5. Building OpenSolaris
      6. Installing and Testing OpenSolaris
      7. Integration Procedure
      8. Best Practices and Requirements
      9. Glossary
   4. Discussions
   5. Installation (from source) Quickstart
      1. Annotated nightly(1) Mail Example
   6. Currently Known Issues
   7. CRT
      1. Advocates & Sponsors
      2. Becoming a CRT Advocate
      3. Charter
      4. RTI nits to avoid
      5. Sponsor Tasks
      6. Becoming a Sponsor
   8. Schedule
   9. ONNV Flag Days, Heads Ups, and Project Integration History
      1. All
      2. Builds 91-95
      3. Builds 86-90
      4. Builds 81-85
      5. Builds 76-80
      6. Builds 71-75
      7. Builds 66-70
      8. Builds 61-65
      9. Builds 56-60
      10. Builds 51-55
      11. Builds 46-50
      12. Builds 41-45
      13. Builds 36-40
      14. Builds 31-35
      15. Builds 26-30
      16. Builds 21-25
   10. Leaders
   11. Observers
   12. Putback Logs
   13. Developing Solaris
       1. Quality Death Spiral
   14. wx
   15. findunref and unreferenced files
   16. Bourne/Korn Shell Coding Conventions

Heads up: Potential problem with GNU ld objects and snv_62 through snv_66

Date: Thu, 14 Jun 2007 13:31:47 -0600
From: Ali Bahrami <Ali.Bahrami at Sun dot COM>
To: onnv-gate at onnv dot eng dot sun dot com
Subject: Heads up: Potential problem with GNU ld objects and snv_62 through snv_66

My fix, in snv_62, for

     6516665 The link-editors should be more resilient against
             gcc's symbol versioning

has triggered two separate cases (6565476 and 6569636) where objects
linked with GNU ld that worked on earlier versions of Solaris no longer
work correctly. I put back a fix last Monday (June 11):

     6565476 rtld symbol version check prevents GNU ld binary from running

to address this. The purpose of this heads up is to warn others
using GNU ld, in the hope that no one else will lose time debugging
this same issue.

If you use GNU ld, and have a program that has worked on Solaris,
but which is failing to run (or to run correctly) on a system
running snv_62 or newer, use elfdump on it as follows:

     % elfdump file > /dev/null

If you see output that looks like:

     a.out: .dynsym: index[15]: version 2 is out of range:
         version definitions available: 0-0

then your program is hitting this case. The giveaway is that the
available version definitions in the file are '0-0', but it has
symbols with version indexes greater than 1.

If you are hitting this, the solution is to upgrade to snv_67
(or newer). Alternatively, you can BFU from any build that contains
the putbacks from Monday June 11th.

As detailed in the evaluation of 6565476, these symbols are
created by GNU ld as a result of copy relocations. We (linker group)
believe that these ELF files are incorrect --- an object without version
definitions (VERDEF section) should never define symbols with a
version index greater than 1. GNU interoperability is important
though, so 6565476 relaxes the recently added checks to allow
this case to work. (Mail has been sent to the GNU ld maintainer
requesting help in understanding what GNU ld is doing, and why,
but there is no answer yet).

The CR evaluations for 6516665 and 6565476 contain more detailed
information on this topic.

- Ali