Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Sat, Dec 11, 2021 at 7:04 PM Riccardo Mottola 
wrote:

> Hi,
>
> commenting to this topic. I was able to first fix and then upgrade my
> faitfhul Ultra 2 (*). Equipped now with 2x 396 MHz processors and 1GB of
> RAM, running NetBSD 9 I could for the first time "dare" to install firefox
> 52 esr, with all the patches done for it by Martin. I am quite impressed:
> it has no immediately apparent Endianness issues and is capable of browsing
> without crashing, even performance is acceptable, although of course JS
> itself is slow. I cannot fully assert speed, since current versions of Xorg
> are quite slow on the Creator card, as if it running without even 2D
> acceleration (moving and scrolling is bad, but even with xterm). Images,
> fonts, interface all display fine. The only broken thing are image
> operations, but this is a long-standing issue that affects also ArcticFox.
> So all-in-all that FF version is more modern than AF39 and has no more
> issue (compared to non-patched official releases).
> I did not find any rust-basef FFs in NetBSD packages, so I couldn't
> compare.
>
> Riccardo
>
>
Hello Riccardo,

yes the FF52 on NetBSD/pkgsrc/sparc64 runs very well... also you can
install or compile a slightly older seamonkey..2.49 if i remember
correctly. Then again there is no libreoffice on NetBSD/sparc64 and also
some other stuff is missing that is available on debian.

qt stuff has broken dependencies on debian and also some stuff is missing
that is present in pkgsrc, which is why i use pkgsrc also on debian to
complete the software collection. However the Mozilla software in pkgsrc (
firefox 52,  seamonkey, thunderbird) is not compiling out of box on debian
and even if you make it compile, the patches in pkgsrc are not taking linux
into account it seems and in the end they will not run. I also don't know
how to make debugging possible on pkgsrc with those..gdb will not give any
info why and where the bus errors happen.

On debian i can either run a slightly older version of libreoffice where
all dependencies are available from snapshot.debian.org or i can compile
the latest version from pkgsrc when i patch pkgsrc to remove the rustc
dependencies everywhere so that it will use the debian provided rustc
during compiling.
The latest firefox working from debian repos is firefox 50.1.0, but it is
less stable than ff52 on NetBSD and has more problems like not saving
certain settings when i activate and modify toolbars.

Linux runs more software but is generally less stable for me than NetBSD on
my machines. I have very strange issues with filesystems where checking
them will occasionally destroy critical parts of the filesystems. I fixed
it it somewhat by using xfs and booting up with read-only filesystems. Then
i execute a few runs of xfs_repair -n on them until i get a stable result.
Then i can remount to rw and use the systems. Pretty annoying but works
reliably.
Another problem is that i have issues with mouse and keyboard on my Ultra
25 on certain kernels. 5.2, 5.6, 5.8 will work for example and a 4.19 or
5.10 kernel will not.

Regards,
Connor

Re: Mozilla Software on Sparc64/Linux

[Riccardo Mottola]

Hi,

commenting to this topic. I was able to first fix and then upgrade my faitfhul 
Ultra 2 (*). Equipped now with 2x 396 MHz processors and 1GB of RAM, running 
NetBSD 9 I could for the first time "dare" to install firefox 52 esr, with all 
the patches done for it by Martin. I am quite impressed: it has no immediately 
apparent Endianness issues and is capable of browsing without crashing, even 
performance is acceptable, although of course JS itself is slow. I cannot fully 
assert speed, since current versions of Xorg are quite slow on the Creator 
card, as if it running without even 2D acceleration (moving and scrolling is 
bad, but even with xterm). Images, fonts, interface all display fine. The only 
broken thing are image operations, but this is a long-standing issue that 
affects also ArcticFox. So all-in-all that FF version is more modern than AF39 
and has no more issue (compared to non-patched official releases).
I did not find any rust-basef FFs in NetBSD packages, so I couldn't compare.

My only comparison is recent Firefox on Debian running on 64Bit ppc and that 
one is unusable with a broken interface and incredible slowness, but didn't 
test it on SPARC, I only have my T2000 running and I guess that on NIagara it 
could take minutes just to start! Should ? (however since it has e10s, t should 
be able to exploit the multi-cores later on)

Riccardo


(*) Some story of the breakage which might be of interest for others running 
vintage Sun hardware.
The machine first smoked badly that I feared a broken MB and PSU! But by 
careful disassembly I was able to determine that the disk drive was so badly 
shorted that it brought down everything. Put hot-swap in a server it did shut 
it down immediatley! Fixed that… it would not boot and die during POST! Damage? 
I was worried. But no - the NVRAM chip was so "dead". With a dead battery the 
computer usually comes up, here not. I got a new chip and with that one it the 
computer starts perfectly! I don't know if it was damaged by the power issues 
or died…

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Wed, Dec 1, 2021 at 12:14 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 11/30/21 23:30, Connor McLaughlan wrote:
> > Since i am using gcc-10 for this build, i wonder if it is the same
> problem
> > and could be fixed by adding - where applicable:
> >
> > #include 
>
> Yes, that sounds reasonable. Just try it.
>
> > Or is it advised to install a lower gcc for the build? If so, which one?
>
> No, that's too much of a hassle. I would advise against that.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>
Hello Adrian,

/toolkit/components/telemetry/ProcessedStack.cpp compiled ok when the
include was added.

Now i am stuck at this new error below.
Unfortunately i can't find something helpful on the internet.

/usr/bin/g++ -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers
-Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits
-Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++1z-compat
-Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized
-Wno-error=deprecated-declarations -Wno-error=array-bounds
-Wno-error=free-nonheap-object -Wno-error=multistatement-macros
-Wno-error=class-memaccess -Wformat -Wformat-overflow=2
-fno-sized-deallocation -fstack-protector-strong -Wformat
-Werror=format-security -fno-schedule-insns2 -fno-lifetime-dse
-fno-delete-null-pointer-checks -fpermissive -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti
-ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno
-pthread -pipe -g -freorder-blocks -O2 -fomit-frame-pointer  -fPIC -shared
-Wl,-z,defs -Wl,--gc-sections -Wl,-h,libxul.so -o libxul.so
/<>/build-browser/toolkit/library/libxul_so.list  -lpthread
-Wl,--as-needed -Wl,--reduce-memory-overheads -Wl,--no-keep-memory
-Wl,--stats -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,--build-id
/<>/toolkit/library/StaticXULComponents.ld
-Wl,-rpath-link,/<>/build-browser/dist/bin
-Wl,-rpath-link,/usr/lib   ../../js/src/build/libjs_static.a
sparc64-unknown-linux-gnu/release/libgkrust.a
../../config/external/lgpllibs/liblgpllibs.so
../../widget/gtk/mozgtk/stub/libmozgtk_stub.so
-Wl,--version-script,symverscript  -ldl  -ljsoncpp -lffi
-L/usr/lib/sparc64-linux-gnu -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lz -lm
-Wl,-rpath-link,/usr/lib/sparc64-linux-gnu -lssl3 -lsmime3 -lnss3
-lnssutil3 -lsqlite3 -lfreetype -lfontconfig -lrt -lXrender -levent -lvpx
-lasound -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0 -lpangocairo-1.0
-lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0
-lgio-2.0 -lstartup-notification-1 -lX11-xcb -lxcb-shm -lxcb -lX11 -lXext
-lpangoft2-1.0 -lXt -lgthread-2.0
/usr/bin/ld: warning:
/<>/toolkit/library/StaticXULComponents.ld contains output
sections; did you forget -T?
/usr/bin/ld:
/<>/build-browser/toolkit/library/../../gfx/vr/openvr/vrpathregistry_public.o:
in function
`ParseStringListFromJson(std::vector, std::allocator >,
std::allocator,
std::allocator > > >*, Json::Value const&, char const*) [clone
.part.0]':
/<>/gfx/vr/openvr/src/vrpathregistry_public.cpp:160: undefined
reference to `Json::Value::operator!() const'
collect2: error: ld returned 1 exit status
make[5]: *** [/<>/config/rules.mk:681: libxul.so] Error 1
make[5]: Leaving directory '/<>/build-browser/toolkit/library'
make[4]: *** [/<>/config/recurse.mk:74:
toolkit/library/target] Error 2
make[4]: Leaving directory '/<>/build-browser'
make[3]: *** [/<>/config/recurse.mk:34: compile] Error 2
make[3]: Leaving directory '/<>/build-browser'
make[2]: *** [/<>/config/rules.mk:418: default] Error 2
make[2]: Leaving directory '/<>/build-browser'
dh_auto_build: error: cd build-browser && make -j1
LD_LIBS=-Wl,--no-gc-sections _LEAKTEST_FILES=leaktest.py returned exit code
2
make[1]: *** [debian/rules:216: stamps/build-browser] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:321: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2

Build finished at 2021-12-02T00:05:14Z


Regards,
Connor

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

On 11/30/21 23:30, Connor McLaughlan wrote:
> Since i am using gcc-10 for this build, i wonder if it is the same problem
> and could be fixed by adding - where applicable:
> 
> #include 

Yes, that sounds reasonable. Just try it.

> Or is it advised to install a lower gcc for the build? If so, which one?

No, that's too much of a hassle. I would advise against that.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Tue, Nov 30, 2021 at 11:25 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hi Conner!
>
> On 11/30/21 23:19, Connor McLaughlan wrote:
> > For the last error, i applied a quick and dirty fix i found here - for
> > compiling problems with nss 3.66:
> > https://bugs.archlinux.org/task/71113
>
> Sorry for not being able to respond the past days, I was busy with other
> software issues, both in Debian and my dayjob. I will start looking into
> this later this week.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>
Hello Adrian,

i just did some research on the last error i reported - it seems to be
caused by compiler changes:
/<>/toolkit/components/telemetry/ProcessedStack.cpp:92:30:
error: ‘numeric_limits’ is not a member of ‘std’

I found it reported for when gcc-11 is used here:
https://github.com/MultiMC/Launcher/issues/3574

Since i am using gcc-10 for this build, i wonder if it is the same problem
and could be fixed by adding - where applicable:

#include 

Or is it advised to install a lower gcc for the build? If so, which one?

Regards,
Connor

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hi Conner!

On 11/30/21 23:19, Connor McLaughlan wrote:
> For the last error, i applied a quick and dirty fix i found here - for
> compiling problems with nss 3.66:
> https://bugs.archlinux.org/task/71113

Sorry for not being able to respond the past days, I was busy with other
software issues, both in Debian and my dayjob. I will start looking into
this later this week.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

>
>
> Hello Adrian,
>
> update on the current progress:
>
> rustc_1.30.0, rustc_1.31.0 and rustc_1.32.0 are crashing on my machine
> during configure or later during rust building.
> rustc_1.33.0 and rustc_1.35.0 seem to work, so when went with
> rustc_1.35.0, since rustc_1.33.0 has the same constraints with missing_docs
> in place.
> llvm stayed at 11 for now.
>
> As stated above i removed #![deny(missing_docs)] from
> servo/components/style/lib.rs and servo/components/style_traits/lib.rs
> The rust part compiled without errors it seems (unsure if a second rust
> part is coming later in the build).
>
> Now after 14 hours of compile time the errors below will appear.
> Have to search if there is a known solution.
>
> However this is now getting somewhat tedious as it seems that i can not
> just apply a change and test it by continuing the build.
> sbuild will always start the building from scratch.
>
> Is there a way around restarting the whole build?
>
> Regards,
> Connor
>
>
>
For the last error, i applied a quick and dirty fix i found here - for
compiling problems with nss 3.66:
https://bugs.archlinux.org/task/71113

Now i have gotten the following error thrown:

/usr/bin/g++ -o ProcessedStack.o -c
-I/<>/build-browser/dist/stl_wrappers
-I/<>/build-browser/dist/system_wrappers -include
/<>/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DOS_POSIX=1
-DOS_LINUX=1 '-DMOZ_APP_VERSION="62.0.3"' -DSTATIC_EXPORTABLE_JS_API
-DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL
-I/<>/toolkit/components/telemetry
-I/<>/build-browser/toolkit/components/telemetry
-I/<>/build-browser/ipc/ipdl/_ipdlheaders
-I/<>/ipc/chromium/src -I/<>/ipc/glue
-I/<>/xpcom/build -I/<>/xpcom/threads
-I/<>/build-browser/dist/include -I/usr/include/nspr
-I/usr/include/nss -fPIC -DMOZILLA_CLIENT -include
/<>/build-browser/mozilla-config.h -Wdate-time
-D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall
-Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith
-Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings
-Wno-invalid-offsetof -Wc++1z-compat -Wduplicated-cond
-Wimplicit-fallthrough -Wno-error=maybe-uninitialized
-Wno-error=deprecated-declarations -Wno-error=array-bounds
-Wno-error=free-nonheap-object -Wno-error=multistatement-macros
-Wno-error=class-memaccess -Wformat -Wformat-overflow=2
-fno-sized-deallocation -fstack-protector-strong -Wformat
-Werror=format-security -fno-schedule-insns2 -fno-lifetime-dse
-fno-delete-null-pointer-checks -fpermissive -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti
-ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno
-pthread -pipe -g -freorder-blocks -O2 -fomit-frame-pointer
-Wno-error=shadow  -MD -MP -MF .deps/ProcessedStack.o.pp
/<>/toolkit/components/telemetry/ProcessedStack.cpp
/<>/toolkit/components/telemetry/ProcessedStack.cpp: In
function ‘mozilla::Telemetry::ProcessedStack
mozilla::Telemetry::GetStackAndModules(const std::vector&)’:
/<>/toolkit/components/telemetry/ProcessedStack.cpp:92:30:
error: ‘numeric_limits’ is not a member of ‘std’
   92 | std::numeric_limits::max()};
  |  ^~
/<>/toolkit/components/telemetry/ProcessedStack.cpp:92:53:
error: expected primary-expression before ‘>’ token
   92 | std::numeric_limits::max()};
  | ^
/<>/toolkit/components/telemetry/ProcessedStack.cpp:92:56:
error: ‘::max’ has not been declared; did you mean ‘std::max’?
   92 | std::numeric_limits::max()};
  |^~~
  |std::max
In file included from /usr/include/c++/11/algorithm:62,
 from
/<>/build-browser/dist/system_wrappers/algorithm:3,
 from
/<>/build-browser/dist/stl_wrappers/algorithm:44,
 from
/<>/build-browser/dist/include/mozilla/Span.h:31,
 from
/<>/build-browser/dist/include/nsTSubstring.h:16,
 from
/<>/build-browser/dist/include/nsAString.h:22,
 from
/<>/build-browser/dist/include/nsString.h:14,
 from
