Re: sparc64 most important tasks

[John Paul Adrian Glaubitz]

Hi!

On 8/7/18 11:53 AM, John Paul Adrian Glaubitz wrote:
> rustc: incremental compilation: could not create session directory lock file: 
> No locks available (os error 37)
> 
>> https://github.com/rust-lang/rust/issues/49773

This has been fixed, btw. I have pushed several SPARC-related fixes over the
holidays to Rust upstream so that the Rust compiler on sparc64 is in a pretty
good shape now.

We still have a couple of failing tests, but the number of testsuite failures
dropped from around 180 to just around 40. For a short time, a serious bug in
the compiler even made the number of failures jump to over 500.

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: sparc64 most important tasks

[John Paul Adrian Glaubitz]

Hi!

On 1/11/19 1:55 AM, Rick Leir wrote:
> What is on your current top pri bug list?
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879970
>> grub2: FTBTS (no bug report yet)
Fixing grub2. I have already some loose ends that I just need to
tie together to fix grub2.

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: sparc64 most important tasks

[Rick Leir]

Hi Adrian

What is on your current top pri bug list?

Thanks -- Rick

On 8/7/18 5:53 AM, John Paul Adrian Glaubitz wrote:

Hi!

In case anyone wonders, here's a list of top priority bugs on
sparc64 that need to be worked on:

hfst-ospell: Testsuite fails on linux-sparc64


https://github.com/hfst/hfst-ospell/issues/43

linux: Application run by unprivileged user can crash the kernel on sparc64


https://bugzilla.kernel.org/show_bug.cgi?id=200625

qtscript-opensource-src: Please include patch to workaround memory issues on 
sparc64


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

rustc: incremental compilation: could not create session directory lock file: 
No locks available (os error 37)


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

firefox: Early startup crash on Linux sparc64 in HashIIDPtrKey (Bus Error)


https://bugzilla.mozilla.org/show_bug.cgi?id=1434726

harfbuzz: FTBFS on sparc64, testsuite failures


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

openexr: DwaCompressor endianess issue


https://github.com/openexr/openexr/issues/222

qtwebsockets-opensource-src: FTBFS on sparc64 and x32: tst_qmlwebsockets 
segfault at startup


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

grub2: FTBTS (no bug report yet)


https://buildd.debian.org/status/fetch.php?pkg=grub2=sparc64=2.02%2Bdfsg1-5=1533001924=0

So, if anyone is wondering what they can do to help, there is now
a list. If you need more details, let us know.

Thanks,
Adrian

Re: sparc64 most important tasks

[Gregor Riepl]

> I don't know if this is helpful, but Ubuntu Launchpad has a ppa package for
> elftoaout which has been built recently.
> 
> https://launchpad.net/~likemartinma/+archive/ubuntu/elftoaout

Thanks for the pointer, but we have the tool in the repos already.
It's in the sparc-utils package. But it would be better to add the tool's
sources to the grub2 tree and build it in-place, then use that to convert the
binary (as Adrian suggested).

Something that needs to be discussed with the grub2 maintainers.

Re: sparc64 most important tasks

[John Paul Adrian Glaubitz]

Hi Rick!

I’m aware that the elftoaout utility exists, this isn’t really my concern 
though.

I’m concerned about an upstream solution, preferably with an elftoaout utility 
being part of the upstream sources.

Adrian

> On Aug 20, 2018, at 12:14 PM, Rick Leir  wrote:
> 
> Hi Gregor, Adrian
> I don't know if this is helpful, but Ubuntu Launchpad has a ppa package for 
> elftoaout which has been built recently.
> 
> https://launchpad.net/~likemartinma/+archive/ubuntu/elftoaout
> Cheers -- Rick
> 
>> On August 10, 2018 8:12:47 PM ADT, Gregor Riepl  wrote:
>  We could modify sparc-utils maybe that it builds on the release
>  architectures similar to what the hppa porters do with their palo 
> package.
 
  I'll have a look. It doesn't look like this package would only build/work 
 on
  sparc. Usefulness is a different matter - but that's probably outside the
  scope of acceptance criteria?
