Re: Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
Hi all I don't know if I can write to you, but i've no more idea First: - Excuse for my english (i'm frenchy), and i'm not a power user of Linux (just a basic user since 3 years) My system: - Debian Etch with kernel 2.4.27, - libc6 2.3.5-6 (I do not upgrade to 2.3.6-3 because of bug who are still tag as open) My problem - The same problem as you with libstdc++.so.6 since I upgrade libsdtc++6 from 4.0 to 4.1 (it was yesterday) - Now I can't use wajig or some streamtuner's pluggins (or amsn) because I have this error : libstdc++.so.6: cannot handle TLS data That I done - For the moment I'have dpkg the previous version of libstdc++6 (4.0.3-1 for replace 4.1.0-1) - Also downgrade libglu1-xorg to the version 6.9.0.dfsg.1-4 because 6.9.0.dfsg.1-6 required libstdc++6 in 4.1 version The Result - Since, all seems be quiet (wajig work again, and streamtuner and amsn too), I think that that will not last for a long time. My question - Can you tell me if that I do is a good solution, or what else can I do ? I espere avoit be clearly Thank you for your responses and i hope you will be able to help me Freddec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#836944: gcc: autoconf test failing on amd64 with -pie -static combination
Package: gcc-6
Version: 6.2.0-3
--
Hi,
I've got an issue close to this one
: https://sourceware.org/bugzilla/show_bug.cgi?id=16428
(unstable)debian@vm81:~$ cat conftest.c
int main() { return 0; }
(unstable)debian@vm81:~$ gcc -fPIE -pie -static conftest1.c
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/crtbeginT.o: relocation
R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a
shared object
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(libc-start.o):
relocation R_X86_64_32 against undefined symbol `_dl_starting_up' can not be
used when making a shared object; recompile with -fPIC
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(check_fds.o):
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(libc-tls.o):
relocation R_X86_64_32S against undefined symbol `_dl_static_dtv' can not be
used when making a shared object; recompile with -fPIC
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(elf-init.o):
relocation R_X86_64_32 against undefined symbol `__preinit_array_end' can not
be used when making a shared object; recompile with -fPIC
...
Though, this does not happen on Ubuntu Yakkety which also uses gcc-6
(6.2.0-3ubuntu11).
It happens on amd64 (not i386 nor ppc64el from my tests).
F.
Bug#845751: patch backported to gcc-6 available
I see upstream has a patch for gcc-6 . Would it be possible to import it ? Thanks, F. pgpUXqJcL52Zf.pgp Description: PGP signature
Bug#146883: Kernel compiled for an Alpha SMP is not bootable.
Package: gcc-2.95 Version: 1:2.95.4-9 Severity: normal -- System Information Debian Release: 3.0 Kernel Version: Linux big2 2.4.19-pre8-30 #1 SMP Mon May 13 18:01:01 PDT 2002 alpha unknown Versions of the packages gcc-2.95 depends on: ii binutils 2.12.90.0.1-5 The GNU assembler, linker and binary utiliti ii cpp-2.95 2.95.4-9 The GNU C preprocessor. ii gcc2.95.4-14 The GNU C compiler. ii libc6.12.2.5-6GNU C Library: Shared libraries and Timezone If I compile a kernel 2.4.x (I tried with x >= 17) on a Compaq DS20, the newly compiled kernel oopses in the fontion: smp_tune_scheduling defined in file arch/alpha/kernel/smp.c The `switch' statement in that function is where the Oops happens, at least I believe so: as an experiment I've hard-coded the `on_chip_cache' variable and commented out the whole switch, the kernel booted up fine. I compiled with gcc-3.0.4 and the problem disappeared. Thanks so much for being a Debian devloper! Regards, -- Frederic.R.Roussel -o)(o- /\\ Join the penguin force (o_ (o_ //\ _\_v The Linux G3N3R47!0N (/)_ (/)_ v_/_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#146883: Kernel compiled for an Alpha SMP is not bootable.
Hi,
Yes, that patch addresses the problem.
The 3.0.4 compiler generates codes that works.
The bottom line is that it is a weird combination of `dead code' in the
kernel and code generation bug.
Thanks to all of you!
On Wed, 2002-05-15 at 21:34, Christopher C. Chimelis wrote:
>
> On 13 May 2002, Frederic Roussel wrote:
>
> > Package: gcc-2.95
> > Version: 1:2.95.4-9
> > Severity: normal
> >
> > -- System Information
> > Debian Release: 3.0
> > Kernel Version: Linux big2 2.4.19-pre8-30 #1 SMP Mon May 13 18:01:01 PDT
> > 2002 alpha unknown
> >
> > Versions of the packages gcc-2.95 depends on:
> > ii binutils 2.12.90.0.1-5 The GNU assembler, linker and binary
> > utiliti
> > ii cpp-2.95 2.95.4-9 The GNU C preprocessor.
> > ii gcc2.95.4-14 The GNU C compiler.
> > ii libc6.12.2.5-6GNU C Library: Shared libraries and
> > Timezone
> >
> > If I compile a kernel 2.4.x (I tried with x >= 17) on a Compaq DS20, the
> > newly compiled kernel oopses in the fontion:
> > smp_tune_scheduling defined in file arch/alpha/kernel/smp.c
> >
> > The `switch' statement in that function is where the Oops happens, at
> > least I believe so: as an experiment I've hard-coded the `on_chip_cache'
> > variable and commented out the whole switch, the kernel booted up fine.
> >
> > I compiled with gcc-3.0.4 and the problem disappeared.
>
> Try the patch below to see if it fixes things. There is a code generation
> problem in 2.95.4, but it's mostly irrelevent since the kernel code that's
> being miscompiled doesn't even need to be used in the 2.4 kernels. I
> tried submitting this patch to upstream kernel folks, but it got ignored
> several times and I didn't have the time to follow up further.
>
> C
>
> Index: arch/alpha/kernel/smp.c
> ===
> RCS file: /home/cvs/linux-24/arch/alpha/kernel/smp.c,v
> retrieving revision 1.1.1.4
> retrieving revision 1.4
> diff -u -r1.1.1.4 -r1.4
> --- arch/alpha/kernel/smp.c 11 Oct 2001 15:41:35 - 1.1.1.4
> +++ arch/alpha/kernel/smp.c 11 Oct 2001 15:51:36 - 1.4
> @@ -80,7 +80,6 @@
> int smp_num_probed; /* Internal processor count */
> int smp_num_cpus = 1;/* Number that came online. */
> int smp_threads_ready; /* True once the per process idle is
> forked. */
> -cycles_t cacheflush_time;
>
> int __cpu_number_map[NR_CPUS];
> int __cpu_logical_map[NR_CPUS];
> @@ -212,63 +211,6 @@
>
>
> /*
> - * Rough estimation for SMP scheduling, this is the number of cycles it
> - * takes for a fully memory-limited process to flush the SMP-local cache.
> - *
> - * We are not told how much cache there is, so we have to guess.
> - */
> -static void __init
> -smp_tune_scheduling (int cpuid)
> -{
> - struct percpu_struct *cpu;
> - unsigned long on_chip_cache;
> - unsigned long freq;
> -
> - cpu = (struct percpu_struct*)((char*)hwrpb + hwrpb->processor_offset
> - + cpuid * hwrpb->processor_size);
> - switch (cpu->type)
> - {
> - case EV45_CPU:
> - on_chip_cache = 16 + 16;
> - break;
> -
> - case EV5_CPU:
> - case EV56_CPU:
> - on_chip_cache = 8 + 8 + 96;
> - break;
> -
> - case PCA56_CPU:
> - on_chip_cache = 16 + 8;
> - break;
> -
> - case EV6_CPU:
> - case EV67_CPU:
> - on_chip_cache = 64 + 64;
> - break;
> -
> - default:
> - on_chip_cache = 8 + 8;
> - break;
> - }
> -
> - freq = hwrpb->cycle_freq ? : est_cycle_freq;
> -
> -#if 0
> - /* Magic estimation stolen from x86 port. */
> - cacheflush_time = freq / 1024L * on_chip_cache / 5000L;
> -
> -printk("Using heuristic of %d cycles.\n",
> - cacheflush_time);
> -#else
> - /* Magic value to force potential preemption of other CPUs. */
> - cacheflush_time = INT_MAX;
> -
> -printk("Using heuristic of %d cycles.\n",
> - cacheflush_time);
> -#endif
> -}
> -
> -/*
> * Send a message to a secondary's console. "START" is one such
> * interesting message. ;-)
> */
> @@ -607,7 +549,6 @@
> current->processor = boot_cpuid;
>
> smp_store_cpu_info(boot_cpuid);
> - smp_tune_scheduling(boot_cpuid);
> smp_setup_percpu_timer(boot_cpuid);
>
> init_idle();
--
Frederic.R.Roussel -o)(o-
/\\ Join the penguin force (o_ (o_ //\
_\_v The Linux G3N3R47!0N (/)_ (/)_ v_/_
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489462: g++-4.3: Problem with #define minor -> gnu_dev_minor
Package: g++-4.3
Version: 4.3.1-2
Severity: normal
Hello
I am trying to update my tango package (not yet release) after the 4.2
-> 4.3 transition.
you can find the packaging git repository here:
git://repo.or.cz/tango.git
during the first compilation it hang on the log4tango compilation
due to ian ambiguity with std::abs
I solved the proble with this patch
--- tango.orig/lib/cpp/log4tango/src/PatternLayout.cpp
+++ tango/lib/cpp/log4tango/src/PatternLayout.cpp
@@ -209,7 +209,7 @@
FormatModifierComponent(PatternLayout::PatternComponent* component,
int minWidth, int
maxWidth) :
_component(component) ,
-_minWidth(std::abs(minWidth)),
+_minWidth(minWidth < 0 ? -minWidth : minWidth),
_maxWidth(maxWidth),
_alignLeft(minWidth < 0) {
}
and a missing header in lib/cpp/log4tango/src/Level.cpp
add
now the real problem is with lib/cpp/client/api_util.cpp
where
make[6]: entrant dans le répertoire «
/home/picca/Debian/tango/tango/lib/cpp/client »
/bin/sh ../../../libtool --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H
-I. -I. -I../../.. -I../../../lib/cpp/server
-I../../../lib/cpp/log4tango/include
-I../../../lib/cpp/log4tango/include -I/usr/include -Wl,-z,defs
-I/usr/include -D_TANGO_LIB -D_REENTRANT -DOMNI_UNLOADABLE_STUBS -c -o
api_util.lo api_util.cpp
g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../lib/cpp/server
-I../../../lib/cpp/log4tango/include
-I../../../lib/cpp/log4tango/include -I/usr/include -Wl,-z,defs
-I/usr/include -D_TANGO_LIB -D_REENTRANT -DOMNI_UNLOADABLE_STUBS -c
api_util.cpp -fPIC -DPIC -o .libs/api_util.o
api_util.cpp: In member function 'void
Tango::ApiUtil::get_asynch_replies()':
api_util.cpp:465: error: 'class CORBA::BAD_INV_ORDER' has no member
named 'gnu_dev_minor'
api_util.cpp: In member function 'void
Tango::ApiUtil::get_asynch_replies(long int)':
api_util.cpp:624: error: 'class CORBA::BAD_INV_ORDER' has no member
named 'gnu_dev_minor'
api_util.cpp:690: error: 'class CORBA::BAD_INV_ORDER' has no member
named 'gnu_dev_minor'
but when I look the code nothing about gnu_dev_minor in the
CORBA::BAD_INV_ORDER class.
so i suspect a problem with a #define of minor in a header.
Is it a bug of gcc-4.3 (it compiles fine with gcc-4.2) ?
have a good night
Frederic
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages g++-4.3 depends on:
ii gcc-4.3 4.3.1-2The GNU C compiler
ii gcc-4.3-base 4.3.1-2The GNU Compiler Collection (base
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library
ii libmpfr1ldbl 2.3.1.dfsg.1-2 multiple precision floating-point
ii libstdc++6-4.3-dev4.3.1-2The GNU Standard C++ Library v3 (d
g++-4.3 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#523869: libffi-dev: gcc doesn't find ffi.h
Hello,
I am also seeing this problem.
#include
int main(int argc, char *argv[])
{
return 0;
}
$ make t
cc t.c -o t
t.c:1:17: error: ffi.h: No such file or directory
make: *** [t] Error 1
$ cc --version
cc (Debian 4.3.3-7) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Frederic
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#803039: [PATCH] libffi: enable autoreconf
Source: libffi Source-Version: 3.2.1-3 Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el -- Hi, here is a patch to enable autoreconf for libffi as it was not figuring out the good linker on ppc64el : --- checking whether the powerpc64le-linux-gnu-gcc linker (/usr/powerpc64le-linux-gnu/bin/ld -m elf64ppc) supports shared libraries... no --- and it should be ld only. This was particularly problematic when cross compiling and rebootstrap was impacted : https://jenkins.debian.net/view/All/job/rebootstrap_ppc64el_gcc5/44/console Thanks, Fred diff -Nru libffi-3.2.1/debian/control libffi-3.2.1/debian/control --- libffi-3.2.1/debian/control 2014-11-18 16:58:51.0 +0100 +++ libffi-3.2.1/debian/control 2015-10-22 10:21:33.0 +0200 @@ -5,7 +5,8 @@ Build-Depends: debhelper (>= 5), g++-multilib [amd64 i386 mips mipsel powerpc ppc64 s390 sparc kfreebsd-amd64], dejagnu, lsb-release, texinfo, - dpkg-dev (>= 1.16.0~ubuntu4) + dpkg-dev (>= 1.16.0~ubuntu4), + dh-autoreconf, libltdl-dev Standards-Version: 3.9.6 Section: libs diff -Nru libffi-3.2.1/debian/rules libffi-3.2.1/debian/rules --- libffi-3.2.1/debian/rules 2014-06-04 15:28:42.0 +0200 +++ libffi-3.2.1/debian/rules 2015-10-26 10:29:11.0 +0100 @@ -39,6 +39,7 @@ dh_testdir rm -rf build mkdir -p build + dh_autoreconf cd build && ../configure \ --host=$(DEB_HOST_GNU_TYPE) \ --build=$(DEB_BUILD_GNU_TYPE) \ @@ -75,6 +76,7 @@ rm -f stamp-* rm -rf build* rm -f doc/libffi.info + dh_autoreconf_clean dh_clean install: build
gcc name bug?
-- System Information ---
Debian Release: stable on Pentium III
Kernel Version: Linux 2.2.18pre21/2.2.19
gcc version: 2.95.2
-
Hi,
While trying to optimize some C code for speed, we have
encountered what we think is a very strange bug with gcc: the
execution time depends on the name of the executable (!). As an
example, here is a bares bones C code snippet which reproduces
the problem:
/* strange.c ==*/
#define N 10
double content()
{
return 0;
}
int main()
{
inti;
double bucket=0;
for (i=0; i
