There is a problem with libreoffice-fresh and libreoffice-still which appears to be caused by the last update to boost and boost-libs which are now at version 1.76.0-1.3

~]$ libreoffice
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
/usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: libboost_locale.so.1.75.0: cannot open shared object file: No such file or directory

Attached to Project: Archlinux32
Opened by Raphael Scholer - 11.11.2018
Last edited by Erich Eckner - 14.11.2018
 FS#56  - libreoffice-fresh 6.1.3-1.0 in [extra] is not build against packages in it

libreoffice-fresh seems not to be build against packages in [extra], but rather against packages in [*testing].

Running libreoffice produces the following error message:

/usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: liborcus-0.14.so.0: cannot open shared object file: No such file or directory

extra/liborcus is 0.13.4-3.1
testing/liborcus is 0.14.1-1.0
Closed by Erich Eckner
14.11.2018 18:05
Reason for closing: Fixed

  Comments (1)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 12.11.2018 10:37

I moved liborcus and libixion from testing to extra - now it should work.

Google Cache

-- Installing: /build/libproxy/pkg/libproxy/usr/include/proxy.h
-- Installing: /build/libproxy/pkg/libproxy/usr/bin/proxy
mv: cannot stat '/build/libproxy/pkg/libproxy/usr/lib/libproxy/*/modules/pacrunner_webkit.so': No such file or directory
==> ERROR: A failure occurred in package_libproxy().
    Aborting...

libhandy0: /usr/share/vala/vapi/libhandy-0.0.deps exists in filesystem (owned by libhandy)
libhandy0: /usr/share/vala/vapi/libhandy-0.0.vapi exists in filesystem (owned by libhandy)

Attached to Project: Archlinux32
Opened by Andreas Baumann - 15.11.2018
Last edited by Andreas Baumann - 31.01.2019
 FS#57  - libc fails on AMD-K6

pacstrap /test base
LD_LIBRARY_PATH=/test/usr/lib gdb –args /test/bin/bash results in:

Program terminated with signal SIGILL, Illegal instruction.
#0 0xb7619991 in strcmp () from /test/usr/lib/libc.so.6
(gdb) bt
#0 0xb7619991 in strcmp () from /test/usr/lib/libc.so.6
#1 0xb75bd41f in setlocale () from /test/usr/lib/libc.so.6
#2 0x0076b7f2 in ?? ()
#3 0x0053acf6 in ?? ()
#4 0xb75b3a31 in __libc_start_main () from /test/usr/lib/libc.so.6
#5 0x0053e561 in ?? ()

So, getting the exact failing opcode is hard.

2.28-5.0 was ok,
2.28-5.2 is not.

So it’s something we changed or something changed on one of the i486 build slaves.

Happens only on the AMD-K6, all other machines with CPUs with limited special instruction
sets (Pentium-S, AMD Geode) are working fine.
Closed by Andreas Baumann
31.01.2019 13:50
Reason for closing: Fixed
Additional comments about closing:

works with glibc-2.28-5.5-i486

  Comments (11)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 10.01.2019 08:27

happens on a Pentium-S now too.
Pentium-II is still fine, so is AMD Geode..
Admin
Andreas Baumann commented on 24.01.2019 10:10

Finally got around to tackle this one
installing a minimal chroot with:

pacstrap /test bash

Then debugging the chroot call:

gdb –args /usr/bin/chroot /test

yields:

Dump of assembler code for function memcpy:

 0xb7ff22f0 <+0>:     test   %al,%al
 0xb7ff22f2 <+2>:     jne    0xb7ff22e8
 0xb7ff22f4 <+4>:     xor    %eax,%eax
 0xb7ff22f6 <+6>:     ret    
 0xb7ff22f7 <+7>:     mov    $0x1,%eax
 0xb7ff22fc <+12>:    mov    $0xffffffff,%ecx

> 0xb7ff2301 <+17>: cmovb %ecx,%eax

 0xb7ff2304 <+20>:    ret    

End of assembler dump.

So, we got cmov creeping in.

/proc/cpuinfo tells us that neither early Pentiums nor AMD K6 had a CMOV opcode.

Now the trick question is, why is it creeping into the C library?

Is the C library compiled with the wrong flags?
Is the gcc assuming that every CPU has a CMOV instruction? Are flags wrong there
or is CMOV suddenly the default?
Admin
Andreas Baumann commented on 24.01.2019 10:39

Checking in glibc: this is the offending opcode

i686/strcmp.S: cmovbl %ecx, %eax

L(neq): movl $1, %eax

      movl    $-1, %ecx
      cmovbl  %ecx, %eax

Now the question is, why does glibc think it’s ok to use i686 optimizations
when compiling with -march-i486.
Admin
Andreas Baumann commented on 24.01.2019 11:09

Not found an obvious reason, retriggering rebuild on known-good (hopefully) i486 build slave.
Admin
Andreas Baumann commented on 24.01.2019 20:44

config.log shows me i686 as build host. This is guessed with config.guess.
Manually executing config.guess on the build machine results in i486-pc-linux-gnu.
setarch i486 ./config.guess results in i686-pc-linux-gnu.
setarch i486 uname -m results in i686.

This breaks every build on i486!

/usr/bin/setarch is owned by util-linux 2.33.1-2.3 and is is completly broken!

And of course, it’s used in setarch “${arch}” mkarchroot in staging-i486-build.

So the consequenses are:
- devtools32 must NOT use setarch anywhere in the *i486* files
- the whole i486 toolchain and all packages have to be rebuilt (basically from the stage of last bootstrapping, every package above could contain bad opcodes!).

The irony is, that building just with makepkg on a emulated i486 virtual machine works
fine, using the devtools breaks things..
Admin
Andreas Baumann commented on 24.01.2019 21:11

Actually, thinking about it: I should try to patch setarch in coreutils for i486.
So we don’t have to fork devtools32 too much from upstream..

binutils and gcc have an explicit host and build flags, so they should be fine.
Maybe rebuilding just glibc with a fixed setarch is sufficient.
Admin
Andreas Baumann commented on 24.01.2019 21:15

If we are unlucky, utsname information in setarch.c is wrong and it’s not
a coreutils problem..
Admin
Andreas Baumann commented on 25.01.2019 08:05

The man page of setarch documents the bug:

The execution domains currently only affects the output of uname -m. For example, on an AMD64 sys-

     tem, running setarch i386 program will cause program to see i686 instead of x86_64 as  the  machine
     type.  It also allows to set various personality options.  The default program is /bin/sh.

So, we are not allowed to fix this, as other programs may rely on the bug.

So, fixing the devtools32 it is… Admin
Andreas Baumann commented on 25.01.2019 09:15

setarch bug reported here:

https://github.com/karelzak/util-linux/issues/707

and here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506632

uname -p reports unknown, this explains why config.guess relies
on uname -m to guess the CPU.

We came to those possible solutions:
- fix setarch.c (rather let it report something different than what the kernel is providing)
- add flags to devtools32 to switch off setarch usage (means, we can no longer build i486 on x86_64 slaves)
- add –build=i486-pc-linux-gnu in every configure call necessary
- go with the CLFS uname hack
- hack setarch of the host machine
Admin
Andreas Baumann commented on 27.01.2019 16:05

The CLFS uname hack solution.

http://trac.clfs.org/ticket/146

http://clfs.org/view/svn/ppc/chroot/before-chroot.html Admin
Andreas Baumann commented on 27.01.2019 18:04

wget http://clfs.org/files/extras/uname_hack-20080713.tar.bz2