>>>  
>>>  Correct. Usefulness doesn't matter. Maybe there is another package or
>>>  upstream project that offers an elftoaout tool?
>> 
>> So for now, I manually modified the boot image build step to strip with
>> objcopy first, then convert with elftoaout from sparc-utils.
>> 
>> The resulting boot.img is identical to the one installed by
>> grub-ieee1275-bin_2.02+dfsg1-4 - that looks promising!
>> This means we have at least a method to build the boot code without a.out
>> support in objcopy. I also looked into making OpenBoot run the ELF binary
>> directly, but that seems impossible for an unexpected reason: boot.img is
>> written directly into the boot sector of the /boot partition, and there is
>> simply not enough space to accommodate the ELF binary. It's 816 bytes, while
>> the a.out is exactly 512.
>> 
>> I'll discuss integrating the change with the grub2 package maintainer and
>> upstream, if that's ok for you. And I'll take a look at the sparc-utils
>> package, maybe making it build for any instead of just sparc64 (as 
>> discussed).
>> 
> 
> -- 
> Sorry for being brief. Alternate email is rickleir at yahoo dot com

Re: sparc64 most important tasks

[Rick Leir]

Hi Gregor, Adrian
I don't know if this is helpful, but Ubuntu Launchpad has a ppa package for 
elftoaout which has been built recently.

https://launchpad.net/~likemartinma/+archive/ubuntu/elftoaout
Cheers -- Rick

On August 10, 2018 8:12:47 PM ADT, Gregor Riepl  wrote:
 We could modify sparc-utils maybe that it builds on the release
 architectures similar to what the hppa porters do with their palo
>package.
>>>
>>> I'll have a look. It doesn't look like this package would only
>build/work on
>>> sparc. Usefulness is a different matter - but that's probably
>outside the
>>> scope of acceptance criteria?
>> 
>> Correct. Usefulness doesn't matter. Maybe there is another package or
>> upstream project that offers an elftoaout tool?
>
>So for now, I manually modified the boot image build step to strip with
>objcopy first, then convert with elftoaout from sparc-utils.
>
>The resulting boot.img is identical to the one installed by
>grub-ieee1275-bin_2.02+dfsg1-4 - that looks promising!
>This means we have at least a method to build the boot code without
>a.out
>support in objcopy. I also looked into making OpenBoot run the ELF
>binary
>directly, but that seems impossible for an unexpected reason: boot.img
>is
>written directly into the boot sector of the /boot partition, and there
>is
>simply not enough space to accommodate the ELF binary. It's 816 bytes,
>while
>the a.out is exactly 512.
>
>I'll discuss integrating the change with the grub2 package maintainer
>and
>upstream, if that's ok for you. And I'll take a look at the sparc-utils
>package, maybe making it build for any instead of just sparc64 (as
>discussed).

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

Re: sparc64 most important tasks

[John Paul Adrian Glaubitz]

On 08/11/2018 01:12 AM, Gregor Riepl wrote:
> The resulting boot.img is identical to the one installed by
> grub-ieee1275-bin_2.02+dfsg1-4 - that looks promising!
> This means we have at least a method to build the boot code without a.out
> support in objcopy.

Sounds good. Thanks for testing.

> I also looked into making OpenBoot run the ELF binary
> directly, but that seems impossible for an unexpected reason: boot.img is
> written directly into the boot sector of the /boot partition, and there is
> simply not enough space to accommodate the ELF binary. It's 816 bytes, while
> the a.out is exactly 512.

I think the elftoaout solution is fine.

> I'll discuss integrating the change with the grub2 package maintainer and
> upstream, if that's ok for you. And I'll take a look at the sparc-utils
> package, maybe making it build for any instead of just sparc64 (as discussed).

I think upstream would have to incorporate elftoaout into their sources
so they don't depend on external, obscure tools.

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: sparc64 most important tasks

[Gregor Riepl]

>>> We could modify sparc-utils maybe that it builds on the release
>>> architectures similar to what the hppa porters do with their palo package.
>>
>> I'll have a look. It doesn't look like this package would only build/work on
>> sparc. Usefulness is a different matter - but that's probably outside the
>> scope of acceptance criteria?
> 
> Correct. Usefulness doesn't matter. Maybe there is another package or
> upstream project that offers an elftoaout tool?

