Bug#925567: gcc-8-cross: FTBFS: conftest.c:72: undefined reference to `getexecname'
Control: retitle 925567 gcc-8-cross: FTBFS: out of memory allocating 4064 bytes after a total of 155293664 bytes Control: notfound 925567 gcc-8-cross/26 Control: fixed 925567 gcc-8-cross/26 The error message the build failed with according to the linked log is actually: | out of memory allocating 4064 bytes after a total of 155293664 bytes | cc1plus: out of memory allocating 65536 bytes after a total of 3620864 bytes (The "undefined reference to `getexecname'" if part of a check an no error but part of the full config.log) This bugs still appears on https://bugs.debian.org/release-critical/other/testing.html, I guess because bugs.debian.org says: Found in version gcc-8-cross/26 Fixed in version 26 and thus thinks testing is still affected. I'm trying to send some notfound and fixed commands to clear that. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#452402: gcc-4.2: cannot generate sparc64 executables
Package: gcc-4.2 Version: 4.2.2-3 Severity: normal When I try to compile a 64 bit executable on sparc, I get errors about missing a libgcc.a file for it: $ cat > test.c <
Bug#452402: gcc-4.2: cannot generate sparc64 executables
* Matthias Klose <[EMAIL PROTECTED]> [071122 17:14]: > > When I try to compile a 64 bit executable on sparc, I get errors > > about missing a libgcc.a file for it: > > please install gcc-multilib. Thanks for you quick response. I guess I was to fixated to search for packages with 64 in the name and there seems to be a bug in http://packages.debian.org/search?suite=sid&arch=sparc&mode=filename&searchon=contents&keywords=libgcc.a What is still an issue is that gcc -m64 -print-libgcc-file-name prints a wrong filename without gcc-multilib installed. Is this worth reopening another bug or reopen/retitle this one? Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DSO linking changes for wheezy
* Kurt Roeckx [101114 14:08]:
> People have been claiming that constructors or init section are a
> possible problem. I have yet to see an example where it breaks.
The following example is a bit constructed, but shows a silent change
of run-time behaviour if --as-needed is passed:
$ cat > ertest.c <<'EOF'
#include
#include
#include
#include
#include
static String fr[] = {
"*geometry: 100x100\n",
NULL
};
int main(int argc, String argv[]) {
XtAppContext context;
Widget app_shell;
app_shell = XtOpenApplication(&context, "ERTEST",
NULL, 0, &argc, argv, fr,
applicationShellWidgetClass, NULL, 0);
XtRealizeWidget(app_shell);
XtAppMainLoop(context);
return 0;
}
EOF
$ gcc -o ertest -Wall -O2 ertest.c -lXaw -lXt
$ ./ertest &
$ editres
# Select Commands/Get Tree and click at the window the first program created
$ gcc -o ertest -Wl,--as-needed -Wall -O2 ertest.c -lXaw -lXt
$ ./ertest &
$ editres
# Try it again and it fails now...
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20101116100120.ga29...@pcpool00.mathematik.uni-freiburg.de
Bug#667519: gcc-4.6-multilib: 32 bit libgcc_s.so missing
Package: gcc-4.6-multilib Version: 4.6.3-2 Severity: important Creating 32 bit binaries with -m32 does not work, as there is only a broken libgcc_s.so symlink. $ gcc -v -m32 some.o Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.3 (Debian 4.6.3-2) COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/32/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/:/lib/../lib32/:/usr/lib/../lib32/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-m32' '-o' 'libnss_extrausers32.so.2' '-mtune=generic' '-march=i586' /usr/lib/gcc/x86_64-linux-gnu/4.6/collect2 --sysroot=/ --build-id --no-add-needed --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o libnss_extrausers32.so.2 /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6/32/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.6/32 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. some.o -lc -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.6/32/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/crtn.o /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status $ ls -la /usr/lib/gcc/x86_64-linux-gnu/4.6/32/libgcc_s.so lrwxrwxrwx 1 root root 34 Apr 4 08:15 /usr/lib/gcc/x86_64-linux-gnu/4.6/32/libgcc_s.so -> ../../../../../lib32/libgcc_s.so.1 but that points nowhere. -- System Information: Debian Release: wheezy/sid Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 Versions of packages gcc-4.6-multilib depends on: ii gcc-4.6 4.6.3-2 ii gcc-4.6-base4.6.3-2 ii lib32gomp1 4.7.0-2 ii lib32quadmath0 4.7.0-2 ii libc6-dev-i386 2.13-27 gcc-4.6-multilib recommends no packages. Versions of packages gcc-4.6-multilib suggests: pn lib32mudflap0 -- no debconf information -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120404161629.ga27...@client.brlink.eu
Bug#667519: gcc-4.6-multilib: 32 bit libgcc_s.so missing
title 667519 gcc-4.6-multilib: misses dependency on lib32gcc1
severity 667519 normal
thanks
* Bernhard R. Link [120404 18:16]:
> Creating 32 bit binaries with -m32 does not work, as there is only
> a broken libgcc_s.so symlink.
Looks like this is caused by a missing dependency on lib32gcc1.
(gcc-4.7-multilib has a dependency on something pulling this in,
while gcc-4.6-multilib has not).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120404162727.ga28...@client.brlink.eu
Bug#677139: gcc-4.6: unresolved symbol __aeabi_unwind_cpp_pr1@GCC_3.5
d=c99 -U__STRICT_ANSI__ -fPIC -O3 -DNDEBUG -shared -o libgmp_caml.so
gmp_caml.o mpz_caml.o mpq_caml.o mpf_caml.o mpfr_caml.o gmp_random_caml.o
-L/usr/lib -lmpfr -L/usr/lib -lgmp -L/usr/lib/ocaml -lcamlidl
With only -shared and no -nostdlib or the like, it should be gcc's
responsibility to link the needed system libs, shouldn't it?
dpkg-shlibdeps: warning: symbol __aeabi_unwind_cpp_pr1@GCC_3.5 used by
debian/libapron/usr/lib/libap_ppl.so.0 found in none of the libraries.
Some third example:
Build log for attica (0.2.0-1) on armhf
g++-4.6_4.6.2-6 gcc-4.6_4.6.2-6 libc6-dev_2.13-22 libstdc++6_4.6.2-6
libstdc++6-4.6-dev_4.6.2-6 libgcc1_1:4.6.2-6
/usr/bin/c++ -fPIC -fvisibility=hidden -fvisibility-inlines-hidden-shared
-Wl,-soname,libattica.so.0 -o libattica.so.0.2.0
CMakeFiles/attica.dir/accountbalance.cpp.o
CMakeFiles/attica.dir/accountbalanceparser.cpp.o
CMakeFiles/attica.dir/activity.cpp.o CMakeFiles/attica.dir/activityparser.cpp.o
CMakeFiles/attica.dir/atticabasejob.cpp.o
CMakeFiles/attica.dir/atticautils.cpp.o CMakeFiles/attica.dir/privatedata.cpp.o
CMakeFiles/attica.dir/privatedataparser.cpp.o
CMakeFiles/attica.dir/category.cpp.o CMakeFiles/attica.dir/categoryparser.cpp.o
CMakeFiles/attica.dir/comment.cpp.o CMakeFiles/attica.dir/commentparser.cpp.o
CMakeFiles/attica.dir/content.cpp.o CMakeFiles/attica.dir/contentparser.cpp.o
CMakeFiles/attica.dir/distribution.cpp.o
CMakeFiles/attica.dir/distributionparser.cpp.o
CMakeFiles/attica.dir/downloaddescription.cpp.o
CMakeFiles/attica.dir/downloaditem.cpp.o
CMakeFiles/attica.dir/downloaditemparser.cpp.o
CMakeFiles/attica.dir/event.cpp.o CMakeFiles/attica.dir/eventparser.cpp.o
CMakeFiles/attica.dir/folder.cpp.o CMakeFiles/attica.dir/folderparser.cpp.o
CMakeFiles/attica.dir/getjob.cpp.o CMakeFiles/attica.dir/homepageentry.cpp.o
CMakeFiles/attica.dir/homepagetype.cpp.o
CMakeFiles/attica.dir/homepagetypeparser.cpp.o CMakeFiles/attica.dir/icon.cpp.o
CMakeFiles/attica.dir/itemjob.cpp.o
CMakeFiles/attica.dir/knowledgebaseentry.cpp.o
CMakeFiles/attica.dir/knowledgebaseentryparser.cpp.o
CMakeFiles/attica.dir/license.cpp.o CMakeFiles/attica.dir/licenseparser.cpp.o
CMakeFiles/attica.dir/listjob_inst.cpp.o CMakeFiles/attica.dir/message.cpp.o
CMakeFiles/attica.dir/messageparser.cpp.o CMakeFiles/attica.dir/metadata.cpp.o
CMakeFiles/attica.dir/parser.cpp.o CMakeFiles/attica.dir/person.cpp.o
CMakeFiles/attica.dir/personparser.cpp.o
CMakeFiles/attica.dir/postfiledata.cpp.o CMakeFiles/attica.dir/postjob.cpp.o
CMakeFiles/attica.dir/provider.cpp.o
CMakeFiles/attica.dir/providermanager.cpp.o
CMakeFiles/attica.dir/qtplatformdependent.cpp.o -lQtCore -lQtNetwork
dpkg-shlibdeps: warning: symbol __aeabi_unwind_cpp_pr1@GCC_3.5 used by
debian/libattica0/usr/lib/libattica.so.0.2.0 found in none of the libraries.
Is this a bug in gcc/libgcc or something else (libc?, ld?).
Or should dpkg-shlibs just ignore this particular symbol?
Thanks in advance,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120611181646.ga1...@client.brlink.eu
Bug#684635: ICE when compiling malformed struct initializers
Package: gcc-4.7
Version: 4.7.1-6
Severity: minor
The following invalid C code triggers an segmentation fault
in gcc-4.7:
cat > t.c <<'EOF'
struct bla{char **a;};void test(void){struct bla b = {.a =(char**){"a","b"}};}
EOF
gcc -c t.c
results in:
| t.c: In function ‘test’:
| t.c:1:46: warning: initialization from incompatible pointer type [enabled by
default]
| t.c:1:46: warning: (near initialization for ‘(anonymous)’) [enabled by
default]
| t.c:1:46: warning: excess elements in scalar initializer [enabled by default]
| t.c:1:46: warning: (near initialization for ‘(anonymous)’) [enabled by
default]
| t.c:1:50: internal compiler error: Segmentation fault
| Please submit a full bug report,
while gcc-snapshot 20120714-1 says:
| t.c: In function 'test':
| t.c:1:46: warning: initialization from incompatible pointer type [enabled by
default]
| struct bla{char **a;};void test(void){struct bla b = {.a
=(char**){"a","b"}};}
| ^
| t.c:1:46: warning: (near initialization for '(anonymous)') [enabled by
default]
| t.c:1:46: warning: excess elements in scalar initializer [enabled by default]
| t.c:1:46: warning: (near initialization for '(anonymous)') [enabled by
default]
| t.c:1:50: internal compiler error: tree check: expected constructor, have
nop_expr in optimize_compound_literals_in_ctor, at gimplify.c:3855
| struct bla{char **a;};void test(void){struct bla b = {.a
=(char**){"a","b"}};}
| ^
| Please submit a full bug report,
-- System Information:
Debian Release: wheezy/sid
Architecture: amd64 (x86_64)
Versions of packages gcc-4.7 depends on:
ii binutils 2.22-7.1
ii cpp-4.7 4.7.1-6
ii gcc-4.7-base 4.7.1-6
ii libc6 2.13-35
ii libgcc1 1:4.7.1-6
ii libgmp10 2:5.0.5+dfsg-2
ii libgomp1 4.7.1-6
ii libitm1 4.7.1-6
ii libmpc2 0.9-4
ii libmpfr4 3.1.0-5
ii libquadmath0 4.7.1-6
ii zlib1g1:1.2.7.dfsg-13
Versions of packages gcc-4.7 recommends:
ii libc6-dev 2.13-35
Versions of packages gcc-4.7 suggests:
pn binutils-gold
pn gcc-4.7-doc
pn gcc-4.7-locales
ii gcc-4.7-multilib 4.7.1-6
pn libgcc1-dbg
pn libgomp1-dbg
pn libitm1-dbg
pn libmudflap0-4.7-dev
pn libmudflap0-dbg
pn libquadmath0-dbg
-- no debconf information
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120812073948.ga4...@client.brlink.eu
Re: Suggested buildd log check
* Jonathan Nieder [26 01:15]: > > If you have ideas for warnings/diagnostics visibile in buildd logs > > that are worth having listed in a view like that, please let me > > know. > > I'm not sure how your infrastructure copes with something like this, > but I would find it useful to have gcc 4.6's machine-parsable warnings > in such a list. They look like this: > > ../../src/gcc/graphite.c:59:29: warning: non-local variable > 'cloog_pointers__' with anonymous type is questionable in C++ [-Wc++-compat] > > I guess a regex like "\[-W[-+=a-z0-9]*\]" would do, plus > "\[-pedantic\]" and "\[-fpermissive\]".. > > I suppose these could all be lumped as one diagnostic type, except > that when new gcc releases introduce new warnings (like the recent > -Wunused-but-set-variable and -Wunused-but-set-parameter), they could > get a different tag. What do you think? While this could be extracted, I'm not sure it makes that much sense. Few packages are totally warning free and some are quite harmless, to it could distract to have too much information. (it could be info and not error and warning, but it still might not have that much information). Also the logs are usually done with very different compiler versions. Having packages in unstable with the last log two years old is not that uncommon. I definitely plan to add information pages for any dangerous warnings (currently a global rescan also looking for "warning: assignment makes pointer from integer without a cast" is running), and I'd love to get hints for other interesting warnings like those to add to that list. I can also gather more information, but would like to see some idea what to actually do with that vast amount of information. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2026150123.ga14...@server.brlink.eu
Re: Suggested buildd log check
* Matthias Klose [26 15:50]: > It would be good not to limit this to warnings only. Another use case is the > check if build flags are really passed to the upstream build system; this > seems > to be a requisite to the hardening release goal, because you generally can't > see > for every object in the resulting binary if it was built with or without > hardening defaults. This was already on my TODO list, but not near the top. So if anyone has some ideas or wants to write some little checkscript to look for those that would very much be appreciated. I guess one needs: - some checks to look for builds hiding compiler options (as that makes detecting which build flags impossible and also means porters have it much harder to investigate stuff) - some way to find out which buildflags the package got if it asked. (version of dpkg-buildflags exporting those also printed them. Currently there is no such information in the log. One might guess them from looking what dpkg-dev version was installed, but I guess it might be best to have dpkg-buildpackage print them and that information extracted). - some way to identify command lines calling a compiler. gcc can be called as cc, gcc, or something like i486-gnu-gcc. (similar for g++). Bernhard R. Link P.S: I guess the discussion left the topic of this mailing list. Any better to switch to? -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2026151840.gb14...@server.brlink.eu
