Something seems to be clearly wrong with gjs with bundled mozjs52, when I remove the symlink in /usr/lib64 running gjs from terminal throws again:

gjs: error while loading shared libraries: libmozjs-52.so: cannot open shared object file: No such file or directory

The libmozjs52 loading issue should be fixed in gjs-1.50.2-2.el7. That gets us a bit further, but gnome-weather still fails with:

Gjs-CRITICAL **: JS ERROR: SyntaxError: redeclaration of let copyright @ resource:///org/gnome/Weather/Application/js/app/window.js:221
JS_EvaluateScript() failed

To fix that, we'll need to either backport gjs related fixes to gnome-weather or rebase gnome-weather+libgweather to 3.26. Looking at the changes upstream between 3.20 (that's what we have in RHEL 7.4) and 3.26 (latest upstream), there's very little else beyond gjs fixes and translations updates. tpelka, mclasen, if you agree, can you help set up rebase bugs for these two please?

Ahh correction, libgweather was already rebased to 3.26. That just leaves gnome-weather to rebase.

I suspect that this isn't completely fixed. eg., on aarch64, I get:

  [test@hp-moonshot-02-c19 ~]$ rpm -q gjs
  gjs-1.50.2-2.el7.aarch64
  [test@hp-moonshot-02-c19 ~]$ gjs
  gjs: error while loading shared libraries: libmozjs-52.so: cannot open
    shared object file: No such file or directory
  [test@hp-moonshot-02-c19 ~]$

That leads to AX_CHECK_GIRS_GJS failing in the gnome-documents build on aarch64:
  https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14648040

-> ASSIGNED

as per tpelka's suggestion

On aarch64:

[test@hp-moonshot-02-c19 ~]$ ldd /usr/bin/gjs | grep mozjs
	libmozjs-52.so => not found
	libmozjs-52.so => /usr/lib64/gjs/libmozjs-52.so (0x0000ffff8f520000)
[test@hp-moonshot-02-c19 ~]$


On x86_64:

[rishi@kolache-rhel75 ~]$ ldd /usr/bin/gjs | grep mozjs
	libmozjs-52.so => /usr/lib64/gjs/libmozjs-52.so (0x00007ff0d85d5000)
[rishi@kolache-rhel75 ~]$

On aarch64:

[test@hp-moonshot-02-c19 ~]$ objdump -p /usr/bin/gjs | grep NEEDED | grep mozjs
  NEEDED               libmozjs-52.so
[test@hp-moonshot-02-c19 ~]$


On x86_64:

[rishi@kolache-rhel75 ~]$ objdump -p /usr/bin/gjs | grep NEEDED | grep mozjs
[rishi@kolache-rhel75 ~]$


It makes me wonder if --as-needed isn't working as expected on aarch64.

ldd -v /usr/bin/gjs-console has:

        /usr/bin/gjs-console:
                ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
                libstdc++.so.6 (CXXABI_1.3) => /lib64/libstdc++.so.6
                libc.so.6 (GLIBC_2.17) => /lib64/libc.so.6
                libmozjs-52.so (js) => /usr/lib64/gjs/libmozjs-52.so


objdump -T /usr/bin/gjs-console has:

0000000000000000      DF *UND*  0000000000000000  js          abort


Could it be that the "abort" symbol is pulling in libmozjs-52.so?

objdump -T /usr/lib64/gjs/libmozjs-52.so has:

000000000066dd44 g    DF .text  0000000000000014  js          abort


Question is, why is that getting picked up only in aarch64?

