[Bug 292544] Failed to build edk2-bhyve g202508.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292544

Mark Millard <marklmi26-fbsd@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marklmi26-fbsd@yahoo.com

--- Comment #6 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
Some notes about the context:

gcc-ar is a gcc wrapping script intended for use with
binutils ar as it is in contexts like Linux: gcc-ar
has the purpose of implicitly/.automatically adding a
--plugin SO_NAME to the ar command line formed to
select the bintuils ar related plugin for giving ar
LTO support.

It appears that, for exmaple, lang/gcc15 installs a:

# file /usr/local/bin/gcc-ar15
/usr/local/bin/gcc-ar15: ELF 64-bit LSB executable, x86-64, version 1
(FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD
15.0 (1500065), FreeBSD-style, stripped


It is also the case that the use of the "@" notation
is part of the bintuils ar context (like on Linux):

QUOTE from https://man7.org/linux/man-pages/man1/ar.1.html :
      @file
           Read command-line options from file.  The options read are
           inserted in place of the original @file option.  If file does
           not exist, or cannot be read, then the option will be treated
           literally, and not removed.

           Options in file are separated by whitespace.  A whitespace
           character may be included in an option by surrounding the
           entire option in either single or double quotes.  Any
           character (including a backslash) may be included by prefixing
           the character to be included with a backslash.  The file may
           itself contain additional @file options; any such options will
           be processed recursively.
END QUOTE

It appears that devel/binutils installs the likes of:

# file /usr/local/bin/ar
/usr/local/bin/ar: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 15.0
(1500065), FreeBSD-style, stripped


Given that mostly-upstream sort of background information
. . .

I'll note that llvm-ar has:

QUOTE from "man 1 ar" on FreeBSD:
     @<FILE>
            Read command-line options and commands from response file <FILE>.
END QUOTE

Removing a "@" from in front of a response file's
name or path on a command line does not appear to
be sufficient to produce correct/intended behavior
in any context, though it may well change the error
reports that result.

As for the "ar: unrecognized option `--plugin'": that
would tend to suggest it is not a message from a
normal binutils ar implementation. For example:

# /usr/local/bin/ar --plugin
/usr/local/bin/ar: option `--plugin' requires an argument
. . .

The "man 7 ar" output for freebsd reports:

QUOTE
     Here's where llvm-ar departs from previous ar implementations:

     The following option is not supported
        [f] - truncate inserted filenames

     The following options are ignored for compatibility
        --plugin=<string> - load a plugin which adds support for other file
        formats

        [l] - ignored in ar
END QUOTE

But that means using llvm-ar would not produce the
error message:

# which ar
/usr/bin/ar

# ar -V
LLVM (http://llvm.org/):
  LLVM version 19.1.7
  Optimized build.

# ar --plugin
ar: error: plugin requires an argument

I've no clue what the port's intent is for the
commands in question as shown in the patch. But it
does not look like the patch is appropriate on its
own.

Given the way portmaster works, I've no clue which
or where it might be finding the gcc-ar or ar that
end up being used. But it does not seem to be any
of the above for the "ar" command, given the ar
command's message about --plugin notation on the
command line.

-- 
You are receiving this mail because:
You are the assignee for the bug.