PKGBUILD of linux:
_srcver=4.20.4-arch1
pkgver=${_srcver//-/.}
pkgrel=1.0
make modules_prepare

make -C /root/linux/src/archlinux-linux SUBDIRS=$PWD uname_hack_fake_machine=i486

insmod uname_hack.ko

setarch i486 uname -m
i686
setarch i486 ./config.guess
i686-pc-linux-gnu

Ok, the uname hack no longer works, or setarch doesn’t rely on this module information.

Google Cache

Trying to start udisks2 daemon (systemctl start udisks2.service) fails because of a library issue.

/usr/lib/udisks2/udisksd: symbol lookup error: /usr/lib/libbd_utils.so.2: undefined symbol: g_spawn_check_wait_status

Maybe libblockdev needs to be recompiled with the right glibc version.

Thus, it is not possible to auto-mount external USB drives.

resolving dependencies...
warning: cannot resolve "libpulse.so=0-32", a dependency of "libao"
warning: cannot resolve "libpulse-simple.so=0-32", a dependency of "libao"
:: The following package cannot be upgraded due to unresolvable dependencies:
      libao

:: Do you want to skip the above package for this upgrade? [y/N] n
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'libpulse.so=0-32' required by libao
:: unable to satisfy dependency 'libpulse-simple.so=0-32' required by libao

12.04.2018 - io_queue_run.os: In function `io_queue_run’: io_queue_run.c:(.text+0×71): undefined reference to `__stack_chk_fail_local’ io_getevents.os: In …

01.05.2019 - Program terminated with signal SIGSEGV, Segmentation fault. #0 0xb30d3329 in getenv () from /usr/lib/libc.so.6 (gdb) bt #0 0xb30d3329 in …

Feb 12 11:57:48 arch32-testing-pentium4 audit[9829]: USER_LOGIN pid=9829 uid=0 auid=1000 ses=7 msg='op=login id=1000 exe="/usr/bin/lightdm" hostname=arch32-testing-pentium4 addr=? terminal=/dev/tty7 res=success'
Feb 12 11:57:48 arch32-testing-pentium4 kernel: audit: type=1112 audit(1613127468.816:104): pid=9829 uid=0 auid=1000 ses=7 msg='op=login id=1000 exe="/usr/bin/lightdm" hostname=arch32-testing-pentium4 addr=? terminal=/dev/tty7 res=success'
Feb 12 11:57:55 arch32-testing-pentium4 kaccess[9880]: Xlib XKB extension major= 1  minor= 0
Feb 12 11:57:56 arch32-testing-pentium4 kaccess[9880]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:57:58 arch32-testing-pentium4 kaccess[9880]: "Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)"
Feb 12 11:58:00 arch32-testing-pentium4 kgpg[9909]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:58:01 arch32-testing-pentium4 kgpg[9909]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:58:01 arch32-testing-pentium4 kgpg[9909]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:58:01 arch32-testing-pentium4 kgpg[9909]: "Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)"

re.so.8 error messages, re.so.9 is in stable

and then segfaults in libQt5WebEngineCore

Kmail 20.08.1-1.0 fails to start with symbol lookup error.

Steps to reproduce: invoking kmail on the console shows:

kmail: symbol lookup error: /usr/lib/libKF5MailImporter.so.5: undefined symbol: _ZN9PimCommon15CustomLogWidgetC1EP7QWidget

Downgrading messagelib fixes this issue but generates other issues (missing files or other undefined symbols).

After all I didn’t find a solution.

With linux 5.11.1.arch1-1.0, iwd no longer works for associating with WPA2 access points. On attempting to start the service, the journal reads:

iwd: RC4 support not found
iwd: The following options are missing in the kernel:
iwd:    CONFIG_CRYPTO_USER_API_SKCIPHER
iwd:    CONFIG_CRYPTO_ECB
iwd:    CONFIG_CRYPTO_ARC4

It would be nice to have these options enabled in the kernel config, so as to continue support for the iwd package.

Attached to Project: Archlinux32
Opened by Andreas Baumann - 13.07.2019
 FS#83  - kdeinit5 is filling the systemd journal with nonsensical messages

Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()

225 root      20   0  359832 225172 224128 S  24.5  29.5   0:45.52 systemd-journal 

Upstream too? Or is it fast enough if one core is dedicated to output
nonsensical output.. :->

Google Cache

Attached to Project: Archlinux32
Opened by Andreas Baumann - 07.07.2019
 FS#81  - KDE/Plasma crashes on startup (i686)

Application: ksplashqml (ksplashqml), signal: Aborted
Using host libthread_db library “/usr/lib/libthread_db.so.1”.
[Current thread is 1 (Thread 0xb21d5900 (LWP 427))]

Thread 3 (Thread 0xaa75cb40 (LWP 429)):
#0 0xb4b95418 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0
#1 0xb4b959f7 in ?? () from /usr/lib/libglib-2.0.so.0
#2 0xb4b95be6 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3 0xb6e75ce5 in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/libQt5Core.so.5
#4 0xb6e18ef5 in QEventLoop::exec(QFlags) () from /usr/lib/libQt5Core.so.5
#5 0xb6c5fe1a in QThread::exec() () from /usr/lib/libQt5Core.so.5
#6 0xb66317c3 in ?? () from /usr/lib/libQt5Qml.so.5
#7 0xb6c611cc in ?? () from /usr/lib/libQt5Core.so.5
#8 0xb5e34018 in start_thread () from /usr/lib/libpthread.so.0
#9 0xb697c25a in clone () from /usr/lib/libc.so.6

Thread 2 (Thread 0xb1a18b40 (LWP 428)):
#0 0xb7f6a82d in kernel_vsyscall ()
#1 0xb6972873 in poll () from /usr/lib/libc.so.6
#2 0xb550c6ce in ?? () from /usr/lib/libxcb.so.1
#3 0xb550e864 in xcb_wait_for_event () from /usr/lib/libxcb.so.1
#4 0xb1bad3da in ?? () from /usr/lib/libQt5XcbQpa.so.5
#5 0xb6c611cc in ?? () from /usr/lib/libQt5Core.so.5
#6 0xb5e34018 in start_thread () from /usr/lib/libpthread.so.0
#7 0xb697c25a in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0xb21d5900 (LWP 427)):
[KCrash Handler]
#6 0xb7f6a82d in kernel_vsyscall ()
#7 0xb68c4376 in raise () from /usr/lib/libc.so.6
#8 0xb68ae299 in abort () from /usr/lib/libc.so.6
#9 0xb6c1f873 in QMessageLogger::fatal(char const*, …) const () from /usr/lib/libQt5Core.so.5
#10 0xb6387c44 in QV4::Compiler::Codegen::visit(QQmlJS::AST::UiProgram*) () from /usr/lib/libQt5Qml.so.5
#11 0xb64298d6 in QJSEngine::QJSEngine(QJSEnginePrivate&, QObject*) () from /usr/lib/libQt5Qml.so.5
#12 0xb6575fcd in QQmlEngine::QQmlEngine(QObject*) () from /usr/lib/libQt5Qml.so.5
#13 0xb6888bc4 in KDeclarative::QmlObjectSharedEngine::QmlObjectSharedEngine(QObject*) () from /usr/lib/libKF5Declarative.so.5
#14 0xb7f0fb00 in KQuickAddons::QuickViewSharedEngine::QuickViewSharedEngine(QWindow*) () from /usr/lib/libKF5QuickAddons.so.5
#15 0x0040a29b in ?? ()
#16 0x00408e7a in ?? ()
#17 0x004095a2 in ?? ()
#18 0x004081de in ?? ()
#19 0xb68af7b9 in __libc_start_main () from /usr/lib/libc.so.6
#20 0x004082e5 in _start ()
[Inferior 1 (process 427) detached]

Google Cache

KDE applications fail to start with the following error:

symbol lookup error: /usr/lib/libKF5QuickAddons.so.5: undefined symbol: _ZNK19KCoreConfigSkeleton10isDefaultsEv

The affected applications I’ve found so far are:
dolphin 19.08.3-1.0
kwin 5.17.3-1.0
plasma-workspace 5.17.0-2.0

After downgrading kdeclarative to 5.63.0-1.0 kwin and plasma start but dolphin fails with a new error:

dolphin: symbol lookup error: /usr/lib/libKF5KCMUtils.so.5: undefined symbol: _ZNK12KQuickAddons12ConfigModule11errorStringEv

Downgrading kcmutils to 5.63.0-1.0 finally fixed dolphin.

07.07.2019 -  FS#80  - kate refuses to build due to some broken shared library dependencies. /usr/bin/ld: warning: libgit2.so.27, needed by …

# pacman -S jack --noconfirm
:: There are 2 providers available for jack:
:: Repository extra
   1) jack2  2) pipewire-jack

Enter a number (default=1): 
resolving dependencies...
warning: cannot resolve "libcelt0.so=2-32", a dependency of "jack2"
:: The following package cannot be upgraded due to unresolvable dependencies:
      jack2

:: Do you want to skip the above package for this upgrade? [y/N] error: failed to prepare transaction (could not satisfy dependencies)

:: unable to satisfy dependency 'libcelt0.so=2-32' required by jack2

Attached to Project: Archlinux32
Opened by Andreas Baumann - 10.05.2018
Last edited by Andreas Baumann - 23.01.2019
 FS#37  - ISO 2018.05.01 is not bootable with qemu or Virtualbox

I tried the i686 image. Booting leads to kernel panic.
Adding an explicit init=/lib/systemd/systemd parameter also panics.

qemu-system-i386 -cdrom archlinux-2018.05.01-i686.iso

It also panics in Virtualbox.

The same ISO works with libvirtd though.
Closed by Andreas Baumann
23.01.2019 18:29
Reason for closing: Fixed
Additional comments about closing:

works

  Comments (6)
  Related Tasks (0/0)

Admin
Tyzoid commented on 10.05.2018 10:49

i686 iso works fine in virtualbox on both a windows and linux host from my testing.
Admin
Tyzoid commented on 10.05.2018 11:04

Issue confirmed on qemu-system-i386 and qemu-system-x86_64. archlinux-2018.04.01-i686.iso fails to boot correctly as well.

Screenshot of the issue on i386 qemu: https://i.imgur.com/KRt21gI.png Screenshot of the issue on x86_64 qemu: https://i.imgur.com/wozM2hb.png Admin
Andreas Baumann commented on 11.05.2018 09:02

So /lib/systemd/systemd is either not found or cannot be executed, maybe because of a wrong
shared library dependency? I doubt it has to do with the kernel itself, as the log message
indicates the initial ram disk has been loaded.
Admin
Andreas Baumann commented on 16.06.2018 18:35

The write error indicates that the ramdisk could not be extracted.

So, if I start qemu with:

qemu-system-i386 -enable-kvm -cpu pentium3 -m 2048 -cdrom archlinux-2018.06.01-i686.iso

it works.

The default in qemu is 128MB Admin
Andreas Baumann commented on 16.06.2018 18:48

Sadly this is not the cause for VirtualBox, there it still fails even with 2048MB memory.
Admin
Andreas Baumann commented on 23.01.2019 18:18

The 2019.01.04 ISO works with Virtualbox 6.0.0.

Google Cache

root@arch32-stable-pentium4 ~]# iotop
No module named 'iotop'
To run an uninstalled copy of iotop,
launch iotop.py in the top directory

iotop is a Python script, presumably some Python modules are missing.

Seen with trojita:
Cannot mix incompatible Qt library (version 0x50d02) with this library (version 0x50d01)

