Bug 218808 - www/firefox: usr/bin/ld: error: unknown argument: --warn-unresolved-symbols (WITH_LLD_IS_LD)
Summary: www/firefox: usr/bin/ld: error: unknown argument: --warn-unresolved-symbols (...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-gecko (Nobody)
URL:
Keywords:
Depends on:
Blocks: 214864
  Show dependency treegraph
 
Reported: 2017-04-22 07:25 UTC by O. Hartmann
Modified: 2017-09-29 12:51 UTC (History)
2 users (show)

See Also:
jbeich: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2017-04-22 07:25:51 UTC
In poudriere, I receive upon building firefox this error:

/usr/bin/ld: error: unknown argument: --warn-unresolved-symbols
c++: error: linker command failed with exit code 1 (use -v to see invocation)

Host and poudriere's jail are most recent CURRENT (reeBSD 12.0-CURRENT #12 r317278: Sat Apr 22 09:03:03 CEST 2017 amd64), on both, host and jail, I've enabled option

WITH_LLD_IS_LD=yes

I'm wondering about the error as it indicates a missing flag?
Comment 1 Jan Beich freebsd_committer freebsd_triage 2017-04-22 08:06:04 UTC
(In reply to O. Hartmann from comment #0)
> I'm wondering about the error as it indicates a missing flag?

Probably. Firefox uses --ignore-unresolved-symbol (ld.bfd 2.26+ or ld.gold 2.28+) or --warn-unresolved-symbol to allow environ(7) in shared libraries together with --no-undefined. This is a workaround for BSD libc, GNU libc is unaffected.

$ cat a.c
#include <stdio.h>

void foo() {
  extern char **environ;
  for(int i = 0; environ[i] != NULL; i++)
    printf("%s\n", environ[i]);
}

$ cc -fPIC -shared -Wl,-z,defs -o a.so a.c -B/usr/local/bin -Wl,--ignore-unresolved-symbol,environ
$ cc -fPIC -shared -Wl,-z,defs -o a.so a.c -Wl,--warn-unresolved-symbols
/tmp/a-52cbc1.o: In function `foo':
a.c:(.text+0x12): warning: undefined reference to `environ'
a.c:(.text+0x32): warning: undefined reference to `environ'

http://searchfox.org/mozilla-central/rev/6e1c138a06a8/old-configure.in#662
Comment 2 Jan Beich freebsd_committer freebsd_triage 2017-04-22 08:18:11 UTC
(In reply to Jan Beich from comment #1)
> --ignore-unresolved-symbol (ld.bfd 2.26+

Oops, since ld.bfd 2.24 but the flag came from NetBSD.

https://mail-index.netbsd.org/source-changes/2008/04/03/msg004439.html
Comment 3 O. Hartmann 2017-04-26 11:04:20 UTC
(In reply to Jan Beich from comment #2)

Is there a solution? www/firefox doesn't build on 12-CURRENT (recent, as of today) anymore if WITH_LLD_IS_LD is enabled.

poudriere also fails on the very same error.
Comment 4 O. Hartmann 2017-05-20 08:14:23 UTC
The recent update of www/firefox (at revision 441291) doesn't fix the reported problem, it still exists on traditional "make"-driven builds as well as in poudriere!
Comment 5 O. Hartmann 2017-06-18 09:24:57 UTC
The problem still persists in ports tree revision r443820 and prvents me from compiling www/firefox, which is now crashing rapidly on recent CURRENT (i.e. At revision 320065, amd64, with WITH_LLD_IS_LD=yes is set and the INO64 issue never resolved due to compilation problems).

I consider this a serious issue since there are plans to make WITH_LLD_IS_LD the default on AMD64 platforms.

Also, I stepped into another issue regarding  devel/glib20 and I'd like to refer to Bug 220103 which seems to be related somehow having Jan Beichs comment (Comment 1) in mind.
Comment 6 Jan Beich freebsd_committer freebsd_triage 2017-07-22 18:03:21 UTC
lld 5.0 per base r321369 does support --warn-unresolved-symbols, so comment 1 shows the following:

/usr/bin/ld.lld: warning: undefined symbol: environ
>>> referenced by a.c
>>>               /tmp/a-e9e734.o:(foo)

/usr/bin/ld.lld: warning: undefined symbol: environ
>>> referenced by a.c
>>>               /tmp/a-e9e734.o:(foo)

Can you try building www/firefox on -CURRENT again?
Comment 7 O. Hartmann 2017-07-27 04:17:00 UTC
(In reply to Jan Beich from comment #6)
I "solved" those problems for now by not usinf LLD as LD for the time being it is still harmful.

Thanks.
Comment 8 O. Hartmann 2017-07-28 06:51:03 UTC
I'll keep this bug open just in case someone is searching for fallout of option WITH_LLD_IS_LS=yes.

The problem seems to disappear when going the "GNU ld" path ...
Comment 9 commit-hook freebsd_committer freebsd_triage 2017-09-28 19:32:21 UTC
A commit references this bug:

Author: jbeich
Date: Thu Sep 28 19:32:05 UTC 2017
New revision: 450860
URL: https://svnweb.freebsd.org/changeset/ports/450860

Log:
  gecko: unbreak on 11.1 aarch64

  /usr/bin/ld: error: unknown argument: --warn-unresolved-symbols

  PR:		218808
  Reported by:	O. Hartmann, pkg-fallout (for /head before lld 5.0 update)

Changes:
  head/Mk/bsd.gecko.mk
Comment 10 commit-hook freebsd_committer freebsd_triage 2017-09-29 12:51:53 UTC
A commit references this bug:

Author: jbeich
Date: Fri Sep 29 12:51:15 UTC 2017
New revision: 450890
URL: https://svnweb.freebsd.org/changeset/ports/450890

Log:
  gecko: unbreak on 12.0 (lld by default)

  /usr/bin/ld: error: ../../js/src/jsarray.o: string table non-null terminated

  PR:		218808

Changes:
  head/Mk/bsd.gecko.mk