Created attachment 236544 [details] Update the edk2 Makefile to use /usr/local/lib/gcc*/libgcc_s.so.1 The new: https://lists.freebsd.org/archives/freebsd-uboot/2022-September/000295.html for [package - 131arm64-default][sysutils/edk2] Failed for edk2-fvp-g202202_1 in build shows a failure reason: ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by /usr/local/lib/gcc11/libstdc++.so.6 not found Even main does not have GCC_4.5.0 in /lib/libgcc_s.so.1: # strings /lib/libgcc_s.so.1 | grep GCC_ | more GCC_3.0 GCC_3.3 GCC_3.3.1 GCC_3.4 GCC_3.4.2 GCC_3.4.4 GCC_3.5 GCC_4.0.0 GCC_4.2.0 GCC_4.3.0 GCC_4.6.0 Until/unless FreeBSD makes /lib/libgcc_s.so.1 have the symbols that aarch64 gcc/g++/libstdc++ actually requires under various conditions, it takes linking against the g++*'s specific /usr/local/lib/gcc*/libgcc_s.so.1 instead of using /lib/libgcc_s.so.1 when the activity happens to hit those conditions. EDK2 and other things around do not always do this.
(In reply to Mark Millard from comment #0) For portlint I get: # portlint -C /usr/ports/sysutils/edk2/ WARN: Makefile: [37]: Setting a specific version for USE_GCC should only be done as a last resort. Unless you have confirmed this port does not build with later versions of GCC, please use USE_GCC=${GCC_VINTAGE}:build+. WARN: Makefile: "ONLY_FOR_ARCHS" has to appear earlier. WARN: Makefile: "ONLY_FOR_ARCHS_REASON" has to appear earlier. 0 fatal errors and 3 warnings found. The USE_GCC WARN is tied to being able to bind rpath to the right /usr/local/lib/gcc*/libgcc_s.so.1 . I'm not aware of a hook for being able to handle such for :build+ possibly picking a newer GCC vintage. The ONLY_FOR_ARCHS WARNs are historical and are for conditional such based on FLAVOR . I replaced some space sequences with tab usage, thus avoiding some historical WARNs. In my aarch64 enviroment I get: [00:05:00] [03] [00:04:46] Finished sysutils/edk2@fvp | edk2-fvp-g202202_1: Success [00:05:21] [04] [00:05:07] Finished sysutils/edk2@macchiatobin | edk2-macchiatobin-g202202_1: Success [00:06:27] [05] [00:06:13] Finished sysutils/edk2@rpi3 | edk2-rpi3-g202202_1: Success [00:06:27] [01] [00:06:13] Finished sysutils/edk2@rpi4 | edk2-rpi4-g202202_1: Success This was in a context where I had set lang/gcc12 as the default.
(In reply to Mark Millard from comment #1) I forgot to note that I took a stab at providing a WWW= . . . as well.
For reference, about the invented GCC_VINTAGE: I invented GCC_VINTAGE instead of directly referencing GCC_DEFAULT everywhere because edk2 at times goes long periods with being broken for building on newer gcc*'s and port patching need not be easy/appropriate. (There are multiple upstreams and such involved overall, for example.) GCC_VINTAGE allows editing one place to specify, say, 12 if 13 or later would be a problem but 12 is no longer the default. This makes it easier to avoid sysutils/edk2 being a reason to delay GCC_DEFAULT updates in the future: update GCC_VINTAGE instead.
(In reply to Mark Millard from comment #3) Looks like my attempt is wasteful garbage. /usr/ports/Mk/bsd.gcc.mk has: # A concrete version has been selected. Set proper ports dependencies, # CC, CXX, CPP, and flags. V:= ${_USE_GCC:S/.//} . if ${V} == 13 _GCC_PORT:= gcc${V}-devel . else _GCC_PORT:= gcc${V} . endif CC:= gcc${V} CXX:= g++${V} CPP:= cpp${V} _GCC_RUNTIME:= ${LOCALBASE}/lib/gcc${V} . if ${PORTNAME} == gcc # We don't want the rpath stuff while building GCC itself # so we do not set the FLAGS as done in the else part. # When building a GCC, we want the target libraries to be used and not the # host GCC libraries. . else CFLAGS+= -Wl,-rpath=${_GCC_RUNTIME} CXXFLAGS+= -Wl,-rpath=${_GCC_RUNTIME} LDFLAGS+= -Wl,-rpath=${_GCC_RUNTIME} -L${_GCC_RUNTIME} . endif .undef V So use of either the CFLAGS/CXXFLAGS/LDFLAGS or use of the likes of: -Wl,-rpath=${_GCC_RUNTIME} -L${_GCC_RUNTIME} would autoadjust, allowing :build+ use. I see only about 4 ports with Makefiles directly using _GCC_RUNTIME .
Comment on attachment 236544 [details] Update the edk2 Makefile to use /usr/local/lib/gcc*/libgcc_s.so.1 Looks like there is ports infrastruture to help with using the right -Wl,-rpath=/usr/local/lib/gcc* . So this attempt of mine looks to be wasteful garbage.
Created attachment 236582 [details] Update the edk2 Makefile to use /usr/local/lib/gcc*/libgcc_s.so.1 This updated patch uses bsd.ports.pre.mk material to track the lang/gcc* that the ports infrastucture picks. portlint reports: # portlint -C /usr/ports/sysutils/edk2/ WARN: Makefile: [23]: Setting a specific version for USE_GCC should only be done as a last resort. Unless you have confirmed this port does not build with later versions of GCC, please use USE_GCC=yes:build+. WARN: Makefile: "ONLY_FOR_ARCHS" has to appear earlier. WARN: Makefile: "ONLY_FOR_ARCHS_REASON" has to appear earlier. But its suggested notation "USE_GCC=yes:build+" is rejected in poudriere bulk testing. For example: [00:00:07] Ignoring sysutils/edk2@fvp | edk2-fvp-g202202_1: bad target specification in USE_GCC; only "build" is supported Thus the use of just: USE_GCC=yes:build The ONLY_FOR_ARCHS relted notices are because of historically present such conditional on FLAVOR .
(In reply to Mark Millard from comment #6) For reference: [00:04:49] [02] [00:04:36] Finished sysutils/edk2@fvp | edk2-fvp-g202202_1: Success [00:05:11] [03] [00:04:58] Finished sysutils/edk2@macchiatobin | edk2-macchiatobin-g202202_1: Success [00:06:15] [04] [00:06:02] Finished sysutils/edk2@rpi3 | edk2-rpi3-g202202_1: Success [00:06:18] [01] [00:06:05] Finished sysutils/edk2@rpi4 | edk2-rpi4-g202202_1: Success
(In reply to Mark Millard from comment #6) FYI: I did not do anything relative to the likes of testport reporting as below: # poudriere testport -jmain-CA72 sysutils/edk2@macchiatobin . . . ===> Building package for edk2-macchiatobin-g202202_1 pkg-static: DEVELOPER_MODE: Notice: arch "FreeBSD:14:aarch64" -- no architecture specific files found: **** could this package use a wildcard architecture? . . . ===> Registering installation for edk2-macchiatobin-g202202_1 pkg-static: DEVELOPER_MODE: Notice: arch "FreeBSD:14:aarch64" -- no architecture specific files found: **** could this package use a wildcard architecture? . . .
It has been a little over 15 days since attachment 236582 [details] . If I understand right, at this point any committer with an interest could commit some variation on it that they find appropriate in order to get EDK2 building on FreeBSD's aarch64 build servers. (I'm fine with others adjusting what I submitted. Or they can have me do so if adjustments are appropriate.)
Comment on attachment 236582 [details] Update the edk2 Makefile to use /usr/local/lib/gcc*/libgcc_s.so.1 Mark, I can commit your patch, but I do not have any knowledge on this port. Although there is indeed a maintainer timeout, I don't feel confident in committing it without an explicit maintainer approval (by the way, be careful to not forget asking for maintainer approval on your patches: I am adding the flag for you). Is anyone in uboot@ able to approve this patch? Maybe manu@?
(In reply to Lorenzo Salvadore from comment #10) manu@ is the creator and most frequent one to commit over the port's history. The commit history shows, more recent to older, the last being port creation: Oleg Sidorkin Emmanuel Vadot Rebecca Cran Emmanuel Vadot Rebecca Cran Emmanuel Vadot Emmanuel Vadot Emmanuel Vadot Emmanuel Vadot Alexey Dokuchaev Stefan Eßer Emmanuel Vadot Andrew Turner Roger Pau Monné Roger Pau Monné Roger Pau Monné Emmanuel Vadot Emmanuel Vadot Roger Pau Monné Emmanuel Vadot Mathieu Arnold Mathieu Arnold Mark Linimon Emmanuel Vadot
The patch looks good to my eye. I'm only weakly on uboot@ these days, so consider this 'weak' maintainer approval to move forward, but if Manu has issues, listen to him more than me.
(In reply to Lorenzo Salvadore from comment #10) It has been about 2 weeks since: "maintainer approval on your patches: I am adding the flag for you" So, Warner's "'weak' maintainer approval" may be all you are going to get.
(In reply to Mark Millard from comment #13) Yea, I was thinking "wait 24-48 hours for manu to object and then go for it" when I made the comments. I'm too swamped to properly test any commits here, so please proceed.
(In reply to Warner Losh from comment #14) I'm not a committer. Lorenzo or some other committer will have to be the one to "please proceed" at some point.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=819bf69c15605e1e31998c91fb3fd02d5bc9fa0f commit 819bf69c15605e1e31998c91fb3fd02d5bc9fa0f Author: Mark Millard <marklmi26-fbsd@yahoo.com> AuthorDate: 2022-10-21 21:47:14 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2022-10-21 22:00:03 +0000 sysutils/edk2: Fix build on aarch64 Build on aarch64 was failing with the following error: ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by /usr/local/lib/gcc11/libstdc++.so.6 not found Fix by using /usr/local/lib/gcc*/libgcc_s.so.1 instead. While here, also define WWW variable. PR: 266404 Approved by: imp (uboot) sysutils/edk2/Makefile | 51 +++++++++++++++++++++++++++++--------------------- 1 file changed, 30 insertions(+), 21 deletions(-)
Finally committed. Thanks Mark and sorry for the delay.
(In reply to Lorenzo Salvadore from comment #17) http://ampere3.nyi.freebsd.org/build.html?mastername=131arm64-default&build=5bb856165324 shows sysutils/edk2@fvp , sysutils/edk2@rpi4 , sysutils/edk2 , and sysutils/edk2@rpi3 all built (under 13.1-RELEASE). The other flavors are amd64 only. So no build failures. I do not know if updating quarterly to avoid the failure notices would be appropriate or not.
(In reply to Mark Millard from comment #18) In general it is a good idea to merge into the quarterly branch build fixes. However, in this case, - the patch has been committed with a 'weak' maintainer approval only. So, while we know builds are fine, we do not know if the patch could also have introduced some bad side effect at runtime; - as far as I know, there is no demand for edk2 on aarch64: indeed this PR has been opened to submit the patch directly, not because someone needed to run on edk2 on aarch64. Hence, I believe that there is no hurry to merge quarterly and we can wait the next quarterly branch.
(In reply to Lorenzo Salvadore from comment #19) > indeed this PR has been opened to submit the patch > directly, not because someone needed to run on edk2 on aarch64. Well . . . While I later made a better patch, my first patch was submitted in support of someone having problems with the usual u-boot.bin based booting in RPi3 and/or RPi4 contexts with specific USB boot devices involved. (It was not known if either EDK2 would end up being better or not.) I was hoping to leave them with the self buildable alternative for which ever FreeBSD version(s) they wanted. They use aarch64 (and armv7) to exclusion as far as I know. They build their own ports as I understand. They run a mix of main [so: 14] and stable/13 or, may be, releng/13, as I remember. Not a large number of folks, for sure. As stands, the person in question has used the pftf releases from the web to experiment. As I understand, those 2 EDK2 releases (or just the RPi3 one?) ended up with a mixed status. I do not know if they will end up building 1 or both ports and testing such or not. > I believe that there is no hurry to merge quarterly and > we can wait the next quarterly branch. The above need not change that status. It is just that the context was not as simple as presented.
(In reply to Mark Millard from comment #20) Thanks Mark for this additional information. Indeed, I have been too quick in my reply and I should have thought about it more. Moreover, even if no one wanted edk2 on aarch64 from the quarterly branch today, someone might still want it next week. So that argument I provided was wrong. There is however still the argument that the patch has only a weak maintainer approval. I don't feel very confident in forwarding to the quarterly branch a commit that I don't fully understand without a strong approval. I would still prefer to wait for the next quarterly branch (or a strong approval, or some successfull runtime testing on all architectures and flavors).
(In reply to Lorenzo Salvadore from comment #21) > a commit that I don't fully understand Just an FYI. I'll note that other ports than EDK2 have had issues with aarch64 FreeBSD's libgcc_s.so.1 being incomplete relative to GCC aarch64 code generation and have also needed to use a: /usr/local/lib/gcc*/libgcc_s.so.1 instead to supply all the required things that the GCC compiler expects to be supplied. "version GCC_4.5.0" is not the only missing thing in the aarch64 FreeBSD libgcc_s.so.1 . For example, in an aarch64 context, g++ use floating point support routines can be an issue, here code that was generated inside libstdc++.so . . . # more trivial.cpp // aarch64 g++12 example that shows the symbols missing for the // /usr/local/lib/gcc12/libstdc++.so.6 build involved : // // # g++12 -o trivial -L/usr/lib trivial.cpp // // This finds /usr/lib/libgcc_s.so , which in turn is a link // to /lib/libgcc_s.so.1 . int main() { } For example, in my context: # g++12 -o trivial -L/usr/lib trivial.cpp /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__floatunditf@GCC_4.2.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__subtf3@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__unordtf2@GCC_4.5.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__getf2@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__addtf3@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__letf2@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__fixunstfdi@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__multf3@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__eqtf2@GCC_3.0' /usr/local/bin/ld: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd13.1/12.2.0/../../../libstdc++.so: undefined reference to `__lttf2@GCC_3.0' collect2: error: ld returned 1 exit status If it turns out that GCC/G++ happens to not generate a reference to something that is missing, such build errors do not happen when /lib/libgcc_s.so.1 is being used. But if GCC/G++ generates a reference to such, a use of a /usr/local/lib/gcc*/libgcc_s.so.1 is needed. Some ports were likely marked broken instead of being fixed.
(In reply to Mark Millard from comment #22) I found my old, even simpler, example, avoiding libstdc++ completely: # more fp-binding-failure-aarch64.cpp #include <cmath> volatile long double v=NAN; int main() { return std::isnan(v) ? 1 : 0; } # g++11 fp-binding-failure-aarch64.cpp # ./a.out ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by /usr/home/root/c_tests/a.out not found The a.out has its own reference to __unordtf2@GCC_4.5.0 : # nm -a a.out | grep '@GCC_[4-9]\.' | more U __unordtf2@GCC_4.5.0 (It is text from an old message.)
(In reply to Mark Millard from comment #23) Actually, that 2nd example still does implicitly have a libstdc++ binding involved,, so not as simple as I was thinking. But it does show ending up with the a.out having its own __unordtf2@GCC_4.5.0 reference.
As possibly one of the "not a large number" of folks playing with edk2, I'll offer a couple of thoughts: My interest in EDK2 was stimulated by difficulties using u-boot, in particular what looked like USB disk discovery failures that were not readiy diagnosable with u-boot. It appeared for a time as if EDK2 might be a more tractable alternative. Mark revealed more of the debugging features of u-boot and the existence of EDK2. Additionally he has explained how to make EDK2 compile for Pi3 under poudriere. Meanwhile, it looks as if most of the disk discovery problems have been fixed by HPS's patches to FreeBSD's USB system. USB disk discovery is still imperfect, but it's usable now. U-boot seems inferior to the FreeBSD boot manager from i386 days. If EDK2 has potential as an alternative to u-boot it appears desirable to encourage development. At the very least having man pages for either port would be helpful. Thanks for reading, bob prohaska
(In reply to Bob Prohaska from comment #25) I'll note that HPS's changes were to FreeBSD and do not contribute solutions to problems at earlier stages. So I learn that the earlier stages (RPi* firmware, U-boot.bin [or EDK2's code]) were not where most of the failures were. (I'm unsure about if the FreeBSD EFI loader got any changes, I've not gone back to look.)