[keith@Arch32 ~]$ calibre
Failed to import PyQt module: PyQt6.QtQuick with error: No module named 'PyQt6.QtQuick'
Traceback (most recent call last):
  File "/usr/bin/calibre", line 21, in <module>
    sys.exit(calibre())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 73, in calibre
    main(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 546, in main
    app, opts, args = init_qt(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 123, in init_qt
    app = Application(args, override_program_name=override, windows_app_uid=MAIN_APP_UID)
  File "/usr/lib/calibre/calibre/gui2/__init__.py", line 1096, in __init__
    setup_to_run_webengine()
  File "/usr/lib/calibre/calibre/gui2/__init__.py", line 1078, in setup_to_run_webengine
    from qt.core import QQuickWindow, QSGRendererInterface
ImportError: cannot import name 'QQuickWindow' from 'qt.core' (/usr/lib/calibre/qt/core.py)
[keith@Arch32 ~]$ calibre --version
calibre (calibre 6.7.1)
[keith@Arch32 ~]$ 

Hi,

pango-list (and many packages depending on pango) fails to run with the following error:

$ pango-list 
pango-list: symbol lookup error: /usr/lib/libpangoft2-1.0.so.0: undefined symbol: hb_font_set_synthetic_slant

hb_font_set_synthetic_slant seems to be related to harfbuzz.

While I used Parabola i686 for the test, both pango and harfbuzz come from Arch Linux 32 i686, so Arch Linux 32 i686 should also be affected:

$ pacman -Q -o pango-list 
/usr/bin/pango-list is owned by pango 1:1.50.4-1.0
$ pacman -sS "^pango$"
extra/pango 1:1.50.4-1.0 [installed]
    A library for layout and rendering of text
$ pacman -sS "^harfbuzz$"
extra/harfbuzz 3.1.2-1.0 [installed]
    OpenType text shaping engine

Denis.

+ exec setarch i486 systemd-nspawn -q -D /var/lib/archbuild/staging-i486/root -E PATH=/usr/local/sbin:/usr/local/bin:/usr/bin –register=no –keep-unit –as-pid2 –bind=/var/cache/archbuild32 pacman -Syuu –noconfirm
error: failed to initialize alpm library

Note:- It will compile very easily as i have a modified PKGBUILD

```
# Maintainer: Frederik Schwan freswa@archlinux.org pkgdesc=’A simple VTE-based terminal’ pkgname=termite
pkgver=16.4
pkgrel=2
url=https://github.com/aperezdc/termite license=(LGPL)
depends=(gtk3 pcre2 gnutls vte-common)
makedepends=(gperf ‘meson>=0.58’ ninja)
arch=(’x86_64’,’i686’,’pentium4’‘i486’)
backup=(etc/xdg/termite/config)

source=(”${url}/releases/download/v${pkgver}/termite-${pkgver}.tar.xz”{,.asc})
b2sums=(’SKIP’

      'SKIP')

build () {

rm -rf _build
arch-meson _build "${pkgname}-${pkgver}"
meson compile -C _build

}

package () {

meson install -C _build --skip-subprojects vte --destdir "${pkgdir}"

}
```

Note:- It will compile very easily as i have a modified PKGBUILD

# Maintainer: Frederik Schwan freswa@archlinux.org pkgdesc=’A simple VTE-based terminal’ pkgname=termite
pkgver=16.4
pkgrel=2
url=https://github.com/aperezdc/termite license=(LGPL)
depends=(gtk3 pcre2 gnutls vte-common)
makedepends=(gperf ‘meson>=0.58’ ninja)
arch=(’x86_64’,’i686’,’pentium4’‘i486’)
backup=(etc/xdg/termite/config)

source=(”${url}/releases/download/v${pkgver}/termite-${pkgver}.tar.xz”{,.asc})
b2sums=(’SKIP’

      'SKIP')

build () {

rm -rf _build
arch-meson _build "${pkgname}-${pkgver}"
meson compile -C _build

}

package () {

meson install -C _build --skip-subprojects vte --destdir "${pkgdir}"

}

Configuring attoparsec-0.13.2.4...
Error:
    The following packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used.
installed package tasty-1.3.1 is broken due to missing package ansi-terminal-0.11-2SXi8ZhU18i2uWLidRUotS, async-2.2.2-K8T9LglWxlG5HgD5vvGjbo, optparse-applicative-0.16.1.0-JDPEASK1GJS1Nsq2qjjZCq
installed package tasty-quickcheck-0.10.1.2 is broken due to missing package QuickCheck-2.14.2-io0WylueSG4seqSTUQCKM, optparse-applicative-0.16

I had to rebuild sqlite to have dirmng start and still –recv-keys is not working, returning “general error”.

The go build fails with this error:

unsupported setting GO386=387. Consider using GO386=softfloat instead.

go tool dist: FAILED: /build/go/src/go/pkg/tool/linux_386/compile -std -pack -o /tmp/go-tool-dist-250139381/runtime/internal/atomic/_go_.a -p runtime/internal/atomic -importcfg /tmp/go-tool-dist-250139381/runtime/internal/atomic/importcfg -asmhdr /tmp/go-tool-dist-250139381/runtime/internal/atomic/go_asm.h -symabis /tmp/go-tool-dist-250139381/runtime/internal/atomic/symabis /build/go/src/go/src/runtime/internal/atomic/atomic_386.go /build/go/src/go/src/runtime/internal/atomic/stubs.go /build/go/src/go/src/runtime/internal/atomic/unaligned.go: exit status 1
go tool dist: open /tmp/go-tool-dist-250139381/runtime/internal/atomic/_go_.a: no such file or directory
go tool dist: open /tmp/go-tool-dist-250139381/runtime/internal/sys/_go_.a: no such file or directory
go tool dist: open /tmp/go-tool-dist-250139381/internal/cpu/_go_.a: no such file or directory
unsupported setting GO386=387. Consider using GO386=softfloat instead.

go tool dist: FAILED: /build/go/src/go/pkg/tool/linux_386/compile -std -pack -o /tmp/go-tool-dist-250139381/internal/cpu/_go_.a -p internal/cpu -importcfg /tmp/go-tool-dist-250139381/internal/cpu/importcfg -asmhdr /tmp/go-tool-dist-250139381/internal/cpu/go_asm.h -symabis /tmp/go-tool-dist-250139381/internal/cpu/symabis /build/go/src/go/src/internal/cpu/cpu.go /build/go/src/go/src/internal/cpu/cpu_386.go /build/go/src/go/src/internal/cpu/cpu_x86.go: exit status 1
unsupported setting GO386=387. Consider using GO386=softfloat instead.

go tool dist: FAILED: /build/go/src/go/pkg/tool/linux_386/compile -std -pack -o /tmp/go-tool-dist-250139381/runtime/internal/sys/_go_.a -p runtime/internal/sys -importcfg /tmp/go-tool-dist-250139381/runtime/internal/sys/importcfg -asmhdr /tmp/go-tool-dist-250139381/runtime/internal/sys/go_asm.h -symabis /tmp/go-tool-dist-250139381/runtime/internal/sys/symabis /build/go/src/go/src/runtime/internal/sys/arch.go /build/go/src/go/src/runtime/internal/sys/arch_386.go /build/go/src/go/src/runtime/internal/sys/intrinsics_common.go /build/go/src/go/src/runtime/internal/sys/intrinsics_stubs.go /build/go/src/go/src/runtime/internal/sys/stubs.go /build/go/src/go/src/runtime/internal/sys/sys.go /build/go/src/go/src/runtime/internal/sys/zgoarch_386.go /build/go/src/go/src/runtime/internal/sys/zgoos_linux.go /build/go/src/go/src/runtime/internal/sys/zversion.go: exit status 1
=⇒ ERROR: A failure occurred in build().

  Aborting...

Upstream discussion about this bug: https://github.com/golang/go/issues/44500

Someone mentions a fix, but it doesn’t apply for non SSE2 devices.

# Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Could not connect: Connection refused

As this is the case since months, I cannot imagine somebody is still using Gnome on Archlinux32..

Feb 19 10:22:46 arch32-stable-pentium4 gnome-control-center.desktop[10992]: gnome-control-center: symbol lookup error: /usr/lib/libwebkit2gtk-4.0.so.37: undefined symbol: wpe_fdo_initialize_shm

gnome-shell segfaults in libmutter.

                                                               Stack trace of thread 1009:
                                                               #0  0x00000000b64d5436 n/a (libmutter-cogl-6.so.0 + 0xe436)
                                                               #1  0x00000000b64d809c n/a (libmutter-cogl-6.so.0 + 0x1109c)
                                                               #2  0x00000000b653edb9 n/a (libmutter-cogl-6.so.0 + 0x77db9)
                                                               #3  0x00000000b64f8fc5 cogl_flush (libmutter-cogl-6.so.0 + 0x31fc5)
                                                               #4  0x00000000b6549154 cogl_onscreen_swap_buffers_with_damage (libmutter-cogl-6.so.0 + 0x82154)
                                                               #5  0x00000000b6c59f73 n/a (libmutter-clutter-6.so.0 + 0x10ff73)
                                                               #6  0x00000000b6c53cf2 n/a (libmutter-clutter-6.so.0 + 0x109cf2)
                                                               #7  0x00000000b6c54747 n/a (libmutter-clutter-6.so.0 + 0x10a747)
                                                               #8  0x00000000b6bf52ad n/a (libmutter-clutter-6.so.0 + 0xab2ad)
                                                               #9  0x00000000b7703bde g_main_context_dispatch (libglib-2.0.so.0 + 0x4dbde)
                                                               #10 0x00000000b7752962 n/a (libglib-2.0.so.0 + 0x9c962)
                                                               #11 0x00000000b7702299 g_main_loop_run (libglib-2.0.so.0 + 0x4c299)
                                                               #12 0x00000000b697f216 meta_run (libmutter-6.so.0 + 0xb9216)
                                                               #13 0x000000000043144e n/a (gnome-shell + 0x244e)
                                                               #14 0x00000000b7cd900e __libc_start_main (libc.so.6 + 0x1f00e)
                                                               #15 0x0000000000431635 n/a (gnome-shell + 0x2635)

:: installing mutter (3.38.3-1.0) breaks dependency ‘libmutter-6.so=0-32’ required by gnome-shell

let’s try to push mutter, making most of gnome happy, most likely breaking gnome-shell (if not
already broken).

I’m getting a “BadAccess” Xorg error. I think this is happening because the packaged version has been compiled against libraries which have meanwhile been upgraded.

Just to get to this point I had to install “libldap24” and “libffi7”.

/usr/lib/libc.6: CPU ISA level is lower than required.

updating effectively breaks all commands!

For those lucky enough to have a pacman-static installed, they can
IMMEDIATEDY downgrade glibc and keep the machine alive.

This is considered a distribution-killing bug for i486 and i686.

Pentium4 is not affectted.

I’m on pentium4 and I’m getting:

/usr/bin/xgettext: error while loading shared libraries: libunistring.so.2: cannot open shared object file: No such file or directory
/usr/bin/msgmerge: error while loading shared libraries: libunistring.so.2: cannot open shared object file: No such file or directory
/usr/bin/msgfmt: error while loading shared libraries: libunistring.so.2: cannot open shared object file: No such file or directory

gettext 0.21.1-1.1
libunistring 1.1-2.0

gedit: error while loading shared libraries: libtepl-5.so.0: cannot open shared object file: No such file or directory

The bug report has been sent upstream to GDBM directly. This is too important to just ignore the failure.. (make check || true)

Current version in /usr/lib is libboost_regex.so.1.78.0

```
gcompris-qt: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
```

We need llvm 7.0 instead of 7.1.
If we muss a llvm update, bootstrapping rust fails (due to a to old libLLVM.so).
defined multiple times

1. > /build/rust/src/rustc-1.34.1-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-02dad87448159bce/out/consts.rs:2112:5

2110 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;

 |     ------------------------------------------------------------------------------------------------------------------------------------- previous definition of the type `U1024` here

2111 | pub type P1024 = PInt; pub type N1024 = NInt;
2112 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;

 |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `U1024` redefined here

https://github.com/paholg/typenum/commit/14a3322d1081fd63d5eb44bf8ab8f90676208228

Can anobody tell me, how we apply patches to downloaded artifacts while building?!

  Comments (32)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 13.05.2019 04:32

> Can anobody tell me, how we apply patches to downloaded artifacts while building?!

I only have a racy solutions for that. Put the following at the start of build():

while true; do
find $rust-build-dir-path -type f -name $name-to-patch -execdir patch -p1 -i $srcdir/patch \; && break
done &
Admin
Erich Eckner commented on 29.07.2019 09:25

trying to compile rust 1.34 with llvm-libs 7:

error[E0428]: the name `U1024` is defined multiple times

1. -> /build/rust/src/rustc-1.34.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs:2112:5

|
2110 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;

   |     ------------------------------------------------------------------------------------------------------------------------------------- previous definition of the type `U1024` here

2111 | pub type P1024 = PInt; pub type N1024 = NInt;
2112 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;

   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `U1024` redefined here
   |
   = note: `U1024` must be defined only once in the type namespace of this module

error[E0428]: the name `P1024` is defined multiple times

1. -> /build/rust/src/rustc-1.34.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs:2113:5

|
2111 | pub type P1024 = PInt; pub type N1024 = NInt;

   |     ----------------------------- previous definition of the type `P1024` here

2112 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;
2113 | pub type P1024 = PInt; pub type N1024 = NInt;

   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `P1024` redefined here
   |
   = note: `P1024` must be defined only once in the type namespace of this module

error[E0428]: the name `N1024` is defined multiple times

1. -> /build/rust/src/rustc-1.34.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs:2113:35

|
2111 | pub type P1024 = PInt; pub type N1024 = NInt;

   |                                   ----------------------------- previous definition of the type `N1024` here

2112 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;
2113 | pub type P1024 = PInt; pub type N1024 = NInt;

   |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `N1024` redefined here
   |
   = note: `N1024` must be defined only once in the type namespace of this module

error: aborting due to 3 previous errors

Admin
Erich Eckner commented on 29.07.2019 09:32

let’s try again with:

while true; do
  sed -i '
    2112 { /pub type U1024/ d }
    2113 { /pub type P1024/ d }
  ' build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs 2>/dev/null || true
done &

injected in build() … which is the mother of all race conditions
Admin
Erich Eckner commented on 30.07.2019 08:36

current error:

error: this file contains an un-closed delimiter

1. -> /build/rust/src/rustc-1.34.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs:482:56

|
54 | pub mod consts {

  |                - un-closed delimiter

… 482 | pub type U210 = UInt`, const, identifier, lifetime, or type, found `}`

1. -> /build/rust/src/rustc-1.34.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs:482:55

|
482 | pub type U210 = UInt`, const, identifier, lifetime, or type here

error: aborting due to 2 previous errors

error: Could not compile `typenum`.
warning: build failed, waiting for other jobs to finish… error: build failed

trying again with some even-more-racing build()

build() {

cd "rustc-$pkgver-src"

while true; do
  find build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build \
    -type f \
    -name consts.rs \
    -exec grep -qF 'pub type P1024' {} \; \
    -exec sleep 1 \; \
    -exec sed -i '
      2112 { /pub type U1024/ d }
      2113 { /pub type P1024/ d }
    ' {} \; 2>/dev/null || true
done &
_kill_pid=$!

python2 ./x.py build -j"$(nproc)"
kill $_kill_pid

}

Admin
Erich Eckner commented on 30.07.2019 13:03

this is super-annoying: now the old “duplicate definition” error is back … but in package_rust()
Let’s build again (for several hours O.o) with this hack also applied in package_rust() … Admin
Erich Eckner commented on 30.07.2019 18:41

whoah, even more fun:

warning: the feature `try_from` has been stable since 1.34.0 and no longer requires an attribute to enable

1. -> src/tools/clippy/clippy_lints/src/lib.rs:12:12

|
12 | #![feature(try_from)]

 |            ^^^^^^^^
 |
 = note: #[warn(stable_features)] on by default

warning: the feature `try_from` has been stable since 1.34.0 and no longer requires an attribute to enable

1. -> src/tools/clippy/clippy_lints/src/lib.rs:12:12

|
12 | #![feature(try_from)]

 |            ^^^^^^^^
 |
 = note: #[warn(stable_features)] on by default

warning: the feature `try_from` has been stable since 1.34.0 and no longer requires an attribute to enable
–> src/tools/clippy/src/driver.rs:4:12

|

4 | #![feature(try_from)]

|            ^^^^^^^^
|
= note: #[warn(stable_features)] on by default

  Finished release [optimized] target(s) in 9m 17s

Building stage2 tool rls (i686-unknown-linux-gnu)
error: the listed checksum of `/build/rust/src/rustc-1.34.0-src/vendor/rustc-ap-rustc_target/spec/i686_unknown_linux_gnu.rs` has changed:
expected: a75a6025d7e3424edf9baf3039056c0f8eea157631a175d00ac5a218aa54b510
actual: 484bf8be15015b330fa9a97b6dabb8c7627e59d5cddb2dd0e83478749f8aabad

directory sources are not intended to be edited, if modifications are required then it is recommended that [replace] is used with a forked copy of the source
command did not execute successfully: “/usr/bin/cargo” “build” “–target” “i686-unknown-linux-gnu” “-j” “4” “–release” “–frozen” “–manifest-path” “/build/rust/src/rustc-1.34.0-src/src/tools/rls/Cargo.toml” “–features” “clippy” “–message-format” “json” expected success, got: exit code: 101
thread ‘main’ panicked at ‘Unable to build RLS’, src/bootstrap/dist.rs:65:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
failed to run: /build/rust/src/rustc-1.34.0-src/build/bootstrap/debug/bootstrap install
Build completed unsuccessfully in 2:02:38

Admin
Erich Eckner commented on 08.08.2019 06:18

current approach: using rust-1.36 from manjaro32 (thanks, jonathon!) … this fails in stage 1, because it does not find some library, which actually _is_ there (but apparently not in the search path).
Admin
Erich Eckner commented on 09.08.2019 05:16

symlinking the library to the correct one hidden in some “stage1” folder solved it. Now we have rust 1.36 for i686 in [build-support] - let’s hope some build slave can build a regular rust (e.g. one where I do not extract additional files with bsdtar into the build chroot) from that and we can close this bug report.
Admin
Andreas Baumann commented on 22.08.2019 07:43

Rebuilds of rust on i686 and pentium4 show:

— stderr
error: couldn’t load codegen backend “/usr/lib/rustlib/i686-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so”: “libLLVM-7.so: cannot open shared object file: No such file or directory”

Admin
Andreas Baumann commented on 22.08.2019 09:56

Tried with precompiled binaries (AUR package ‘rust-bin’):

https://aur.archlinux.org/packages/rust-bin/

Compiling 1.37.0 from source now results in LLVM: out of memory,
see also:

https://github.com/rust-lang/rust/issues/60294 Admin
Andreas Baumann commented on 22.08.2019 10:10

Fedora 31 will also complain, so there is a chance Rust people are actually doing something
and not just ignoring us:

https://bugzilla.redhat.com/show_bug.cgi?id=1723064 Admin
Andreas Baumann commented on 08.09.2019 14:29

Asked upstream about how rust is supposed to be built on a machine with 32-bit
address space:

https://github.com/rust-lang/rust/issues/60294

–debuginfo-level-std=1

in config.toml

works over the first out of memory situations.

Now I get:

error: failed to run custom build command for `backtrace-sys v0.1.27`

Caused by:

process didn’t exit successfully: `/build/rust/src/rustc-1.37.0-src/build/i686-unknown-linux-gnu/stage2-std/release/build/backtrace-sys-e11a26709e2be131/build-script-build` (exit code: 101)

— stdout

command did not execute successfully: “/usr/bin/cargo” “build” “–target” “x86_64-unknown-linux-gnu” “-j” “1” “–release” “–frozen” “–features” “panic-unwind backtrace profiler” “–manifest-path” “/build/rust/src/rustc-1.37.0-src/src/libstd/Cargo.toml” “–message-format” “json” expected success, got: exit code: 101

‘, /build/rust/src/rustc-1.37.0-src/vendor/cc/src/lib.rs:2398:5
stack backtrace:

0: std::panicking::default_hook::closure 1: std::panicking::default_hook
2: std::panicking::rust_panic_with_hook
3: std::panicking::continue_panic_fmt
4: std::panicking::begin_panic_fmt
5: cc::fail

         at /build/rust/src/rustc-1.37.0-src/vendor/cc/src/lib.rs:2398

6: cc::Build::compile

         at /build/rust/src/rustc-1.37.0-src/vendor/cc/src/lib.rs:951

7: build_script_build::main

         at ./build.rs:107

8: std::rt::lang_start::closure 8: std::rt::lang_start::closure

         at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b/src/libstd/rt.rs:64

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I’m personally quite fed up with the quality and documentation of this compiler..
Admin
Andreas Baumann commented on 09.09.2019 06:43

cargo:warning=cc1: sorry, unimplemented: 64-bit mode not compiled in

Does this mean that the architecture triplet is wrong?
Admin
Andreas Baumann commented on 09.09.2019 18:03

Indeed. Fixed config.toml, which was completely wrong ([build] had a amd64 target,
building for two architectures instead one (i686)..
Admin
Andreas Baumann commented on 12.09.2019 07:13

pentium4 went through, trying now the sed trick above on the i686 version..
Admin
Andreas Baumann commented on 29.09.2019 18:12

error[E0428]: the name `U1024` is defined multiple times

1. -> /build/rust/src/rustc-1.37.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-895469ec3d111e10/out/consts.rs:2112:5

|
2110 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;

   |     ------------------------------------------------------------------------------------------------------------------------------------- previous definition of the type `U1024` here

2111 | pub type P1024 = PInt; pub type N1024 = NInt;
2112 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;

   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `U1024` redefined here
   |
   = note: `U1024` must be defined only once in the type namespace of this module

error[E0428]: the name `P1024` is defined multiple times

1. -> /build/rust/src/rustc-1.37.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-895469ec3d111e10/out/consts.rs:2113:5

|
2111 | pub type P1024 = PInt; pub type N1024 = NInt;

   |     ----------------------------- previous definition of the type `P1024` here

2112 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;
2113 | pub type P1024 = PInt; pub type N1024 = NInt;

   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `P1024` redefined here
   |
   = note: `P1024` must be defined only once in the type namespace of this module

error[E0428]: the name `N1024` is defined multiple times

1. -> /build/rust/src/rustc-1.37.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-895469ec3d111e10/out/consts.rs:2113:35

|
2111 | pub type P1024 = PInt; pub type N1024 = NInt;

   |                                   ----------------------------- previous definition of the type `N1024` here

2112 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;
2113 | pub type P1024 = PInt; pub type N1024 = NInt;

   |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `N1024` redefined here
   |
   = note: `N1024` must be defined only once in the type namespace of this module

error: aborting due to 3 previous errors

For more information about this error, try `rustc –explain E0428`.

 Compiling strip-ansi-escapes v0.1.0

error: Could not compile `typenum`.

Admin
Andreas Baumann commented on 02.10.2019 19:32

There is no documentation how to use x.py properly, what the build does, what
the bootstrapping does. And life-patching of typenum is just the really last
straw (currently failing)..

Currently blocking:
- librsvg2 on i686 (rust-bin generates SSE2-code)
- firefox, thunderbird and friends on i686
- some random software on i686 like newsboat
Admin
Andreas Baumann commented on 03.10.2019 05:39

We should try to understand x.py

https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md

To me it looks like we can have a PKGBUILD calling each stage individually and do
the necessary patching in-between.
Admin
Andreas Baumann commented on 04.10.2019 08:06

Ok, I see several issues here:

rustc –target i686-unknown-linux-gnu –print cfg

says:

target_feature=”sse” target_feature=”sse2”

rustc –target i586-unknown-linux-gnu –print cfg

has no SSE/SSE2, so we pick:
- i686-unknown-linux-gnu for our pentium4 and
- i586-unknown-linux-gnu for our i486 and i686

see also some interesting notes in:
- https://github.com/rust-lang/rust/issues/54740 - https://internals.rust-lang.org/t/is-pentium4-still-an-appropriate-base-cpu-for-i686/7353/6

The current config.toml.patch doesn’t apply correctly and silently fails:

patching file config.toml
Hunk #1 FAILED at 2.
Hunk #2 succeeded at 21 with fuzz 2 (offset 2 lines).
1 out of 2 hunks FAILED – saving rejects to file config.toml.rej

This needs proper treatment in the build scripts, as we cannot continue building
if patches apply partially!
Admin
Andreas Baumann commented on 05.10.2019 08:57

Now I get the same typenum error also in stage2 of cargo on pentium4.

Trying the stage 2 –keep-stage 1 trick..
Admin
Andreas Baumann commented on 05.10.2019 09:11

Some internal documentation on x.py:

https://rust-lang.github.io/rustc-guide/how-to-build-and-run.html Admin
Andreas Baumann commented on 05.10.2019 12:46

Cool, so the conflicting consts.rs of typenum appears out of the blue in the middle of a stage.
So this multi-layered building will also not work.
Admin
Andreas Baumann commented on 05.10.2019 14:06

Trying an inotifywait approach watching for consts.rs to appear and calling a sed on it then:

inotifywait -mrq -e create –format %w%f $srcdir | while read -r FILE; do

case "$$FILE" in
  *consts.rs)
    echo "--> patching $$FILE"
    sed -i '/pub type U1024/d;/pub type P1024/d' $FILE
esac

done

Admin
Andreas Baumann commented on 05.10.2019 17:41

The inotify-trick helped to rebuild 1.38 for pentium4.

So, rust 1.38 can only be built with rust 1.37, not with 1.38 (rebuilding itself),
see:

https://github.com/rust-lang/rust/issues/63911

This means, having a rust package building rust works, if you do it once,
otherwise I would suggest to upstream to have a rust137 and build rust138
which provides rust, so the build can be done more than once (especially
automatically).

When I use rust-bin for 1.37 I cannot build 1.38 again for i686 (out of
memory). This one I’m trying to tackle with debug_level=0 (which seems
to help). Didn’t have this problem with ‘rust’ 1.37.0 on pentium4 for
rebuilding 1.38.0, so maybe rust-bin has some bad internal properties?
Admin
Andreas Baumann commented on 06.10.2019 07:57

inotifywait and sed is in the middle of patching the consts.rs file, so you get
half of a source-file:

error: this file contains an un-closed delimiter

1. -> /build/rust/src/rustc-1.38.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-483ffd21aece8552/out/consts.rs:266:56

Maybe some mandatory file locking helps?

Otherwise, I start considering a “fuse-patching” pseudo-filesystem. Admin
Andreas Baumann commented on 06.10.2019 09:42

flock doesn’t help, the file is now locked, but rust sees it as a sequence of \0.
Admin
Andreas Baumann commented on 19.10.2019 18:17

The following works: wait for inotify event close_write on file consts.rs and patch
it then.
Kill the watcher (which also kills inotifywait).

Now I can rebuild rust 1.38 from 1.37, but I still have problems rebuilding 1.38
with an 1.38 compiler (*sigh*).

As we have to assume that rust 1.37 and 1.36 are broken, let’s bootstrap again a
rust 1.38 from rust-bin 1.37.
Admin
Andreas Baumann commented on 19.10.2019 18:35

Now someting hangs in the middle..
Admin
Andreas Baumann commented on 20.10.2019 14:38

upstream fixed the boostrapping 1.38 with 1.38 issue (seems to be just some
superflous unsafe directives):

# Fix bootstrap to compile with 1.38
patch -Np1 -i ../bootstrap-1.38.patch

Admin
Andreas Baumann commented on 20.10.2019 14:38

Trying again to rebuild 1.38 with 1.38 (both for i686 and pentium4) against my bootstrapped
1.38 version. When this works, I’ll build official version in the regular way..
Admin
Andreas Baumann commented on 20.10.2019 14:41

cat > config.toml <<EOF

… EOF

This seems to be a new trend. I don’t like it, as it makes patching really hard..
Admin
Andreas Baumann commented on 20.10.2019 17:13

i686 1.38 rebuild of 1.38 results in:

error: Could not compile `typenum`.
warning: build failed, waiting for other jobs to finish… error: build failed
command did not execute successfully: “/usr/bin/cargo” “build” “–target” “i686-unknown-linux-gnu” “-j” “16” “–release” “–frozen” “–manifest-path” “/build/rust/src/rustc-1.38.0-src/src/tools/cargo/Cargo.toml” “–message-format” “json” expected success, got: exit code: 101
failed to run: /build/rust/src/rustc-1.38.0-src/build/bootstrap/debug/bootstrap install -j16
Build completed unsuccessfully in 0:38:12

no error messages, exit code 101 means what exactly?

Bing Cache

no task description

On arch32 currently foot and alacritty is broken

warning: cannot resolve “firefox>=71.0”, a dependency of “firefox-i18n-de”

/build/seamonkey/src/seamonkey-2.53.5/obj-i686-pc-linux-gnu/_virtualenv/bin/python /build/seamonkey/src/s                                                                                                           eamonkey-2.53.5/mozilla/toolkit/mozapps/installer/packager.py -DMOZ_APP_NAME=seamonkey -DPREF_DIR=default                                                                                                           s/pref -DJAREXT= -DMOZ_CALENDAR=1 -DMOZ_GTK=1 -DMOZ_IRC=1 -DMOZ_DOMINSPECTOR=1 -DMOZ_SYSTEM_NSPR=1 -DMOZ_                                                                                                           SYSTEM_NSS=1 -DMOZ_MOVEMAIL=1 -DNECKO_WIFI=1 -DMOZ_BUNDLED_FONTS=1 -DMOZ_CHILD_PROCESS_NAME=plugin-contai                                                                                                           ner -DDLL_PREFIX=lib -DDLL_SUFFIX=.so -DBIN_SUFFIX= -DDIR_MACOS= -DDIR_RESOURCES= -DBINPATH=bin -DRESPATH                                                                                                           =bin -DLPROJ_ROOT=en -DCLANG_CXX -DA11Y_LOG=1 -DACCESSIBILITY=1 -DATK_MAJOR_VERSION=2 -DATK_MINOR_VERSION                                                                                                           =36 -DATK_REV_VERSION=0 -DBUILD_CTYPES=1 -DCROSS_COMPILE='' -DD_INO=d_ino -DENABLE_INTL_API=1 -DENABLE_SY                                                                                                           STEM_EXTENSION_DIRS=1 -DEXPOSE_INTL_API=1 -DFIREFOX_VERSION=60.7.5 -DFORCE_PR_LOG=1 -DFUNCPROTO=15 -DGDK_                                                                                                           VERSION_MAX_ALLOWED=GDK_VERSION_3_4 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_32 -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -DGL_PROVIDER_GLX=1 -DHAVE_ALLOCA_H=1 -DHAVE_BYTESWAP_H=1 -DHAVE_CLOCK_MONOTONIC=1 -DHAVE_CPUID_H=1 -DHAVE_DIRENT_H=1 -DHAVE_DLADDR=1 -DHAVE_DLOPEN=1 -DHAVE_FONTCONFIG_FCFREETYPE_H=1 -DHAVE_FT_BITMAP_SIZE_Y_PPEM=1 -DHAVE_FT_GLYPHSLOT_EMBOLDEN=1 -DHAVE_FT_LOAD_SFNT_TABLE=1 -DHAVE_GETOPT_H=1 -DHAVE_GETTID=1 -DHAVE_GMTIME_R=1 -DHAVE_I18N_LC_MESSAGES=1 -DHAVE_INTTYPES_H=1 -DHAVE_LCHOWN=1 -DHAVE_LINUX_IF_ADDR_H=1 -DHAVE_LINUX_PERF_EVENT_H=1 -DHAVE_LINUX_QUOTA_H=1 -DHAVE_LINUX_RTNETLINK_H=1 -DHAVE_LOCALECONV=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LSTAT64=1 -DHAVE_MALLINFO=1 -DHAVE_MALLOC_H=1 -DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MEMALIGN=1 -DHAVE_MEMMEM=1 -DHAVE_MOVEMAIL=1 -DHAVE_NETINET_IN_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_POSIX_FADVISE=1 -DHAVE_POSIX_FALLOCATE=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_PTHREAD_H=1 -DHAVE_RES_NINIT=1 -DHAVE_SETPRIORITY=1 -DHAVE_STAT64=1 -DHAVE_STDINT_H=1 -DHAVE_STRERROR=1 -DHAVE_STRNDUP=1 -DHAVE_SYSCALL=1 -DHAVE_SYS_QUEUE_H=1 -DHAVE_SYS_QUOTA_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_THREAD_TLS_KEYWORD=1 -DHAVE_TRUNCATE64=1 -DHAVE_UNISTD_H=1 -DHAVE_VALLOC=1 -DHAVE_VA_COPY=1 -DHAVE_VISIBILITY_ATTRIBUTE=1 -DHAVE_VISIBILITY_HIDDEN_ATTRIBUTE=1 -DHAVE__UNWIND_BACKTRACE=1 -DHAVE___CXA_DEMANGLE=1 -DJS_DEFAULT_JITREPORT_GRANULARITY=3 -DMALLOC_H='<malloc.h>' -DMALLOC_USABLE_SIZE_CONST_PTR='' -DMOZILLA_OFFICIAL=1 -DMOZILLA_UAVERSION='"60.0"' -DMOZILLA_VERSION='"60.7.5"' -DMOZILLA_VERSION_U=60.7.5 -DMOZ_ACCESSIBILITY_ATK=1 -DMOZ_ALLOW_LEGACY_EXTENSIONS=1 -DMOZ_APP_UA_NAME='""' -DMOZ_APP_UA_VERSION='"2.53.5"' -DMOZ_AV1=1 -DMOZ_BUILD_APP=../suite -DMOZ_BUNDLED_FONTS=1 -DMOZ_CONTENT_SANDBOX=1 -DMOZ_DAV1D_ASM=1 -DMOZ_DISABLE_STARTUPCACHE=1 -DMOZ_DISTRIBUTION_ID='"org.mozilla"' -DMOZ_DLL_SUFFIX='".so"' -DMOZ_ENABLE_DBUS=1 -DMOZ_ENABLE_MASK_AS_SHORTHAND=1 -DMOZ_ENABLE_SKIA=1 -DMOZ_ENABLE_STARTUP_NOTIFICATION=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_FEEDS=1 -DMOZ_FFMPEG=1 -DMOZ_FFVPX=1 -DMOZ_FFVPX_FLACONLY=1 -DMOZ_FMP4=1 -DMOZ_GECKO_PROFILER=1 -DMOZ_GLUE_IN_PROGRAM=1 -DMOZ_GMP_SANDBOX=1 -DMOZ_INSTRUMENT_EVENT_LOOP=1 -DMOZ_LOGGING=1 -DMOZ_MACBUNDLE_ID=org.mozilla.seamonkey -DMOZ_MEMORY=1 -DMOZ_MORK=1 -DMOZ_PEERCONNECTION=1 -DMOZ_PERMISSIONS=1 -DMOZ_PLACES=1 -DMOZ_PULSEAUDIO=1 -DMOZ_RAW=1 -DMOZ_RUST_SIMD=1 -DMOZ_SAMPLE_TYPE_FLOAT32=1 -DMOZ_SANDBOX=1 -DMOZ_SCTP=1 -DMOZ_SEPARATE_MANIFEST_FOR_THEME_OVERRIDES=1 -DMOZ_SRTP=1 -DMOZ_STATIC_JS=1 -DMOZ_SUITE=1 -DMOZ_SYSTEM_ICU=1 -DMOZ_TREE_CAIRO=1 -DMOZ_UPDATE_CHANNEL=default -DMOZ_USER_DIR='".mozilla"' -DMOZ_VORBIS=1 -DMOZ_VPX_NO_MEM_REPORTING=1 -DMOZ_WEBM_ENCODER=1 -DMOZ_WEBRTC=1 -DMOZ_WEBRTC_ASSERT_ALWAYS=1 -DMOZ_WEBRTC_SIGNALING=1 -DMOZ_WEBSPEECH=1 -DMOZ_WEBSPEECH_TEST_BACKEND=1 -DMOZ_WIDGET_GTK=3 -DMOZ_X11=1 -DMOZ_XUL=1 -DNO_NSPR_10_SUPPORT=1 -DNS_PRINTING=1 -DNS_PRINT_PREVIEW=1 -DRELEASE_OR_BETA=1 -DSTATIC_JS_API=1 -DSTDC_HEADERS=1 -DTARGET_XPCOM_ABI='"x86-gcc3"' -DUSE_SKIA=1 -DUSE_SKIA_GPU=1 -DU_USING_ICU_NAMESPACE=0 -DVA_COPY=va_copy -DVPX_X86_ASM=1 -DXP_LINUX=1 -DXP_UNIX=1 -D_REENTRANT=1 -DAB_CD=en-US \
        --format omni \
        --removals /build/seamonkey/src/seamonkey-2.53.5/suite/installer/removed-files.in \
         \
         \
         \
         \
        --optimizejars \
        --disable-compression \
        package-manifest ../../dist ../../dist/seamonkey \
        --non-resource defaults/messenger/mailViews.dat defaults/profile/panels.rdf defaults/profile/mimeTypes.rdf defaults/profile/chrome/userChrome-example.css defaults/profile/chrome/userContent-example.css 
terminate called after throwing an instance of 'std::runtime_error'
  what():  Section index out of bounds
Traceback (most recent call last):
  File "/build/seamonkey/src/seamonkey-2.53.5/mozilla/toolkit/mozapps/installer/packager.py", line 326, in <module>
    main()
  File "/build/seamonkey/src/seamonkey-2.53.5/mozilla/toolkit/mozapps/installer/packager.py", line 320, in main
    copier.copy(args.destination)
  File "/build/seamonkey/src/seamonkey-2.53.5/mozilla/python/mozbuild/mozpack/copier.py", line 428, in copy
    copy_results.append((destfile, f.copy(destfile, skip_if_older)))
  File "/build/seamonkey/src/seamonkey-2.53.5/mozilla/python/mozbuild/mozpack/files.py", line 296, in copy
    elfhack(dest)
  File "/build/seamonkey/src/seamonkey-2.53.5/mozilla/python/mozbuild/mozpack/executables.py", line 124, in elfhack
    errors.fatal('Error executing ' + ' '.join(cmd))
  File "/build/seamonkey/src/seamonkey-2.53.5/mozilla/python/mozbuild/mozpack/errors.py", line 103, in fatal
    self._handle(self.FATAL, msg)
  File "/build/seamonkey/src/seamonkey-2.53.5/mozilla/python/mozbuild/mozpack/errors.py", line 98, in _handle
    raise ErrorMessage(msg)
mozpack.errors.ErrorMessage: Error: Error executing /build/seamonkey/src/seamonkey-2.53.5/obj-i686-pc-linux-gnu/build/unix/elfhack/elfhack ../../dist/seamonkey/libxul.so
make[2]: *** [/build/seamonkey/src/seamonkey-2.53.5/mozilla/toolkit/mozapps/installer/packager.mk:22: stage-package] Error 1
make[2]: Leaving directory '/build/seamonkey/src/seamonkey-2.53.5/obj-i686-pc-linux-gnu/suite/installer'
make[1]: *** [/build/seamonkey/src/seamonkey-2.53.5/mozilla/../suite/build.mk:13: install] Error 2
make[1]: Leaving directory '/build/seamonkey/src/seamonkey-2.53.5/obj-i686-pc-linux-gnu'
make: *** [client.mk:404: install] Error 2
==> ERROR: A failure occurred in package().
    Aborting...
==> ERROR: Build failed, check /var/lib/archbuild/slave1/staging-pentium4/slave1/build
used straw: :mirrored_source:mirrored_source_by_hash:

Attached to Project: Archlinux32
Opened by Andreas Baumann - 21.09.2019
Last edited by Andreas Baumann - 21.09.2019
 FS#87  - firefox doesn’t rebuild

OOM when build gkrust:

patching out debug_level=2 in moz.configure/toolchain.configure

thanks BoidLinux for the hint.

  Comments (3)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 21.09.2019 17:05

A test is executed testing the generated Gecko rust library (a static library), whether
it contains references to networking functions, this fails on IA32:

https://hg.mozilla.org/mozilla-central/rev/47cd8671b12c

$(call py_action,check_binary,–target –networking $@)

Solution is just not to execute this check in config/makefiles/rust.mk
Admin
Andreas Baumann commented on 21.09.2019 17:08

187:52.88 toolkit/library/libxul.so
190:00.47 readelf: Error: Unable to seek to 0x801db328 for section headers
190:01.36 out of memory allocating 3761314508 bytes after a total of 1595923192 bytes
190:01.47 File “/build/firefox/src/firefox-69.0.1/python/mozbuild/mozbuild/action/check_binary.py”, line 361, in

=> python/readelf combo reads whole generated libxul.so into memory in order to do
some ELF fidding.

190:01.48 make[4]: *** [/build/firefox/src/firefox-69.0.1/config/rules.mk:661: libxul.so] Error 1

shows us:

$(SHARED_LIBRARY): $(OBJS) $(RESFILE) $(RUST_STATIC_LIB) $(STATIC_LIBS) $(EXTRA_DEPS) $(GLOBAL_DEPS)

      $(REPORT_BUILD)

ifndef INCREMENTAL_LINKER

      $(RM) $@

endif

      $(MKSHLIB) $($@_$(OBJS_VAR_SUFFIX)) $(RESFILE) $(LDFLAGS) $(STATIC_LIBS) $(RUST_STATIC_LIB) $(SHARE
      $(call py_action,check_binary,--target $@)

Trying to comment that out too (the python check).
Admin
Andreas Baumann commented on 22.09.2019 07:46

Now libxul.so misses some libraries, like libmozsandbox.so, liblgpllibs.so, … The libraries exists, but most likely libxul.so cannot find them (rpath ELF fiddling?).

As a workaround I’ll set LD_LIBRARY_PATH=/usr/lib/firefox in the startup wrapper
scripts /usr/bin/firefox.

Google Cache

I checked the firefox on the build-list and its not compiling because of missing lvm13 libs which are packages are llvm13-libs and llvm13

Attached to Project: Archlinux32
Opened by Andreas Baumann - 09.05.2019
Last edited by Andreas Baumann - 09.05.2019
 FS#69  - firefox breaks heavily in micro-optimized code

The root cause is rust is not recompiling currently.

The log in detail:

14:57.22 error[E0432]: unresolved import `simd_funcs`
14:57.22 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:16:1 3
14:57.22 |
14:57.22 16 | use simd_funcs::*;
14:57.22 | ^^^^^^^^^^ maybe a missing `extern crate simd_funcs;`?
14:57.22 error[E0432]: unresolved import `packed_simd`
14:57.22 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:17:1 3
14:57.22 |
14:57.22 17 | use packed_simd::u16x8;
14:57.22 | ^^^^^^^^^^^ maybe a missing `extern crate packed_simd;`?
14:57.45 error[E0425]: cannot find function `load16_unaligned` in this scope
14:57.45 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:120 :34
14:57.45 |
14:57.45 120 | let input = unsafe { load16_unaligned(src_ptr.add(i * 16)) };
14:57.45 | ^^^^^^^^^^^^^^^^ not found in this scope
14:57.45 error[E0425]: cannot find function `simd_unpack` in this scope
14:57.45 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:121 :35
14:57.45 |
14:57.45 121 | let (first, second) = simd_unpack(input);
14:57.45 | ^^^^^^^^^^^ not found in this scope
14:57.45 error[E0425]: cannot find function `store8_unaligned` in this scope
14:57.45 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:123 :17
14:57.45 |
14:57.45 123 | store8_unaligned(dst_ptr.add(i * 16), shift_upper(first));
14:57.45 | ^^^^^^^^^^^^^^^^ not found in this scope
14:57.45 error[E0425]: cannot find function `store8_unaligned` in this scope
14:57.45 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:124 :17
14:57.45 |
14:57.45 124 | store8_unaligned(dst_ptr.add1);
14:57.45 | ^^^^^^^^^^^^^^^^ not found in this scope
14:57.46 error[E0412]: cannot find type `u16x8` in this scope
14:57.46 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:121:40
14:57.46 |
14:57.46 121 | pub fn simd_at(&self, i: usize) -> u16x8 {
14:57.46 | ^^^^^ not found in this scope
14:57.46 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.46 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:122:21
14:57.46 |
14:57.46 122 | assert!(i + SIMD_STRIDE_SIZE / 2 <= self.len);
14:57.46 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STR IDE_SIZE`
14:57.47 error[E0425]: cannot find function `to_u16_lanes` in this scope
14:57.47 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:124:18
14:57.47 |
14:57.47 124 | unsafe { to_u16_lanes(load16_unaligned(self.ptr.add(byte_index))) }
14:57.47 | ^^^^^^^^^^^^ not found in this scope
14:57.47 error[E0425]: cannot find function `load16_unaligned` in this scope
14:57.47 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:124:31
14:57.47 |
14:57.47 124 | unsafe { to_u16_lanes(load16_unaligned(self.ptr.add(byte_index))) }
14:57.47 | ^^^^^^^^^^^^^^^^ not found in this scope
14:57.47 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.47 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:145:12
14:57.47 |
14:57.47 145 | if SIMD_STRIDE_SIZE / 2 <= self.len {
14:57.47 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:57.48 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.48 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:146:47
14:57.48 |
14:57.48 146 | let len_minus_stride = self.len - SIMD_STRIDE_SIZE / 2;
14:57.48 | ^^^^^^^^^^^^^^^^ help: a constant with a sim ilar name exists: `ALU_STRIDE_SIZE`
14:57.48 error[E0425]: cannot find function `simd_byte_swap` in this scope
14:57.48 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:150:28
14:57.48 |
14:57.48 150 | simd = simd_byte_swap(simd);
14:57.48 | ^^^^^^^^^^^^^^ not found in this scope
14:57.49 error[E0425]: cannot find function `store8_unaligned` in this scope
14:57.49 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:153:21
14:57.49 |
14:57.49 153 | store8_unaligned(other.as_mut_ptr().add(offset), simd);
14:57.49 | ^^^^^^^^^^^^^^^^ not found in this scope
14:57.49 error[E0425]: cannot find function `contains_surrogates` in this scope
14:57.49 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:155:20
14:57.49 |
14:57.49 155 | if contains_surrogates(simd) {
14:57.49 | ^^^^^^^^^^^^^^^^^^^ not found in this scope
14:57.49 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.49 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:158:27
14:57.49 |
14:57.49 158 | offset += SIMD_STRIDE_SIZE / 2;
14:57.49 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `A LU_STRIDE_SIZE`
14:57.50 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.50 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:237:8
14:57.50 |
14:57.50 237 | if SIMD_STRIDE_SIZE <= len {
14:57.50 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:57.50 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.50 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.50 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:237:8
14:57.50 |
14:57.50 237 | if SIMD_STRIDE_SIZE <= len {
14:57.50 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:57.50 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.50 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:238:38
14:57.50 |
14:57.50 238 | let len_minus_stride = len - SIMD_STRIDE_SIZE;
14:57.50 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:57.51 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.51 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:241:52
14:57.51 |
14:57.51 241 | let mut second = src.simd_at(offset + (SIMD_STRIDE_SIZE / 2));
14:57.51 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:57.51 error[E0425]: cannot find function `simd_byte_swap` in this scope
14:57.51 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:243:25
14:57.51 |
14:57.51 243 | first = simd_byte_swap(first);
14:57.51 | ^^^^^^^^^^^^^^ not found in this scope
14:57.52 error[E0425]: cannot find function `simd_byte_swap` in this scope
14:57.52 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:244:26
14:57.52 |
14:57.52 244 | second = simd_byte_swap(second);
14:57.52 | ^^^^^^^^^^^^^^ not found in this scope
14:57.52 error[E0425]: cannot find function `simd_is_basic_latin` in this scope
14:57.52 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:246:17
14:57.52 |
14:57.52 246 | if !simd_is_basic_latin(first | second) {
14:57.52 | ^^^^^^^^^^^^^^^^^^^ help: a function with a similar name exists: `ascii_to_basic_latin`
14:57.52 error[E0425]: cannot find function `simd_pack` in this scope
14:57.52 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:249:26
14:57.52 |
14:57.52 249 | let packed = simd_pack(first, second);
14:57.52 | ^^^^^^^^^ not found in this scope
14:57.53 error[E0425]: cannot find function `store16_unaligned` in this scope
14:57.53 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:251:17
14:57.53 |
14:57.53 251 | store16_unaligned(dst.as_mut_ptr().add(offset), packed);
14:57.53 | ^^^^^^^^^^^^^^^^^ not found in this scope
14:57.53 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.53 –> /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:253:23
14:57.53 |
14:57.53 253 | offset += SIMD_STRIDE_SIZE;
14:57.53 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:59.28 error: aborting due to 25 previous errors
14:59.28 Some errors occurred: E0412, E0425, E0432.
14:59.28 For more information about an error, try `rustc –explain E0412`.
14:59.44 error: Could not compile `encoding_rs`.

  Comments (5)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 09.05.2019 19:36

Compilation of firefox continues..

14:59.44 To learn more, run the command again with –verbose.
14:59.45 make[4]: * [/build/firefox/src/mozilla-unified/config/rules.mk:1027: force-cargo-library-build] Error 101
14:59.45 make[3]: * [/build/firefox/src/mozilla-unified/config/recurse.mk:74: toolkit/library/rust/target] Error 2
14:59.45 make[3]: * Waiting for unfinished jobs….
17:24.43 Compiling lalrpop v0.16.0 good build system :->
Admin
Andreas Baumann commented on 09.05.2019 19:38 Let’s see how bad the situation is on pentium4, could easily be Mozilla projects get
build only for pentium4 in the future..
Admin
Andreas Baumann commented on 09.05.2019 19:46 Aha: i686 finally failed: 17:24.43 Compiling lalrpop v0.16.0
21:26.67 Compiling webidl v0.8.0
22:03.14 Compiling binjs_meta v0.4.3
22:25.46 Compiling binast v0.1.1 (/build/firefox/src/mozilla-unified/js/src/frontend/binsource)
22:58.29 Finished release [optimized] target(s) in 17m 41s
22:58.32 make[2]: * [/build/firefox/src/mozilla-unified/config/recurse.mk:34: compile] Error 2
22:58.32 make[1]: * [/build/firefox/src/mozilla-unified/config/rules.mk:415: default] Error 2
22:58.32 make: * [client.mk:125: build] Error 2
22:58.33 0 compiler warnings present.

Admin
Andreas Baumann commented on 10.05.2019 05:59

pentium4 seems to work fine.
Levi commented on 16.05.2019 21:08

So, is this getting dropped for i686 then? Probably no great loss; I remember when I was using a P3 in my server box, I gave up trying to use anything graphical, and just used links when I needed to look something up on t’internet.

I note in the i686 repo there’s currently a firefox 65.x rather than the 66.x we’ve got in pentium4, and some language packs that are 66 and some that are 65. English and all its variants are still on 65.x, but I note that it looks broken to me for German or Finnish users. Time to put it out of its misery?

Google Cache

 2:52.15 error: `[u32; 2]` is forbidden as the type of a const generic parameter
 2:52.15   --> /build/firefox/src/firefox-93.0/third_party/rust/packed_simd/src/codegen/llvm.rs:20:44
 2:52.15    |
 2:52.15 20 | pub unsafe fn __shuffle_vector2<const IDX: [u32; 2], T, U>(x: T, y: T) -> U
 2:52.15    |                                            ^^^^^^^^
 2:52.15    |
 2:52.15    = note: the only supported types are integers, `bool` and `char`
 2:52.15    = help: more complex types are supported with `#![feature(adt_const_params)]`
 2:52.15 error: `[u32; 4]` is forbidden as the type of a const generic parameter
 2:52.15   --> /build/firefox/src/firefox-93.0/third_party/rust/packed_simd/src/codegen/llvm.rs:30:44
 2:52.15    |
 2:52.15 30 | pub unsafe fn __shuffle_vector4<const IDX: [u32; 4], T, U>(x: T, y: T) -> U
 2:52.15    |                                            ^^^^^^^^
 2:52.15    |
 2:52.15    = note: the only supported types are integers, `bool` and `char`
 2:52.15    = help: more complex types are supported with `#![feature(adt_const_params)]`
 2:52.15 error: `[u32; 8]` is forbidden as the type of a const generic parameter
 2:52.15   --> /build/firefox/src/firefox-93.0/third_party/rust/packed_simd/src/codegen/llvm.rs:40:44
 2:52.15    |
 2:52.15 40 | pub unsafe fn __shuffle_vector8<const IDX: [u32; 8], T, U>(x: T, y: T) -> U
 2:52.15    |                                            ^^^^^^^^
 2:52.15    |
 2:52.15    = note: the only supported types are integers, `bool` and `char`
 2:52.15    = help: more complex types are supported with `#![feature(adt_const_params)]`
 2:52.15 error: `[u32; 16]` is forbidden as the type of a const generic parameter
 2:52.15   --> /build/firefox/src/firefox-93.0/third_party/rust/packed_simd/src/codegen/llvm.rs:50:45
 2:52.15    |
 2:52.15 50 | pub unsafe fn __shuffle_vector16<const IDX: [u32; 16], T, U>(x: T, y: T) -> U
 2:52.15    |                                             ^^^^^^^^^
 2:52.15    |
 2:52.15    = note: the only supported types are integers, `bool` and `char`
 2:52.15    = help: more complex types are supported with `#![feature(adt_const_params)]`
 2:52.15 error: `[u32; 32]` is forbidden as the type of a const generic parameter
 2:52.15   --> /build/firefox/src/firefox-93.0/third_party/rust/packed_simd/src/codegen/llvm.rs:60:45
 2:52.15    |
 2:52.15 60 | pub unsafe fn __shuffle_vector32<const IDX: [u32; 32], T, U>(x: T, y: T) -> U
 2:52.15    |                                             ^^^^^^^^^
 2:52.15    |
 2:52.15    = note: the only supported types are integers, `bool` and `char`
 2:52.15    = help: more complex types are supported with `#![feature(adt_const_params)]`
 2:52.15 error: `[u32; 64]` is forbidden as the type of a const generic parameter
 2:52.15   --> /build/firefox/src/firefox-93.0/third_party/rust/packed_simd/src/codegen/llvm.rs:70:45
 2:52.15    |
 2:52.15 70 | pub unsafe fn __shuffle_vector64<const IDX: [u32; 64], T, U>(x: T, y: T) -> U
 2:52.15    |                                             ^^^^^^^^^
 2:52.15    |
 2:52.15    = note: the only supported types are integers, `bool` and `char`
 2:52.15    = help: more complex types are supported with `#![feature(adt_const_params)]`
 2:52.35    Compiling num_cpus v1.13.0
 2:53.13    Compiling fluent-langneg v0.13.0
 2:53.15    Compiling intl_pluralrules v7.0.1
 2:53.59    Compiling intl-memoizer v0.5.1
 2:55.32    Compiling gl_generator v0.14.0
 2:55.37    Compiling cose-c v0.1.5
 2:55.96    Compiling time v0.1.43
 2:56.01    Compiling iovec v0.1.4
 2:56.05    Compiling atty v0.2.14
 2:56.21 For more information about this error, try `rustc --explain E0557`.
 2:56.23    Compiling net2 v0.2.37
 2:56.24 The following warnings were emitted during compilation:
 2:56.25 warning: Cannot set `RUSTC_BOOTSTRAP=1` from build script of `packed_simd v0.3.4 (https://github.com/hsivonen/packed_simd?rev=6a16f954950401b92b4e220fbf2dfaf6f00e1fb2#6a16f954)`.
 2:56.25 note: Crates cannot set `RUSTC_BOOTSTRAP` themselves, as doing so would subvert the stability guarantees of Rust for your project.
 2:56.25 error: could not compile `packed_simd` due to 13 previous errors
 2:56.25 warning: build failed, waiting for other jobs to finish...
 3:17.66 error: build failed

Again, we get into out-of-memory situations with rust:

pentium4
41:24.75   cargo:warning=src/vector_type.h:502:11: warning: ‘void* memcpy(void*, const void*, size_t)’ writing to an object of type ‘struct glsl::vec4’ with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]
41:24.75   cargo:warning=  502 |     memcpy(&v, p, sizeof(v));
41:24.75   cargo:warning=      |     ~~~~~~^~~~~~~~~~~~~~~~~~
41:24.75   cargo:warning=In file included from src/gl.cc:78:
41:24.75   cargo:warning=src/glsl.h:1772:8: note: ‘struct glsl::vec4’ declared here
41:24.75   cargo:warning= 1772 | struct vec4 {
41:24.75   cargo:warning=      |        ^~~~
41:24.75   cargo:warning=
41:24.75   cargo:warning=cc1plus: out of memory allocating 21906724 bytes after a total of 213745664 bytes

i686
 6:42.75    Compiling geckoservo v0.0.1 (/build/firefox/src/firefox-87.0/servo/ports/geckolib)
Process Process-1:
Traceback (most recent call last):
  File "/usr/lib/python3.9/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/lib/python3.9/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/build/firefox/src/firefox-87.0/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py", line 141, in _collect
    while not _poll(pipe, poll_interval=sleep_interval):
  File "/build/firefox/src/firefox-87.0/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py", line 107, in _poll
    return pipe.poll(poll_interval)
  File "/usr/lib/python3.9/multiprocessing/connection.py", line 262, in poll
    return self._poll(timeout)
  File "/usr/lib/python3.9/multiprocessing/connection.py", line 429, in _poll
    r = wait([self], timeout)
  File "/usr/lib/python3.9/multiprocessing/connection.py", line 936, in wait
    ready = selector.select(timeout)
  File "/usr/lib/python3.9/selectors.py", line 416, in select
    fd_event_list = self._selector.poll(timeout)
KeyboardInterrupt
52:46.35 make[4]: *** [/build/firefox/src/firefox-87.0/config/makefiles/rust.mk:348: force-cargo-library-build] Interrupt
52:46.35 make[3]: *** [/build/firefox/src/firefox-87.0/config/recurse.mk:72: toolkit/library/rust/target] Interrupt
52:46.35 make[2]: *** [/build/firefox/src/firefox-87.0/config/recurse.mk:34: compile] Interrupt
52:46.35 make[1]: *** [/build/firefox/src/firefox-87.0/config/rules.mk:355: default] Interrupt

Rust is 1.51.0 on both pentium4 and i686.