-isysroot option ignored for crosscompiler?
Hello! Trying to use --with-build-sysroot configure option, the build failed with "error: no include path in which to search for ..." error. This problem come down to the fact, that -isysroot is ignored when crosscompiling: $ more in.c #include Native compiler compiles this without problems: $ ~/gcc-build/gcc/xgcc -B ~/gcc-build/gcc -isysroot /home/uros/sys-root -quiet -v in.c Target: x86_64-unknown-linux-gnu Configured with: ../gcc-svn/trunk/configure --enable-languages=c,c++,fortran Thread model: posix gcc version 4.6.0 20101015 (experimental) [trunk revision 165513] (GCC) COLLECT_GCC_OPTIONS='-B' '/home/uros/gcc-build/gcc' '-isysroot' '/home/uros/sys-root' '-v' '-mtune=generic' '-march=x86-64' /home/uros/gcc-build/gcc/cc1 -quiet -v -iprefix /home/uros/gcc-build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/ -isystem /home/uros/gcc-build/gcc/include -isystem /home/uros/gcc-build/gcc/include-fixed -isysroot /home/uros/sys-root in.c -quiet -dumpbase in.c -mtune=generic -march=x86-64 -auxbase in -version -o /tmp/ccyTmHfz.s GNU C (GCC) version 4.6.0 20101015 (experimental) [trunk revision 165513] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20101015 (experimental) [trunk revision 165513], GMP version 4.3.1, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/home/uros/gcc-build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include" ignoring nonexistent directory "/home/uros/gcc-build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed" ignoring nonexistent directory "/home/uros/gcc-build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "/home/uros/gcc-build/gcc/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include" ignoring nonexistent directory "/home/uros/sys-root/usr/local/include" ignoring nonexistent directory "/home/uros/gcc-build/gcc/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed" ignoring nonexistent directory "/home/uros/gcc-build/gcc/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/uros/gcc-build/gcc/include /home/uros/gcc-build/gcc/include-fixed /home/uros/sys-root/usr/include End of search list. Crosscompiler does not handle -isysroot correctly: $ ~/gcc-build-alpha/gcc/xgcc -B ~/gcc-build-alpha/gcc -isysroot /home/uros/sys-root -quiet -v in.c Target: alphaev68-pc-linux-gnu Configured with: ../gcc-svn/trunk/configure --target=alphaev68-pc-linux-gnu --enable-languages=c Thread model: posix gcc version 4.6.0 20101009 (experimental) [trunk revision 165234] (GCC) COLLECT_GCC_OPTIONS='-B' '/home/uros/gcc-build-alpha/gcc' '-isysroot' '/home/uros/sys-root' '-v' '-mcpu=ev67' /home/uros/gcc-build-alpha/gcc/cc1 -quiet -v -iprefix /home/uros/gcc-build-alpha/gcc/../lib/gcc/alphaev68-pc-linux-gnu/4.6.0/ -isystem /home/uros/gcc-build-alpha/gcc/include -isystem /home/uros/gcc-build-alpha/gcc/include-fixed -isysroot /home/uros/sys-root in.c -quiet -dumpbase in.c -mcpu=ev67 -auxbase in -version -o /tmp/cc9QXyzH.s GNU C (GCC) version 4.6.0 20101009 (experimental) [trunk revision 165234] (alphaev68-pc-linux-gnu) compiled by GNU C version 4.4.4 20100630 (Red Hat 4.4.4-10), GMP version 4.3.1, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/home/uros/gcc-build-alpha/gcc/../lib/gcc/alphaev68-pc-linux-gnu/4.6.0/include" ignoring nonexistent directory "/home/uros/gcc-build-alpha/gcc/../lib/gcc/alphaev68-pc-linux-gnu/4.6.0/include-fixed" ignoring nonexistent directory "/home/uros/gcc-build-alpha/gcc/../lib/gcc/alphaev68-pc-linux-gnu/4.6.0/../../../../alphaev68-pc-linux-gnu/sys-include" ignoring nonexistent directory "/home/uros/gcc-build-alpha/gcc/../lib/gcc/alphaev68-pc-linux-gnu/4.6.0/../../../../alphaev68-pc-linux-gnu/include" ignoring nonexistent directory "/home/uros/gcc-build-alpha/gcc/../lib/gcc/../../lib/gcc/alphaev68-pc-linux-gnu/4.6.0/include" ignoring nonexistent directory "/home/uros/gcc-build-alpha/gcc/../lib/gcc/../../lib/gcc/alphaev68-pc-linux-gnu/4.6.0/include-fixed" ignoring nonexistent directory "/home/uros/gcc-build-alpha/gcc/../lib/gcc/../../lib/gcc/alphaev68-pc-linux-gnu/4.6.0/../../../../alphaev68-pc-linux-gnu/sys-include" ignoring nonexistent directory "/home/uros/gcc-build-alpha/gcc/../lib/gcc/../../lib/gcc/alphaev68-pc-linux-gnu/4.6.0/../../../../alphaev68-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/uros/gcc-build-alpha/gcc/include /home/uros/gcc-build-alpha/gcc/include-fixed End of search list. Please note that /home/uros/sys-root/usr/include include directory is missing at the end. The difference happens in gcc/cppdefault.c: #if defined (CROSS_DIRECTORY_STRUCTURE) && !defi
dropping gccbug
I noticed mainline still installs "gccbug" Is the gccbug script still useful? It seems to be gnats specific, and I don't think gnats is used anymore. Should it be dropped? Thanks, -Andi
Re: dropping gccbug
On Sat, 16 Oct 2010, Andi Kleen wrote: > I noticed mainline still installs "gccbug" > > Is the gccbug script still useful? It seems to be gnats specific, > and I don't think gnats is used anymore. Should it be dropped? That's PR 43448. Yes, it should be removed from trunk and active release branches. I think the gcc-gnats email gateway to Bugzilla was disabled (or broken) with the recent Bugzilla upgrade, though I don't know what sort of bounce you get if you submit something with gccbug now. -- Joseph S. Myers jos...@codesourcery.com
LTO symtabs inconsistency
Hello team,
Previously, I have noticed that symbols in LTO symtabs don't have
underscores. Now I have found that some of them do. These are the native
symbols from gcc/intl.o during LTO-enabled bootstrap stage2:
> $ nm intl.o
> b .bss
> d .data
> N .debug_abbrev
> N .debug_aranges
> N .debug_info
> N .debug_line
> N .debug_loc
> N .debug_str
> r .eh_frame
> r .gnu.lto_.cgraph.e2eb6ce9
> r .gnu.lto_.decls.e2eb6ce9
> r .gnu.lto_.jmpfuncs.e2eb6ce9
> r .gnu.lto_.opts
> r .gnu.lto_.pureconst.e2eb6ce9
> r .gnu.lto_.refs.e2eb6ce9
> r .gnu.lto_.statics.e2eb6ce9
> r .gnu.lto_.symtab.e2eb6ce9
> r .gnu.lto_.vars.e2eb6ce9
> r .gnu.lto_gcc_gettext_width.e2eb6ce9
> r .gnu.lto_gcc_init_libintl.e2eb6ce9
> r .gnu.lto_get_spaces.e2eb6ce9
> r .rdata
> t .text
> U ___chkstk_ms
> 0001 C ___gnu_lto_v1
> D _close_quote
> 0110 T _gcc_gettext_width
> T _gcc_init_libintl
> 0180 T _get_spaces
> U _libintl_bindtextdomain
> U _libintl_gettext
> U _libintl_textdomain
> 0004 B _locale_encoding
> B _locale_utf8
> U _mbstowcs
> U _memset
> U _nl_langinfo
> 0004 D _open_quote
> U _setlocale
> U _strcasecmp
> U _wcswidth
> U _xmalloc
This is i686-pc-cygwin, btw, and PE-COFF object format. Here is the
contents of the LTO symtab from the file:
> $ objdump -s -j .gnu.lto_.symtab.e2eb6ce9 intl.o
>
> intl.o: file format pe-i386
>
> Contents of section .gnu.lto_.symtab.e2eb6ce9:
> 6763635f 696e6974 5f6c6962 696e746c gcc_init_libintl
> 0010 7000 p...
> 0020 6763635f 67657474 6578745f 77696474 gcc_gettext_widt
> 0030 6800 0074 ht..
> 0040 00676574 5f737061 63657300 .get_spaces.
> 0050 007b 006e 6c5f6c61 ...{...nl_la
> 0060 6e67696e 666f 0200 nginfo..
> 0070 9600 5f6c 6962696e 746c5f74 .._libintl_t
> 0080 65787464 6f6d6169 6e02 extdomain...
> 0090 00a6 005f6c69 62696e74 ._libint
> 00a0 6c5f6269 6e647465 7874646f 6d61696e l_bindtextdomain
> 00b0 0200 a900
> 00c0 7365746c 6f63616c 6502 setlocale...
> 00d0 00af 00776373 77696474 .wcswidt
> 00e0 6802 00b5 h...
> 00f0 006d6273 746f7763 7302 .mbstowcs...
> 0100 00bd 00786d61 6c6c6f63 .xmalloc
> 0110 0200 cf00
> 0120 6f70656e 5f71756f 7465 open_quote..
> 0130 d500 636c 6f73655f ..close_
> 0140 71756f74 6500 quote...
> 0150 00da 006c6f63 616c655f 656e636f .locale_enco
> 0160 64696e67 ding
> 0170 df00 6c6f6361 6c655f75 74663800 locale_utf8.
> 0180 00e1 00...
For some reason, the two libintl symbols have underscores. gettext is
missing altogether because we have a builtin for it, but I don't think we do
for (bind)textdomain.
Is this expected?
cheers,
DaveK
[trunk] hard-reg-set.h not installed in plugins/include
Hello,
It seems that the file hard-reg-set.h is included from gimple.h
but it is not installed in the PLUGIN_HEADERS (inside gcc/Makefile.in)
So I believe that any plugin for gcc trunk (at least rev 165392) which
#include-s "gimple.h" cannot be compiled.
(I actually noticed that bug in the MELT branch,
but it follows the trunk in that respect).
Did anyone installed the trunk recently and compiled a plugin including
"gimple.h" for it?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [trunk] hard-reg-set.h not installed in plugins/include
On Sat, 16 Oct 2010 23:14:18 +0200
Basile Starynkevitch wrote:
>
> Hello,
>
> It seems that the file hard-reg-set.h is included from gimple.h
> but it is not installed in the PLUGIN_HEADERS (inside gcc/Makefile.in)
>
> So I believe that any plugin for gcc trunk (at least rev 165392) which
> #include-s "gimple.h" cannot be compiled.
I believe that $(REGSET_H) should be added to $(PLUGIN_HEADERS) near
line 4506 of gcc/Makefile.in [but I don't propose a patch now, because
I really would prefer my
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01262.html patch to be
reviewed and Ok-ed first.]
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [trunk] hard-reg-set.h not installed in plugins/include
On Sat, 16 Oct 2010 23:28:37 +0200
Basile Starynkevitch wrote:
>
> I believe that $(REGSET_H) should be added to $(PLUGIN_HEADERS) near
> line 4506 of gcc/Makefile.in [but I don't propose a patch now, because
> I really would prefer my
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01262.html patch to be
> reviewed and Ok-ed first.]
I just commited such a patch to the MELT branch (which I merged to
trunk rev.165564), I built and installed it, and the installed MELT
works again. So I believe the fix should work even on the trunk.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
gcc-4.6-20101016 is now available
Snapshot gcc-4.6-20101016 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101016/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 165566 You'll find: gcc-4.6-20101016.tar.bz2 Complete GCC (includes all of below) MD5=58e77420e3da443601faec3db8cbad2b SHA1=f721f4ca3a3c88305145fbfff292359f27cf82d2 gcc-core-4.6-20101016.tar.bz2C front end and core compiler MD5=950c8088f778b53dcd4dc3f65ed045e0 SHA1=ac7e4764a10c4194da56a4daf223e99068dfe706 gcc-ada-4.6-20101016.tar.bz2 Ada front end and runtime MD5=6217b039d68dff47d1217d5e83877bd4 SHA1=945c7d0ddc7cea39eb5b173d4e76e2e136f44338 gcc-fortran-4.6-20101016.tar.bz2 Fortran front end and runtime MD5=66ba0b5425ae9ad572dc029a912470d5 SHA1=e9833c1756ceae35dc5f6eb584d162625750ff6e gcc-g++-4.6-20101016.tar.bz2 C++ front end and runtime MD5=da9111cf0f760fcd10ed5c2cce94b518 SHA1=1d08dcb233533e4791828f40b3e18bb13e453d51 gcc-java-4.6-20101016.tar.bz2Java front end and runtime MD5=7178a551712ff292e57fa0e349131046 SHA1=c20c1fdbe0a651a6f452d1a47dc5666df7cb0229 gcc-objc-4.6-20101016.tar.bz2Objective-C front end and runtime MD5=12aeed33c5834b1e4e5d85f6c5b784e5 SHA1=1d3ecc380fb5b6872942cde4188ec5fa41fbbe91 gcc-testsuite-4.6-20101016.tar.bz2 The GCC testsuite MD5=8198c9be3d01e740b0a18b23240b9a5b SHA1=81fa77eb7b8f4164f44f28d0ea0737c3feec5fcb Diffs from 4.6-20101009 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: LTO symtabs inconsistency
On 16/10/2010 21:20, Dave Korn wrote: >> U _libintl_bindtextdomain >> U _libintl_gettext >> U _libintl_textdomain >> 0070 9600 5f6c 6962696e 746c5f74 .._libintl_t >> 0080 65787464 6f6d6169 6e02 extdomain... >> 0090 00a6 005f6c69 62696e74 ._libint >> 00a0 6c5f6269 6e647465 7874646f 6d61696e l_bindtextdomain >> 00b0 0200 a900 > For some reason, the two libintl symbols have underscores. gettext is > missing altogether because we have a builtin for it, but I don't think we do > for (bind)textdomain. Ah. It's because those functions have assembler names defined for them already: > (gdb) call debug_tree ($5) > Can someone clarify the purpose of the LTO symtab: is it there for anything that LTO itself does, or is it solely to get the linker to pick up kind-of-more-or-less the right dependencies? IOW, would it make sense for the LTO symtab entries to be transformed by ASM_OUTPUT_LABELREF, are they intended to be assembler-level symbols, or are they supposed to be C-level symbols? cheers, DaveK
