[llvm-bugs] [Bug 51223] New: AVR driver can't find avr-libc in /opt/local/avr/

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51223

            Bug ID: 51223
           Summary: AVR driver can't find avr-libc in /opt/local/avr/
           Product: clang
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mhjacobson at me.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

$ clang -v
clang version 13.0.0 (https://github.com/llvm/llvm-project.git
4e52a04833fb352090498d6d1c013a2c61d75e53)

A common AVR toolchain setup on macOS is to use /opt/local/ as the "prefix" and
/opt/local/avr/ as the "sysroot" where the headers and libraries live.  Under
this scheme:

* avr-gcc lives at /opt/local/bin/avr-gcc (the cc1s live in
/opt/local/libexec/gcc/...),
* the AVR binutils live in /opt/local/avr/bin/ (hardlinked to avr-prefixed
versions in /opt/local/bin/), and
* avr-libc (including the crt0s) lives in /opt/local/avr/lib/.

In clang 13.0.0, I can't find any way to get the driver to link an AVR program
with this setup.  I'm using (see NOTE below):

$ clang -v -o build/foo -mmcu=atmega644p -target avr --sysroot /opt/local/ -I
'=avr/include' build/foo.o

which produces

clang-13: warning: no avr-libc installation can be found on the system, cannot
link standard libraries [-Wavr-rtlib-linking-quirks]
clang-13: warning: standard library not linked and so no interrupt vector table
or compiler runtime routines will be linked [-Wavr-rtlib-linking-quirks]

followed by the expected linker failures because libc is missing.

I think I tracked this down to the fact that `PossibleAVRLibcLocations` (in
Driver/ToolChains/AVR.cpp) consists of "/usr/avr" and "/usr/lib/avr", neither
of which (even when prepended with the given `--sysroot`) is a directory that
exists.

If I add simply "avr" to that array, things work great.  But as far as I know
there's no way to control that without rebuilding clang.

===

NOTE: In that clang invocation above, I *believe* it would be more correct for
me to use

--sysroot /opt/local/avr/ -I '=include'

If I do that, however, I get a different weird warning (notice it's complaining
about `avr-gcc`, not avr-libc):

clang: warning: no avr-gcc installation can be found on the system, cannot link
standard libraries [-Wavr-rtlib-linking-quirks]

I don't understand this warning -- surely clang shouldn't need to invoke
`avr-gcc` itself, right?  Why would knowing where `avr-gcc` is be important to
find the avr-libc libraries?

In any case, the `PossibleAVRLibcLocations` situation described above means
that the driver tries looking for avr-libc in /opt/local/avr/usr/avr and
/opt/local/avr/usr/lib/avr, neither of which exist.

===

Patch I used to make my setup work, for posterity:

diff --git a/clang/lib/Driver/ToolChains/AVR.cpp
b/clang/lib/Driver/ToolChains/AVR.cpp
index ea35abb86f45..85edf905dcc7 100644
--- a/clang/lib/Driver/ToolChains/AVR.cpp
+++ b/clang/lib/Driver/ToolChains/AVR.cpp
@@ -298,6 +298,7 @@ llvm::Optional<unsigned> GetMCUSectionAddressData(StringRef
MCUName) {
 }

 const StringRef PossibleAVRLibcLocations[] = {
+    "/avr",
     "/usr/avr",
     "/usr/lib/avr",
 };

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210727/337637cf/attachment-0001.html>