Hi Everyone,
I help maintain the Crypto++ library. László Böszörményi is our Debian
packager/developer.
László alerted us to a ppc64-le failure at
https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B&arch=ppc64el&ver=8.0.0-1
.
I believe Debian's GCC needs the fix provided at
https://gc
s Klose
> To: noloa...@gmail.com, 856528-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 2 Mar 2017 10:08:54 +0100
> Subject: Re: Bug#856528: Unable to install GCC7 on Debian 8/i386 with
> Experimental enabled
> On 02.03.2017 02:27, Jeffrey Walton wrote:
>> Package: gcc-7
Package: gcc-7
Version: 7-20170226-1
Severity: important
I'm unable to install GCC7 on Debian 8/i386 with Experimental enabled.
Things worked well under x86_64; the issue seems to be limited to
i386.
=
A fresh install of Debian 8.7 for i386. The machine is ful
This is also kind of interesting in a morbid sort of way:
$ cpp -dM http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf,
Section 12.1, __ARM_NEON is defined when ARM Neon Intrinsics are
available:
NEON intrinsics are available if the __ARM_NEON macro is predefi
Package: gcc-4.9
Version: 4.9.2-10
-
I have a LeMaker HiKey
(http://www.96boards.org/products/ce/hikey-lemaker/). Its AARCH64 and
Neon is mandatory feature
(https://community.arm.com/groups/android-community/blog/2014/10/10/runtime-detection-of-cpu-features-on-an-armv8-a-cpu).
GCC appears to
>On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote:
>> >>It appears Debian built the library with GCC, and GCC used
>> >>_GLIBCXX_USE_CXX11_ABI. The user then compiled with Clang and caught a
>> >>link error. The tools did not warn him about the pro
>> - compile and link a program that uses libfoo and libbar with uvw compiler
>
> Let me follow up with some real result from a minimal test case.
>
>> (but I'm probably getting the sequence of events totally wrong so please
>> specify what is actually going on)
>
> Not at all. Its a confluence of
> On Wed, 23 Mar 2016 at 13:31:32 +0100, Matthias Klose wrote:
>> If you want to change that, that change should be made in dpkg-buildflags.
>
> From the original report:
>
>> >On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote:
>> >>It appears Deb
On Tue, Mar 22, 2016 at 6:03 PM, Rebecca N. Palmer
wrote:
>> The user then compiled with Clang and caught a link error.
>
> clang can't handle abi tags (i.e. can't link to new-ABI code even if you
> aren't trying to mix it with old-ABI code):
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797
Package: g++
Version: 4:4.9.2-2
Severity: normal
A compiler warning would be nice if the linker does not accept the
option. Otherwise, the compiler should not advertise it accepts the
option. Accepting it without warning has wasted hours of build time in
this emulated environment. (-fsanitize=addr
I'm still getting the undefined behavior findings. I'd like to thank
the Debian folks for their prompt handling of the issue
Its pretty clear to me taking the time to report bugs and follow up
under this antiquated (and painful) system is a waste of my time.
*
30 configurations teste
tags 804521 + upstream
tags 804521 + fixed
Jonathan Wakely cleared this issue upstream. See
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158.
Package: g++
Version: 4:5.2.1-4
Severity: normal
Control: tags jessie sid
Tags: jessie sid
**
Another Debian specific bug... GCC can't compile a program using
RDSEED intrinsics. It results in an error "error: ‘_rdseed64_step’ was
not declared in this scope".
According the Intel (which th
Package: libstdc++6
Version: 5.2.1-20
Severity: normal
Control: tags jessie sid
**
On Linux, the distros often use libstdc++ (GNU) rather than libc++
(LLVM) for Clang. Building libcxx is an art that I have never been
able to untangle, and I think the maintainers have discovered the same
(
Here's an update since using clang++ with -stdlib-libstdc++ (GNU's
runtime) may seem odd or cause confusion. I just used whatever the
host platform provided.
The machine is an old Athlon system I use for testing. This test
system happens to include Clang, so the Sanitizer test under Clang
gets inv
Package: libstdc++6
Source: gcc-4.9
Version: 4.9.2-10
**
I believe the fix is to cast from an Ios_Fmtflags to an unsigned type,
perform the bit operations, and then cast back to a Ios_Fmtflags
before returning it.
I recall seeing this one in some Apple headers. Also see
http://lists.llvm
Package: g++
Version: 4:4.9.2-2
Severity: normal
**
I'm catching a compile failure when building a library (not a
program). The library is a crypto library called Crypto++
(https://cryptopp.com). Here's the project's bug report on the issue:
https://github.com/weidai11/cryptopp/issues/53
17 matches
Mail list logo
