Project

General

Profile

Actions

Bug #5465

closed

CFLAGS missing from BUILD.SO in lib/Makefile.lib

Added by Gary Mills almost 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
lib - userland libraries
Start date:
2014-12-21
Due date:
% Done:

100%

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

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

lib.diff (695 Bytes) lib.diff Gary Mills, 2014-12-21 10:20 PM
libMlib.diff (887 Bytes) libMlib.diff Gary Mills, 2015-03-13 01:51 PM

Related issues

Related to illumos gate - Bug #5468: Missing dependencies in lib/MakefileClosedYuri Pankov2014-12-21

Actions
Actions #1

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

Actions #2

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.)

Actions #3

Updated by Gary Mills over 8 years ago

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
Actions #4

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.

Actions #5

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.

Actions #6

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.

Actions #7

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>

Actions

Also available in: Atom PDF