/<>/toolkit/components/telemetry/ProcessedStack.h:11,
 from
/<>/toolkit/components/telemetry/ProcessedStack.cpp:7:
/usr/include/c++/11/bits/stl_algo.h:3467:5: note: ‘std::max’ declared here
 3467 | max(initializer_list<_Tp> __l, _Compare __comp)
  | ^~~
make[5]: *** [/<>/config/rules.mk:1033: ProcessedStack.o]
Error 1
make[5]: Leaving directory
'/<>/build-browser/toolkit/components/telemetry'
make[4]: *** [/<>/config/recurse.mk:74:
toolkit/components/telemetry/target] Error 2
make[4]: Leaving directory '/<>/build-browser'
make[3]: *** [/<>/config/recurse.mk:34: compile] Error 2
make[3]: Leaving directory '/<>/build-browser'
make[2]: *** [/<>/config/rules.mk:418: default] Error 2
make[2]: Leaving 

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Thu, Nov 25, 2021 at 6:31 PM Connor McLaughlan 
wrote:

>
> Hello Adrian,
>
> both rustc 1.31 and 1.32 fail during configure:
>
> checking rustc version... 1.32.0
> checking cargo version... 1.31.0
> DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib
> --target=sparc64-unknown-linux-gnu -o /tmp/conftestz9qzPs.rlib
> /tmp/conftestveP467.rs`
> DEBUG: The command returned non-zero exit status 101.
> DEBUG: Its error output was:
> DEBUG: | thread 'main' panicked at 'specified instant was later than
> self', src/libstd/sys/unix/time.rs:298:17
> DEBUG: | note: Run with `RUST_BACKTRACE=1` for a backtrace.
> DEBUG: |
> DEBUG: | error: internal compiler error: unexpected panic
> DEBUG: |
> DEBUG: | note: the compiler unexpectedly panicked. this is a bug.
> DEBUG: |
> DEBUG: | note: we would appreciate a bug report:
> https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
> DEBUG: |
> DEBUG: | note: rustc 1.32.0 running on sparc64-unknown-linux-gnu
> DEBUG: |
> DEBUG: | note: compiler flags: --crate-type staticlib
> DEBUG: |
> ERROR: Cannot compile for sparc64-unknown-linux-gnu with /usr/bin/rustc
> The target may be unsupported, or you may not have
> a rust std library for that target installed. Try:
>
>   rustup target add sparc64-unknown-linux-gnu
>
> make[1]: *** [debian/rules:205: stamps/configure-browser] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:321: build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
> status 2
>
> 
> Build finished at 2021-11-25T17:02:23Z
>
>
> I suppose sbuild cleans everything between builds..or do i need to clean
> something?
>
> Otherwise i will go higher or back to rustc 1.35 which worked well and try
> to comment out the restriction with the documentation:
>
> "To build with current Rust, you also need to remove
> #![deny(missing_docs)] from servo/components/style/lib.rs and
> servo/components/style_traits/lib.rs."
>
>
> Regards,
> Connor
>
>

Hello Adrian,

update on the current progress:

rustc_1.30.0, rustc_1.31.0 and rustc_1.32.0 are crashing on my machine
during configure or later during rust building.
rustc_1.33.0 and rustc_1.35.0 seem to work, so when went with rustc_1.35.0,
since rustc_1.33.0 has the same constraints with missing_docs in place.
llvm stayed at 11 for now.

As stated above i removed #![deny(missing_docs)] from
servo/components/style/lib.rs and servo/components/style_traits/lib.rs
The rust part compiled without errors it seems (unsure if a second rust
part is coming later in the build).

Now after 14 hours of compile time the errors below will appear.
Have to search if there is a known solution.

However this is now getting somewhat tedious as it seems that i can not
just apply a change and test it by continuing the build.
sbuild will always start the building from scratch.

Is there a way around restarting the whole build?

Regards,
Connor

/usr/bin/g++ -o UnifiedBindings8.o -c
-I/<>/build-browser/dist/stl_wrappers
-I/<>/build-browser/dist/system_wrappers -include
/<>/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1
-DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER
-DOS_POSIX=1 -DOS_LINUX=1 -DHAVE_SIDEBAR -DSTATIC_EXPORTABLE_JS_API
-DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL
-I/<>/dom/bindings
-I/<>/build-browser/dom/bindings
-I/<>/build-browser/dist/include/mozilla/dom
-I/<>/dom/base -I/<>/dom/battery
-I/<>/dom/canvas -I/<>/dom/geolocation
-I/<>/dom/html -I/<>/dom/indexedDB
-I/<>/dom/media/webaudio
-I/<>/dom/media/webspeech/recognition
-I/<>/dom/svg -I/<>/dom/xbl
-I/<>/dom/xml -I/<>/dom/xslt/base
-I/<>/dom/xslt/xpath -I/<>/dom/xul
-I/<>/js/xpconnect/src
-I/<>/js/xpconnect/wrappers -I/<>/layout/generic
-I/<>/layout/style -I/<>/layout/xul/tree
-I/<>/media/mtransport -I/<>/media/webrtc
-I/<>/media/webrtc/signaling/src/common/time_profiling
-I/<>/media/webrtc/signaling/src/peerconnection
-I/<>/media/webrtc/trunk
-I/<>/build-browser/ipc/ipdl/_ipdlheaders
-I/<>/ipc/chromium/src -I/<>/ipc/glue
-I/<>/build-browser/dist/include -I/usr/include/nspr
-I/usr/include/nss -fPIC -DMOZILLA_CLIENT -include
/<>/build-browser/mozilla-config.h -Wdate-time
-D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall
-Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith
-Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings
-Wno-invalid-offsetof -Wc++1z-compat -Wduplicated-cond
-Wimplicit-fallthrough -Wno-error=maybe-uninitialized
-Wno-error=deprecated-declarations -Wno-error=array-bounds
-Wno-error=free-nonheap-object -Wno-error=multistatement-macros
-Wno-error=class-memaccess -Wformat -Wformat-overflow=2
-fno-sized-deallocation -fstack-protector-strong -Wformat
-Werror=format-security -fno-schedule-insns2 -fno-lifetime-dse
-fno-delete-null-pointer-checks -fpermissive -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Tue, Nov 23, 2021 at 10:56 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hi!
>
> On 11/23/21 22:34, Connor McLaughlan wrote:
> > Should i go up or down with the rustc version?
>
> You need to go down since you need a Rust version that is less strict
> with macros.
>
> > Or is there another way to fix it?
>
> As I said, the best way is to work on the NodeJS workaround that the
> Solaris
> developers are using. I might write something down for that tomorrow and
> then
> you can try whether you can get it working.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>
Hello Adrian,

both rustc 1.31 and 1.32 fail during configure:

checking rustc version... 1.32.0
checking cargo version... 1.31.0
DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib
--target=sparc64-unknown-linux-gnu -o /tmp/conftestz9qzPs.rlib
/tmp/conftestveP467.rs`
DEBUG: The command returned non-zero exit status 101.
DEBUG: Its error output was:
DEBUG: | thread 'main' panicked at 'specified instant was later than self',
src/libstd/sys/unix/time.rs:298:17
DEBUG: | note: Run with `RUST_BACKTRACE=1` for a backtrace.
DEBUG: |
DEBUG: | error: internal compiler error: unexpected panic
DEBUG: |
DEBUG: | note: the compiler unexpectedly panicked. this is a bug.
DEBUG: |
DEBUG: | note: we would appreciate a bug report:
https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
DEBUG: |
DEBUG: | note: rustc 1.32.0 running on sparc64-unknown-linux-gnu
DEBUG: |
DEBUG: | note: compiler flags: --crate-type staticlib
DEBUG: |
ERROR: Cannot compile for sparc64-unknown-linux-gnu with /usr/bin/rustc
The target may be unsupported, or you may not have
a rust std library for that target installed. Try:

  rustup target add sparc64-unknown-linux-gnu

make[1]: *** [debian/rules:205: stamps/configure-browser] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:321: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2

Build finished at 2021-11-25T17:02:23Z


I suppose sbuild cleans everything between builds..or do i need to clean
something?

Otherwise i will go higher or back to rustc 1.35 which worked well and try
to comment out the restriction with the documentation:

"To build with current Rust, you also need to remove #![deny(missing_docs)]
from servo/components/style/lib.rs and servo/components/style_traits/lib.rs
."


Regards,
Connor

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hi!

On 11/23/21 22:34, Connor McLaughlan wrote:
> Should i go up or down with the rustc version?

You need to go down since you need a Rust version that is less strict
with macros.

> Or is there another way to fix it?

As I said, the best way is to work on the NodeJS workaround that the Solaris
developers are using. I might write something down for that tomorrow and then
you can try whether you can get it working.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Mon, Nov 22, 2021 at 9:30 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 11/21/21 22:37, Connor McLaughlan wrote:
> > Now it compiles unicode-xid v.0.1.0, but crashes at libc v0.2.39:
> > make[5]: Entering directory
>
> Try building with a slightly newer rustc version or use LLVM-6.0 instead
> as originally intended.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>
Hello Adrian,

i now used rustc version... 1.35.0, cargo version... 1.34.0 and it went
much further and compiled many rust targets.

It stopped at:

  Compiling style_traits v0.0.1
(/<>/servo/components/style_traits)
error: missing documentation for macro
   --> servo/components/style_traits/values.rs:142:1
