Bug #5595
closed
libzpool won't build with a studio primary
100%
Description
Since ZFS started putting inline functions in headers, libzpool has been unable to build with Sun Studio.
The reason is that Sun Studio creates COMDAT GROUP sections for the out-of-line version of these symbols, but in doing so creates invalid groups which refer to non-existent sections:
Group Section: .group%zap_m_phys
index flags / section signature symbol
[0] [ COMDAT ] zap_m_phys
[1] .text%zap_m_phys [6]
[2] <invalid section> [20]
[3] <invalid section> [21]
ld(1), quite rightly (in my view) considers this group invalid, and its presence a fatal error
ld: fatal: file pics/zap_micro.o: group section [2].group%zap_m_phys: entry 2: invalid section index: 20 ld: fatal: file pics/zap_micro.o: section [6].text%zap_m_phys: SHF_GROUP flag set, but no corresponding SHT_GROUP section found
There is nothing I can do about this except make ld(1) more forgiving of invalid groups where in this case "forgiving" is, perhaps, a way of saying "wrong". I would rather not do this.
Clearly, though, we also can't fix Sun Studio.
The other option is ZFS ceasing to use inline functions in headers like this, or doing so in a way which (portably) never emits an out-of-line definition.
Related issues
Updated by Rich Lowe over 8 years ago
What's happening is not Studio emitting invalid groups. What happens is that Studio emits a group that contains 3 sections, the .text, and the .stabs for the out-of-line functions.
ctfconvert then comes along and deletes the stabs sections as it runs, but never updates the group. This means the group is now trash.
ctfconvert needs to fix all this up. ld(1) is certainly working fine.
Updated by Rich Lowe over 8 years ago
- Status changed from New to In Progress
- Assignee set to Rich Lowe
- % Done changed from 0 to 80
Updated by Gordon Ross over 8 years ago
Generally, inline functions in headers are intended to be used only as inlines.
As long as that's true here, convincing the compiler to not create the external version of the inline seems best.
What's the best (portable) way to do that?
Updated by Rich Lowe over 8 years ago
I'm fixing ctfconvert (and ctfmerge) because they're unquestionably broken.
Updated by Gary Mills over 8 years ago
The Studio compiler has these options:
-features=[a]
The compiler's treatment of extern inline functions
conforms by default to the behavior specified by the
ISO/IEC 9899:1999 C standard. Compile new codes with
-features=no%extinl to obtain the same treatment of
extern inline functions as provided by versions 5.5, or
older, of the C and C++ compilers.
If you do not specify a flag for -features, the com-
piler sets it to -features=extinl.
extinl Generates extern inline functions as
global functions. This is the default,
which conforms with the 1999 C standard.
[no%]extinl Generates extern inline functions as
static functions.
Updated by Electric Monk over 8 years ago
- Status changed from In Progress to Closed
- % Done changed from 80 to 100
git commit 495021bdf7d49b2cc9a6e6981b5ec4110264741b
commit 495021bdf7d49b2cc9a6e6981b5ec4110264741b
Author: Richard Lowe <richlowe@richlowe.net>
Date: 2015-02-26T19:19:39.000Z
5595 libzpool won't build with a studio primary
Reviewed by: Josef 'Jeff' Sipek <josef.sipek@nexenta.com>
Reviewed by: Robert Mustacchi <rm@joyent.com>
Approved by: Gordon Ross <gwr@nexenta.com>
Updated by Electric Monk over 8 years ago
git commit c79a74a8321729c8f50472db67e907324bace4e5
commit c79a74a8321729c8f50472db67e907324bace4e5
Author: Richard Lowe <richlowe@richlowe.net>
Date: 2015-03-09T21:15:17.000Z
5595 libzpool won't build with a studio primary (fix usage message)