Follow aur4 version
Search Criteria
Package Details: refind-efi-git 0.8.7.3.374.d738a7a-1
Package Actions
- View PKGBUILD
- Download tarball
- Search wiki
- Flagged out-of-date (2015-06-09)
| Package Base: | refind-efi-git |
|---|---|
| Description: | Rod Smith's fork of rEFIt UEFI Boot Manager - GIT Version - Built with GNU-EFI libs |
| Upstream URL: | http://www.rodsbooks.com/refind/index.html |
| Category: | system |
| Licenses: | |
| Conflicts: | |
| Provides: | |
| Submitter: | ridikulusrat |
| Maintainer: | None |
| Last Packager: | ridikulusrat |
| Votes: | 4 |
| First Submitted: | 2012-11-12 14:04 |
| Last Updated: | 2015-03-31 03:41 |
Dependencies (6)
- bash
- dosfstools
- efibootmgr
- gnu-efi-libs (make)
- imagemagick (optional) – For refind-mkfont script
- mactel-boot (optional) – For bless command in Apple Mac systems
Required by (0)
Sources
- refind
- refind_linux.conf
Latest Comments
Comment by ridikulusrat
Comment by mike.cloaked
I just found that gnu-efi-libs was updated to 3.0v-2, and re-running the gnu-efi build now works for the first time since I tried it in the past couple of days.
Comment by mike.cloaked
I saw that there was a reference to building refind in the report at https://bugs.archlinux.org/task/40277?project=1&openedfrom=-1+week but also I was puzzled by the output from the gcc -v command on my machine which was:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9-20140521/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.0 20140521 (prerelease) (GCC)
Are the references to "unknown" normal here? I have not done any attempts at building for some time until recently when trying to build refind-efi. I have tried various PKGBUILD files, including from this package page. All show build fails but changing the options gives different errors which I can't find any consistency with.
Comment by mike.cloaked
I guess the edk2 revision number is changing not infrequently. I just looked and it is currently at revision 15547 (in the PKGBUILD file is is 15322 at the moment). I don't know if it is worth simply trying again with the newer revision or if there is code somewhere in the source files that needs fixing?
Comment by ridikulusrat
@ALL: I switched to GNU-EFI build for now, till I figure out the Tianocore GenFw issue.
Comment by ridikulusrat
@ALL: I have bumped the pkgver. Btrfs, Iso9660 and Reiserfs drivers are not building with gcc 4.9 and have not been built. The error is "Unsupported section alignment" similar to error while building ovmf-svn (see latest comment by FredBezies at https://aur.archlinux.org/packages/ovmf-svn/ ). This is due to some issue between tianocore and gcc 4.9 which I am unable to understand. This error does not seem to affect main refind.efi, and ext4, ext2 and hfs drivers.
Comment by ridikulusrat
All files have been moved to /usr/share/refind/ in the pkg.
Comment by ridikulusrat
@klickverbot: Should build now.
Comment by klickverbot
I'm trying to build this on a fully up-to-date Arch x86_64 box, and get
…/refind-efi-tianocore-git/src/tianocore-udk-svn_build_x86_64/Build/Mde/RELEASE_GCC46/X64/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib/OUTPUT/UefiDevicePathLib.lib(UefiDevicePathLib.obj): In function `IsDevicePathValid':
UefiDevicePathLib.c:(.text.IsDevicePathValid+0x50): undefined reference to `_gPcd_FixedAtBuild_PcdMaximumDevicePathNodeCount'
Any workaround known for this?
Anonymous comment
Hi, the included patch fails to apply at the moment.