egcc -static was broken on most arches; the static binary wrongly
requested ld.so(1), but /usr/lib/rcrt0.o wants to do the relocation
without ld.so(1). The fix is to drop ld.so,
%{!static:-dynamic-linker /usr/libexec/ld.so}
Remove "%{!dynamic-linker:...}" because gcc -dynamic-linker is not an
option. Correct "%{!r*:...}" to "%{!r:...}" because gcc -r doesn't
take an option argument. Use "%{!nostdlib:-L/usr/lib}" on lld
arches, like base-gcc.
Edit the powerpc LINK_SPEC in rs6000/openbsd.h to be like the others.
Add "%{!nostdlib:-L/usr/lib}" so I can try lld on powerpc. For now,
don't edit the powerpc64 LINK_SPEC.
ok pascal@ (maintainer)
in seabios (sysutils/firmware/vmm).
/usr/bin/ld.bfd: scripts/kconfig/zconf.tab.o: invalid relocation type 42
/usr/bin/ld.bfd: BFD 2.17 assertion fail /usr/src/gnu/usr.bin/binutils-2.17/bfd/elf64-x86-64.c:259
...
/usr/bin/ld.bfd: scripts/kconfig/conf.o(.text+0x3b3): unresolvable L<8B>^]^A^Z^E relocation against symbol `__sF'
etc.
- remove no-longer needed g77 and java subpackages.
- remove an outdated patch comment
- move HOMEPAGE from http -> https
- bump all subpackages due to HOMEPAGE change
ok pascal@ (MAINTAINER)
an error if the last component of the path does not exist.
This is a bug in libgnat. The System.File_IO.Open function calls
full_name -> __gnat_full_name -> realpath on files that have not
yet been created. The Linux realpath was considered lacking, so a
different approach is used there. We now remove OpenBSD from the
#ifdef of operating systems supporting realpath and follow the Linux
code path.
New Ada bootstraps are required.
ok sthen@ pascal@
the command line. This resulted in shared libraries with an .interp section,
confusing plist generation tools.
Discussed with espie@, guenther@ and kettenis@; initial patch from espie@.
ok espie@
"ld: error: XX: has non-ABS relocation R_386_GOTOFF against symbol 'XX'"
is seen on other ports (telephony/asterisk, math/py-scipy) when built
with gcc 8 and znotext does not help there, so is unlikely to help here
either.
* switch gcc4 module to gcc/8
* register the gcc/8 subpackages as updates for their gcc/4.9 counterparts
* sync the gcc version in devel/llvm
* add a quirk entry that gcj is obsolete
* unhook 4.9 from the build
Preparatory work by many.
ok sthen@