Opened 2 years ago

Closed 2 years ago

#28695 closed defect (fixed)

gcc: mismatch of assembler / linker during configure

Reported by: embray Owned by:
Priority: minor Milestone: sage-9.1
Component: build: configure Keywords:
Cc: dimpase Merged in:
Authors: Erik Bray Reviewers: Dima Pasechnik
Report Upstream: N/A Work issues:
Branch: ca7013b (Commits, GitHub, GitLab) Commit: ca7013b61464c3516db1554534f6f01f2b6514ad
Dependencies: Stopgaps:

Status badges

Description (last modified by dimpase)

When activating the sage environment (e.g. with sage -sh) for some reason (I'm not sure what the motivation is - but cf. #14296, where this was set up) it sets the AS environment variable by calling

$CC -print-file-name=as

and likewise with LD.

In my case this command is just returning the strings as and ld without a full path.

However, when I run ./configure in this environment I get output like:

checking g++ version... 7.4.0
configure: Installing GCC because there is a mismatch of assemblers
configure:   g++ -std=gnu++11 -std=gnu++11 uses /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/as.exe
configure:   $AS equal to as
configure: Installing GCC because there is a mismatch of linkers
configure:   g++ -std=gnu++11 -std=gnu++11 uses /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/ld.exe
configure:   $LD equal to ld

and, in turn, sage will try to build its own gcc.

Change History (14)

comment:1 Changed 2 years ago by dimpase

How about changing file to prog?

$ gcc  -print-prog-name=as
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/as

comment:2 Changed 2 years ago by dimpase

  • Description modified (diff)

comment:3 Changed 2 years ago by embray

Yes, that seems to give the answer the configure script is likely looking for:

$ gcc  -print-prog-name=as
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/as.exe

However, I wonder why sage-env sets $AS and $LD in the first place.

comment:4 follow-up: Changed 2 years ago by dimpase

#14296 checks that as and ld match what compiler have, although it does it wrongly, imho.

comment:5 in reply to: ↑ 4 Changed 2 years ago by embray

Replying to dimpase:

#14296 checks that as and ld match what compiler have, although it does it wrongly, imho.

Yes, as you say it should probably use -print-prog-name instead; I wonder if that was something that changed in gcc at one point.

However, that still doesn't answer why sage-env sets those variables too, which seems unnecessary...

comment:6 Changed 2 years ago by embray

Also I think it's a bit overkill that it will just go ahead and build gcc in this case. Perhaps it should just error-out the configure instead. It's a misconfiguration, and should tell the user as such, rather than just plowing ahead and compiling a different gcc.

comment:7 Changed 2 years ago by embray

I see; the sage-env changes were made as part of that ticket as well, I guess to prevent a user's $LD or $AS from breaking things somehow.

I still think that's overkill; we can't just override every imaginable environment variable in the user's environment that might have some undesired impact. This strikes me as the kind of thing that annoyed someone once, just enough, that it required a workaround.

However, I'd be okay with keeping the sage-env stuff as long as it is changed to use -print-prog-name, and we change the configure script to make inconsistency on this a hard error.

comment:8 Changed 2 years ago by dimpase

Yes, I agree that ./configure should just error out on such a mismatch. As to sage-env, I'd have just removed that check, as over-engineering (but proceed as you like, your solution just might need more checks, with clang...).

comment:9 Changed 2 years ago by embray

  • Milestone changed from sage-9.0 to sage-9.1

Ticket retargeted after milestone closed

comment:10 Changed 2 years ago by embray

Ahhh, I forgot about this, but it still causes problems when trying to install optional packages if you're already in a sage environment shell (this is especially a problem for the Windows version). I'll go ahead and make a patch...

comment:11 Changed 2 years ago by embray

Interesting--for some reason I wasn't able to reproduce this problem on my local Windows development build, but I was on Sage installed by the Windows installer. It turns out this almost already works because the current code in build/pkgs/gcc/spkg-configure.m4 reads like:

    if test -n "$AS"; then
        CXX_as=`$CXX -print-prog-name=as 2>/dev/null`
        CXX_as=`command -v $CXX_as 2>/dev/null`
        cmd_AS=`command -v $AS`

        if ! (test "$CXX_as" = "" -o "$CXX_as" -ef "$cmd_AS"); then
            SAGE_SHOULD_INSTALL_GCC([there is a mismatch of assemblers])
            AC_MSG_NOTICE([  $CXX uses $CXX_as])
            AC_MSG_NOTICE([  \$AS equal to $AS])
        fi
    fi

The tricky part is in the test ... $CXX_as -ef $cmd_AS. I didn't know this but the -ef flag means the two files have the same device and inode number. In my case I had

CXX_as=/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/as.exe
cmd_AS=/usr/bin/as

but it turns out this test is true in my case, so /usr/bin/as must be a hard link to the real as.exe. However, after being bundled into the installer and then unpacked the two files are just copies of each other--oops. Right now the build of the Windows installer does not have a good way to preserve hard links.

Nevertheless, the fact that this happens to work on my Cygwin install is a happy accident. I think this is still an issue, and the fix is the same.

comment:12 Changed 2 years ago by embray

  • Authors set to Erik Bray
  • Branch set to u/embray/ticket-28695
  • Commit set to ca7013b61464c3516db1554534f6f01f2b6514ad
  • Priority changed from major to minor
  • Status changed from new to needs_review

New commits:

b6833f7Trac #28695: Make mismatch between compiler and AS/LD a fatal error.
ca7013bTrac #28695: These settings (if they are even needed at all) should use

comment:13 Changed 2 years ago by dimpase

  • Reviewers set to Dima Pasechnik
  • Status changed from needs_review to positive_review

lgtm

comment:14 Changed 2 years ago by vbraun

  • Branch changed from u/embray/ticket-28695 to ca7013b61464c3516db1554534f6f01f2b6514ad
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.