1382364 - Solaris and BSD configure fails with: Could not find gold

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Petr Sumbera]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

Solaris and BSD configure process ends with:

 0:24.00 checking for ld...
 0:24.01 DEBUG: Executing: `/usr/bin/gcc -print-prog-name=ld.gold`
 0:24.01 ERROR: Could not find gold

"--enable-release" desn't seem to help on Solaris either:

 0:17.01 checking for ld...
 0:17.01 DEBUG: Executing: `/usr/bin/gcc -std=gnu99 -Wl,--version`
 0:17.01 DEBUG: The command returned non-zero exit status 1.
 0:17.01 DEBUG: Its error output was:
 0:17.01 DEBUG: | collect2 version 5.4.0
 0:17.01 DEBUG: | /usr/bin/ld -Y P,/lib/amd64:/usr/lib/amd64 -Qy /usr/lib/amd64/crt1.o /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0/crtp.o /usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o /usr/lib/amd64/values-xpg6.o /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0/crtbegin.o -L/usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0 -L/usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0/../../.. --version -lgcc -z ignore -lgcc_s -z record -lc -lgcc -z ignore -lgcc_s -z record /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0/crtend.o /usr/lib/amd64/crtn.o
 0:17.01 DEBUG: | ld: Software Generation Utilities - Solaris Link Editors: 5.12-1.3113
 0:17.01 DEBUG: | Undefined                     first referenced
 0:17.01 DEBUG: |  symbol                           in file
 0:17.01 DEBUG: | main                                /usr/lib/amd64/crt1.o
 0:17.01 DEBUG: | ld: fatal: symbol referencing errors
 0:17.01 DEBUG: | collect2: error: ld returned 1 exit status
 0:17.01 ERROR: Command `/usr/bin/gcc -std=gnu99 -Wl,--version` failed with exit status 1.

Comment 1

[Sylvestre Ledru [:Sylvestre]]

Thanks, I will update the parsing to manage that!

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Attachment: Bug 1382364 - Do not fail the build when the linker is unknown.

Instead, tag it as 'other'

Review commit: https://reviewboard.mozilla.org/r/159722/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/159722/

Comment 3

[Sylvestre Ledru [:Sylvestre]]

I could not test the patch...

Comment 4

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8888682 [details]
Bug 1382364 - Do not fail the build when the linker is unknown.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/159722/diff/1-2/

Comment 5

[Jan Beich]

Comment on attachment 8888682 [details]
Bug 1382364 - Do not fail the build when the linker is unknown.

Thanks. This fixes "Could not find any linker" I get when using --enable-release (downstream) with LLD (soon to be default).

$ echo 'int main() {}' | c++ -Wl,-v -xc - -o /dev/null
LLD 5.0.0 (FreeBSD 308421) (compatible with GNU linkers)

Comment 6

[Mike Hommey [:glandium]]

Comment on attachment 8888682 [details]
Bug 1382364 - Do not fail the build when the linker is unknown.

https://reviewboard.mozilla.org/r/159722/#review166088

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e7613d8dfb7c
Do not fail the build when the linker is unknown. r=glandium

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e7613d8dfb7c

Comment 9

[Petr Sumbera]

It's still failing on Solaris:

 0:16.57 checking for ld...
 0:16.57 DEBUG: Executing: `/usr/bin/gcc -print-prog-name=ld.gold`
 0:16.57 DEBUG: Executing: `/usr/bin/gcc -std=gnu99 -Wl,--version`
 0:16.57 DEBUG: The command returned non-zero exit status 1.
 0:16.57 DEBUG: Its error output was:
 0:16.57 DEBUG: | collect2 version 5.4.0
 0:16.57 DEBUG: | /usr/bin/ld -Y P,/lib/amd64:/usr/lib/amd64 -Qy /usr/lib/amd64/crt1.o /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0/crtp.o /usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o /usr/lib/amd64/values-xpg6.o /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0/crtbegin.o -L/usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0 -L/usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0/../../.. --version -lgcc -z ignore -lgcc_s -z record -lc -lgcc -z ignore -lgcc_s -z record /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.12/5.4.0/crtend.o /usr/lib/amd64/crtn.o
 0:16.57 DEBUG: | ld: Software Generation Utilities - Solaris Link Editors: 5.12-1.3113
 0:16.57 DEBUG: | Undefined                     first referenced
 0:16.57 DEBUG: |  symbol                           in file
 0:16.57 DEBUG: | main                                /usr/lib/amd64/crt1.o
 0:16.57 DEBUG: | ld: fatal: symbol referencing errors
 0:16.57 DEBUG: | collect2: error: ld returned 1 exit status
 0:16.57 ERROR: Command `/usr/bin/gcc -std=gnu99 -Wl,--version` failed with exit status 1.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Petr, what is the equivalent way to get Solaris ld to be happy with "/usr/bin/gcc -std=gnu99 -Wl,--version" ?

