On 10/4/2022 4:31 PM, Chris Johns wrote:
On 5/10/2022 12:52 am, Ryan Long wrote:
It looks like gcc checks for gsed if sed is not the GNU version.
Thanks for checking this.
I've installed it on FreeBSD and MacOS. I had to install it via Homebrew on
MacOS, but that's because it fails to build gsed.
Homebrew complicates your work. I make sure my test Macs have never had Homebrew
or Macports installed. When I played with this a long time ago the install
prefix was /usr/local and after a while I found I had no idea what was installed
and what was provided by the OS and if the base OS versions were overwritten. I
believe Macports is not doing this these days (if it ever did) but I have not
looked.
On the m1 macs, Homebrew installs under /opt/homebrew/bin. The prefix
for Intel macs is /usr/local, so I assume anything installed would be
under /usr/local/homebrew/bin.
I don't know when the packages in Homebrew may overwrite the programs
used by the systems, but at least in the case of gsed, it didn't
overwrite the system's sed.
The error is "machine `arm64-apple' not recognized".
Does the GNU sed upstream project have a fix?
I looked into how Homebrew builds it. All that they do is
def install
args = %W[
--prefix=#{prefix}
--disable-dependency-tracking
]
args << if OS.mac?
"--program-prefix=g"
else
"--without-selinux"
end
system "./configure", *args
system "make", "install"
I experimented with the building of gsed with the RSB. I just removed
the --host flag, and I was able to get around the error. However, it
then reports
sizes: gsed-4.8-arm64-apple-darwin21.6.0-1: 16.874MB (installed: 0.000B)
So I added this check to get around that, and it built successfully.
Sorry, I see Homebrew and Macports as user options and not a project option. We
need repeatable builds and not builds based on a local checkout of some
packages.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