(In reply to Debarshi Ray from comment #11)
> objdump -T /usr/lib64/gjs/libmozjs-52.so has:
> 
> 000000000066dd44 g    DF .text  0000000000000014  js          abort

As far as I can figure out, it is:
  #define abort moz_abort
... done through one of mozjs-52's moz.build files.

(sorry about this continued rambling)

The aarch64 startup code does this:

        /* Let the libc call main and exit with its return code.  */
        bl      __libc_start_main

        /* should never get here....*/
        bl      abort

This means that every binary has a reference to the abort function.  libmozjs-52.so redefines abort and versions it with @js, so linking produces a reference to abort@js.  This pulls in libmozjs-52.so, but the build then strips the rpath of the directory which contains it.  So the aarch64 binary does not load.

On x86-64, the startup code does not call abort, so there is no reference to the symbol, and things happen to work.

The bug is the redefinition of abort.  There is a comment:

// Define abort() here, so that it is used instead of the system abort(). This
// lets us control the behavior when aborting, in order to get better results
// on *NIX platforms. See mozalloc_abort for details.

mozalloc_abort is uncommented.

Thanks for digging into it, Florian!

I put together a scratch SRPM with this patch to see if that stops the "js" abort from getting exported:
diff -urNp firefox-52.4.0esr.orig/memory/mozalloc/mozalloc_abort.h firefox-52.4.0esr/memory/mozalloc/mozalloc_abort.h
--- firefox-52.4.0esr.orig/memory/mozalloc/mozalloc_abort.h	2017-12-04 16:29:43.955029594 +0100
+++ firefox-52.4.0esr/memory/mozalloc/mozalloc_abort.h	2017-12-04 16:32:50.855179785 +0100
@@ -18,7 +18,6 @@
  * Note: MOZ_NORETURN seems to break crash stacks on ARM, so we don't
  * use that annotation there.
  */
-MFBT_API
 #if !defined(__arm__)
   MOZ_NORETURN
 #endif

The Brew build is here:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14674175

(In reply to Debarshi Ray from comment #14)
> diff -urNp firefox-52.4.0esr.orig/memory/mozalloc/mozalloc_abort.h
> firefox-52.4.0esr/memory/mozalloc/mozalloc_abort.h
> --- firefox-52.4.0esr.orig/memory/mozalloc/mozalloc_abort.h	2017-12-04
> 16:29:43.955029594 +0100
> +++ firefox-52.4.0esr/memory/mozalloc/mozalloc_abort.h	2017-12-04
> 16:32:50.855179785 +0100
> @@ -18,7 +18,6 @@
>   * Note: MOZ_NORETURN seems to break crash stacks on ARM, so we don't
>   * use that annotation there.
>   */
> -MFBT_API
>  #if !defined(__arm__)
>    MOZ_NORETURN
>  #endif

Oops, no. That's the wrong file. That's the signature for mozalloc_abort, not abort. Let's try to '#if 0' the whole abort redefinition.

The other option is __attribute__((visibility("hidden"))), but let's try the bigger hammer first. I am not sure what these DEFINE['abort'] lines in the moz.build files are about, so I want to be really really sure that this particular definition has been nuked.

(In reply to Debarshi Ray from comment #15)
> Oops, no. That's the wrong file. That's the signature for mozalloc_abort,
> not abort. Let's try to '#if 0' the whole abort redefinition.

This seems OK so far. I say "seems" because I didn't exhaustively test all architectures. Only x86_64 and aarch64, and I saw from my earlier build failure (comment 6) that s390(x) didn't have this problem.

I have submitted a build for gjs-1.50.2-3.el7 to unblock the builds relying on this fix:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14689747

We can resort to __attribute__((visibility("hidden"))) if the "#if 0" hammer turns out / is considered to be too extreme.

(In reply to Debarshi Ray from comment #16)
> We can resort to __attribute__((visibility("hidden"))) if the "#if 0" hammer
> turns out / is considered to be too extreme.
Hammer may be a good idea, anyway.  Florian mentioned on IRC that libc had to remove fflush(stderr) from its abort() implementation because it caused problems (don't know the details), and the mozjs implementation of abort() does fflush(stderr).

Created attachment 1378553 [details]
objdump aarch64

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0770