Why do we need to set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes?
Hi, Setting HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes causes: as: error while loading shared libraries: /builddir/build/BUILD/binutils/./opcodes/.libs/libopcodes-2.23.51.0.2-0.1.fc17.so: file too short make[4]: *** [gold-threads.o] Error 2 when compiling gold using binutils linked with the same versions of libbfd and libopcodes. As far as I can tell, one can run the newly built binutils without setting them since libtool already sets up proper DT_RPATH. -- H.J.
PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes
On Sat, Aug 25, 2012 at 8:31 AM, H.J. Lu wrote:
> Hi,
>
> Setting HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes causes:
>
> as: error while loading shared libraries:
> /builddir/build/BUILD/binutils/./opcodes/.libs/libopcodes-2.23.51.0.2-0.1.fc17.so:
> file too short
> make[4]: *** [gold-threads.o] Error 2
>
> when compiling gold using binutils linked with the same versions of libbfd
> and libopcodes. As far as I can tell, one can run the newly built binutils
> without setting them since libtool already sets up proper DT_RPATH.
>
The change was introduced by
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01452.html
Paolo, do you remember the reason for this?
I tested this patch and works fine with --enable-shared for binutils.
I tested both separate build directory and in-source build. OK
to install?
Thanks.
--
H.J.
2012-08-24 H.J. Lu
* Makefile.def (host_modules): Rmove lib_path=.libs from bfd
and opcodes.
* Makefile.in: Regenerated.
diff --git a/Makefile.def b/Makefile.def
index 9e41ff5..220c720 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -32,8 +32,8 @@ build_modules= { module= m4; };
build_modules= { module= texinfo; };
build_modules= { module= fixincludes; };
-host_modules= { module= bfd; lib_path=.libs; bootstrap=true; };
-host_modules= { module= opcodes; lib_path=.libs; bootstrap=true; };
+host_modules= { module= bfd; bootstrap=true; };
+host_modules= { module= opcodes; bootstrap=true; };
host_modules= { module= binutils; bootstrap=true; };
host_modules= { module= bison; no_check_cross= true; };
host_modules= { module= cgen; };
diff --git a/Makefile.in b/Makefile.in
index 038f801..4fc4d36 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -621,7 +621,7 @@ TARGET_LIB_PATH_libgomp =
$$r/$(TARGET_SUBDIR)/libgomp/.libs:
# This is the list of directories that may be needed in RPATH_ENVVAR
# so that programs built for the host machine work.
-HOST_LIB_PATH =
$(HOST_LIB_PATH_bfd)$(HOST_LIB_PATH_opcodes)$(HOST_LIB_PATH_gmp)$(HOST_LIB_PATH_mpfr)$(HOST_LIB_PATH_mpc)$(HOST_LIB_PATH_ppl)$(HOST_LIB_PATH_cloog)$(HOST_LIB_PATH_libelf)
+HOST_LIB_PATH =
$(HOST_LIB_PATH_gmp)$(HOST_LIB_PATH_mpfr)$(HOST_LIB_PATH_mpc)$(HOST_LIB_PATH_ppl)$(HOST_LIB_PATH_cloog)$(HOST_LIB_PATH_libelf)
# Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch
@if gcc
@@ -629,16 +629,6 @@ HOST_LIB_PATH_gcc =
$$r/$(HOST_SUBDIR)/gcc$(GCC_SHLIB_SUBDIR):$$r/$(HOST_SUBDIR)
@endif gcc
-@if bfd
-HOST_LIB_PATH_bfd = \
- $$r/$(HOST_SUBDIR)/bfd/.libs:$$r/$(HOST_SUBDIR)/prev-bfd/.libs:
-@endif bfd
-
-@if opcodes
-HOST_LIB_PATH_opcodes = \
- $$r/$(HOST_SUBDIR)/opcodes/.libs:$$r/$(HOST_SUBDIR)/prev-opcodes/.libs:
-@endif opcodes
-
@if gmp
HOST_LIB_PATH_gmp = \
$$r/$(HOST_SUBDIR)/gmp/.libs:$$r/$(HOST_SUBDIR)/prev-gmp/.libs:
GDB issues on Trunk
Hello Everyone, I am trying to debug "cc1" through gdb but is not working as it was before (my current revision is 190623) . For example, when I try to print out any local variable when I am inside the function, it says the variable is not in in the context. Here is an example below: e.g. Single stepping until exit from function _ZL14tree_vectorizev, which has no line number information. vectorize_loops() () at ../../trunk-gcc/gcc/tree-vectorizer.c:168 168 unsigned int num_vectorized_loops = 0; (gdb) n 173 vect_loops_num = number_of_loops (); (gdb) p num_vectorized_loops No symbol "num_vectorized_loops" in current context. Another wierd thing I noticed is that "Breakpoint 1 and Breakpoint 2" generally point to 2 lines in diagnostic.c (I believe they are fancy_abort and internal_error) but now it is just giving addresses. Also, when I start something, it says it can't find line number information: Can someone please tell me how I can to fix these? Any help is greatly appreciated! Thanks, Balaji V. Iyer. PS. Please CC me when responding.
Re: GDB issues on Trunk
On Sat, Aug 25, 2012 at 10:28 AM, Iyer, Balaji V wrote: > Hello Everyone, > I am trying to debug "cc1" through gdb but is not working as it was > before (my current revision is 190623) . For example, when I try to print out > any local variable when I am inside the function, it says the variable is not > in in the context. Here is an example below: What version of gdb are you using? IIRC for the trunk at least GDB 7.5 is required now to debug code generated from it as we produce some dwarf4 that only 7.5 and above understands. Thanks, Andrew > > e.g. > > Single stepping until exit from function _ZL14tree_vectorizev, > which has no line number information. > vectorize_loops() () at ../../trunk-gcc/gcc/tree-vectorizer.c:168 > 168 unsigned int num_vectorized_loops = 0; > (gdb) n > 173 vect_loops_num = number_of_loops (); > (gdb) p num_vectorized_loops > No symbol "num_vectorized_loops" in current context. > > > Another wierd thing I noticed is that "Breakpoint 1 and Breakpoint 2" > generally point to 2 lines in diagnostic.c (I believe they are fancy_abort > and internal_error) but now it is just giving addresses. Also, when I start > something, it says it can't find line number information: > > Can someone please tell me how I can to fix these? > > Any help is greatly appreciated! > > Thanks, > > Balaji V. Iyer. > > PS. Please CC me when responding.
RE: GDB issues on Trunk
>-Original Message- >From: Andrew Pinski [mailto:pins...@gmail.com] >Sent: Saturday, August 25, 2012 1:31 PM >To: Iyer, Balaji V >Cc: gcc@gcc.gnu.org >Subject: Re: GDB issues on Trunk > >On Sat, Aug 25, 2012 at 10:28 AM, Iyer, Balaji V >wrote: >> Hello Everyone, >> I am trying to debug "cc1" through gdb but is not working as it was >> before >(my current revision is 190623) . For example, when I try to print out any >local >variable when I am inside the function, it says the variable is not in in the >context. >Here is an example below: > >What version of gdb are you using? IIRC for the trunk at least GDB >7.5 is required now to debug code generated from it as we produce some >dwarf4 that only 7.5 and above understands. Yes, upgrading to gdb 7.5 seem to have fixed the problem! I was using 7.4.1 and 7.2 in my machines. Thanks, Balaji V. Iyer. > >Thanks, >Andrew > >> >> e.g. >> >> Single stepping until exit from function _ZL14tree_vectorizev, which >> has no line number information. >> vectorize_loops() () at ../../trunk-gcc/gcc/tree-vectorizer.c:168 >> 168 unsigned int num_vectorized_loops = 0; >> (gdb) n >> 173 vect_loops_num = number_of_loops (); >> (gdb) p num_vectorized_loops >> No symbol "num_vectorized_loops" in current context. >> >> >> Another wierd thing I noticed is that "Breakpoint 1 and Breakpoint 2" >> generally >point to 2 lines in diagnostic.c (I believe they are fancy_abort and >internal_error) >but now it is just giving addresses. Also, when I start something, it says it >can't >find line number information: >> >> Can someone please tell me how I can to fix these? >> >> Any help is greatly appreciated! >> >> Thanks, >> >> Balaji V. Iyer. >> >> PS. Please CC me when responding.
Using C++ - Problem with
Hello, I'm currently playing around with an RTL pass and started using C++. When including I get the following: /usr/include/c++/4.6/cstdlib:76:8: error: attempt to use poisoned "calloc" /usr/include/c++/4.6/cstdlib:83:8: error: attempt to use poisoned "malloc" /usr/include/c++/4.6/cstdlib:89:8: error: attempt to use poisoned "realloc" It seems the story is old: http://gcc.gnu.org/ml/gcc/2009-08/msg00553.html Now that the switch to C++ has been made, how should this be handled? Cheers, Oleg
Re: Using C++ - Problem with
On Sat, Aug 25, 2012 at 1:27 PM, Oleg Endo wrote: > > I'm currently playing around with an RTL pass and started using C++. > When including I get the following: > > /usr/include/c++/4.6/cstdlib:76:8: error: attempt to use poisoned > "calloc" > /usr/include/c++/4.6/cstdlib:83:8: error: attempt to use poisoned > "malloc" > /usr/include/c++/4.6/cstdlib:89:8: error: attempt to use poisoned > "realloc" > > It seems the story is old: > http://gcc.gnu.org/ml/gcc/2009-08/msg00553.html > > Now that the switch to C++ has been made, how should this be handled? Add #include to system.h, right by, or perhaps replacing, the #include . Ian
Re: Let INSTALL/README mention the instructions on line
On Wed, 15 Feb 2012, Křištof Želechovski wrote: > Please consider the following patch: Thank you, Křištof! I made some small tweaks, created a ChangeLog entry and applied the variation of your patch that is included below. Gerald 2012-08-25 Křištof Želechovski * INSTALL/README: Also refer to the online installation instructions. Index: INSTALL/README === --- INSTALL/README (revision 190505) +++ INSTALL/README (working copy) @@ -4,3 +4,4 @@ gcc/doc/install.texi and copied into this directory. To read this documentation, please point your HTML browser to "index.html". +The latest version is always available at http://gcc.gnu.org/install/ .
Re: PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes
On Saturday 25 August 2012 11:58:08 H.J. Lu wrote: > On Sat, Aug 25, 2012 at 8:31 AM, H.J. Lu wrote: > > Hi, > > > > Setting HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes causes: > > > > as: error while loading shared libraries: > > /builddir/build/BUILD/binutils/./opcodes/.libs/libopcodes-2.23.51.0.2-0.1 > > .fc17.so: file too short > > make[4]: *** [gold-threads.o] Error 2 > > > > when compiling gold using binutils linked with the same versions of > > libbfd and libopcodes. As far as I can tell, one can run the newly built > > binutils without setting them since libtool already sets up proper > > DT_RPATH. > > The change was introduced by > > http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01452.html > > Paolo, do you remember the reason for this? > > I tested this patch and works fine with --enable-shared for binutils. > I tested both separate build directory and in-source build. OK > to install? does this also fix: http://sourceware.org/bugzilla/show_bug.cgi?id=4970 -mike signature.asc Description: This is a digitally signed message part.
Re: PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes
On Sat, Aug 25, 2012 at 3:27 PM, Mike Frysinger wrote: > On Saturday 25 August 2012 11:58:08 H.J. Lu wrote: >> On Sat, Aug 25, 2012 at 8:31 AM, H.J. Lu wrote: >> > Hi, >> > >> > Setting HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes causes: >> > >> > as: error while loading shared libraries: >> > /builddir/build/BUILD/binutils/./opcodes/.libs/libopcodes-2.23.51.0.2-0.1 >> > .fc17.so: file too short >> > make[4]: *** [gold-threads.o] Error 2 >> > >> > when compiling gold using binutils linked with the same versions of >> > libbfd and libopcodes. As far as I can tell, one can run the newly built >> > binutils without setting them since libtool already sets up proper >> > DT_RPATH. >> >> The change was introduced by >> >> http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01452.html >> >> Paolo, do you remember the reason for this? >> >> I tested this patch and works fine with --enable-shared for binutils. >> I tested both separate build directory and in-source build. OK >> to install? > > does this also fix: > http://sourceware.org/bugzilla/show_bug.cgi?id=4970 > -mike Yes, it should. That is the same bug I ran into. Please give my patch a try. Thanks. -- H.J.
gcc-4.7-20120825 is now available
Snapshot gcc-4.7-20120825 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120825/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 190670 You'll find: gcc-4.7-20120825.tar.bz2 Complete GCC MD5=c10e6a5dcf0186afc4eb584aaefde2e1 SHA1=eaabc866369fe0c24f4b5436e737184da481007f Diffs from 4.7-20120818 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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: internal compiler error using lambda and this
On Tue, 29 May 2012, Andreas Karrenbauer wrote:
> To whom it may concern:
>
> Please find a small code example which causes an internal compiler error with
> g++-4.7 (opensuse):
Thanks for the report, Andreas.
I tried this with a current snapshot of what will become GCC 4.8.0
in several months, and now get this:
$ cat x.cc
auto foo = [&](int a) { return a > this->b; };
$ g++ x.cc
x.cc:1:6: error: 'foo' does not name a type
auto foo = [&](int a) { return a > this->b; };
^
And seeing that you used openSUSE, the GCC 4.7.1 based system compiler
of openSUSE 12.2 now issues
$ g++ x.cc
x.cc:1:6: error: ‘foo’ does not name a type
Note, the best way to report bugs so that they get tracked properly
is via our bug tracker at http://gcc.gnu.org/bugzilla/ .
Gerald
GCC with Solaris -- using std::locale crashes
Hi,
I am currently using GCC 4.4.4 on my Solaris machine and I am having a
difficult time getting it to compile with "locale-support".
For example, if I build the simple file:
#include
int main()
{
std::cout.imbue(std::locale("en_US.UTF-8"));
return 0;
}
and run it, it will throw a runtime exception -- "std::runtime_error:
locale::facet::_S_create_c_locale name not valid"
I've stepped through the GCC code and I notice that there is code in
c++locale.cc (libstdc++v3 folder) that looks something like this:
If (locale being used is NOT “C” and NOT “POSIX”)
{
throw std::runtime_error(“locale::facet::_S_create name not valid”);
}
So, I am guessing that the problem here, is that GCC is not build with
"locale-support" and therefore, I am only allowed to use "C" and
"POSIX" locales. Is this correct? Also, I am guessing if that if I
rebuild GCC to support locales, that I can use locales other than "C"
or "POSIX" on Solaris.
I tried rebuilding GCC 4.4.4 with the flag "--enable-clocale=gnu" and
it still crashed in the same location. I also tried building GCC with
the flag "--enable-clocale=ieee_1003.1-2001", and this time, it didn't
even build.
So, I was wondering if there is something that I haven't tried that
someone can suggest? I'd like to build GCC so that I can use UTF-8
locales.
Thanks,
J
Re: GCC with Solaris -- using std::locale crashes
On 26 August 2012 00:29, JonathonS wrote:
> Hi,
>
> I am currently using GCC 4.4.4 on my Solaris machine and I am having a
> difficult time getting it to compile with "locale-support".
Your question is not appropriate for this mailing list, which is about
development of GCC. For help using GCC please use the gcc-help mailing
list, thanks.
> For example, if I build the simple file:
>
> #include
>
> int main()
> {
> std::cout.imbue(std::locale("en_US.UTF-8"));
> return 0;
> }
>
> and run it, it will throw a runtime exception -- "std::runtime_error:
> locale::facet::_S_create_c_locale name not valid"
>
> I've stepped through the GCC code and I notice that there is code in
> c++locale.cc (libstdc++v3 folder) that looks something like this:
>
> If (locale being used is NOT “C” and NOT “POSIX”)
> {
>throw std::runtime_error(“locale::facet::_S_create name not valid”);
> }
>
> So, I am guessing that the problem here, is that GCC is not build with
> "locale-support" and therefore, I am only allowed to use "C" and
> "POSIX" locales. Is this correct? Also, I am guessing if that if I
> rebuild GCC to support locales, that I can use locales other than "C"
> or "POSIX" on Solaris.
>
> I tried rebuilding GCC 4.4.4 with the flag "--enable-clocale=gnu" and
That won't work on Solaris.
> it still crashed in the same location. I also tried building GCC with
> the flag "--enable-clocale=ieee_1003.1-2001", and this time, it didn't
> even build.
Please check if it's the same as an existing report in
http://gcc.gnu.org/bugzilla and open a new bug i not.
> So, I was wondering if there is something that I haven't tried that
> someone can suggest? I'd like to build GCC so that I can use UTF-8
> locales.
The "gnu" model is the only one that is complete. The
"ieee_1003.1-2001" model should work on Solaris, but does have some
issues.
If I ever find time I intend to work on the locale code to use the
POSIX 2008 xlocale features, which would provide the same
functionality as the "gnu" model but on more platforms than just
GNU/Linux.
Re: typos in http://gcc.gnu.org/wiki/CppConventions
On Fri, 15 Jun 2012, Jonathan Wakely wrote: >> They clause client code taking the address >> >> => cause >> >> >> structs adn classes >> => and > So fix them, it's a wiki. I saw these typos were still there, so I just fixed them. Thanks for the report, Jay. Gerald
Re: PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes
On Saturday 25 August 2012 18:31:32 H.J. Lu wrote: > On Sat, Aug 25, 2012 at 3:27 PM, Mike Frysinger wrote: > > On Saturday 25 August 2012 11:58:08 H.J. Lu wrote: > >> On Sat, Aug 25, 2012 at 8:31 AM, H.J. Lu wrote: > >> > Hi, > >> > > >> > Setting HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes causes: > >> > > >> > as: error while loading shared libraries: > >> > /builddir/build/BUILD/binutils/./opcodes/.libs/libopcodes-2.23.51.0.2- > >> > 0.1 .fc17.so: file too short > >> > make[4]: *** [gold-threads.o] Error 2 > >> > > >> > when compiling gold using binutils linked with the same versions of > >> > libbfd and libopcodes. As far as I can tell, one can run the newly > >> > built binutils without setting them since libtool already sets up > >> > proper DT_RPATH. > >> > >> The change was introduced by > >> > >> http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01452.html > >> > >> Paolo, do you remember the reason for this? > >> > >> I tested this patch and works fine with --enable-shared for binutils. > >> I tested both separate build directory and in-source build. OK > >> to install? > > > > does this also fix: > > http://sourceware.org/bugzilla/show_bug.cgi?id=4970 > > Yes, it should. That is the same bug I ran into. Please > give my patch a try. yep, seems to fix the use case i described (cross-compiler with shared libs enabled and running the same version of binutils with shared libs on the host) -mike signature.asc Description: This is a digitally signed message part.