|
142 | macro_rules! serialize_function {
| ^^^
|
note: lint level defined here
   --> servo/components/style_traits/lib.rs:12:22
|
12  | #![deny(unsafe_code, missing_docs)]
|  
error: missing documentation for macro
   --> servo/components/style_traits/values.rs:414:1
|
414 | macro_rules! define_css_keyword_enum {
| 
error: aborting due to 2 previous errors
error: Could not compile `style_traits`.

Should i go up or down with the rustc version? Or is there another way to
fix it?

Regards,
Connor

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

On 11/21/21 22:37, Connor McLaughlan wrote:
> Now it compiles unicode-xid v.0.1.0, but crashes at libc v0.2.39:
> make[5]: Entering directory

Try building with a slightly newer rustc version or use LLVM-6.0 instead
as originally intended.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Sun, Nov 21, 2021 at 6:29 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hello!
>
> On 11/21/21 04:17, Connor McLaughlan wrote:
> >Compiling unicode-xid v0.1.0
> > error: Unrecognized option: 'json'
> >
> > error: could not compile `unicode-xid`
>
> You need to downgrade cargo to 0.29.0-1:
>
> > http://snapshot.debian.org/package/cargo/0.29.0-1/#cargo_0.29.0-1
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>
Hello Adrian,

i installed cargo 0.29.0-1:
root@SunUltra25:/# aptitude versions cargo
Warning: Invalid locale (please review locale settings, this might lead to
problems later):
  locale::facet::_S_create_c_locale name not valid
i   0.29.0-1

   100
p   0.57.0-3
  unstable
500

Strangely it gets reported as 1.28 during configure - but well:
checking for rustc... /usr/bin/rustc
checking for cargo... /usr/bin/cargo
checking rustc version... 1.29.0
checking cargo version... 1.28.0

Now it compiles unicode-xid v.0.1.0, but crashes at libc v0.2.39:
make[5]: Entering directory
'/<>/build-browser/toolkit/library/rust'
force-cargo-library-build
env   RUSTFLAGS='-C opt-level=2 -C debuginfo=2 '
 CARGO_TARGET_DIR=/<>/build-browser/toolkit/library
RUSTC=/usr/bin/rustc RUSTDOC=/usr/bin/rustdoc MOZ_SRC=/<>
MOZ_DIST=/<>/build-browser/dist
LIBCLANG_PATH="/usr/lib/llvm-11/lib"
CLANG_PATH="/usr/lib/llvm-11/bin/clang" PKG_CONFIG_ALLOW_CROSS=1
RUST_BACKTRACE=full MOZ_TOPOBJDIR=/<>/build-browser
 MOZ_CARGO_WRAP_LDFLAGS="-lpthread -Wl,--as-needed
-Wl,--reduce-memory-overheads -Wl,--no-keep-memory -Wl,--stats
-Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,--build-id
-Wl,-rpath-link,/<>/build-browser/dist/bin
-Wl,-rpath-link,/usr/lib" MOZ_CARGO_WRAP_LD=" /usr/bin/gcc -std=gnu99"
CARGO_TARGET_SPARC64_UNKNOWN_LINUX_GNU_LINKER=/<>/build/cargo-linker
/usr/bin/cargo rustc  --release --frozen --manifest-path
/<>/toolkit/library/rust/Cargo.toml --lib
--target=sparc64-unknown-linux-gnu --features "servo bindgen quantum_render
cubeb_pulse_rust cubeb-remoting moz_memory" --  -C lto
   Compiling unicode-xid v0.1.0
   Compiling siphasher v0.2.1
   Compiling libc v0.2.39
thread 'main' panicked at 'specified instant was later than self',
libstd/sys/unix/time.rs:292:17
stack backtrace:
   0: 0xfff10059e81b -
rust_metadata_std_495c22e44ed0c1b01a54db1d43dc4cfc
   1: 0xfff10056966b -
rust_metadata_std_495c22e44ed0c1b01a54db1d43dc4cfc
   2: 0xfff1005adf2f -
rust_metadata_std_495c22e44ed0c1b01a54db1d43dc4cfc
   3: 0xfff1005adaf7 -
rust_metadata_std_495c22e44ed0c1b01a54db1d43dc4cfc
   4: 0xfff1005a9e4b -
rust_metadata_std_495c22e44ed0c1b01a54db1d43dc4cfc
   5: 0xfff1038bbe9f - 
   6: 0xfff103649f3f - 
   7: 0xfff1005ae927 -
std::panicking::rust_panic_with_hook::h8a42f1f698beebb2
   8: 0xfff1005ae65f -
rust_metadata_std_495c22e44ed0c1b01a54db1d43dc4cfc
   9: 0xfff1005822bb -
rust_metadata_std_495c22e44ed0c1b01a54db1d43dc4cfc
  10: 0xfff100573a73 - std::time::Instant::elapsed::hecaa22291126e88e
  11: 0xfff1009c2bfb - 
  12: 0xfff1009e4daf - 
  13: 0xfff103482f87 - 
  14: 0xfff1033694a7 - 
  15: 0xfff1030a328b -
rust_metadata_rustc_a73bbf9616326d00f8c80ec67817568c
  16: 0xfff1032d955b -
rust_metadata_rustc_a73bbf9616326d00f8c80ec67817568c
  17: 0xfff1034a84bf -Compiling unicode-xid v0.1.0
   Compiling siphasher v0.2.1

  18: 0xfff10352179f - 
  19: 0xfff1035ebf17 - rustc::ty::query::>::symbol_name::hf254445141a56f8d
  20: 0xfff105c08e0f - 
  21: 0xfff105bf2f23 - 
  22: 0xfff105b63a93 - 
  23: 0xfff105c1638f - 
  24: 0xfff103485747 - 
  25: 0xfff10336a0db - 
  26: 0xfff1030ae7a7 -
rust_metadata_rustc_a73bbf9616326d00f8c80ec67817568c
  27: 0xfff10334946b - 
  28: 0xfff1034ba2f3 - 
  29: 0xfff10351ea0b - 
  30: 0xfff1035ecb7b - rustc::ty::query::>::collect_and_partition_mono_items::h8d5c5762b2e3f51a
  31: 0xfff105c1bba7 - ::codegen_crate::hc83533030405993f
  32: 0xfff10021eb03 - 
  33: 0xfff10021331b -
rustc_driver::driver::phase_4_codegen::heaf479227585b87b
  34: 0xfff1002ed573 - 
  35: 0xfff1002e7e8f - 
  36: 0xfff100282d03 - 
  37: 0xfff100314e5b - 
  38: 0xfff10020b47b -
rustc_driver::driver::compile_input::h8fc997d3d02841ae
  39: 0xfff1002f342f - 
  40: 0xfff1001c482b - 
  41: 0xfff1001c458b - 
  42: 0xfff10029849f - 
  43: 0xfff1001c2d3f - 
  44: 0xfff1002d39b3 - 
  45: 0xfff1005b7fcb - __rust_maybe_catch_panic
  46: 0xfff1002ef8bb - 
  47: 0xfff1003003c7 - rustc_driver::main::h518b3d26bef3a0dc
  48:  0x1000ccf - 
  49:  0x1000c97 - 
  50: 0xfff10056a213 -
rust_metadata_std_495c22e44ed0c1b01a54db1d43dc4cfc
  51: 0xfff1005ae1af -
rust_metadata_std_495c22e44ed0c1b01a54db1d43dc4cfc
  52: 

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hello!

On 11/21/21 04:17, Connor McLaughlan wrote:
>Compiling unicode-xid v0.1.0
> error: Unrecognized option: 'json'
> 
> error: could not compile `unicode-xid`

You need to downgrade cargo to 0.29.0-1:

> http://snapshot.debian.org/package/cargo/0.29.0-1/#cargo_0.29.0-1

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Sat, Nov 20, 2021 at 9:56 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 11/20/21 21:34, Connor McLaughlan wrote:
> > However when i execute sbuild, 1.29 gets replaced with 1.56
> automatically:
> >
> > Selecting previously unselected package libstd-rust-1.56:sparc64.
> > Preparing to unpack .../12-libstd-rust-1.56_1.56.0+dfsg1-2_sparc64.deb
> ...
> > Unpacking libstd-rust-1.56:sparc64 (1.56.0+dfsg1-2) ...
> > Preparing to unpack .../13-rustc_1.56.0+dfsg1-2_sparc64.deb ...
> > Unpacking rustc (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1) ...
> > Preparing to unpack .../14-libstd-rust-dev_1.56.0+dfsg1-2_sparc64.deb ...
> > Unpacking libstd-rust-dev:sparc64 (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1)
> ...
> >
> > How do i prevent it?
> >
> > Do i need to modify control.in and set it to 1.29 exactly:
> >
> > rustc (>= 1.24) -> rustc (= 1.29)
>
> Run sbuild with "--no-apt-upgrade --no-apt-distupgrade".
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>
With rustc 1.29 it fails in unicode-xid v.0.1.0 which i think is one of the
first or the first rust target.
I have not seen another "Compiling ..." statement before it.

The error:

make[5]: Leaving directory '/<>/build-browser/security'
make[5]: Entering directory
'/<>/build-browser/toolkit/library/gtest/rust'
make[5]: Nothing to be done for 'target'.
make[5]: Leaving directory
'/<>/build-browser/toolkit/library/gtest/rust'
make[5]: Entering directory
'/<>/build-browser/toolkit/library/rust'
force-cargo-library-build
env   RUSTFLAGS='-C opt-level=2 -C debuginfo=2 '
 CARGO_TARGET_DIR=/<>/build-browser/toolkit/library
RUSTC=/usr/bin/rustc RUSTDOC=/usr/bin/rustdoc MOZ_SRC=/<>
MOZ_DIST=/<>/build-browser/dist
LIBCLANG_PATH="/usr/lib/llvm-11/lib"
CLANG_PATH="/usr/lib/llvm-11/bin/clang" PKG_CONFIG_ALLOW_CROSS=1
RUST_BACKTRACE=full MOZ_TOPOBJDIR=/<>/build-browser
 MOZ_CARGO_WRAP_LDFLAGS="-lpthread -Wl,--as-needed
-Wl,--reduce-memory-overheads -Wl,--no-keep-memory -Wl,--stats
-Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,--build-id
-Wl,-rpath-link,/<>/build-browser/dist/bin
-Wl,-rpath-link,/usr/lib" MOZ_CARGO_WRAP_LD=" /usr/bin/gcc -std=gnu99"
CARGO_TARGET_SPARC64_UNKNOWN_LINUX_GNU_LINKER=/<>/build/cargo-linker
/usr/bin/cargo rustc  --release --frozen --manifest-path
/<>/toolkit/library/rust/Cargo.toml --lib
--target=sparc64-unknown-linux-gnu --features "servo bindgen quantum_render
cubeb_pulse_rust cubeb-remoting moz_memory" --  -C lto
   Compiling unicode-xid v0.1.0
error: Unrecognized option: 'json'

error: could not compile `unicode-xid`
make[5]: *** [/<>/config/rules.mk:951:
force-cargo-library-build] Error 101
make[5]: Leaving directory
'/<>/build-browser/toolkit/library/rust'
make[4]: *** [/<>/config/recurse.mk:74:
toolkit/library/rust/target] Error 2
make[4]: Leaving directory '/<>/build-browser'
make[3]: *** [/<>/config/recurse.mk:34: compile] Error 2
make[3]: Leaving directory '/<>/build-browser'
make[2]: *** [/<>/config/rules.mk:418: default] Error 2
make[2]: Leaving directory '/<>/build-browser'
dh_auto_build: error: cd build-browser && make -j1
LD_LIBS=-Wl,--no-gc-sections _LEAKTEST_FILES=leaktest.py returned exit code
2
make[1]: *** [debian/rules:216: stamps/build-browser] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:321: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2

Build finished at 2021-11-21T02:58:31Z

Regards,
Connor

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

On 11/20/21 21:34, Connor McLaughlan wrote:
> However when i execute sbuild, 1.29 gets replaced with 1.56 automatically:
> 
> Selecting previously unselected package libstd-rust-1.56:sparc64.
> Preparing to unpack .../12-libstd-rust-1.56_1.56.0+dfsg1-2_sparc64.deb ...
> Unpacking libstd-rust-1.56:sparc64 (1.56.0+dfsg1-2) ...
> Preparing to unpack .../13-rustc_1.56.0+dfsg1-2_sparc64.deb ...
> Unpacking rustc (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1) ...
> Preparing to unpack .../14-libstd-rust-dev_1.56.0+dfsg1-2_sparc64.deb ...
> Unpacking libstd-rust-dev:sparc64 (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1) ...
> 
> How do i prevent it?
> 
> Do i need to modify control.in and set it to 1.29 exactly:
> 
> rustc (>= 1.24) -> rustc (= 1.29)

Run sbuild with "--no-apt-upgrade --no-apt-distupgrade".

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Sat, Nov 20, 2021 at 11:01 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 11/19/21 17:21, Connor McLaughlan wrote:
> > Now it is stuck at a rustc compile error:
> >
> >Compiling url v1.7.0
> > error[E0713]: borrow may still be in use when destructor runs
> >--> /<>/third_party/rust/url/src/form_urlencoded.rs:261
> :40
>
> I would suggest downloading and installing rustc 1.29 from snapshots [1]
> which
> should be easier than starting to update the individual Rust components of
> the
> Firefox sources.
>
> Adrian
>
> > [1] https://snapshot.debian.org/package/rustc/1.29.0%2Bdfsg1-1/
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>
Hello Adrian,

i entered  the chroot and installed rustc 1.29 from snapshot.

However when i execute sbuild, 1.29 gets replaced with 1.56 automatically:

Selecting previously unselected package libstd-rust-1.56:sparc64.
Preparing to unpack .../12-libstd-rust-1.56_1.56.0+dfsg1-2_sparc64.deb ...
Unpacking libstd-rust-1.56:sparc64 (1.56.0+dfsg1-2) ...
Preparing to unpack .../13-rustc_1.56.0+dfsg1-2_sparc64.deb ...
Unpacking rustc (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1) ...
Preparing to unpack .../14-libstd-rust-dev_1.56.0+dfsg1-2_sparc64.deb ...
Unpacking libstd-rust-dev:sparc64 (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1) ...

How do i prevent it?

Do i need to modify control.in and set it to 1.29 exactly:

rustc (>= 1.24) -> rustc (= 1.29)


Regards,
Connor

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

On 11/19/21 17:21, Connor McLaughlan wrote:
> Now it is stuck at a rustc compile error:
> 
>Compiling url v1.7.0
> error[E0713]: borrow may still be in use when destructor runs
>--> /<>/third_party/rust/url/src/form_urlencoded.rs:261:40

I would suggest downloading and installing rustc 1.29 from snapshots [1] which
should be easier than starting to update the individual Rust components of the
Firefox sources.

Adrian

> [1] https://snapshot.debian.org/package/rustc/1.29.0%2Bdfsg1-1/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Fri, Nov 19, 2021 at 5:28 PM Connor McLaughlan 
wrote:

>
>
> On Fri, Nov 19, 2021 at 5:21 PM Connor McLaughlan 
> wrote:
>
>>
>> On Fri, Nov 19, 2021 at 3:26 PM John Paul Adrian Glaubitz <
>> glaub...@physik.fu-berlin.de> wrote:
>>
>>> On 11/19/21 01:14, Connor McLaughlan wrote:
>>> > adding "CONFIGURE_FLAGS += --disable-warnings-as-errors" to
>>> debian/rules
>>> > didn't remove the error.
>>> >
>>> > Should i try to add -fpermissive to the CFLAGS?
>>>
>>> Yes, you can try this. But make sure you add it with "+=" to not
>>> overwrite
>>> the other CFLAGS/CXXFLAGS.
>>>
>>> You can also use DEB_CXXFLAGS_MAINT_APPEND, see [1].
>>>
>>>
>>  By adding -fpermissive to the CFLAGS the build process went further.
>>
>> Now it is stuck at a rustc compile error:
>>
>>Compiling url v1.7.0
>> error[E0713]: borrow may still be in use when destructor runs
>>--> /<>/third_party/rust/url/src/form_urlencoded.rs:261
>> :40
>> |
>> 259 | impl<'a> Target for ::UrlQuery<'a> {
>> |  -- lifetime `'a` defined here
>> 260 | fn as_mut_string( self) ->  String { 
>> self.url.serialization }
>> 261 | fn finish(self) -> &'a mut ::Url { self.url }
>> | - here, drop of
>> `self` needs exclusive access to `*self.url`, because the type
>> `UrlQuery<'_>` implements the `Drop` trait
>> ||
>> |returning this value
>> requires that `*self.url` is borrowed for `'a`
>>
>> For more information about this error, try `rustc --explain E0713`.
>> error: could not compile `url` due to previous error
>> make[5]: *** [/<>/config/rules.mk:951:
>> force-cargo-library-build] Error 101
>> make[5]: Leaving directory
>> '/<>/build-browser/toolkit/library/rust'
>> make[4]: *** [/<>/config/recurse.mk:74:
>> toolkit/library/rust/target] Error 2
>> make[4]: Leaving directory '/<>/build-browser'
>> make[3]: *** [/<>/config/recurse.mk:34: compile] Error 2
>> make[3]: Leaving directory '/<>/build-browser'
>> make[2]: *** [/<>/config/rules.mk:418: default] Error 2
>> make[2]: Leaving directory '/<>/build-browser'
>> dh_auto_build: error: cd build-browser && make -j1
>> LD_LIBS=-Wl,--no-gc-sections _LEAKTEST_FILES=leaktest.py returned exit code
>> 2
>> make[1]: *** [debian/rules:218: stamps/build-browser] Error 25
>> make[1]: Leaving directory '/<>'
>> make: *** [debian/rules:323: build-arch] Error 2
>> dpkg-buildpackage: error: debian/rules build-arch subprocess returned
>> exit status 2
>>
>> 
>> Build finished at 2021-11-19T16:01:50Z
>>
>> Regards,
>> Connor
>>
>>
> It seems the cause is that rust compiler has changed behavior and so the
> url v1.7.0 needs an update.
> But i don't know where to take it from and how to apply it...
>
> Regards,
> Connor
>

I tried to add modify third_party/rust/url/src/form_urlencoded.rs like here:
https://hg.mozilla.org/mozilla-central/rev/93bdaf4be8e4042cadf8fddcc20d43155622474c

I modified the file and did the three steps after that like before...
commit and the 2x dch commands.
But something appears to have gone wrong:

force-cargo-library-build
env   RUSTFLAGS='-C opt-level=2 -C debuginfo=2 '
 CARGO_TARGET_DIR=/<>/build-browser/toolkit/library
RUSTC=/usr/bin/rustc RUSTDOC=/usr/bin/rustdoc MOZ_SRC=/<>
MOZ_DIST=/<>/build-browser/dist
LIBCLANG_PATH="/usr/lib/llvm-11/lib"
CLANG_PATH="/usr/lib/llvm-11/bin/clang" PKG_CONFIG_ALLOW_CROSS=1
RUST_BACKTRACE=full MOZ_TOPOBJDIR=/<>/build-browser
 MOZ_CARGO_WRAP_LDFLAGS="-lpthread -Wl,--as-needed
-Wl,--reduce-memory-overheads -Wl,--no-keep-memory -Wl,--stats
-Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,--build-id
-Wl,-rpath-link,/<>/build-browser/dist/bin
-Wl,-rpath-link,/usr/lib" MOZ_CARGO_WRAP_LD=" /usr/bin/gcc -std=gnu99"
CARGO_TARGET_SPARC64_UNKNOWN_LINUX_GNU_LINKER=/<>/build/cargo-linker
/usr/bin/cargo rustc  --release --frozen --manifest-path
/<>/toolkit/library/rust/Cargo.toml --lib
--target=sparc64-unknown-linux-gnu --features "servo bindgen quantum_render
cubeb_pulse_rust cubeb-remoting moz_memory" --  -C lto
error: the listed checksum of `/<>/third_party/rust/url/src/
form_urlencoded.rs` has changed:
expected: 320418526c4564a4469581d426e7467bcefe504eecd098e1eb90a2663a75fd80
actual:   d8c35e92375cafcd7e12c4f0d5374bab62aa1f333629d55b007a9c3d5c3cb615

directory sources are not intended to be edited, if modifications are
required then it is recommended that `[patch]` is used with a forked copy
of the source


Not sure how to undo it and reapply it correctly.
But i can start from scratch if needed i guess...

Regards,
Connor

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Fri, Nov 19, 2021 at 5:21 PM Connor McLaughlan 
wrote:

>
> On Fri, Nov 19, 2021 at 3:26 PM John Paul Adrian Glaubitz <
> glaub...@physik.fu-berlin.de> wrote:
>
>> On 11/19/21 01:14, Connor McLaughlan wrote:
>> > adding "CONFIGURE_FLAGS += --disable-warnings-as-errors" to debian/rules
>> > didn't remove the error.
>> >
>> > Should i try to add -fpermissive to the CFLAGS?
>>
>> Yes, you can try this. But make sure you add it with "+=" to not overwrite
>> the other CFLAGS/CXXFLAGS.
>>
>> You can also use DEB_CXXFLAGS_MAINT_APPEND, see [1].
>>
>>
>  By adding -fpermissive to the CFLAGS the build process went further.
>
> Now it is stuck at a rustc compile error:
>
>Compiling url v1.7.0
> error[E0713]: borrow may still be in use when destructor runs
>--> /<>/third_party/rust/url/src/form_urlencoded.rs:261:40
> |
> 259 | impl<'a> Target for ::UrlQuery<'a> {
> |  -- lifetime `'a` defined here
> 260 | fn as_mut_string( self) ->  String { 
> self.url.serialization }
> 261 | fn finish(self) -> &'a mut ::Url { self.url }
> | - here, drop of
> `self` needs exclusive access to `*self.url`, because the type
> `UrlQuery<'_>` implements the `Drop` trait
> ||
> |returning this value requires
> that `*self.url` is borrowed for `'a`
>
> For more information about this error, try `rustc --explain E0713`.
> error: could not compile `url` due to previous error
> make[5]: *** [/<>/config/rules.mk:951:
> force-cargo-library-build] Error 101
> make[5]: Leaving directory
> '/<>/build-browser/toolkit/library/rust'
> make[4]: *** [/<>/config/recurse.mk:74:
> toolkit/library/rust/target] Error 2
> make[4]: Leaving directory '/<>/build-browser'
> make[3]: *** [/<>/config/recurse.mk:34: compile] Error 2
> make[3]: Leaving directory '/<>/build-browser'
> make[2]: *** [/<>/config/rules.mk:418: default] Error 2
> make[2]: Leaving directory '/<>/build-browser'
> dh_auto_build: error: cd build-browser && make -j1
> LD_LIBS=-Wl,--no-gc-sections _LEAKTEST_FILES=leaktest.py returned exit code
> 2
> make[1]: *** [debian/rules:218: stamps/build-browser] Error 25
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:323: build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
> status 2
>
> 
> Build finished at 2021-11-19T16:01:50Z
>
> Regards,
> Connor
>
>
It seems the cause is that rust compiler has changed behavior and so the
url v1.7.0 needs an update.
But i don't know where to take it from and how to apply it...

Regards,
Connor

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

On Fri, Nov 19, 2021 at 3:26 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 11/19/21 01:14, Connor McLaughlan wrote:
> > adding "CONFIGURE_FLAGS += --disable-warnings-as-errors" to debian/rules
> > didn't remove the error.
> >
> > Should i try to add -fpermissive to the CFLAGS?
>
> Yes, you can try this. But make sure you add it with "+=" to not overwrite
> the other CFLAGS/CXXFLAGS.
>
> You can also use DEB_CXXFLAGS_MAINT_APPEND, see [1].
>
>
 By adding -fpermissive to the CFLAGS the build process went further.

Now it is stuck at a rustc compile error:

   Compiling url v1.7.0
error[E0713]: borrow may still be in use when destructor runs
   --> /<>/third_party/rust/url/src/form_urlencoded.rs:261:40
|
259 | impl<'a> Target for ::UrlQuery<'a> {
|  -- lifetime `'a` defined here
260 | fn as_mut_string( self) ->  String { 
self.url.serialization }
261 | fn finish(self) -> &'a mut ::Url { self.url }
| - here, drop of
`self` needs exclusive access to `*self.url`, because the type
`UrlQuery<'_>` implements the `Drop` trait
||
|returning this value requires
that `*self.url` is borrowed for `'a`

For more information about this error, try `rustc --explain E0713`.
error: could not compile `url` due to previous error
make[5]: *** [/<>/config/rules.mk:951:
force-cargo-library-build] Error 101
make[5]: Leaving directory
'/<>/build-browser/toolkit/library/rust'
make[4]: *** [/<>/config/recurse.mk:74:
toolkit/library/rust/target] Error 2
make[4]: Leaving directory '/<>/build-browser'
make[3]: *** [/<>/config/recurse.mk:34: compile] Error 2
make[3]: Leaving directory '/<>/build-browser'
make[2]: *** [/<>/config/rules.mk:418: default] Error 2
make[2]: Leaving directory '/<>/build-browser'
dh_auto_build: error: cd build-browser && make -j1
LD_LIBS=-Wl,--no-gc-sections _LEAKTEST_FILES=leaktest.py returned exit code
2
make[1]: *** [debian/rules:218: stamps/build-browser] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:323: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2

Build finished at 2021-11-19T16:01:50Z

Regards,
Connor

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

On 11/19/21 01:14, Connor McLaughlan wrote:
> adding "CONFIGURE_FLAGS += --disable-warnings-as-errors" to debian/rules
> didn't remove the error.
> 
> Should i try to add -fpermissive to the CFLAGS?

Yes, you can try this. But make sure you add it with "+=" to not overwrite
the other CFLAGS/CXXFLAGS.

You can also use DEB_CXXFLAGS_MAINT_APPEND, see [1].

Adrian

> [1] 
> https://www.debian.org/doc/manuals/debmake-doc/ch04.en.html#step-maintainer

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Adrian,

adding "CONFIGURE_FLAGS += --disable-warnings-as-errors" to debian/rules
didn't remove the error.

Should i try to add -fpermissive to the CFLAGS?

Regards,
Connor


On Thu, Nov 18, 2021 at 7:57 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hello!
>
> On 11/18/21 19:48, Connor McLaughlan wrote:
> > In file included from
> > /<>/build-browser/js/src/Unified_cpp_js_src26.cpp:20:
> > /<>/js/src/util/NativeStack.cpp:29:1: error: ‘pid_t
> gettid()’
> > was declared ‘extern’ and later ‘static’ [-fpermissive]
> >29 | gettid()
> >   | ^~
>
> Try building with "--disable-warnings-as-errors":
>
> --- debian/rules.orig   2018-10-03 09:18:06.0 +0200
> +++ debian/rules2021-11-18 19:57:12.041480785 +0100
> @@ -87,6 +87,8 @@
>
>  AUTOCONF_DIRS := build/autoconf
>
> +CONFIGURE_FLAGS += --disable-warnings-as-errors
> +
>  ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
> CONFIGURE_FLAGS += --disable-optimize
>  endif
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hello!

On 11/18/21 19:48, Connor McLaughlan wrote:
> In file included from
> /<>/build-browser/js/src/Unified_cpp_js_src26.cpp:20:
> /<>/js/src/util/NativeStack.cpp:29:1: error: ‘pid_t gettid()’
> was declared ‘extern’ and later ‘static’ [-fpermissive]
>29 | gettid()
>   | ^~

Try building with "--disable-warnings-as-errors":

--- debian/rules.orig   2018-10-03 09:18:06.0 +0200
+++ debian/rules2021-11-18 19:57:12.041480785 +0100
@@ -87,6 +87,8 @@
 
 AUTOCONF_DIRS := build/autoconf
 
+CONFIGURE_FLAGS += --disable-warnings-as-errors
+
 ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
CONFIGURE_FLAGS += --disable-optimize
 endif

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Adrian,

build has started now and i got  a build error:

/usr/bin/g++ -o Unified_cpp_js_src26.o -c
-I/<>/build-browser/dist/system_wrappers -include
/<>/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1
-DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API -DJS_HAS_CTYPES
'-DDLL_PREFIX="lib"' '-DDLL_SUFFIX=".so"' -DMOZ_HAS_MOZGLUE
-I/<>/js/src -I/<>/build-browser/js/src
-I/<>/build-browser/dist/include -I/usr/include/nspr -fPIC
-DMOZILLA_CLIENT -include
/<>/build-browser/js/src/js-confdefs.h -Wdate-time
-D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall
-Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith
-Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings
-Wno-invalid-offsetof -Wc++1z-compat -Wduplicated-cond
-Wimplicit-fallthrough -Wno-error=maybe-uninitialized
-Wno-error=deprecated-declarations -Wno-error=array-bounds
-Wno-error=free-nonheap-object -Wno-error=multistatement-macros
-Wno-error=class-memaccess -Wformat -Wformat-overflow=2 -Wno-noexcept-type
-fno-sized-deallocation -fstack-protector-strong -Wformat
-Werror=format-security -fno-schedule-insns2 -fno-lifetime-dse
-fno-delete-null-pointer-checks -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
-fno-rtti -ffunction-sections -fdata-sections -fno-exceptions
-fno-math-errno -pthread -pipe -g -freorder-blocks -O3 -fomit-frame-pointer
-Wno-shadow -Werror=format -fno-strict-aliasing  -MD -MP -MF
.deps/Unified_cpp_js_src26.o.pp
/<>/build-browser/js/src/Unified_cpp_js_src26.cpp
In file included from
/<>/build-browser/js/src/Unified_cpp_js_src26.cpp:20:
/<>/js/src/util/NativeStack.cpp:29:1: error: ‘pid_t gettid()’
was declared ‘extern’ and later ‘static’ [-fpermissive]
   29 | gettid()
  | ^~
In file included from /usr/include/unistd.h:1186,
 from
/<>/build-browser/dist/system_wrappers/unistd.h:3,
 from /<>/js/src/util/NativeStack.cpp:27,
 from
/<>/build-browser/js/src/Unified_cpp_js_src26.cpp:20:
/usr/include/sparc64-linux-gnu/bits/unistd_ext.h:34:16: note: previous
declaration of ‘__pid_t gettid()’
   34 | extern __pid_t gettid (void) __THROW;
  |^~
In file included from /<>/js/src/jsutil.h:18,
 from /<>/js/src/threading/Thread.h:19,
 from /<>/js/src/threading/posix/Thread.cpp:26,
 from
/<>/build-browser/js/src/Unified_cpp_js_src26.cpp:2:
/<>/build-browser/dist/include/mozilla/PodOperations.h: In
instantiation of ‘void mozilla::PodArrayZero(T (&)[N]) [with T = JS::Value;
long unsigned int N = 2]’:
/<>/js/src/jsapi.h:85:30:   required from
‘JS::AutoValueArray::AutoValueArray(JSContext*) [with long unsigned int
N = 2]’
/<>/js/src/vm/Stack.h:982:45:   required from
‘js::detail::FixedArgsBase::FixedArgsBase(JSContext*) [with
js::MaybeConstruct Construct = js::NO_CONSTRUCT; long unsigned int N = 0]’
/<>/js/src/vm/Stack.h:1019:54:   required from
‘js::FixedInvokeArgs::FixedInvokeArgs(JSContext*) [with long unsigned
int N = 0]’
/<>/js/src/vm/Interpreter.h:85:31:   required from here
/<>/build-browser/dist/include/mozilla/PodOperations.h:67:9:
warning: ‘void* memset(void*, int, size_t)’ clearing an object of
non-trivial type ‘union JS::Value’; use assignment or value-initialization
instead [-Wclass-memaccess]
   67 |   memset(aT, 0, N * sizeof(T));
  |   ~~^~
In file included from /<>/js/src/jsutil.h:24,
 from /<>/js/src/threading/Thread.h:19,
 from /<>/js/src/threading/posix/Thread.cpp:26,
 from
/<>/build-browser/js/src/Unified_cpp_js_src26.cpp:2:
/<>/build-browser/dist/include/js/Value.h:313:32: note: ‘union
JS::Value’ declared here
  313 | union MOZ_NON_PARAM alignas(8) Value
  |^
In file included from /<>/js/src/jsutil.h:18,
 from /<>/js/src/threading/Thread.h:19,
 from /<>/js/src/threading/posix/Thread.cpp:26,
 from
/<>/build-browser/js/src/Unified_cpp_js_src26.cpp:2:
/<>/build-browser/dist/include/mozilla/PodOperations.h: In
instantiation of ‘void mozilla::PodArrayZero(T (&)[N]) [with T = JS::Value;
long unsigned int N = 3]’:
/<>/js/src/jsapi.h:85:30:   required from
‘JS::AutoValueArray::AutoValueArray(JSContext*) [with long unsigned int
N = 3]’
/<>/js/src/vm/Stack.h:982:45:   required from
‘js::detail::FixedArgsBase::FixedArgsBase(JSContext*) [with
js::MaybeConstruct Construct = js::NO_CONSTRUCT; long unsigned int N = 1]’
/<>/js/src/vm/Stack.h:1019:54:   required from
‘js::FixedInvokeArgs::FixedInvokeArgs(JSContext*) [with long unsigned
int N = 1]’
/<>/js/src/vm/Interpreter.h:100:31:   required from here
/<>/build-browser/dist/include/mozilla/PodOperations.h:67:9:
warning: ‘void* memset(void*, int, size_t)’ clearing an object of
non-trivial type ‘union JS::Value’; use assignment or value-initialization
instead [-Wclass-memaccess]
   67 |   memset(aT, 0, N * sizeof(T));
  |   ~~^~
In file included from 

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

On 11/18/21 13:57, Connor McLaughlan wrote:
> Build-Depends: autotools-dev, debhelper (>= 9.20160114), autoconf2.13,
> libx11-dev, libx11-xcb-dev, libxt-dev, libgtk-3-dev, libgtk2.0-dev (>=
> 2.10), libglib2.0-dev (>= 2.16.0), libstartup-notification0-dev,
> libjpeg-dev, zlib1g-dev, libreadline-dev, python2.7, python2-minimal (>=
> 2.6.6-13~), python3, python-ply, dpkg-dev (>= 1.16.1.1~), libnspr4-dev (>=
> 2:4.19~), libnss3-dev (>= 2:3.38~), libsqlite3-dev (>= 3.24.0), libvpx-dev
> (>= 1.5.0), libdbus-glib-1-dev, libffi-dev, libevent-dev (>= 1.4.1),
> libjsoncpp-dev, libpulse-dev, libasound2-dev, yasm (>= 1.1), rustc (>=
> 1.24), cargo (>= 0.25), llvm-11-dev, libclang-11-dev, clang-11, llvm-11,
> zip, unzip, locales, xvfb, xfonts-base, xauth, ttf-bitstream-vera,
> fonts-freefont-ttf, fonts-dejima-mincho, iso-codes
> 
> However this didn't change anything regarding the error...

Did you add "llvm"? Not "llvm-11".

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Adrian,

i added llvm-11 to the build depends and it is listed, when i start the
building process:

Build-Depends: autotools-dev, debhelper (>= 9.20160114), autoconf2.13,
libx11-dev, libx11-xcb-dev, libxt-dev, libgtk-3-dev, libgtk2.0-dev (>=
2.10), libglib2.0-dev (>= 2.16.0), libstartup-notification0-dev,
libjpeg-dev, zlib1g-dev, libreadline-dev, python2.7, python2-minimal (>=
2.6.6-13~), python3, python-ply, dpkg-dev (>= 1.16.1.1~), libnspr4-dev (>=
2:4.19~), libnss3-dev (>= 2:3.38~), libsqlite3-dev (>= 3.24.0), libvpx-dev
(>= 1.5.0), libdbus-glib-1-dev, libffi-dev, libevent-dev (>= 1.4.1),
libjsoncpp-dev, libpulse-dev, libasound2-dev, yasm (>= 1.1), rustc (>=
1.24), cargo (>= 0.25), llvm-11-dev, libclang-11-dev, clang-11, llvm-11,
zip, unzip, locales, xvfb, xfonts-base, xauth, ttf-bitstream-vera,
fonts-freefont-ttf, fonts-dejima-mincho, iso-codes

However this didn't change anything regarding the error...

Regards,
Connor



On Thu, Nov 18, 2021 at 2:10 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

>
> On Nov 18, 2021, at 2:01 AM, Connor McLaughlan 
> wrote:
>
>
> checking for llvm-config... not found
> ERROR: Could not find LLVM/Clang installation for compiling stylo
> build-time
> bindgen.  Please specify the 'LLVM_CONFIG' environment variable
> (recommended), pass the '--with-libclang-path' and '--with-clang-path'
> options to configure, or put 'llvm-config' in your PATH.  Altering your
> PATH may expose 'clang' as well, potentially altering your compiler,
> which may not be what you intended.
> make[1]: *** [debian/rules:205: stamps/configure-browser] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:321: build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
> status 2
>
> 
>
> What can i do here?
>
>
> Try adding “llvm” to Build-Depends, see:
>
>
> https://packages.debian.org/search?searchon=contents=llvm-config=exactfilename=stable=any
>
> Adrian
>

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

> On Nov 18, 2021, at 2:01 AM, Connor McLaughlan  wrote:
> 
> checking for llvm-config... not found
> ERROR: Could not find LLVM/Clang installation for compiling stylo build-time
> bindgen.  Please specify the 'LLVM_CONFIG' environment variable
> (recommended), pass the '--with-libclang-path' and '--with-clang-path'
> options to configure, or put 'llvm-config' in your PATH.  Altering your
> PATH may expose 'clang' as well, potentially altering your compiler,
> which may not be what you intended.
> make[1]: *** [debian/rules:205: stamps/configure-browser] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:321: build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2
> 
> 
> What can i do here?

Try adding “llvm” to Build-Depends, see:

https://packages.debian.org/search?searchon=contents=llvm-config=exactfilename=stable=any

Adrian

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Adrian,

it took a few more steps to get sbuild to get over missing dependencies...i
had to go into the chroot again, import repo keys or it wouldn't let me
execute apt-get update.
apt-get update was needed to resolve some more dependencies where packages
presumedly changed in the middle of my chroot installation.

One example was:
libdrm2 : Depends: libdrm-common (>= 2.4.108-1) but 2.4.107-8 is to be
installed

Now it fails during configure:

checking for llvm-config... not found
ERROR: Could not find LLVM/Clang installation for compiling stylo build-time
bindgen.  Please specify the 'LLVM_CONFIG' environment variable
(recommended), pass the '--with-libclang-path' and '--with-clang-path'
options to configure, or put 'llvm-config' in your PATH.  Altering your
PATH may expose 'clang' as well, potentially altering your compiler,
which may not be what you intended.
make[1]: *** [debian/rules:205: stamps/configure-browser] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:321: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2


What can i do here?

Regards,
Connor


On Wed, Nov 17, 2021 at 2:40 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hello!
>
> On 11/17/21 00:33, Connor McLaughlan wrote:
> > i  had also to replace python-minimal in the config.in it seems,
> otherwise
> > it would show up again with the original package.
>
> Yes, you're right. debian/control is generated from debian/control.in
> (not config.in).
>
> > Now it is missing those dependencies:
> >
> > The following packages have unmet dependencies:
> >  sbuild-build-depends-main-dummy : Depends: llvm-6.0-dev but it is not
> > installable
> >Depends: libclang-6.0-dev but it is
> not
> > installable
> >Depends: clang-6.0 but it is not
> > installable
> >
>
> Try replacing the following in debian/control.in:
>
>llvm-6.0-dev,
>libclang-6.0-dev,
>clang-6.0,
>
> with:
>
>llvm-11-dev,
>libclang-11-dev,
>clang-11,
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hello!

On 11/17/21 00:33, Connor McLaughlan wrote:
> i  had also to replace python-minimal in the config.in it seems, otherwise
> it would show up again with the original package.

Yes, you're right. debian/control is generated from debian/control.in (not 
config.in).

> Now it is missing those dependencies:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-main-dummy : Depends: llvm-6.0-dev but it is not
> installable
>Depends: libclang-6.0-dev but it is not
> installable
>Depends: clang-6.0 but it is not
> installable
> 

Try replacing the following in debian/control.in:

   llvm-6.0-dev,
   libclang-6.0-dev,
   clang-6.0,

with:

   llvm-11-dev,
   libclang-11-dev,
   clang-11,

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Adrian,

i  had also to replace python-minimal in the config.in it seems, otherwise
it would show up again with the original package.

Now it is missing those dependencies:

The following packages have unmet dependencies:
 sbuild-build-depends-main-dummy : Depends: llvm-6.0-dev but it is not
installable
   Depends: libclang-6.0-dev but it is not
installable
   Depends: clang-6.0 but it is not
installable

Should i get those from snapshot or is there also a possible replacement?

Regards,
Connor

On Tue, Nov 16, 2021 at 8:35 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hello!
>
> On 11/16/21 18:23, Connor McLaughlan wrote:> sbuild was able to start now.
> >
> > I am now getting the dependency problem regarding python-minimal here
> also:
> > (...)
> >   unsat-dependency: python-minimal:sparc64 (>= 2.6.6-13~)
>
> You need to replace "python-minimal" with "python2-minimal" in the
> Build-Depends
> field in debian/control:
>
> $ sed -i 's/python-minimal/python2-minimal/g' debian/control
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hello!

On 11/16/21 18:23, Connor McLaughlan wrote:> sbuild was able to start now.
> 
> I am now getting the dependency problem regarding python-minimal here also:
> (...)
>   unsat-dependency: python-minimal:sparc64 (>= 2.6.6-13~)

You need to replace "python-minimal" with "python2-minimal" in the Build-Depends
field in debian/control:

$ sed -i 's/python-minimal/python2-minimal/g' debian/control

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

When i try to install python-minimal into the chroot, i get:

root@SunUltra25:/work/chroot# chroot /work/chroot/sid-sparc64-sbuild
root@SunUltra25:/# apt install python-minimal
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package python-minimal is not available, but is referred to by another
package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  python2-minimal python-is-python3 python-is-python2

E: Package 'python-minimal' has no installation candidate

Regards,
Connor


On Tue, Nov 16, 2021 at 6:23 PM Connor McLaughlan 
wrote:

> Hello Adrian,
>
> sbuild was able to start now.
>
> I am now getting the dependency problem regarding python-minimal here also:
>
> output-version: 1.2
> native-architecture: sparc64
> report:
>  -
>   package: sbuild-build-depends-main-dummy
>   version: 0.invalid.0
>   architecture: sparc64
>   status: broken
>   reasons:
>-
> missing:
>  pkg:
>   package: sbuild-build-depends-main-dummy
>   version: 0.invalid.0
>   architecture: sparc64
>   unsat-dependency: python-minimal:sparc64 (>= 2.6.6-13~)
>
> background-packages: 77315
> foreground-packages: 1
> total-packages: 77316
> broken-packages: 1
>
>
> +--+
> | Cleanup
>  |
>
> +--+
>
> Purging /<>
> Not cleaning session: cloned chroot in use
> E: Package build dependencies not satisfied; skipping
>
>
> +--+
> | Summary
>  |
>
> +--+
>
> Build Architecture: sparc64
> Build Type: any
> Build-Space: n/a
> Build-Time: 0
> Distribution: sid
> Fail-Stage: install-deps
> Host Architecture: sparc64
> Install-Time: 0
> Job: /work/firefox-build/firefox_62.0.3-1.1.dsc
> Machine Architecture: sparc64
> Package: firefox
> Package-Time: 0
> Source-Version: 62.0.3-1.1
> Space: n/a
> Status: given-back
> Version: 62.0.3-1.1
>
> 
> Finished at 2021-11-16T16:15:18Z
> Build needed 00:00:00, no disk space
> E: Package build dependencies not satisfied; skipping
> connor@SunUltra25:/work/firefox-build/firefox-62.0.3$
>
> On Tue, Nov 16, 2021 at 3:26 PM John Paul Adrian Glaubitz <
> glaub...@physik.fu-berlin.de> wrote:
>
>> On 11/16/21 15:22, Connor McLaughlan wrote:
>> > onnor@SunUltra25:/work/firefox-build/firefox-62.0.3$ sbuild -d sid
>> > --arch=sparc64 --no-arch-all
>> > hostname: Name or service not known
>> > /bin/sh: 1: python: not found
>>
>> As root, change into the chroot and install python-is-python2:
>>
>> # chroot /srv/chroot/sid-sparc64-sbuild
>> # apt install python-is-python2
>> # exit
>>
>> Then try again.
>>
>> Adrian
>>
>> --
>>  .''`.  John Paul Adrian Glaubitz
>> : :' :  Debian Developer - glaub...@debian.org
>> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>>
>>

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Adrian,

sbuild was able to start now.

I am now getting the dependency problem regarding python-minimal here also:

output-version: 1.2
native-architecture: sparc64
report:
 -
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: sparc64
  status: broken
  reasons:
   -
missing:
 pkg:
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: sparc64
  unsat-dependency: python-minimal:sparc64 (>= 2.6.6-13~)

background-packages: 77315
foreground-packages: 1
total-packages: 77316
broken-packages: 1

+--+
| Cleanup
   |
+--+

Purging /<>
Not cleaning session: cloned chroot in use
E: Package build dependencies not satisfied; skipping

+--+
| Summary
   |
+--+

Build Architecture: sparc64
Build Type: any
Build-Space: n/a
Build-Time: 0
Distribution: sid
Fail-Stage: install-deps
Host Architecture: sparc64
Install-Time: 0
Job: /work/firefox-build/firefox_62.0.3-1.1.dsc
Machine Architecture: sparc64
Package: firefox
Package-Time: 0
Source-Version: 62.0.3-1.1
Space: n/a
Status: given-back
Version: 62.0.3-1.1

Finished at 2021-11-16T16:15:18Z
Build needed 00:00:00, no disk space
E: Package build dependencies not satisfied; skipping
connor@SunUltra25:/work/firefox-build/firefox-62.0.3$

On Tue, Nov 16, 2021 at 3:26 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 11/16/21 15:22, Connor McLaughlan wrote:
> > onnor@SunUltra25:/work/firefox-build/firefox-62.0.3$ sbuild -d sid
> > --arch=sparc64 --no-arch-all
> > hostname: Name or service not known
> > /bin/sh: 1: python: not found
>
> As root, change into the chroot and install python-is-python2:
>
> # chroot /srv/chroot/sid-sparc64-sbuild
> # apt install python-is-python2
> # exit
>
> Then try again.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

On 11/16/21 15:22, Connor McLaughlan wrote:
> onnor@SunUltra25:/work/firefox-build/firefox-62.0.3$ sbuild -d sid
> --arch=sparc64 --no-arch-all
> hostname: Name or service not known
> /bin/sh: 1: python: not found

As root, change into the chroot and install python-is-python2:

# chroot /srv/chroot/sid-sparc64-sbuild
# apt install python-is-python2
# exit

Then try again.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Adrian,

i went through all steps and when i finally try to start the building
process, i get these errors:

onnor@SunUltra25:/work/firefox-build/firefox-62.0.3$ sbuild -d sid
--arch=sparc64 --no-arch-all
hostname: Name or service not known
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
dh clean
dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/work/firefox-build/firefox-62.0.3'
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
rm -f debian/firefox-dev.links debian/firefox.1 debian/firefox.NEWS
debian/firefox.README.Debian debian/firefox.bug-control
debian/firefox.bug-presubj debian/firefox.bug-script debian/firefox.desktop
debian/firefox.dirs debian/firefox.install debian/firefox.js
debian/firefox.links debian/firefox.lintian-overrides
debian/firefox.manpages debian/firefox.mime debian/firefox.mozconfig
debian/firefox.postinst debian/firefox.prerm debian/noinstall
debian/l10n/browser-l10n.control
rm -f configure js/src/configure old-configure js/src/old-configure
rm -rf stamps l10n
debian/rules debian/control TESTDIR=
make[2]: Entering directory '/work/firefox-build/firefox-62.0.3'
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
/bin/sh: 1: python: not found
python -B debian/l10n/gen  > debian/l10n/browser-l10n.control
/bin/sh: 1: python: not found
make[2]: *** [debian/rules:148: debian/l10n/browser-l10n.control] Error 127
make[2]: Leaving directory '/work/firefox-build/firefox-62.0.3'
make[1]: *** [debian/rules:255: override_dh_auto_clean] Error 2
make[1]: Leaving directory '/work/firefox-build/firefox-62.0.3'
make: *** [debian/rules:321: clean] Error 2
E: Failed to clean source directory /work/firefox-build/firefox-62.0.3
(/work/firefox-build/firefox_62.0.3-1.1.dsc)
connor@SunUltra25:/work/firefox-build/firefox-62.0.3$

What can i do to correct it?

Regards,
Connor

On Tue, Nov 16, 2021 at 9:37 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hello!
>
> On 11/15/21 23:20, Connor McLaughlan wrote:
> > i have read through the sbuild page and it is very long and looks very
> > complicated and not tailored to a sparc64 machine.
> > Is really everything on that page needed to get it running?
>
> No, it's actually very simple and works on any architecture.
>
> As root:
>
> # apt install sbuild devscripts
> # sbuild-createchroot unstable /srv/chroot/sid-sparc64-sbuild --alias=sid \
>   --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg \
>   http://ftp.ports.debian.org/debian-ports
> # sbuild-adduser $YOURUSER
>
> Then, as your normal user ($YOURUSER):
>
> $ mkdir firefox-build
> # cd firefox-build
> # dget -u
> http://snapshot.debian.org/archive/debian/20181003T162948Z/pool/main/f/firefox/firefox_62.0.3-1.dsc
> # wget https://bug1434726.bmoattachments.org/attachment.cgi?id=8947275 -O
> align-fix.diff
> # cd firefox-62.0.3
> # patch -p1 < ../align-fix.diff
> # dpkg-source --commit (enter a desired patch name, then opens an editor;
> just save and close)
> # dch -i 'Add patch to fix alignment on sparc64'
> # dch -r ''
> # sbuild -d sid --arch=sparc64 --no-arch-all
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Mozilla Software on Sparc64/Linux

[Anatoly Pugachev]

On Mon, Nov 15, 2021 at 5:21 PM Connor McLaughlan  wrote:
>
> Hello Anatoly,
>
> i am using the highest available gdb for sparc64:
> root@SunUltra25:/work/firefox62# aptitude versions gdb
> i   10.1-2
> unstable  
> 500
>
> Should i use something else?

version 10.1-2 of gdb has a crucial bug in printing backtrace output
or just printing variables,
please see explanation in
https://sourceware.org/bugzilla/show_bug.cgi?id=27147#c16

So use either older version of gdb 9.x (could be installed from
snapshot.d.o) or more recent one, i.e. 10.2 or even 11.x (not
available to debian package yet, but could be compiled from sources).

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hello!

On 11/15/21 23:20, Connor McLaughlan wrote:
> i have read through the sbuild page and it is very long and looks very
> complicated and not tailored to a sparc64 machine.
> Is really everything on that page needed to get it running?

No, it's actually very simple and works on any architecture.

As root:

# apt install sbuild devscripts
# sbuild-createchroot unstable /srv/chroot/sid-sparc64-sbuild --alias=sid \
  --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg \
  http://ftp.ports.debian.org/debian-ports
# sbuild-adduser $YOURUSER

Then, as your normal user ($YOURUSER):

$ mkdir firefox-build
# cd firefox-build
# dget -u 
http://snapshot.debian.org/archive/debian/20181003T162948Z/pool/main/f/firefox/firefox_62.0.3-1.dsc
# wget https://bug1434726.bmoattachments.org/attachment.cgi?id=8947275 -O 
align-fix.diff
# cd firefox-62.0.3
# patch -p1 < ../align-fix.diff
# dpkg-source --commit (enter a desired patch name, then opens an editor; just 
save and close)
# dch -i 'Add patch to fix alignment on sparc64'
# dch -r ''
# sbuild -d sid --arch=sparc64 --no-arch-all

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Adrian,

i have read through the sbuild page and it is very long and looks very
complicated and not tailored to a sparc64 machine.
Is really everything on that page needed to get it running?

I tried to follow this page instead to build the package:
https://wiki.debian.org/BuildingTutorial

But i here i am unable to solve the build dependencies for firefox-62.0.3
on my install:

dpkg-checkbuilddeps: error: Unmet build dependencies: python-minimal (>=
2.6.6-13~) llvm-6.0-dev libclang-6.0-dev clang-6.0

These are not available from the current repo and fetching from snapshot
leads to dependency conflicts:

root@SunUltra25:/work/firefox62/build# dpkg -i
python-minimal_2.7.17-2_sparc64.deb
Selecting previously unselected package python-minimal.
(Reading database ... 281832 files and directories currently installed.)
Preparing to unpack python-minimal_2.7.17-2_sparc64.deb ...
Unpacking python-minimal (2.7.17-2) ...
dpkg: dependency problems prevent configuration of python-minimal:
 python-minimal depends on python2-minimal (= 2.7.17-2); however:
  Version of python2-minimal on system is 2.7.18-3.
 python3-six (1.16.0-2) breaks python-minimal (<< 2.7.18) and is installed.
  Version of python-minimal to be configured is 2.7.17-2.
 python2.7-minimal (2.7.18-9) breaks python-minimal (<< 2.7.18) and is
installed.
  Version of python-minimal to be configured is 2.7.17-2.
 python2.7 (2.7.18-9) breaks python-minimal (<< 2.7.18) and is installed.
  Version of python-minimal to be configured is 2.7.17-2.
 libpython2.7-stdlib:sparc64 (2.7.18-9) breaks python-minimal (<< 2.7.18)
and is installed.
  Version of python-minimal to be configured is 2.7.17-2.
 libpython2.7-minimal:sparc64 (2.7.18-9) breaks python-minimal (<< 2.7.18)
and is installed.
  Version of python-minimal to be configured is 2.7.17-2.


I am unsure on how to proceed.

Regards,
Connor

On Mon, Nov 15, 2021 at 3:44 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hi!
>
> On 11/15/21 15:00, Connor McLaughlan wrote:
> > i installed firefox_62.0.3-1_sparc64.deb. On start i get a bus error, no
> > window comes up.
> > (...)
> > Thread 1 "firefox" received signal SIGBUS, Bus error.
> > HashIIDPtrKey (key=0xfff10a7cfe4c )
> > at
> /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp:26
> > 26 /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp: No
> > such file or directory.
>
> That's this bug [1]. It got fixed in Firefox 68. So you need to cherry-pick
> this patch and rebuild the package as I explained in one of my previous
> mails.
>
> I can maybe do that later this week if you can't do it yourself.
>
> Adrian
>
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1434726
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hi!

On 11/15/21 15:00, Connor McLaughlan wrote:
> i installed firefox_62.0.3-1_sparc64.deb. On start i get a bus error, no
> window comes up.
> (...)
> Thread 1 "firefox" received signal SIGBUS, Bus error.
> HashIIDPtrKey (key=0xfff10a7cfe4c )
> at /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp:26
> 26 /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp: No
> such file or directory.

That's this bug [1]. It got fixed in Firefox 68. So you need to cherry-pick
this patch and rebuild the package as I explained in one of my previous
mails.

I can maybe do that later this week if you can't do it yourself.

Adrian

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1434726

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Anatoly,

i am using the highest available gdb for sparc64:
root@SunUltra25:/work/firefox62# aptitude versions gdb
i   10.1-2
   unstable
 500

Should i use something else?

Regards,
Connor

On Mon, Nov 15, 2021 at 3:12 PM Anatoly Pugachev  wrote:

> On Mon, Nov 15, 2021 at 5:10 PM Anatoly Pugachev 
> wrote:
> >
> > On Mon, Nov 15, 2021 at 5:00 PM Connor McLaughlan 
> wrote:
> > >
> > > i installed firefox_62.0.3-1_sparc64.deb. On start i get a bus error,
> no window comes up.
> > >
> > > gdb output:
> > >
> > > connor@SunUltra25:/usr/lib/firefox$ gdb firefox
> > > GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
> >
> > make sure to use recent gdb (11+) or more ancient one (9.x), since
> > version 10.x is buggy on sparc64
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988711
>
> sorry for misinformation, gdb-10.2.x will work on sparc64, please see
> https://sourceware.org/bugzilla/show_bug.cgi?id=27147
>

Re: Mozilla Software on Sparc64/Linux

[Anatoly Pugachev]

On Mon, Nov 15, 2021 at 5:10 PM Anatoly Pugachev  wrote:
>
> On Mon, Nov 15, 2021 at 5:00 PM Connor McLaughlan  wrote:
> >
> > i installed firefox_62.0.3-1_sparc64.deb. On start i get a bus error, no 
> > window comes up.
> >
> > gdb output:
> >
> > connor@SunUltra25:/usr/lib/firefox$ gdb firefox
> > GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
>
> make sure to use recent gdb (11+) or more ancient one (9.x), since
> version 10.x is buggy on sparc64
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988711

sorry for misinformation, gdb-10.2.x will work on sparc64, please see
https://sourceware.org/bugzilla/show_bug.cgi?id=27147

Re: Mozilla Software on Sparc64/Linux

[Anatoly Pugachev]

On Mon, Nov 15, 2021 at 5:00 PM Connor McLaughlan  wrote:
>
> i installed firefox_62.0.3-1_sparc64.deb. On start i get a bus error, no 
> window comes up.
>
> gdb output:
>
> connor@SunUltra25:/usr/lib/firefox$ gdb firefox
> GNU gdb (Debian 10.1-2) 10.1.90.20210103-git

make sure to use recent gdb (11+) or more ancient one (9.x), since
version 10.x is buggy on sparc64

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

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Adrian,

i installed firefox_62.0.3-1_sparc64.deb. On start i get a bus error, no
window comes up.

gdb output:

connor@SunUltra25:/usr/lib/firefox$ gdb firefox
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from firefox...
Reading symbols from
/usr/lib/debug/.build-id/5e/7c2ce19658b5a547605e9716c409337752cd54.debug...
(gdb) run
Starting program: /usr/lib/firefox/firefox
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 4008]
[New Thread 0xfff10e6a3870 (LWP 4009)]
[New Thread 0xfff111f79870 (LWP 4010)]
[Thread 0xfff111f79870 (LWP 4010) exited]
[New Thread 0xfff111f79870 (LWP 4011)]
[New Thread 0xfff11277b870 (LWP 4012)]
[New Thread 0xfff112f7d870 (LWP 4013)]
[New Thread 0xfff11377f870 (LWP 4015)]
[New Thread 0xfff113981870 (LWP 4016)]
[New Thread 0xfff113b83870 (LWP 4017)]
[New Thread 0xfff113d85870 (LWP 4018)]
[New Thread 0xfff113f87870 (LWP 4019)]

Thread 1 "firefox" received signal SIGBUS, Bus error.
HashIIDPtrKey (key=0xfff10a7cfe4c )
at /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp:26
26 /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp: No
such file or directory.
(gdb) bt
#0  HashIIDPtrKey(void const*) (key=0xfff10a7cfe4c
)
at /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp:26
#1  0xfff106d77ad4 in PLDHashTable::ComputeKeyHash(void const*)
(aKey=0xed9, this=0xed9)
at /build/firefox-YyDH69/firefox-62.0.3/xpcom/ds/PLDHashTable.cpp:518
#2  PLDHashTable::Add(void const*, std::nothrow_t const&) (this=0xed9,
aKey=0xed9)
at /build/firefox-YyDH69/firefox-62.0.3/xpcom/ds/PLDHashTable.cpp:586
#3  0x0ee1 in  ()
(gdb) list
21 in /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp
(gdb)
connor@SunUltra25:/usr/lib/firefox$ gdb firefox
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from firefox...
Reading symbols from
/usr/lib/debug/.build-id/5e/7c2ce19658b5a547605e9716c409337752cd54.debug...
(gdb) run
Starting program: /usr/lib/firefox/firefox
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 4008]
[New Thread 0xfff10e6a3870 (LWP 4009)]
[New Thread 0xfff111f79870 (LWP 4010)]
[Thread 0xfff111f79870 (LWP 4010) exited]
[New Thread 0xfff111f79870 (LWP 4011)]
[New Thread 0xfff11277b870 (LWP 4012)]
[New Thread 0xfff112f7d870 (LWP 4013)]
[New Thread 0xfff11377f870 (LWP 4015)]
[New Thread 0xfff113981870 (LWP 4016)]
[New Thread 0xfff113b83870 (LWP 4017)]
[New Thread 0xfff113d85870 (LWP 4018)]
[New Thread 0xfff113f87870 (LWP 4019)]

Thread 1 "firefox" received signal SIGBUS, Bus error.
HashIIDPtrKey (key=0xfff10a7cfe4c )
at /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp:26
26 /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp: No
such file or directory.
(gdb) bt
#0  HashIIDPtrKey(void const*) (key=0xfff10a7cfe4c
)
at /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp:26
#1  0xfff106d77ad4 in PLDHashTable::ComputeKeyHash(void const*)
(aKey=0xed9, this=0xed9)
at /build/firefox-YyDH69/firefox-62.0.3/xpcom/ds/PLDHashTable.cpp:518
#2  PLDHashTable::Add(void const*, std::nothrow_t const&) (this=0xed9,
aKey=0xed9)
at /build/firefox-YyDH69/firefox-62.0.3/xpcom/ds/PLDHashTable.cpp:586
#3  0x0ee1 in  ()
(gdb) list
21 in 

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hello Connor!

On 11/15/21 01:53, Connor McLaughlan wrote:
> did the working rust based firefox make it into a released package?

Yes, as I said in a previous mail, Firefox 60 was successfully built and
uploaded.

If you want to see which packages where built, check the build log archive
by opening:

> https://buildd.debian.org

then type "firefox" and click "Go".

Look for the row with "sparc64" and click on "old" in the eight column,
there you'll see that the last successfully built package version was
"62.0.3-1".

If you now go to snapshot.debian.org and type "firefox" in the source package
name field and click "Submit", you will get a list of versions, including
sparc64. Click it and scroll down to "firefox_62.0.3-1_sparc64.deb" and you
get your package.

To install the package directly, add the following line to your sources.list:

deb [trusted=yes] 
https://snapshot.debian.org/archive/debian-ports/20181004T035335Z/ unstable main

> The only packaged version of firefox i could get to run was firefox50.
> And i have tested all higher available version of firefox and firefox-esr
> on snapshot.debian.org

What problem did you run in to? You need to describe the actual problem so that
I can help you debug it.

Building newer versions should be possible as explained before, but I haven't 
had
the time for the NodeJS hack yet.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Adrian,

did the working rust based firefox make it into a released package?

The only packaged version of firefox i could get to run was firefox50.
And i have tested all higher available version of firefox and firefox-esr
on snapshot.debian.org

Regards,
Connor

On Mon, Nov 15, 2021 at 1:06 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hello!
>
> On 11/14/21 17:58, Riccardo Mottola wrote:
> >> i would be very interested in getting Firefox and Thunderbird (and
> possibly
> >> Seamonkey, but this isn't available at all with debian it seam)
> running, if
> >> possible at all for the newer versions.
> >
> > yes, SeaMonkey is for me a missed package for both Debian/Devuan and
> FreeBSD.
> > I just love it. I like the classic interface and can't stand the
> chrome-like
> > of Firefox.
>
> There is currently no one willing to step up being the maintainer of
> Seamonkey
> in Debian which is why it's currently not included.
>
> > SeaMonkey up to 2.49 was FF 52 based, so very portable and no rust. It
> should
> > be a decent candidate to get it running on SPARC, since a specific Mac
> PPC G5
> > version was maintained for a long time. Current SM is FF 60 based and so
> has rust
>
> Rust is available on SPARC and fully supported.
>
> >> Rust seems not to be an issue any more for sparc64/linux, but the
> general upstream
> >> neglect of sparc64 seems to be the major problem.
> >
> > Rust is evil... however as you write it does not to be the biggest
> problem here.
>
> Calling Rust "evil" is not a technical argument but an emotional one.
>
> > The major issue is endianness - current FireFox runs on PPC64 but is
> totally unusable.
> > Everything in the UI has mangled colors, endianness is broken at about
> every level.
> > E.g. FF relies now a lot on skia and officially it will never support
> BE. And so a
> > lot of other issues, including Mesa.
>
> As I mentioned before, Oracle officially support Firefox on Solaris on
> SPARC and thus
> on a big-endian system. Debian ships Firefox on s390x as a supported
> package.
>
> Claiming that Firefox is a mess on big-endian is definitely not accurate
> although
> Firefox upstream does not officially support big-endian targets, but they
> don't
> prevent it either.
>
> > Add to endianness issues that SPARCs are sensitive to memory alignment
> and issues and you get the crashes.
>
> The more Rust code Firefox has, the less likely this is going to happen as
> Rust is much
> stricter with alignment than C/C++.
>
> > I am working since a long time on ArcticFox and intend to keep it as
> much as possible
> > cross-platform, close to Firefox, but incorporating as many fixes done
> for TenFourFox
> > as I can. Currently, it is quite usable on PPC, although there are
> endianness issues
> > with image composition operations. I can browser Wikipedia and even
> watch a youtube
> > video with audio. That is already impossible with standard Firefox.
>
> Well, it's based on an ancient Firefox code base which is why it still has
> many of the
> old bugs that have been fixed in the mean time.
>
> >> I would like to hear opinions on how to proceed or if you think this is
> a lost cause?
> >
> >
> > It is not a lost cause, but it is a hard cause, not well supported by
> upstream. I intend
> > to generalize a lot of TenFourFox patches in ArcticFox, but it requires
> work.
> >
> > NetBSD should have a working FF (I think FF 52) on SPARC.
> >
> > I was finally able to compile ArcticFox on NetBSD/SPARC64 and
> Linux/SPARC64. It will start,
> > show a window but crash very soon. That's already an improvement
> compared to crashing immediately
> > as it did one year ago!
>
> We have already had a fully working Rust-based Firefox on SPARC. I don't
> think it's a good
> idea to use these ancient versions, especially since there is no official
> security support.
>
> > For this cause, I need help - I am working alone and I have no real
> Gecko knowledge. I need
> > to port patches from Gecko to improve certain parts, so I need somebody
> how knows Firefox
> > code more than me to help me understand why certain give issues. Not
> specific SPARC, but I
> > work mostly on amd64 and arm64 and then "test" on PPC and SPARC (my
> netra T1 takes 20 hours
> > to compile ArcticFox) So if you know somebody who can help me with
> some specific issues
> > please ping me. I have some blocking issues I need to solve so that
> ArcticFox doesn't die
> > out and can evolve, specifically some JavaScript and JIT issues,
> currently verified on Intel.
>
> It's probably a better idea to start working on separating the Javascript
> transpilation process
> in the Firefox build system from the build process for the native code as
> this will remove
> the NodeJS build dependency for Firefox.
>
> Firefox itself does not require NodeJS. It's just that the Mozilla
> developers decided to pull
> in NodeJS as a hard dependency for the build so that the Javascript files
> are always freshly
> 

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hello!

On 11/14/21 17:58, Riccardo Mottola wrote:
>> i would be very interested in getting Firefox and Thunderbird (and possibly
>> Seamonkey, but this isn't available at all with debian it seam) running, if
>> possible at all for the newer versions.
> 
> yes, SeaMonkey is for me a missed package for both Debian/Devuan and FreeBSD.
> I just love it. I like the classic interface and can't stand the chrome-like
> of Firefox.

There is currently no one willing to step up being the maintainer of Seamonkey
in Debian which is why it's currently not included.

> SeaMonkey up to 2.49 was FF 52 based, so very portable and no rust. It should
> be a decent candidate to get it running on SPARC, since a specific Mac PPC G5
> version was maintained for a long time. Current SM is FF 60 based and so has 
> rust

Rust is available on SPARC and fully supported.

>> Rust seems not to be an issue any more for sparc64/linux, but the general 
>> upstream
>> neglect of sparc64 seems to be the major problem.
> 
> Rust is evil... however as you write it does not to be the biggest problem 
> here.

Calling Rust "evil" is not a technical argument but an emotional one.

> The major issue is endianness - current FireFox runs on PPC64 but is totally 
> unusable.
> Everything in the UI has mangled colors, endianness is broken at about every 
> level.
> E.g. FF relies now a lot on skia and officially it will never support BE. And 
> so a
> lot of other issues, including Mesa.

As I mentioned before, Oracle officially support Firefox on Solaris on SPARC 
and thus
on a big-endian system. Debian ships Firefox on s390x as a supported package.

Claiming that Firefox is a mess on big-endian is definitely not accurate 
although
Firefox upstream does not officially support big-endian targets, but they don't
prevent it either.

> Add to endianness issues that SPARCs are sensitive to memory alignment and 
> issues and you get the crashes.

The more Rust code Firefox has, the less likely this is going to happen as Rust 
is much
stricter with alignment than C/C++.

> I am working since a long time on ArcticFox and intend to keep it as much as 
> possible
> cross-platform, close to Firefox, but incorporating as many fixes done for 
> TenFourFox
> as I can. Currently, it is quite usable on PPC, although there are endianness 
> issues
> with image composition operations. I can browser Wikipedia and even watch a 
> youtube
> video with audio. That is already impossible with standard Firefox.

Well, it's based on an ancient Firefox code base which is why it still has many 
of the
old bugs that have been fixed in the mean time.

>> I would like to hear opinions on how to proceed or if you think this is a 
>> lost cause?
> 
> 
> It is not a lost cause, but it is a hard cause, not well supported by 
> upstream. I intend
> to generalize a lot of TenFourFox patches in ArcticFox, but it requires work.
> 
> NetBSD should have a working FF (I think FF 52) on SPARC.
> 
> I was finally able to compile ArcticFox on NetBSD/SPARC64 and Linux/SPARC64. 
> It will start,
> show a window but crash very soon. That's already an improvement compared to 
> crashing immediately
> as it did one year ago!

We have already had a fully working Rust-based Firefox on SPARC. I don't think 
it's a good
idea to use these ancient versions, especially since there is no official 
security support.

> For this cause, I need help - I am working alone and I have no real Gecko 
> knowledge. I need
> to port patches from Gecko to improve certain parts, so I need somebody how 
> knows Firefox
> code more than me to help me understand why certain give issues. Not specific 
> SPARC, but I
> work mostly on amd64 and arm64 and then "test" on PPC and SPARC (my netra T1 
> takes 20 hours
> to compile ArcticFox) So if you know somebody who can help me with some 
> specific issues
> please ping me. I have some blocking issues I need to solve so that ArcticFox 
> doesn't die
> out and can evolve, specifically some JavaScript and JIT issues, currently 
> verified on Intel.

It's probably a better idea to start working on separating the Javascript 
transpilation process
in the Firefox build system from the build process for the native code as this 
will remove
the NodeJS build dependency for Firefox.

Firefox itself does not require NodeJS. It's just that the Mozilla developers 
decided to pull
in NodeJS as a hard dependency for the build so that the Javascript files are 
always freshly
transpiled from the source.

However, the transpilation process does not necessarily have to happen on the 
same architecture
and one can transpile the Javascript files on x86_64 and copy them into the 
Firefox build
tree later. This is what Oracle does on Solaris and we could do the same on 
Debian by moving
the transpiled Javascript packages into a firefox-common package which will be 
used by the
firefox package on the various architectures.

This way we could use current versions of Firefox and wouldn't be stuck 

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hi Riccardo,

thank you for your reply and insights into the matter.

I have Firefox52 and Thunderbird52 up and running on NetBSD9.2/Sparc64
compiled from pkgsrc.
Now i wanted to do the same on Debian/Sparc64, but the pkgsrc patches seem
to be custom created for NetBSD by Martin Husemann, and they will not build
on Debian ootb.
While NetBSD is a fine system, i can get more software to compile and run
on Debian/Sparc64, like Libreoffice, xrdp-server and others. NetBSD is also
missing rust and ada on sparc64.

On Debian I tried to apply various sparc64 patches i found left and right
on the internet, could get pkgsrc's firefox52 and thunderbird52 to build
but they will not run and bus error out in libxul.so.
So i will try soon to rebuild firefox50 from debian source package as
Adrian told and try to apply some patches i found for the "[GFX1]: Unknown
image format 1" errors and others that
are filling up the console.

But as these versions are old and not security fixed, it makes less and
less sense to use those for anything on the internet. This led me to the
fitting of Raspberry-Pis 3 into my workstations which will display their
up-to-date browsers on the screen via ssh x forwarding. But of course this
is cheating, i would rather have them do it natively on their own.

So I will also try to build your ArcticFox. Somehow i did not come across
it yet, thank you for the suggestion.
Unfortunately i am an intermediate end user in this regard. I can apply
patches, work around certain library problems and get stuff to compile, but
i can't help with coding.
So if it helps at all, if someone compiles and tests it, let me know.

Sparc64 as a platform is almost dead and i know that as a result most
projects still doing something for it are mostly one-man shows.
But it is still fun to have the boxes running and i am also still planning
to get some of those beefier T3-T8 servers once they are cheaply available
on ebay and when i have more experience in quieting them down without
killing them.

Regards,
Connor



On Sun, Nov 14, 2021 at 6:06 PM Riccardo Mottola 
wrote:

> Hi Connor,
>
>
> you touch a delicate subject. You touch both endianness and SPARC cpu in
>
> On 11/6/21 5:05 PM, Connor McLaughlan wrote:
> > Hello All,
> >
> > i would be very interested in getting Firefox and Thunderbird (and
> > possibly Seamonkey, but this isn't available at all with debian it
> > seam) running, if possible at all for the newer versions.
>
>
> yes, SeaMonkey is for me a missed package for both Debian/Devuan and
> FreeBSD. I just love it. I like the classic interface and can't stand
> the chrome-like of Firefox.
>
> SeaMonkey up to 2.49 was FF 52 based, so very portable and no rust. It
> should be a decent candidate to get it running on SPARC, since a
> specific Mac PPC G5 version was maintained for a long time. Current SM
> is FF 60 based and so has rust
>
>
> >
> > Rust seems not to be an issue any more for sparc64/linux, but the
> > general upstream neglect of sparc64 seems to be the major problem.
>
> Rust is evil... however as you write it does not to be the biggest
> problem here.
>
> The major issue is endianness - current FireFox runs on PPC64 but is
> totally unusable. Everything in the UI has mangled colors, endianness is
> broken at about every level. E.g. FF relies now a lot on skia and
> officially it will never support BE. And so a lot of other issues,
> including Mesa.
>
> Add to endianness issues that SPARCs are sensitive to memory alignment
> and issues and you get the crashes.
>
>
> I follow the Big Endian issues closely, since I am interested in getting
> a usable browser on PPC, but it is an uphill road. I have been in
> contact for a long time with Cameron Kaiser who maintained TenFourFox
> (winding down activity right this year) and which as an excellent
> browser on MacOS PPC. Some of his patches were accepted upstream, but
> several not. His browser fork however is heavily MacOS 10.4 optimized
> (hence the name).
>
> I am working since a long time on ArcticFox and intend to keep it as
> much as possible cross-platform, close to Firefox, but incorporating as
> many fixes done for TenFourFox as I can. Currently, it is quite usable
> on PPC, although there are endianness issues with image composition
> operations. I can browser Wikipedia and even watch a youtube video with
> audio. That is already impossible with standard Firefox.
>
>
> >
> > I would like to hear opinions on how to proceed or if you think this
> > is a lost cause?
>
>
> It is not a lost cause, but it is a hard cause, not well supported by
> upstream. I intend to generalize a lot of TenFourFox patches in
> ArcticFox, but it requires work.
>
> NetBSD should have a working FF (I think FF 52) on SPARC.
>
> I was finally able to compile ArcticFox on NetBSD/SPARC64 and
> Linux/SPARC64. It will start, show a window but crash very soon. That's
> already an improvement compared to crashing immediately as it did one
> year ago!
>
>
> For this cause, I 

Re: Mozilla Software on Sparc64/Linux

[Riccardo Mottola]

Hi Connor,


you touch a delicate subject. You touch both endianness and SPARC cpu in

On 11/6/21 5:05 PM, Connor McLaughlan wrote:

Hello All,

i would be very interested in getting Firefox and Thunderbird (and 
possibly Seamonkey, but this isn't available at all with debian it 
seam) running, if possible at all for the newer versions.



yes, SeaMonkey is for me a missed package for both Debian/Devuan and 
FreeBSD. I just love it. I like the classic interface and can't stand 
the chrome-like of Firefox.


SeaMonkey up to 2.49 was FF 52 based, so very portable and no rust. It 
should be a decent candidate to get it running on SPARC, since a 
specific Mac PPC G5 version was maintained for a long time. Current SM 
is FF 60 based and so has rust





Rust seems not to be an issue any more for sparc64/linux, but the 
general upstream neglect of sparc64 seems to be the major problem.


Rust is evil... however as you write it does not to be the biggest 
problem here.


The major issue is endianness - current FireFox runs on PPC64 but is 
totally unusable. Everything in the UI has mangled colors, endianness is 
broken at about every level. E.g. FF relies now a lot on skia and 
officially it will never support BE. And so a lot of other issues, 
including Mesa.


Add to endianness issues that SPARCs are sensitive to memory alignment 
and issues and you get the crashes.



I follow the Big Endian issues closely, since I am interested in getting 
a usable browser on PPC, but it is an uphill road. I have been in 
contact for a long time with Cameron Kaiser who maintained TenFourFox 
(winding down activity right this year) and which as an excellent 
browser on MacOS PPC. Some of his patches were accepted upstream, but 
several not. His browser fork however is heavily MacOS 10.4 optimized 
(hence the name).


I am working since a long time on ArcticFox and intend to keep it as 
much as possible cross-platform, close to Firefox, but incorporating as 
many fixes done for TenFourFox as I can. Currently, it is quite usable 
on PPC, although there are endianness issues with image composition 
operations. I can browser Wikipedia and even watch a youtube video with 
audio. That is already impossible with standard Firefox.





I would like to hear opinions on how to proceed or if you think this 
is a lost cause?



It is not a lost cause, but it is a hard cause, not well supported by 
upstream. I intend to generalize a lot of TenFourFox patches in 
ArcticFox, but it requires work.


NetBSD should have a working FF (I think FF 52) on SPARC.

I was finally able to compile ArcticFox on NetBSD/SPARC64 and 
Linux/SPARC64. It will start, show a window but crash very soon. That's 
already an improvement compared to crashing immediately as it did one 
year ago!



For this cause, I need help - I am working alone and I have no real 
Gecko knowledge. I need to port patches from Gecko to improve certain 
parts, so I need somebody how knows Firefox code more than me to help me 
understand why certain give issues. Not specific SPARC, but I work 
mostly on amd64 and arm64 and then "test" on PPC and SPARC (my netra T1 
takes 20 hours to compile ArcticFox) So if you know somebody who can 
help me with some specific issues please ping me. I have some blocking 
issues I need to solve so that ArcticFox doesn't die out and can evolve, 
specifically some JavaScript and JIT issues, currently verified on Intel.



I have the hardware, I can test and often GDB stacktraces are quite 
meaningless if a debug is not used. I need real "code" help, if you know 
somebody, please point him.



Riccardo

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hello Gregor!

On 11/10/21 15:28, Gregor Riepl wrote:
>> I guess i have to then load the specific source package form snapshot
>> manually?
> 
> Isn't it possible to add a specific snapshot as deb-src to your
> sources.list?
> 
> Something like this should work:
> deb-src https://snapshot.debian.org/archive/debian// sid main

Yes, that's possible as well. But then you need to take care of the signing 
issues
as the signatures for these snapshot archives have been expired. It's explained
on the snapshot.debian.org main page.

There are plans to add support for resigning the Release/Package files for
snapshot.d.o in the future to alleviate this problem.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Gregor Riepl]

> but how would this work for a patch set of a specific old release .deb
> where the .deb is only available on snapshot.debian.org
> ?
> 
> I guess i have to then load the specific source package form snapshot
> manually?

Isn't it possible to add a specific snapshot as deb-src to your
sources.list?

Something like this should work:
deb-src https://snapshot.debian.org/archive/debian// sid main

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hi!

On 11/10/21 10:04, Hermann Lauer wrote:
>  apt-get source 
> 
> The debian specific stuff is in the debian/ directory, also the debian 
> specific patches.
> 
> 
> To get the the dependencies needed for building:
>  apt-get build-dep 

The better approach is to setup sbuild as explained here:

> https://wiki.debian.org/sbuild

Then look at the previous build logs and pick a Firefox version that built 
successfully:

> https://buildd.debian.org/status/logs.php?pkg=firefox=sparc64

That would be 63.0.3-1.

Then search for that version on snapshot.debian.org and download it:

$ dget -u 
http://snapshot.debian.org/archive/debian/20181003T162948Z/pool/main/f/firefox/firefox_62.0.3-1.dsc

Then build that package with:

$ sbuild -d sid --arch=sparc64 --no-arch-all firefox_62.0.3-1.dsc

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hello Hermann,

but how would this work for a patch set of a specific old release .deb
where the .deb is only available on snapshot.debian.org?

I guess i have to then load the specific source package form snapshot
manually?

Regards,
Connor

On Wed, Nov 10, 2021 at 10:04 AM Hermann Lauer <
hermann.la...@iwr.uni-heidelberg.de> wrote:

> Hi Connoer,
>
> On Tue, Nov 09, 2021 at 10:59:47PM +0100, Connor McLaughlan wrote:
> > Hi Adrian,
> >
> > thank you for your time. This sounds a bit complicated for the newer
> > versions.
> >
> > Currently i don't know where to start.
> > I was trying to build the old firefox52 and thunderbird52 which run on
> > NetBSD/Sparc64 from pkgsrc and manually. The thunderbird52 exists on
> debian
> > and the firefox package did skip 52 and was only released as a 50 with
> > error messages filling up the console. I can get them to build with
> pkgsrc
> > and manually but some patches seem to be missing to avoid bus errors in
> > libxul.so on debian.
> >
> > Unfortunately i don't know yet how debian builds its own packages and
> where
> > to find the patches used in those builds, so that i could reproduce the
> > building of firefox50 and thunderbird52 to maybe learn something as a
> > starting point.
>
>  apt-get source 
>
> The debian specific stuff is in the debian/ directory, also the debian
> specific patches.
>
>
> To get the the dependencies needed for building:
>  apt-get build-dep 
>
> Good luck,
>  greetings
>Hermann
>
> --
> Administration/Zentrale Dienste, Interdiziplinaeres
> Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
> IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427
> Email: hermann.la...@iwr.uni-heidelberg.de
>

Re: Re: Mozilla Software on Sparc64/Linux

[Hermann Lauer]

Hi Connoer,

On Tue, Nov 09, 2021 at 10:59:47PM +0100, Connor McLaughlan wrote:
> Hi Adrian,
> 
> thank you for your time. This sounds a bit complicated for the newer
> versions.
> 
> Currently i don't know where to start.
> I was trying to build the old firefox52 and thunderbird52 which run on
> NetBSD/Sparc64 from pkgsrc and manually. The thunderbird52 exists on debian
> and the firefox package did skip 52 and was only released as a 50 with
> error messages filling up the console. I can get them to build with pkgsrc
> and manually but some patches seem to be missing to avoid bus errors in
> libxul.so on debian.
> 
> Unfortunately i don't know yet how debian builds its own packages and where
> to find the patches used in those builds, so that i could reproduce the
> building of firefox50 and thunderbird52 to maybe learn something as a
> starting point.

 apt-get source 

The debian specific stuff is in the debian/ directory, also the debian specific 
patches.


To get the the dependencies needed for building:
 apt-get build-dep 

Good luck,
 greetings
   Hermann

-- 
Administration/Zentrale Dienste, Interdiziplinaeres 
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427
Email: hermann.la...@iwr.uni-heidelberg.de

Re: Mozilla Software on Sparc64/Linux

[Connor McLaughlan]

Hi Adrian,

thank you for your time. This sounds a bit complicated for the newer
versions.

Currently i don't know where to start.
I was trying to build the old firefox52 and thunderbird52 which run on
NetBSD/Sparc64 from pkgsrc and manually. The thunderbird52 exists on debian
and the firefox package did skip 52 and was only released as a 50 with
error messages filling up the console. I can get them to build with pkgsrc
and manually but some patches seem to be missing to avoid bus errors in
libxul.so on debian.

Unfortunately i don't know yet how debian builds its own packages and where
to find the patches used in those builds, so that i could reproduce the
building of firefox50 and thunderbird52 to maybe learn something as a
starting point.

Regards,
Connor



On Tue, Nov 9, 2021 at 12:55 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 11/8/21 11:07, Rick Leir wrote:
> > The reason that I think PPC is related is that, if it is also BE then
> PPC users may
> > have solved some of the compatibility problems that we experience. I
> realize that
> > there's  a difference in this between PPC and Sparc; but some of the
> PPC  fixes can
> > at least suggest Sparc fixes as long as they have stayed BE. IBM is
> putting considerable
> > effort into this.
>
> The fundamental problem with Firefox and Thunderbird is that building both
> requires NodeJS.
>
> There is no NodeJS for SPARC which is why you have to compile the
> JavaScript sources on a
> different architecture and then put them into the SPARC
> Firefox/Thunderbird packages, see:
>
> >
> https://github.com/oracle/solaris-userland/tree/master/components/desktop/firefox/wrapper-node
>
> This has got nothing to do with big-endian vs. little-endian.
>
> > I talked with an IBM consultant at the X11 conference in Montreal two
> years ago. But we didn't
> > discuss Sparc. And I didn't discuss IBM changing to LE. Is it true?
>
> IBM is supporting Linux on POWER both big- and little-endian. Their
> zSeries mainframes are BE
> and so is AIX on POWER.
>
> Big-endian is not going anywhere, doesn't matter what anyone on Phoronix
> or the LKML writes.
>
> And it's not related to Firefox or Thunderbird on SPARC as explained above.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

On 11/8/21 11:07, Rick Leir wrote:
> The reason that I think PPC is related is that, if it is also BE then PPC 
> users may
> have solved some of the compatibility problems that we experience. I realize 
> that
> there's  a difference in this between PPC and Sparc; but some of the PPC  
> fixes can
> at least suggest Sparc fixes as long as they have stayed BE. IBM is putting 
> considerable
> effort into this.

The fundamental problem with Firefox and Thunderbird is that building both 
requires NodeJS.

There is no NodeJS for SPARC which is why you have to compile the JavaScript 
sources on a
different architecture and then put them into the SPARC Firefox/Thunderbird 
packages, see:

> https://github.com/oracle/solaris-userland/tree/master/components/desktop/firefox/wrapper-node

This has got nothing to do with big-endian vs. little-endian.

> I talked with an IBM consultant at the X11 conference in Montreal two years 
> ago. But we didn't
> discuss Sparc. And I didn't discuss IBM changing to LE. Is it true?

IBM is supporting Linux on POWER both big- and little-endian. Their zSeries 
mainframes are BE
and so is AIX on POWER.

Big-endian is not going anywhere, doesn't matter what anyone on Phoronix or the 
LKML writes.

And it's not related to Firefox or Thunderbird on SPARC as explained above.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[Rick Leir]

Hi Adrian
The reason that I think PPC is related is that, if it is also BE then PPC users 
may have solved some of the compatibility problems that we experience. I 
realize that there's  a difference in this between PPC and Sparc; but some of 
the PPC  fixes can at least suggest Sparc fixes as long as they have stayed BE. 
IBM is putting considerable effort into this.

I talked with an IBM consultant at the X11 conference in Montreal two years 
ago. But we didn't discuss Sparc. And I didn't discuss IBM changing to LE. Is 
it true?

Cheers -- Rick


On November 7, 2021 5:18:54 p.m. EST, John Paul Adrian Glaubitz 
 wrote:
>Hello Rick!
>
>On 11/7/21 22:44, rl...@leirtech.com wrote:
>> This thread below claims that Big-Endian is dead (2015). It says that IBM 
>> changed
>> their PowerPC's from BE to LE. Also that web developers assume LE.
>
>Not sure how your comment is  related to the original question but let me just 
>add this:
>
>- IBM's s390x architecture is fully supported and one of IBM's cash cows and 
>it's big-endian
>- IBM's AIX operating system which IBM is still actively developing and 
>selling is big-endian
>
>> Adrian explained the problem in Firefox a while ago, it was complex.
>
>Not really. Firefox on Solaris/SPARC exists and works. It's not complex, it's 
>just that I am
>doing the work here alone. I was planning to write an answer to this mail but 
>I haven't gotten
>around to doing that.
>
>> The words of Linus:
>> 
>> https://lkml.org/lkml/2015/4/24/606
>> 
>> Linux Plumbers Congress 2020:
>> 
>> https://lwn.net/Articles/829733/
>
>Linus is not the center of the universe.
>
>Adrian
>
>-- 
> .''`.  John Paul Adrian Glaubitz
>: :' :  Debian Developer - glaub...@debian.org
>`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

-- 
Sorry for being brief. Alternate email is rickleir at yahoo dot com 

Re: Mozilla Software on Sparc64/Linux

[John Paul Adrian Glaubitz]

Hello Rick!

On 11/7/21 22:44, rl...@leirtech.com wrote:
> This thread below claims that Big-Endian is dead (2015). It says that IBM 
> changed
> their PowerPC's from BE to LE. Also that web developers assume LE.

Not sure how your comment is  related to the original question but let me just 
add this:

- IBM's s390x architecture is fully supported and one of IBM's cash cows and 
it's big-endian
- IBM's AIX operating system which IBM is still actively developing and selling 
is big-endian

> Adrian explained the problem in Firefox a while ago, it was complex.

Not really. Firefox on Solaris/SPARC exists and works. It's not complex, it's 
just that I am
doing the work here alone. I was planning to write an answer to this mail but I 
haven't gotten
around to doing that.

> The words of Linus:
> 
> https://lkml.org/lkml/2015/4/24/606
> 
> Linux Plumbers Congress 2020:
> 
> https://lwn.net/Articles/829733/

Linus is not the center of the universe.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Mozilla Software on Sparc64/Linux

[rleir]

Connor

This thread below claims that Big-Endian is dead (2015). It says that 
IBM changed their PowerPC's from BE to LE. Also that web developers 
assume LE.


https://news.ycombinator.com/item?id=9451284

https://news.ycombinator.com/item?id=16187939#:~:text=Big%20endian%20is%20dead%20on%20the%20client.=Big%20endian%20will%20stay%20alive,time%20on%20IBM%20z%20systems.

https://www.reddit.com/r/linux/comments/3467gq/bigendian_is_effectively_dead/

It ticks me off because I like BE better. And one of the most common 
architectures, ARM, is switchable between BE and LE. It is normally used 
as LE, but that is not stopping you.


Adrian explained the problem in Firefox a while ago, it was complex.

The words of Linus:

https://lkml.org/lkml/2015/4/24/606

Linux Plumbers Congress 2020:

https://lwn.net/Articles/829733/

Is it a lost cause? Rephrase that: how many of us want and need to 
scratch the itch?


cheers -- Rick

On 11/6/21 12:05 PM, Connor McLaughlan wrote:

Hello All,

i would be very interested in getting Firefox and Thunderbird (and 
possibly Seamonkey, but this isn't available at all with debian it 
seam) running, if possible at all for the newer versions.


I would be willing to file error reports and produce gdb output on 
crashes, if this would help and someone could direct me to information 
on how and where to do it for debian.
I have a few Sparc64 machines (Ultra45, Blade100, Ultra10, T1000, 
V120) to test.


What i can get running (but also with errors) are only to following 
two versions:

firefox_50.1.0-1_sparc64.deb
thunderbird_52.9.1-1_sparc64.deb

All later packages crash with bus errors.

But as the latest versions for Sparc64 are well behind the releases on 
the other architectures, would debian even accept bug reports for 
older packages? (eg. firefox-esr 78 x86_64 vs. firefox-esr 60 sparc64)


Rust seems not to be an issue any more for sparc64/linux, but the 
general upstream neglect of sparc64 seems to be the major problem.


I would like to hear opinions on how to proceed or if you think this 
is a lost cause?


Regards,
Connor