Page MenuHomePhabricator

[Driver] Add -print-multiarch-triple
ClosedPublic

Authored by phosek on Apr 27 2021, 2:30 PM.

Details

Summary

This is useful in runtimes build for example which currently try to
guess the correct triple where to place libraries in the multiarch
layout. Using this flag, the build system can get the correct triple
directly by querying Clang.

Diff Detail

Event Timeline

phosek created this revision.Apr 27 2021, 2:30 PM
phosek requested review of this revision.Apr 27 2021, 2:30 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 27 2021, 2:30 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

gcc has --print-multiarch. Just use --print-multiarch? I think our semantics are compatible.

It seems odd to have print-runtime-dir tests in immediate-options.c. The tests should be moved to a print-* file.

phosek updated this revision to Diff 341001.Apr 27 2021, 3:25 PM

gcc has --print-multiarch. Just use --print-multiarch? I think our semantics are compatible.

I wasn't aware that GCC already has this option but using the same spelling definitely makes sense.

It seems odd to have print-runtime-dir tests in immediate-options.c. The tests should be moved to a print-* file.

I can move it in a separate change.

MaskRay accepted this revision.Apr 27 2021, 3:40 PM

LG

clang/test/Driver/print-multiarch.c
6

--match-full-lines --strict-whitespace or use {{^}}x86_64-linux-gnu{{$}}

This revision is now accepted and ready to land.Apr 27 2021, 3:40 PM
phosek updated this revision to Diff 341015.Apr 27 2021, 4:03 PM
phosek marked an inline comment as done.
This revision was landed with ongoing or failed builds.Apr 27 2021, 4:05 PM
This revision was automatically updated to reflect the committed changes.
jrtc27 added a subscriber: jrtc27.Sep 8 2021, 1:09 PM

This includes the version number, at least for FreeBSD, in its output, which doesn't make a huge deal of sense to me. This then breaks the build of Python because it generates a module with a name like _sysconfigdata__freebsd14_x86_64-unknown-freebsd14.0.py, and when it comes to import that as _sysconfigdata__freebsd14_x86_64-unknown-freebsd14.0 which breaks because that gets parsed as something like "import 0 from _sysconfigdata__freebsd14_x86_64-unknown-freebsd14". Of course, the Python code is bad here, it shouldn't be failing like that, but given the use case for --print-multiarch it seems to me that the version number shouldn't be included? Does GCC take a stance on this?

jrtc27 added a comment.Sep 8 2021, 1:13 PM

Answering the last part myself: GCC only has MULTIARCH_DIRNAME definitions for various linux-gnu*, linux-musl, linux-uclibc, kfreebsd-gnu and -gnu (as an OS, for GNU/Hurd) targets, everything else prints a blank string here. So either we need to decide what the right behaviour is for other OSes, or we should similarly leave it as undefined for non-GNUish (including musl and uclibc) targets?