On 07/07/2016 04:14 PM, John Paul Adrian Glaubitz wrote:
> With this patch applied, we should be able to fix this issue the same
> way it was fixed for gcc-6 [2].
Ok, here is an actually tested version of the patch (yes, I know :>).
To make it work, I put the patch into debian/patches, removed
s
Control: tags -1 +patch
Hi Matthias!
As discussed previously at DebConf16, I have backported the cpu32 patch by
Jose Marchesi [1] to the gcc-5-branch, I used the current SVN revision
of the gcc-5-branch, so this patch should probably be updated after the
svn-updates.diff patch.
With this patch a
Processing control commands:
> tags -1 +patch
Bug #792204 [src:gcc-5] gcc-5: FTBFS on sparc64, mismatched symbols files
Added tag(s) patch.
--
792204: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792204
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
On 11/06/2015 10:21 AM, John Paul Adrian Glaubitz wrote:
> Interestingly, the future symbols still seem to be missing in
> lib32stdc++6 which I find rather odd.
Ok, back to the drawing board. Apparently sparc-force-cpu.diff doesn't
have any influence anymore. "-mcpu=ultrasparc" is never passed acc
Control: tags -1 patch
On 11/05/2015 11:10 PM, John Paul Adrian Glaubitz wrote:
> But, surprise, surprise, gcc-5 with bi-arch enabled works fine on
> sparc64 now. Hence, please update the patch
> debian/patches/sparc-force-cpu.diff and remove the "DISABLED" in line
> 18.
Attaching a patch for now
Processing control commands:
> tags -1 patch
Bug #792204 [src:gcc-5] gcc-5: FTBFS on sparc64, mismatched symbols files
Added tag(s) patch.
--
792204: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792204
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Hi Matthias!
On Thu, Jul 23, 2015 at 09:55:32AM +0200, John Paul Adrian Glaubitz wrote:
> On 07/21/2015 09:13 PM, Matthias Klose wrote:
> > no, v8 is ancient. re-enable it and check if it works, and if not, fix it.
>
> I modified the patch now to set cpu to "ultrasparc" which results in
> a diffe
On 07/21/2015 08:34 PM, John Paul Adrian Glaubitz wrote:
> On Mon, Jul 20, 2015 at 12:38:45PM +0200, Matthias Klose wrote:
>>> see sparc-force-cpu.diff, which currently disables this for sparc64 biarch.
>>> So
>>> maybe somebody should just enable it and see if it works as intended, or
>>> make i
On Tue, Jul 21, 2015 at 09:13:41PM +0200, Matthias Klose wrote:
> > Ok, but why exactly was it disabled. Were there any issues with
> > -mcpu=ultrasparc when compiling with -m32? Was this chosen to remain
> > compatible with older SPARC CPUs?
>
> no, v8 is ancient. re-enable it and check if it wor
On Mon, Jul 20, 2015 at 12:38:45PM +0200, Matthias Klose wrote:
> > see sparc-force-cpu.diff, which currently disables this for sparc64 biarch.
> > So
> > maybe somebody should just enable it and see if it works as intended, or
> > make it
> > working.
>
> ahh, and r7502 disabled it again, so pr
On 07/20/2015 12:31 PM, Matthias Klose wrote:
> On 07/20/2015 01:37 AM, Michael Karcher wrote:
>> Hello,
>>
>> the problem (ATOMIC_INT_LOCK_FREE == 1) applies for the 32-bit build of
>> libstdc++,
>> and is caused by gcc assuming a too old 32-bit sparc processor, as can
>> be seen by:
>>
>>> (unsta
On 07/20/2015 01:37 AM, Michael Karcher wrote:
> Hello,
>
> the problem (ATOMIC_INT_LOCK_FREE == 1) applies for the 32-bit build of
> libstdc++,
> and is caused by gcc assuming a too old 32-bit sparc processor, as can
> be seen by:
>
>> (unstable-sparc64-sbuild)mkarcher@ravirin:~$ COLUMNS=140 dpk
Hello,
the problem (ATOMIC_INT_LOCK_FREE == 1) applies for the 32-bit build of
libstdc++,
and is caused by gcc assuming a too old 32-bit sparc processor, as can
be seen by:
> (unstable-sparc64-sbuild)mkarcher@ravirin:~$ COLUMNS=140 dpkg -l gcc-4.9
> Desired=Unknown/Install/Remove/Purge/Hold
> |
S
13 matches
Mail list logo
