Project

General

Profile

Bug #3891

Incorrect Makefiles for C++ SPARC

Added by Gary Mills over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
tools - gate/build tools
Start date:
2013-07-16
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

In building illumos-gate on OpenSXCE2013.05 SPARC, I ran into problems with C++ compiles. This error only affects 32-bit modules or executables built with the Sun Studio compiler. According to the CC man page, the correct library order in standard mode is `-lCstd -lCrun'. This is reversed in Makefile.master .
Also in Makefile.master, for compatibility mode, `-lC' is placed on the command line before the object files. It will be ignored in that position. Apparently, the compiler or linker do not re-order or re-scan libraries; they have to be in the correct position on the command line.
I'm doing the build with these compilers and linker:
@ 32-bit compiler
/opt/onbld/bin/sparc/cw -_cc
cw version 1.29
primary: /opt/SUNWspro/bin/cc
cc: Sun C 5.10 SunOS_sparc 2009/06/03
shadow: /opt/gcc/4.4.4/bin/gcc
gcc (Illumos tags/gcc-4.4.4-il-2) 4.4.4

64-bit compiler
/opt/onbld/bin/sparc/cw -_cc
cw version 1.29
primary: /opt/SUNWspro/bin/cc
cc: Sun C 5.10 SunOS_sparc 2009/06/03
shadow: /opt/gcc/4.4.4/bin/gcc
gcc (Illumos tags/gcc-4.4.4-il-2) 4.4.4
/usr/ccs/bin/ld
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1742 (illumos)

I get this error in the case of reversed libraries:
+ /opt/SUNWspro/bin/CC -o libsun_fc.so.1 -G -h libsun_fc.so.1 -ztext -zdefs -M../common/mapfile-vers -M.../usr/src/common/mapfiles/common/map.pagealign -Bdirect -norunpath -nolib pics/Lockable.o
...
pics/Sun_fcDoForceLip.o pics/Sun_fcAdapterCreateWWN.o pics/Sun_fcAdapterReturnWWN.o -L.../proto/root_sparc/lib -L.../proto/root_sparc/usr/lib -ldevinfo -lsysevent -lnvpair -lCrun -lCstd -lc
Undefined first referenced
symbol in file
void*__Crun::vector_del(void*,unsigned,void()(void)) /opt/SUNWspro/sunstudio12.1/prod/lib/sparc/libCstd.a(locale.o)
void _Crun::zero_ints(void*,unsigned) /opt/SUNWspro/sunstudio12.1/prod/lib/sparc/libCstd.a(JgODNtf1KmTCkNJKK2Ek.o)
void*
_Crun::vector_new(void*,unsigned,unsigned,void()(void),void()(void)) /opt/SUNWspro/sunstudio12.1/prod/lib/sparc/libCstd.a(locale.o)
void operator delete[](void*) /opt/SUNWspro/sunstudio12.1/prod/lib/sparc/libCstd.a(ios.o)
ld: fatal: symbol referencing errors. No output written to libsun_fc.so.1

and this error in the case of wrong placement:
+ /opt/SUNWspro/bin/CC -O -cg92 -compat=4 -Qoption ccfe -messages=no%anachronism -xwe -DTEXT_DOMAIN="SUNW_OST_OSCMD" -D_TS_ERRNO -I.../proto/root_sparc/usr/include -I../include -I. -norunpath -nolib -Bdirect
...
-L../utilities -lC convert.o file.o main.o parse.o -o audioconvert -L.../proto/root_sparc/lib -L.../proto/root_sparc/usr/lib -laudio -lm -lc
Undefined first referenced
symbol in file
vector_con convert.o
operator delete(void*) convert.o
operator new(unsigned int) convert.o
pure_error ../utilities/libaudio.a(Audio.o)
[Hint: try checking whether you are linking with the correct libC]
_ex_rethrow_q convert.o
ld: fatal: symbol referencing errors. No output written to audioconvert
@
The attached patch fixes the problem.

Files

Mfiles.diff.Z (1.37 KB) Mfiles.diff.Z Gary Mills, 2013-07-16 02:16 PM

History

#1

Updated by Rich Lowe over 7 years ago

I'm a bit surprised by that, since my builds on SPARC succeed. The order of dynamic libraries relative to objects on the command line shouldn't really matter, either (nor relative to eachother). Are we trying to use the static versions, there? audioconvert, for eg, links the dynamic libC.so.5 (from /usr/lib) in my builds, and libsunfc the dynamic Crun/Cstd. Where you're very clearly linking the archive libraries in the Studio directories.

I wonder if this is something to do with using Studio 12.1, rather than the patched 12?

#2

Updated by Gary Mills over 7 years ago

Static linking! That's something I never considered. I see from `ldd' that it's clearly the problem. Even 64-bit C++ builds are statically linked. Thanks for noticing. I'll revert the Makefiles and pursue the real problem.

#3

Updated by Gary Mills over 7 years ago

  • Status changed from New to Closed

I found the cause of this linking failure. The symbolic links to C++ shared objects in /usr/lib were all broken in /opt/SUNWspro . These were relative symlinks; they need one more `../' in order to resolve. Consequently, the linker only found the static C++ libraries. Once I fixed that problem, I was able to build illumos-gate on OpenSXCE2013.05 with no changes to illumos Makefiles. This bug report is closed.

Also available in: Atom PDF