So for now, I manually modified the boot image build step to strip with
objcopy first, then convert with elftoaout from sparc-utils.

The resulting boot.img is identical to the one installed by
grub-ieee1275-bin_2.02+dfsg1-4 - that looks promising!
This means we have at least a method to build the boot code without a.out
support in objcopy. I also looked into making OpenBoot run the ELF binary
directly, but that seems impossible for an unexpected reason: boot.img is
written directly into the boot sector of the /boot partition, and there is
simply not enough space to accommodate the ELF binary. It's 816 bytes, while
the a.out is exactly 512.

I'll discuss integrating the change with the grub2 package maintainer and
upstream, if that's ok for you. And I'll take a look at the sparc-utils
package, maybe making it build for any instead of just sparc64 (as discussed).

Re: sparc64 most important tasks

[John Paul Adrian Glaubitz]

On 08/10/2018 12:36 AM, Gregor Riepl wrote:
>> We could modify sparc-utils maybe that it builds on the release
>> architectures similar to what the hppa porters do with their palo package.
> 
> I'll have a look. It doesn't look like this package would only build/work on
> sparc. Usefulness is a different matter - but that's probably outside the
> scope of acceptance criteria?

Correct. Usefulness doesn't matter. Maybe there is another package or
upstream project that offers an elftoaout tool?

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: sparc64 most important tasks

[Gregor Riepl]

> Huh? sparc64 *is* UltraSPARC. Any SPARC machine made around the mid-90ies 
> is an UltraSPARC. Are you confusing sun4u and sun4v?

Maybe; I was referring to sun4u vs. other, older sparc32 architectures.
I had SparcStation at one point, and those were certainly not sparc64.
These are (obviously) not supported by debian-sparc64.

>> Ok. I'll contact them and ask if this is a good way to move forward. Why
>> is it in unreleased? Because of bugs, or because it's only available on
>> a ports architecture?
> 
> No. Because the sparc-utils package builds on a ports architecture only
> and a package that does not produce any binaries on the release
> architectures is not accepted by the archive.
> 
> We could modify sparc-utils maybe that it builds on the release
> architectures similar to what the hppa porters do with their palo package.

I'll have a look. It doesn't look like this package would only build/work on
sparc. Usefulness is a different matter - but that's probably outside the
scope of acceptance criteria?

Re: sparc64 most important tasks

[John Paul Adrian Glaubitz]

On 08/09/2018 11:49 PM, Gregor Riepl wrote:
>> Feel free to take this part over:
>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902635
> 
> Umm, ok. That's pushing it a bit.
> Where is that fix you mentioned in your last message, and what needs to be
> done to get it working? Or, are you going to finish this before your vacation?

What do you mean? The workaround is to switch the JS pointer type to 32 bits:

--- 
qtscript-opensource-src-5.10.1+dfsg.orig/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h
+++ 
qtscript-opensource-src-5.10.1+dfsg/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h
@@ -960,9 +960,9 @@
 #endif

 #if !defined(WTF_USE_JSVALUE64) && !defined(WTF_USE_JSVALUE32) && 
!defined(WTF_USE_JSVALUE32_64)
-#if (CPU(X86_64) && !CPU(X32) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || 
OS(HPUX))) || (CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) ||
CPU(SPARC64) || CPU(MIPS64) || CPU(AARCH64) || CPU(S390X)
+#if (CPU(X86_64) && !CPU(X32) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || 
OS(HPUX))) || (CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) ||
CPU(MIPS64) || CPU(AARCH64) || CPU(S390X)
 #define WTF_USE_JSVALUE64 1
