Re: sparc64 most important tasks
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 - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: