Bug 226985 - lang/fasm: fails to link with lld as the system linker
Summary: lang/fasm: fails to link with lld as the system linker
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
Depends on:
Blocks: 214864
  Show dependency treegraph
Reported: 2018-03-27 15:43 UTC by Ed Maste
Modified: 2018-03-29 10:48 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (graudeejs)


Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2018-03-27 15:43:39 UTC
I'm working on switching to LLVM's lld linker as the FreeBSD system linker (/usr/bin/ld)[1], and the port in this PR is reported as a new failure in the exp-run, PR 214864.

An excerpt from the build log[2]:
cd /wrkdirs/usr/ports/lang/fasm/work/fasm && cc -O2 -pipe  -m32 -L/usr/lib32 -B/usr/lib32 -fstack-protector -fno-strict-aliasing fasm.o -o fasm
/usr/bin/ld: error: fasm.o: unaligned data

lld is more strict about invalid data in ELF objects.

FreeBSD 11 and later have lld available as /usr/bin/ld.lld, so one simple option for testing is to just symlink /usr/bin/ld to ld.lld (and restore it to ld.bfd).

A port Makefile knob, LLD_UNSAFE=yes, exists to indicate that a port does not work with lld, and requires either /usr/bin/ld.bfd or binutils from ports. This should work for the common case of ports written in C using GNU autoconf; it may have no effect on other ports.

[1] https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068985.html
[2] http://package18.nyi.freebsd.org/data/headamd64PR214864-default/2018-03-21_17h43m11s/logs/errors/invada-studio-plugins-lv2-1.2.0.log
Comment 2 Niclas Zeising freebsd_committer 2018-03-27 17:56:08 UTC
It seems like fasm is distributed as an object file for 32bit elf, and only linked at build time.  It is possible to generate a new .o from the asm sources included, but that most likely requires fasm already being installed.
I haven't investigated if the .o outputted on a FreeBSD system makes lld happier, but for now, I believe this needs to be marked with LLD_UNSAFE.
Comment 3 Niclas Zeising freebsd_committer 2018-03-27 18:09:01 UTC
I'm also unsure if fasm outputs object files that lld can understand.  If i build fasm locallu using bfd, and then use that fasm to create a .o to link with lld, the linking fails.  I'm not sure if this is an issue with fasm or lld.
Comment 4 Ed Maste freebsd_committer 2018-03-27 20:57:01 UTC
Via tobik@ in ports r465725, BINARY_ALIAS=ld=ld.bfd may be an effective workaround if LLD_UNSAFE does not work.

If fasm generates broken object files as output we may need to mark dependent ports as LLD_UNSAFE / BINARY_ALIAS.
Comment 5 Ed Maste freebsd_committer 2018-03-28 01:06:37 UTC
Followup, if BINARY_ALIAS is used it should be in addition to LLD_UNSAFE, so that architectures without a /usr/bin/ld.bfd (arm64) work. If possible LLD_UNSAFE=yes should imply BINARY_ALIAS=ld=ld.bfd, under discussion on the ports mailing list.
Comment 6 Ed Maste freebsd_committer 2018-03-29 02:49:48 UTC
(In reply to Niclas Zeising from comment #3)
This likely means fasm is emitting broken objects, and if so dependent packages will just need to set LLD_UNSAFE as well. Our choice in that case is to fix fasm or accept the LLD_UNSAFEs.

That said, it appears only textproc/asm-xml is dependent on fasm.
Comment 7 commit-hook freebsd_committer 2018-03-29 10:48:51 UTC
A commit references this bug:

Author: krion
Date: Thu Mar 29 10:48:14 UTC 2018
New revision: 465882
URL: https://svnweb.freebsd.org/changeset/ports/465882

  Update to 1.73.02
  Fix linking with ld.lld

  PR:		226985
  Submitted by:	emaste
  Approved by:	portmgr (LLD_UNSAFE blanket)