-#elif CPU(ARM) || CPU(PPC64)
+#elif CPU(ARM) || CPU(PPC64) || CPU(SPARC64)
 #define WTF_USE_JSVALUE32 1
 #elif OS(WINDOWS) && COMPILER(MINGW)
 /* Using JSVALUE32_64 causes padding/alignement issues for JITStubArg

This fixes 99% of the issues. Some testsuite failures need to be addressed.

> Also, AFAIK there is no common debports-sparc64 group on Salsa where I have
> commit access and I'm not a DD, so if this is on a random repository the best
> I can do is submitting MRs and contacting the maintainers.

You can create an account on salsa and submit a merge request with the
patch. That would be the same I would do. While I am a DD and could
upload the package with the patch myself, the Qt maintainers would get
angry to me if I just did that.

>> I am going to be on vacation from Monday, so any help is appreciated.
>>
>> Also, while the workaround fixes most issues, there are still a handful of 
>> tests failing. Maybe you could look into that?
> 
> I can look into it, but as said, the Ultra 10 is not a very powerful machine
> and building large packages takes long time, so debugging is very inefficient.

You can apply for a Debian guest account here:

> https://dsa.debian.org/doc/guest-account/

I can approve it for you. Also, I could create an account on the slower
Sun Fire 2000 for you that we have. Send me a private mail. The DSA
guest account would give you access to our faster machine though.

>>> In any case, I understand that they want to avoid bit rot, but removing 
>>> coff and a.out is pushing it a bit. Any chance that it gets restored?
>>
>> No idea.
> 
>>> loading ELF binaries, but I have no clue about sun4u. Maybe I could try 
>>> this on my Ultra 10, or have you verified that it really doesn't work?
>>
>> That might be the case. But we officially support all UltraSPARCs, so 
>> switching to ELF format is a no-go.
> 
> Understandable; but since the Debian port is only supporting sparc64 for now,
> it might actually be possible that sparc64's already support ELF.
> I'll try to ask around, maybe I'll actually find out if this issue has come up
> before on other OS's.

Huh? sparc64 *is* UltraSPARC. Any SPARC machine made around the mid-90ies
is an UltraSPARC. Are you confusing sun4u and sun4v?

>>> Further down, someone suggested switching to elftoaout - does that tool
>>> still exist? Do we need to package it?
>>
>> It's part of sparc-utils that is currently in the unreleased repositories.
>>
>> And now that you mention it, I remember that SILO actually uses it in its 
>> build process.
>>
>> GRUB upstream mentioned they could do the same. Maybe you can make a
>> suggestion there.
> 
> Ok. I'll contact them and ask if this is a good way to move forward.
> Why is it in unreleased? Because of bugs, or because it's only available on a
> ports architecture?

No. Because the sparc-utils package builds on a ports architecture only and
a package that does not produce any binaries on the release architectures
is not accepted by the archive.

We could modify sparc-utils maybe that it builds on the release architectures
similar to what the hppa porters do with their palo package.

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: sparc64 most important tasks

[Gregor Riepl]

> Feel free to take this part over:
> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902635

Umm, ok. That's pushing it a bit.
Where is that fix you mentioned in your last message, and what needs to be
done to get it working? Or, are you going to finish this before your vacation?

Also, AFAIK there is no common debports-sparc64 group on Salsa where I have
commit access and I'm not a DD, so if this is on a random repository the best
I can do is submitting MRs and contacting the maintainers.

> I am going to be on vacation from Monday, so any help is appreciated.
> 
> Also, while the workaround fixes most issues, there are still a handful of 
> tests failing. Maybe you could look into that?

I can look into it, but as said, the Ultra 10 is not a very powerful machine
and building large packages takes long time, so debugging is very inefficient.

>> In any case, I understand that they want to avoid bit rot, but removing 
>> coff and a.out is pushing it a bit. Any chance that it gets restored?
> 
> No idea.

>> loading ELF binaries, but I have no clue about sun4u. Maybe I could try 
>> this on my Ultra 10, or have you verified that it really doesn't work?
> 
> That might be the case. But we officially support all UltraSPARCs, so 
> switching to ELF format is a no-go.

Understandable; but since the Debian port is only supporting sparc64 for now,
it might actually be possible that sparc64's already support ELF.
I'll try to ask around, maybe I'll actually find out if this issue has come up
before on other OS's.

>> Further down, someone suggested switching to elftoaout - does that tool
>> still exist? Do we need to package it?
> 
> It's part of sparc-utils that is currently in the unreleased repositories.
> 
> And now that you mention it, I remember that SILO actually uses it in its 
> build process.
> 
> GRUB upstream mentioned they could do the same. Maybe you can make a
> suggestion there.

Ok. I'll contact them and ask if this is a good way to move forward.
Why is it in unreleased? Because of bugs, or because it's only available on a
ports architecture?

Re: sparc64 most important tasks

[John Paul Adrian Glaubitz]

On 08/09/2018 08:37 PM, Gregor Riepl wrote:
>> It's a binutils bug: https://sourceware.org/ml/binutils/2018-08/msg00138.html
>>
>> Upstream intentionally removed a.out and coff support. I protested, it 
>> didn't help.
> 
> Further down, someone suggested switching to elftoaout - does that tool still
> exist? Do we need to package it?

It's part of sparc-utils that is currently in the unreleased repositories.

And now that you mention it, I remember that SILO actually uses it in its
build process.

GRUB upstream mentioned they could do the same. Maybe you can make a suggestion
there.

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: sparc64 most important tasks

[John Paul Adrian Glaubitz]

On 08/09/2018 08:31 PM, Gregor Riepl wrote:
> Still, I believe that at least newer OpenBoot versions actually support
> loading ELF binaries, but I have no clue about sun4u.
> Maybe I could try this on my Ultra 10, or have you verified that it really
> doesn't work?

That might be the case. But we officially support all UltraSPARCs, so switching
to ELF format is a no-go.

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: sparc64 most important tasks

[John Paul Adrian Glaubitz]

On 08/09/2018 08:03 PM, Gregor Riepl wrote:
>> I agree. I haven't had the time yet to upstream my patch to Qt yet. There
>> are a couple of other issues in upstream Qt code that I wanted to fix.
> 
> In the meantime, are you going to push a patch to the Debian repo, or do you
> need any help?

Feel free to take this part over:

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

I am going to be on vacation from Monday, so any help is appreciated.

Also, while the workaround fixes most issues, there are still a handful
of tests failing. Maybe you could look into that?

>> It's a binutils bug: https://sourceware.org/ml/binutils/2018-08/msg00138.html
>>
>> Upstream intentionally removed a.out and coff support. I protested, it 
>> didn't help.
> 
> Is a.out really required for the grub payload? I couldn't find anything in the
> specification you linked that says it is, except for FCode executables (which
> I assume grub-iee1275 isn't).
> 
> In any case, I understand that they want to avoid bit rot, but removing coff
> and a.out is pushing it a bit. Any chance that it gets restored?

No idea.

>>> Also, someone should make V4 JIT sparc64 compatible: https://wiki.qt.io/V4
>>> May or may not be a big task.
>>
>> So, another Javascript engine in this world which will use the braindead
>> concept of tagged pointers which assumes a 48-bit virtual address space?
> 
> You should have told them that before they implemented it that way. ;)

Well, they shouldn't make assumptions about the underlying hardware in the
first place. ARM64 also uses more than 48 bits.

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: sparc64 most important tasks

[Gregor Riepl]

> It's a binutils bug: https://sourceware.org/ml/binutils/2018-08/msg00138.html
> 
> Upstream intentionally removed a.out and coff support. I protested, it didn't 
> help.

Further down, someone suggested switching to elftoaout - does that tool still
exist? Do we need to package it?

Re: sparc64 most important tasks

[Gregor Riepl]

> It's a binutils bug: https://sourceware.org/ml/binutils/2018-08/msg00138.html
> 
> Upstream intentionally removed a.out and coff support. I protested, it didn't 
> help.

Looking at https://sourceware.org/ml/binutils/2018-08/msg00166.html - I think
it's likely a.out will be gone for good. Even if this argument is as bogus as
it gets - we should write a tool to replicate the sole purpose of objcopy?
What's the point of objcopy then?

Still, I believe that at least newer OpenBoot versions actually support
loading ELF binaries, but I have no clue about sun4u.
Maybe I could try this on my Ultra 10, or have you verified that it really
doesn't work?

Re: sparc64 most important tasks

[Gregor Riepl]

> I agree. I haven't had the time yet to upstream my patch to Qt yet. There
> are a couple of other issues in upstream Qt code that I wanted to fix.

In the meantime, are you going to push a patch to the Debian repo, or do you
need any help?

> It's a binutils bug: https://sourceware.org/ml/binutils/2018-08/msg00138.html
> 
> Upstream intentionally removed a.out and coff support. I protested, it didn't 
> help.

Is a.out really required for the grub payload? I couldn't find anything in the
specification you linked that says it is, except for FCode executables (which
I assume grub-iee1275 isn't).

In any case, I understand that they want to avoid bit rot, but removing coff
and a.out is pushing it a bit. Any chance that it gets restored?

>> Also, someone should make V4 JIT sparc64 compatible: https://wiki.qt.io/V4
>> May or may not be a big task.
> 
> So, another Javascript engine in this world which will use the braindead
> concept of tagged pointers which assumes a 48-bit virtual address space?

You should have told them that before they implemented it that way. ;)

Re: sparc64 most important tasks

[John Paul Adrian Glaubitz]

On 08/09/2018 07:18 PM, Gregor Riepl wrote:
>> qtwebsockets-opensource-src: FTBFS on sparc64 and x32: tst_qmlwebsockets 
>> segfault at startup
>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879970
> 
> I think this one is reported upstream and you already found a workaround for
> it? https://bugreports.qt.io/browse/QTBUG-56264
> Unless it's not the same bug as
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894726

Yes, it's the same bug.

> It's a pretty serious bug IMHO, because some other big packages (i.e.
> libreoffice) depend on this library:
> libreoffice -> kio -> kbookmarks -> kxmlgui -> ktextwidgets ->
> qtspeech-opensource-src -> qtmultimedia-opensource-src
> And of course, KDE.

I agree. I haven't had the time yet to upstream my patch to Qt yet. There
are a couple of other issues in upstream Qt code that I wanted to fix.

> Not as serious as the grub2 FTBFS though.

It's a binutils bug: https://sourceware.org/ml/binutils/2018-08/msg00138.html

Upstream intentionally removed a.out and coff support. I protested, it didn't 
help.

> Also, someone should make V4 JIT sparc64 compatible: https://wiki.qt.io/V4
> May or may not be a big task.

So, another Javascript engine in this world which will use the braindead
concept of tagged pointers which assumes a 48-bit virtual address space?

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: sparc64 most important tasks

[Gregor Riepl]

> qtwebsockets-opensource-src: FTBFS on sparc64 and x32: tst_qmlwebsockets 
> segfault at startup
> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879970

I think this one is reported upstream and you already found a workaround for
it? https://bugreports.qt.io/browse/QTBUG-56264
Unless it's not the same bug as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894726

It's a pretty serious bug IMHO, because some other big packages (i.e.
libreoffice) depend on this library:
libreoffice -> kio -> kbookmarks -> kxmlgui -> ktextwidgets ->
qtspeech-opensource-src -> qtmultimedia-opensource-src
And of course, KDE.

Not as serious as the grub2 FTBFS though.

Also, someone should make V4 JIT sparc64 compatible: https://wiki.qt.io/V4
May or may not be a big task.

Re: sparc64 most important tasks

[Frank Scheiner]

On 08/07/2018 05:52 PM, John Paul Adrian Glaubitz wrote:

On 08/07/2018 05:51 PM, John Paul Adrian Glaubitz wrote:

Hi Frank!

On 08/07/2018 05:41 PM, Frank Scheiner wrote:

I'm no expert in these matters, but as per e.g. [1] it looks like the target 
"a.out-sunos-big" is not supported by the used `objcopy`.

Yep, James already mentioned that on #debian-ports (you should really join now 
;)).


Not sure if I can find the time for all this, but I can at least try 
to... :-)




Upstream removed support for a.out and coff on sparc* and mips*, see:


https://sourceware.org/ml/binutils/2018-08/msg00138.html


Ooops and already happened in April. Would be cool if we knew the reason 
for this removal.


I sometimes wonder if it means more effort to (re-)port code to a 
specific architecture than to maintain existing code for a specific 
architecture.




Aha, COFF/A.OUT support for MIPS was already restored:


https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=8e415ce8fee234cd86f29d8f4ebbbdf0f9c0b031


Hopefully this can also be done for sparc(64).

Re: sparc64 most important tasks

[John Paul Adrian Glaubitz]

On 08/07/2018 05:51 PM, John Paul Adrian Glaubitz wrote:
> Hi Frank!
> 
> On 08/07/2018 05:41 PM, Frank Scheiner wrote:
>> I'm no expert in these matters, but as per e.g. [1] it looks like the target 
>> "a.out-sunos-big" is not supported by the used `objcopy`.
> Yep, James already mentioned that on #debian-ports (you should really join 
> now ;)).
> 
> Upstream removed support for a.out and coff on sparc* and mips*, see:
> 
>> https://sourceware.org/ml/binutils/2018-08/msg00138.html

Aha, COFF/A.OUT support for MIPS was already restored:

> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=8e415ce8fee234cd86f29d8f4ebbbdf0f9c0b031

-- 
 .''`.  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: sparc64 most important tasks

[John Paul Adrian Glaubitz]

Hi Frank!

On 08/07/2018 05:41 PM, Frank Scheiner wrote:
> I'm no expert in these matters, but as per e.g. [1] it looks like the target 
> "a.out-sunos-big" is not supported by the used `objcopy`.
Yep, James already mentioned that on #debian-ports (you should really join now 
;)).

Upstream removed support for a.out and coff on sparc* and mips*, see:

> https://sourceware.org/ml/binutils/2018-08/msg00138.html

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: sparc64 most important tasks

[Frank Scheiner]

Hi Adrian,

On 08/07/2018 11:53 AM, John Paul Adrian Glaubitz wrote:

In case anyone wonders, here's a list of top priority bugs on
sparc64 that need to be worked on:
[...]
grub2: FTBTS (no bug report yet)


https://buildd.debian.org/status/fetch.php?pkg=grub2=sparc64=2.02%2Bdfsg1-5=1533001924=0


```
[...]
if test x0 = x1; then   ../grub-macho2img boot.image boot.img; else 
objcopy  -O a.out-sunos-big  --strip-unneeded -R .note -R .comment -R 
.note.gnu.build-id -R .MIPS.abiflags -R .reginfo -R .rel.dyn -R 
.note.gnu.gold-version -R .ARM.exidx boot.image boot.img; fi


if test x0 = x1; then   ../grub-macho2img cdboot.image cdboot.img; else 
 objcopy  -O a.out-sunos-big  --strip-unneeded -R .note -R .comment -R 
.note.gnu.build-id -R .MIPS.abiflags -R .reginfo -R .rel.dyn -R 
.note.gnu.gold-version -R .ARM.exidx cdboot.image cdboot.img; fi


[...]

objcopy:boot.img: invalid bfd target

make[5]: *** [Makefile:42941: boot.img] Error 1
make[5]: *** Waiting for unfinished jobs

objcopy:cdboot.img: invalid bfd target
[...]
```

I'm no expert in these matters, but as per e.g. [1] it looks like the 
target "a.out-sunos-big" is not supported by the used `objcopy`.


[1]: https://github.com/yasuoka/openbsd-uefi/issues/1

...and indeed, the `objcopy` currently shipped with binutils v2.31.1 is 
missing "a.out-sunos-big" in the supported targets list.


```
root@ultra-10:~# objcopy -V
GNU objcopy (GNU Binutils for Debian) 2.31.1
[...]

root@ultra-10:~# objcopy -h
[...]
objcopy: supported targets: elf64-sparc elf32-sparc elf64-little 
elf64-big elf32-little elf32-big plugin srec symbolsrec verilog tekhex 
binary ihex

Report bugs to 
```

...but an older version does include it:
```
root@ultra-10:~/binutils-2.30-22# objcopy -V
GNU objcopy (GNU Binutils for Debian) 2.30
[...]

root@ultra-10:~/binutils-2.30-22# objcopy -h
[...]
objcopy: supported targets: elf64-sparc elf32-sparc a.out-sparc-linux 
a.out-sunos-big elf64-little elf64-big elf32-little elf32-big plugin 
srec symbolsrec verilog tekhex binary ihex

Report bugs to 
```

Cheers,
Frank