dumprestore.h may lost link-time ABI compatibility with -fno-common
Issue #342
resolved
union u_spcl type has tentative definition with same name.
union u_spcl {
...
} u_spcl;
c-lang spec defines tentative definition that:
- has no storage class specifier
- has no initializer
may interpreted to:
- has individual storage per compilation unit.
- has external linkage
but old K&R compiler will do:
- compiler labeled them so called common block.
- when link time, tentative definitions labeled as common block and has same name merged into single global variable
gcc adopts latter as default, but they changed prior as default sinceversion 10.
that is the reason why N/F/O changes code as following:
extern union u_spcl {
...
} u_spcl;
- http://cvsweb.netbsd.org/bsdweb.cgi/src/include/protocols/dumprestore.h.diff?r1=1.18&r2=1.19
- https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/include/protocols/dumprestore.h.diff?r1=1.10&r2=1.11
- https://cgit.freebsd.org/src/commit/include/protocols/dumprestore.h?id=33ceb489d33e71b81adbd12bded321ad4486e42a
but those fix may lose ABI compatibility on link time(undefined symbol u_spcl).
Comments (4)
-
reporter -
reporter - edited description
-
reporter another way, leave u_spcl common block by __attribute__((__common__))
-
reporter - changed status to resolved
BUGFIX: Issue
- dumprestore.h may lost link-time ABI compatibility with -fno-common add new library libdumprestore.a to keep link-time binary compatibility between -fcommon and -fno-common#342→ <<cset ac3988e1013a>>
- Log in to comment
to keep link time ABI compatibility, `u_spcl' symbol must exists on libc or at least we have to introduce new library -ldumprestore.
if we don’t, 3rd party application that includes dumprestore.h should declare u_spcl body themselves, this may lose API incompatibility too.