this actually worked better than no threads, and threads are turned on
in other packaging distributions. Have been using this for a while
and it looks like the more tested config upstream.
Reviewed-by: bapt (back in June)
After a discussion on the mailing list on moving manpages to
${PREFIX}/share/man for consistency with base where it is
installed in usr/share/man, it appeared the same should happen
to GNU info files which were installed under share in base and
not in ports.
Now texinfo is not in base on any of the supported version of FreeBSD
it is possible to proceed to this move and it is easier to do than
the manpage change.
Other benefit than consistency are less patching: all build tools but
cmake are expecting info files to be under share/info and cmake (patched here)
was having an exception for BSD so the patch makes FreeBSD case less
specific for them
Bump revision of all impacted ports
PR: 232907
exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D17816
- Use BUREMOVE to strip binutils tools not installed by the base/binutils
package.
- Update BUREMOVE logic in devel/binutils to cope with the base package
which installs tools without a BUTARGET- prefix.
- Use MANPREFIX for BUREMOVE to handle the PREFIX=/usr case used by
base/binutils.
- Remove binutils headers and libraries explicitly from the staging area
for base/binutils.
- Add missing plist entries for binutils binaries installed under a
BUTARGET subdirectory.
- Drop plist entries from devel/binutils that are now properly removed.
Previously the binaries for Windows tools like dlltool were removed
from the staging area but the manpages were still left in the package.
- Bump PORTREVISION.
This is a recommit of r476186 but with the update to the pkg-plist of
devel/binutils and PORTREVISION bump.
PR: 230278
Reviewed by: antoine
Differential Revision: https://reviews.freebsd.org/D16582
- Use BUREMOVE to strip binutils tools not installed by the base/binutils
package.
- Update BUREMOVE logic in devel/binutils to cope with the base package
which installs tools without a BUTARGET- prefix.
- Use MANPREFIX for BUREMOVE to handle the PREFIX=/usr case used by
base/binutils.
- Remove binutils headers and libraries explicitly from the staging area
for base/binutils.
- Add missing plist entries for binutils binaries installed under a
BUTARGET subdirectory.
Approved by: bapt (implicit for base/*)
Differential Revision: https://reviews.freebsd.org/D16464
- devel/binutils: Remove i386 a.out linker scripts when building
i386-binutils or a base/binutils that targets i386.
- devel/powerpc64-gcc: Remove float.h on i386 since it conflicts
with sys/x86/include/float.h.
- devel/i386-{binutils,gcc,xtoolchain}: New ports.
Reviewed by: bapt (previous version)
Differential Revision: https://reviews.freebsd.org/D16228
This is a follow up to r461057 and fixes base/binutils and base/gcc in my
testing.
PR: 224217
Submitted by: nwhitehorn (partially, I made additional changes)
Reviewed by: bapt
This is required to build Arm64 packages using QEMU. Poudriere copies
the native ld from the host into the jail and uses that during the build.
This only works if ld is static.
Reported by: krion
Approved by: bapt
Clang 3.9.0 changes how weak extern is handled. They now use the got to
handle them. This is a problem as ld.bfd doesn't fill out any default value
in the got so pointers become NULL. This caused the kernel to fail to boot
as we use this in linker sets.
This fixes the issue by setting a default value in the got. The kernel
still loads data through it, but because we always load it at a fixed
virtual address the address it finds is valid.
Approved by: bapt
Differential Revision: https://reviews.freebsd.org/D8622
Some binaries were added by the fact all targets have been enabled. This causes
conflicts with other tools. Given those binaries are already provided by the
mingw32-binutils there is no need for this one to provide them as well
Add a cross buildable binutils package.
The new category is not linked to the regular ports tree to avoid make install,
poudriere and others to catch it automagically
instead of ending with a very complex file removal in the stage, prefer to use
specific plist per arch.
For now only sparc64 tested and added. This version of binutils is stipped down
only the components that are not supported by elftoolchain
Remove aarch64 patches which are now upstream
Disable new x86 relocation to avoid incompatibilities with the old base binutils
Activate all targets on the default binutils (requested by royger@)
Add a RELRO option (default off) to be able to define the default behaviour of
ld(1) on passing or not -z relro
Farnsworth: "Good news, everyone!" The latest revisions of LLVM trunk
not only have a version of LLD that creates usable binaries for x86-64
and aarch64, it also does a better job at creating Position Independent
Executables than the GNU linker.
Because PIE is going to become pretty important for some of the upcoming
projects (emulation on other OSes), I'd like to go ahead and switch the
cloudabi-toolchain port over to the latest snapshot of LLVM. My goal is
to revert back to a stable version (3.9) when available.
Switching to LLD involves patching up the Binutils ports to no longer
install the GNU linker (and remove the linker scripts that it uses). We
can then simply add a couple of extra symlinks to cloudabi-toolchain to
point to the LLD binary.
At the same time, let's switch over to using the ELF toolchain tools on
FreeBSD 11. That way we can even drop the dependency on Binutils on
those systems.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D5874
For CloudABI I slowly want to switch away from certain tools provided by
Binutils. For example, it would be really nice if we could switch from
GNU ld to LLD some time in the future. LLD is not ready yet. Some bug
fixes didn't manage to land into 3.8 and it doesn't support aarch64
properly. There are already some tools that we can use, such as nm,
objdump, size, ar and ranlib.
Introduce a BUREMOVE variable that can be set in Binutils slave ports to
remove specific utilities that are installed by default. There doesn't
seem to be any other elegant way to solve this. Set a bunch of utilities
by default and then extend cloudabi-clang to set up symlinks to the LLVM
versions of the tools.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D5684
