Bug #5465
closedCFLAGS missing from BUILD.SO in lib/Makefile.lib
100%
Description
A build with gcc 4.8.2 on the SPARC platform produces this error message:
Undefined first referenced
symbol in file
_lib_version ../screen/mapfile-vers
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
This first happens at usr/src/lib/libcurses/sparc . Investigation showed that some 32-bit libraries failed to build with this error, in spite of the fact that all 64-bit libraries built correctly. The reason is that BUILD.SO for 32-bit libraries is defined in lib/Makefile.lib with CFLAGS omitted. BUILD.SO for 64-bit libraries is defined in Makefile.master.64 with CFLAGS included. CFLAGS is the only variable that contains architecture options for the compiler. Specifically, it contains `-m32' for the 32-bit SPARC architecture. Modern compilers require this option to build libraries correctly on SPARC. The same thing may hold for the x86 platform, but I didn't test that. Adding CFLAGS to BUILD.SO in lib/Makefile.lib resulted in successful builds for 32-bit libraries. My patch file is attached.
Files
Related issues
Updated by Andrew Stormont over 8 years ago
It looks like BUILDCCC.SO should also be updated to pass CCFLAGS: https://github.com/illumos/illumos-gate/blob/master/usr/src/Makefile.master.64#L82
Updated by Gordon Ross over 8 years ago
It's also a little odd that the 32-bit BUILD.SO is in Makefile.lib but the 64-bit BUILD.SO is in Makefile.master.64
(I would have expected it to be in Makefile.lib.64 instead.)
Updated by Gary Mills over 8 years ago
- File libMlib.diff libMlib.diff added
Yes, I agree that there is a lack of symmetry in those files. It's not a good idea to change that now. I also agree that BUILDCCC.SO should be updated as well in Makefile.lib . I'm attaching an updated patch file, libMlib.diff, that does this.
With this change, a build with g++ on SPARC adds these options to the compiler command line:
-O -m32 -mcpu=v8 -mno-v8plus -mtune=supersparc -Werror -D_POSIX_PTHREAD_SEMANTICS
Updated by Andrew Stormont over 8 years ago
Perhaps if things were in a more logical place to begin with the two versions of the variables might have been kept in sync. I think BUILD.SO should be moved from Makefile.master.64 to lib/Makefile.lib.64 based on what Gordon has said.
Updated by Gary Mills over 8 years ago
You can't move it down the tree because only the library components of illumos will include lib/Makefile.lib.64. In fact, this Makefile contains only:
include $(SRC)/Makefile.master.64 TARGETMACH= $(MACH64)
If you are going to move macros, moving them up is easier. I'd recommend moving BUILD.SO and BUILDCCC.SO from lib/Makefile.lib to Makefile.master, and fixing them in the process.
Updated by Andrew Stormont over 8 years ago
BUILD.SO does seem very specific to libraries though. You will find libraries in usr/src/cmd and other directories including usr/src/lib/Makefile.lib too, so this seems to fit with that assumption.
Updated by Electric Monk over 8 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit ee637354acf5da3e4a5853a500f444e3aec1a76e
commit ee637354acf5da3e4a5853a500f444e3aec1a76e Author: Gary Mills <gary_mills@fastmail.fm> Date: 2015-04-28T00:33:04.000Z 5465 CFLAGS missing from BUILD.SO in lib/Makefile.lib Reviewed by: Andy Stormont <astormont@racktopsystems.com> Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com> Reviewed by: Garrett D'Amore <garrett@damore.org> Approved by: Gordon Ross <gwr@nexenta.com>