Bug 211079 - sysutils/uefi-edk2-bhyve: Can RUN_DEPENDS on gcc48 be removed?
Summary: sysutils/uefi-edk2-bhyve: Can RUN_DEPENDS on gcc48 be removed?
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2016-07-13 14:26 UTC by churchers
Modified: 2018-10-09 08:00 UTC (History)
7 users (show)

See Also:
bugzilla: maintainer-feedback? (fabian.freyer)
koobs: merge-quarterly?


Attachments
v0 (814 bytes, patch)
2016-07-14 13:29 UTC, Jan Beich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description churchers 2016-07-13 14:26:49 UTC
I've noticed that the uefi-edk2-bhyve port has a run-time dependency on gcc48, which means it installs gcc48 + several other packages when installed from pkg.

I don't know if this is something that can be easily changed, seeing as it does require gcc48 to build, but it seems excessive to install these when all the uefi-edk2-bhyve package contains are a couple of binary firmware images.
Comment 1 Jan Beich freebsd_committer freebsd_triage 2016-07-14 13:29:40 UTC
Created attachment 172511 [details]
v0

If you don't mind making portlint angry I did something similar in devel/fb-adb with USE_LINUX.

$ portlint -C
FATAL: Makefile: the last line of Makefile has to be .include <bsd.port(.post).mk>
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2016-07-14 13:37:33 UTC
Could this port instead use USES=compiler, or is this actually an issue for Mk/bsd.gcc.mk to allow for setting only BUILD_DEPENDS as per attachment 172511 [details] ?

If the latter, please create a new blocking issue under Ports Framework for the bsd.gcc.mk change
Comment 3 churchers 2016-07-16 09:47:58 UTC
Just looking at the grub2-bhyve port, I've noticed it also has USE_GCC=yes, but seems to have avoided the run dependency on gcc with the following at the end of the Makefile:

RUN_DEPENDS:= ${RUN_DEPENDS:Ngcc*}

Maybe that's the easiest solution. Not that I do much C development but it does seem strange that USE_GCC adds a run dependency by default. I would of thought it's reasonably unlikely a port would actually need gcc in order to run once built.
Comment 4 Fabian Freyer 2016-07-16 10:26:06 UTC
hmm, a quick grep shows that this is also how sysutils/grub2-efi, sysutils/grub2-pcbsd, sysutils/grub2-efi, sysutils/memtest86+ and misc/seabios do it.

So, agreed, this seems like the way to go. I'll update the diff to that extent.

However, it seems this port isn't the only one that has this problem; see https://www.freshports.org/lang/gcc/#RequiredByRun. I think most of the ports listed there only require gcc for building. So this is probably something of a general issue for bsd.gcc.mk.
Comment 5 elij 2017-04-21 21:37:40 UTC
Any update on this? I also would like to install uefi-edk2-bhyve without pulling in all the gcc deps.
Comment 6 Walter Schwarzenfeld 2018-02-08 18:52:01 UTC
Makefile still shows
MAKE_ARGS:
CC=${LOCALBASE}/bin/gcc48 \
CXX=${LOCALBASE}/bin/g++48

in the meantim gcc48 is
DEPRECATED=     Unsupported by upstream. Use GCC 6 or newer instead.
Comment 7 commit-hook freebsd_committer freebsd_triage 2018-03-10 10:08:28 UTC
A commit references this bug:

Author: tobik
Date: Sat Mar 10 10:07:45 UTC 2018
New revision: 464059
URL: https://svnweb.freebsd.org/changeset/ports/464059

Log:
  sysutils/uefi-edk2-bhyve: Remove GCC run dependency

  The firmware does not require or link with any of the libraries
  provided by GCC, so remove the GCC run dependency.

  Due to the lack of an accepted better solution in bsd.gcc.mk to do
  this, we use the hack used by other ports like devel/linux-kernel,
  sysutils/memtest86+, sysutils/grub2-bhyve, misc/seabios, net/ipxe, ...

  PR:		211079, 211154
  Approved by:	Process paralysis

Changes:
  head/sysutils/uefi-edk2-bhyve/Makefile
Comment 8 Tobias Kortkamp freebsd_committer freebsd_triage 2018-10-09 08:00:42 UTC
Fixed in ports r464059.