Comment 11

[Petr Sumbera]

The only working solution now seems to be:

$ echo 'int main() {}' > test.c &&  gcc -Wl,-V -xc test.c -o /dev/null
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.2552

which seems to work even on Linux (and maybe capital V can be used also for BSDs?):

$ echo 'int main() {}' > test.c &&  gcc -Wl,-V -xc test.c -o /dev/null
GNU ld (GNU Binutils for Ubuntu) 2.24
  Supported emulations:
   elf_x86_64
   elf32_x86_64
   elf_i386
   i386linux
   elf_l1om
   elf_k1om
   i386pep
   i386pe

I would love to offer something similar to what was suggested for BSD:

$ echo 'int main() {}' | c++ -Wl,-V -xc - -o /dev/null
ld: Software Generation Utilities - Solaris Link Editors: 5.12-1.3113

This works for development version of Solaris and for old Solris 10. But there is bug in Solaris 11 now:

$ echo 'int main() {}' | c++ -Wl,-V -xc - -o /dev/null
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.2552
ld: fatal: bad section layout: .SUNW_ldynsym must precede and be adjacent to .dynsym
collect2: error: ld returned 1 exit status

This is tracked internally (23064245) and it's related to reading the input file from stdin.

As for "/usr/bin/gcc -std=gnu99 -Wl,--version". I got following explanation from out linker guru:

> When you call the compilers, they provided "additional" files which are then passed
> to ld.  Seems that gld takes these, and the --version, but the --version causes gld
> to terminate, and any other input files are simply ignored.
> 
> However, ld transforms the --version to -V, and our processing has always been to
> print the version, and keep processing.

Comment 12

[Mike Hommey [:glandium]]

Maybe I'm misreading the explanation or something is missing, but it seems `gcc -Wl,-V` should work? (without an input file)

Comment 13

[Petr Sumbera]

It doesn't:

gcc -Wl,-V
ld: Software Generation Utilities - Solaris Link Editors: 5.12-1.3113
Undefined                       first referenced
 symbol                             in file
main                                /usr/lib/amd64/crt1.o
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status

Comment 14

[Petr Sumbera]

For record I got few other internal suggestions:

> Here's another way to work around it:
> 
>      % echo 'int main() {}' | c++ -Wl,-V -z noldynsym -xc - -o /dev/null
>      ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.2552
> 
> -znoldynzym disables the generation of the .SUNW_ldynsym feature, which 
> isn't
> important to your test, and which causes ld to not go down the code path
> that would otherwise hit:
> 
>      23064245 linker fails unexpectedly with .SUNW_ldynsym error
> 
> If you do that, add a comment saying why, and that the need for it is
> temporary, or future generations will be scratching their heads when
> they see it, and through cut/paste, -z noldynsym will spread in GNU
> Makefiles, and cause GNU software to create worse objects for us than
> they would otherwise.

And:

> If you want to know which linker is used by GCC, you can ask it with:
> 
> $ gcc -print-prog-name=ld
> 
> That will give you the path to the linker that it runs.
> 
> If you want to know more about that linker, you can ask with '-V', so
> 
> $ `gcc -print-prog-name=ld` -V
> 
> will give you version information from the linker that GCC is using.
> 
> That being said, any tests should be for the specific feature, option, 
> or behaviour that is desired, not the version of the linker that may or 
> may not support it.

Comment 15

[Petr Sumbera]

Ops. There is one more issue:

"Something I noticed during this conversation is that the output
from ld -V goes to stderr rather than stdout. That's not very friendly,
as this is user requested output, not an error, and I note that the
GNU linkers send their version text to stdout."

$ echo 'int main() {}' > test.c &&  gcc -Wl,-V -xc test.c -o /dev/null 2>/dev/null  | grep Solaris
$ echo 'int main() {}' > test.c &&  gcc -Wl,-V -xc test.c -o /dev/null 2>&1  | grep Solaris
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.2552

Comment 16

[Petr Sumbera]

Maybe I should handle Solaris problem with following change? I guess I will need to create new bug.

diff -r 33b7b8e81b4b build/moz.configure/toolchain.configure
--- a/build/moz.configure/toolchain.configure   Mon Sep 25 10:41:00 2017 -0700
+++ b/build/moz.configure/toolchain.configure   Wed Sep 27 15:16:22 2017 +0000
@@ -1139,7 +1139,7 @@

 @depends(target)
 def build_not_win_mac(target):
-    if target.kernel not in ('Darwin', 'WINNT'):
+    if target.kernel not in ('Darwin', 'WINNT', 'SunOS'):
         return True

Comment 17

[Sylvestre Ledru [:Sylvestre]]

Sorry, I dropped the ball on that because I could not test the patch.
Please open a new bug. Maybe your patch will be enough.