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
(
I'm catching the issue under ARM64/AARCH64, too.
debian-arm64:/# uname -a
Linux core2 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5
(2015-10-09) aarch64 GNU/Linux
debian-arm64:/# g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch6
Package remake
Package: normal
Version: 3.82+dbg0.9+dfsg-2
Severity: normal
Control: tags jessie sid
**
I'm trying to use Remake to debug a problem with a Makefile under a
Debian Jessie host with a Debian ARM64 Chroot guest. Its not going
well, and I am getting ready to build Remake from sources.
It ap
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
On Tue, Oct 20, 2015 at 7:03 PM, Vagrant Cascadian wrote:
> On 2015-10-20, Jeffrey Walton wrote:
>> # qemu-debootstrap --arch=ppc64 --keyring
>> /usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd
>> --exclude=debfoster debian-ppc64 http://ftp.debian.org/debian
Package: debootstrap
Version: 1.0.72
Severity: normal
**
I'm trying to setup a ppc64 QEMU chroot. I'm not sure if PPC64 is
available, but I usually get a different error when its not available.
The following packages are already installed: qemu binfmt-support
qemu-user-static debootstrap
Package: qemu-user-static
Version: 1:2.1+dfsg-12+deb8u4
Severity: normal
**
I had a working X32 installation. A Debian maintainer reported a
problem under Debian Sid, and he provided instructions on duplicating
his environment (below).
After installing Debian Sid under chroot, X32 broke:
My bad... I probably should have sent this with the original report.
# g++ -Wall -c test.cxx
test.cxx:13:9: warning: #pragma GCC target is not supported for this
machine [-Wpragmas]
#pragma GCC pop_options
^
**
# gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO
Package: qemu-user-static
Version: 1:2.1+dfsg-12+deb8u4
Severity: normal
**
This is kind of odd. I'm in a QEMU chroot environment. The compiler
accepts "pragma GCC push_options", but complains about "pragma GCC
pop_options".
My apologies in advance if this is mis-classified. I have troub
Hi David,
Sorry about the late reply. I just got back on testing that utilizes
the Debian QEMU chroot's.
Also note that this might be better assigned to qemu-user static (my
apologies if it was mis-classified):
$ sudo update-binfmts --display
...
interpreter = /usr/bin/qemu-s390x-s
>> I assume we are talking about a foreign chroot setup with qemu rather
>> than real hardware as I can't see such output in the buildlogs on real
>> hardware, but some searching suggests that it happens in emulation.
>> (In which case: which qemu setup and in which version?)
>
> Yes, its a chroot
On Mon, Sep 28, 2015 at 4:58 PM, David Kalnischkies
wrote:
> On Mon, Sep 28, 2015 at 10:12:30PM +0300, Andrei POPESCU wrote:
>> > # chroot debian-s390x/
>> > debian-s390:/# apt-get update
>> > 0% [Working]Unsupported socketcall: 20
>> > 0% [Working]Unsupported socketcall: 20
>> > Get:1 http://http
It appears reinstalling open-vm-tools after performing an "apt-get
autoclean" followed by "apt-get autoremove" cleared the issue.
I'm guessing open-vm-tools got confused because of multiple 4.x
kernels or tried to compile against the wrong headers.
**
# apt-get autoremove
Reading package
Package: open-vm-tools
Version: 2:9.4.6-1770165-8
Severity: normal
*
I'm working with a machine configured for an X32 port. It was not
really by choice; a Debian maintainer broke us on the platform, so we
had to add it to the testing repertoire. The machine requires we boot
with `syscall.
Control: package -1 apt
Package: apt-get
Version: 1.0.10.2
Severity: normal
X-Debbugs-CC: m...@tls.msk.ru
**
# chroot debian-s390x/
debian-s390:/# apt-get update
0% [Working]Unsupported socketcall: 20
0% [Working]Unsupported socketcall: 20
Get:1 http://httpredir.debian.org unstable InRelease [236 kB]
Get:2 http
Control: user debian-...@lists.debian.org
Control: usertags -1 + port-x32
Control: tags -1 + patch upstream
On Sun, Sep 20, 2015 at 4:25 PM, Kurt Roeckx wrote:
> On Sun, Sep 20, 2015 at 03:52:34PM -0400, Jeffrey Walton wrote:
>>
>> # find /usr -name cdefs.h
>> /usr/include/x86_64-linux-gnux32/sys/cdefs.h
>
> If you want to show include directories, you should show cpp
See GDB Issue 18987, https://sourceware.org/bugzilla/show_bug.cgi?id=18987
There's an unwanted assert causing the failure in
gdb/linux-thread-db.c. Around line 1675, guard the assert based on
__ILP32__:
#if !defined(__ILP32__) && !defined(_ILP32)
/* See comment in thread_db_update_thread_list. */
gdb_assert (!target_has_execution || thread_db_use_events ());
#endif
Building GDB 7.10 from sources reveals:
# export CFLAGS="-mx32"
# export CXXFLAGS="-mx32"
# ./configure --prefix=/usr/local
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-g
> Why are you reporting something about the upstream source to
> Debian while the Debian package build fine? It has an debian-x32
> target that uses -mx32.
>
Debian wants all bugs reported to them, and not upstream. See "Don't
file bugs upstream" at https://www.debian.org/Bugs/Reporting.
Jeff
Package: openssl
Version: 1.0.2d-1
Severity: important
*
>From within the X32 chroot environment (http://wiki.debian.org/X32Port)...
Download and unpack OpenSSL with:
curl -k https://www.openssl.org/source/openssl-1.0.2d.tar.gz -o
openssl-1.0.2d.tar.gz
tar xzfi openssl-1.0.2d.tar.gz
Package: gdb
Version: 7-10.1
Severity: important
X-Debbugs-CC: zu...@debian.org, g...@debian.org
*
A Debian maintainer informed us of some problem on the X32 platform.
I'm attempting to perform the port to X32, but I can't seem to get GDB
to execute/debug a program on the X32 platform (see be
Package: debootstrap
Version: 1.0.72
Severity: important
*
I work with a free/open source project (http://www.cryptopp.com/). A
Debian maintainer reported a failure for X32. I'm trying to get a test
rig setup to duplicate the issue. I'm following Debian's X32Port wiki
page (https://wiki.debia
arev
> To: noloa...@gmail.com, 799120-d...@bugs.debian.org
> Cc:
> Date: Wed, 16 Sep 2015 10:04:11 +0300
> Subject: Re: Bug#799120: cc1/cc1plus fails with "execv: exec format error”
> under QEMU s390x, can't compile C++ program
> Control: reassign -1 qemu-user
> Version: 1:
>> In the future, should I err to qemu-user? (Obviously I don't quite
>> understand things, so I'm happy to do what I am told).
>
> Heh. I read this like "for any bug I encounter in my life, I've been
> told to bug qemu-user" :) No, please don't, use common sense please :)
>
OK, will do :)
Forgi
Package: qemu-system
Version: 1.1.2+dfsg-6a+deb7u9
Severity: important
-
Attempting to install a QEMU s390 emulator for testing on Debian 7:
$ sudo apt-get install qemu binfmt-support qemu-user-static debootstrap
$ su -
# update-binfmts --display | grep s390
qemu-s390x (enabled):
inter
Package: qemu-system
Version: 1:2.4+dfsg-3
Severity: important
-
Attempting to compile Crypto++ (http://www.cryptopp.com/) under s390x
chroot environment:
# chroot debian-s390x
# g++ -dumpmachine
s390x-linux-gnu
# cd /cryptopp-5.6.3/
# make
g++ -DNDEBUG -g2 -O2 -pipe -c osrng.cpp
g++: erro
On Mon, Jan 20, 2014 at 8:33 AM, Ben Hutchings wrote:
> noloa...@gmail.com wrote:
>> I installed Debian 7.3 x64 on a Core i5 laptop for some testing (real
>> hardware, not a VM). When testing a program I wrote, I noticed it was
>> not getting the full number of bytes requested from /dev/random:
>>
Package: haveged
Version: 1.4.4
I installed Debian 7.3 x64 on a Core i5 laptop for some testing (real
hardware, not a VM). When testing a program I wrote, I noticed it was
not getting the full number of bytes requested from /dev/random:
unsigned char buffer[32];
fd = open("/dev/random", O
Package: gnome-control-center
Version: 1:3.4.3.1-2
I'm working on an old machine that's been re-purposed. The machine is
an HP5850 and from circa 2008. It has on Athlon dual-core running
about 2.3 GHz with 4GB of RAM. Worse, I'm running two VirtualBox
guests on it for OpenStack testing (controller
Please close this erroneous report.
r...@bruno:/# nm -D /usr/lib/libcrypto++.so | grep g_nullNameValuePairs
006b7cc0 B _ZN8CryptoPP20g_nullNameValuePairsE
r...@bruno:/# nm -D /usr/lib64/libcrypto++.so | grep g_nullNameValuePairs
006b7cc0 B _ZN8CryptoPP20g_nullNameValuePairsE
Many
ullNameValuePairsE
r...@bruno:/# nm /usr/lib64/libcryptopp.so | grep g_nullNameValuePairs
nm: /usr/lib64/libcryptopp.so: no symbols
Jeffrey Walton
[1] Errors with multiple loading cryptopp as shared lib on Linux,
http://groups.google.com/group/cryptopp-users/browse_thread/thread/68fbc22e8c6e2f48
r.
its gets stale over time. Crypto++ can
also be fetched from SourceForge, which is always up to date. Issue
"svn checkout https://cryptopp.svn.sourceforge.net/svnroot/cryptopp/trunk/c5
cryptopp"/
Jeffrey Walton,
Friend of the Crypto++ Library,
[1] RTLD_GLOBAL and libcryptopp.so crash,
101 - 142 of 142 matches
Mail list logo
