headers
Simon King | 1 Oct 2007 10:03
Picon
Picon
Favicon

Re: A problem related with installation of gcc 4.2.1?

Dear Brian,

> >   `/usr/local/sage-2.8.5.1/spkg/build/ntl-5.4.1.p5/src/src/small/src'
> >   ./InitSettings: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not
> >   found (required by ./InitSettings)
> 
> This simply means that there is a disparity between the version of
> libstdc++ that you linked InitSettings with versus the one that is being
> found at runtime.  You need to tell the dynamic linker (man ld.so) the
> location of the libstdc++ that corresponds to the gcc version used to
> compile and link the app, because right now it's finding the system one
> in /usr/lib64 which is too old.  Normally you do this with
> LD_LIBRARY_PATH but there are other ways.

Thank you very much! In the next few days, i'll not be able to work, but 
it seems that your answer will help me.

Yours sincerely
	Simon
Permalink | Reply | 0 comments |
headers
Andrew Haley | 1 Oct 2007 11:13
Favicon

Re: GCC ARM assembly questions

Phil Endecott writes:
 > Hi Priya,
 > 
 > Priya Narasimhan wrote:
 > > I am compiling relatively simple C programs using "gcc -S
 > > -fomit-frame-pointer -mcpu=xscale" on a gumstix (ARM Xscale) processor. I
 > > noticed that the generated assembly code has additional stuff in, beyond
 > > what I would typically see in a standard ARM assembly program (e.g., one
 > > that was generated instead through the ARM Development Suite toolchain). 
 > >
 > > For instance, I see the following comments in the GNU-generated assembly
 > > code. What do these signify? 
 > >
 > >  <at>  zero_extendqisi2
 > >  <at>  args =0, pretend =0 (what does pretend mean?)
 > >  <at>  frame_needed = 0, uses_anonymous_args = 0 (what does uses_anonymous_args
 > > mean?)
 > 
 > I don't know, and I suspect that the answer is not very interesting.  
 > The best way to find answers to these questions is probably to study 
 > the gcc source code.
 > 
 > > Secondly, I notice that without the "-O" option, saving registers to the
 > > stack happens almost on every alternate line of the generated assembly code.
 > > What is the purpose of doing this?
 > 
 > Without -O, gcc runs faster.  It can run faster by not spending time 
 > working out what can be stored in registers, and just using the stack 
 > for everything.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon King | 1 Oct 2007 12:43
Picon
Picon
Favicon

Re: A problem related with installation of gcc 4.2.1?

Dear Brian,

You wrote:
> This simply means that there is a disparity between the version of
> libstdc++ that you linked InitSettings with versus the one that is being
> found at runtime. 

I found softlinks libstdc++.so.6 both in /usr/lib/ and /usr/lib64/. Even 
after building gcc 4.2.1, they pointed to libstdc++.so.6.8, although gcc 
4.2.1 provides libstdc++.so.6.9. I changed this manually.

Do you think this is a definite solution, or might there be other details 
that i need to change by hand? At least i'm able to build some rather big 
computer algebra system, so, i'm rather confident that everything is 
alright now.

Thank you very much
Yours
	Simon
Permalink | Reply | 2 comments |
headers
Brian Dessent | 1 Oct 2007 13:31
Favicon

Re: A problem related with installation of gcc 4.2.1?

Simon King wrote:

> I found softlinks libstdc++.so.6 both in /usr/lib/ and /usr/lib64/. Even
> after building gcc 4.2.1, they pointed to libstdc++.so.6.8, although gcc
> 4.2.1 provides libstdc++.so.6.9. I changed this manually.

When you configure gcc you give it a --prefix.  If you don't specify a
prefix, the default is /usr/local.  This is the tree under which gcc
installs itself, and it does not mess with anything outside of that
tree.  It would be horribly broken if building gcc from source mucked
about with anything under /usr/lib or /usr/lib64 unless it was
explicitly configured for --prefix=/usr, so what you've observed is the
correct behavior: installing gcc with default options does not touch the
system compiler.  It is essential that software works this way, as it
allows for installing multiple versions side-by-side into different
prefixes, without any interference between them.  It also allows normal
users without administrative privileges to install private copies of
things, e.g. with --prefix=$HOME/foo/bar.

If you really want to replace the default system compiler then you need
to configure and install with --prefix=/usr.  But that's generally a
really, really bad idea because it violates the principle of "don't mess
around behind the back of your distro's package management system." 
This can lead to all kinds of disasterous situations, such as you go to
install routine vendor package updates and it overwrites your custom gcc
with an updated copy of the vendor's gcc, rendering all the programs
you'd compiled with that newer gcc version hopelessly broken.

> Do you think this is a definite solution, or might there be other details
> that i need to change by hand? At least i'm able to build some rather big
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Love-Jensen | 1 Oct 2007 13:47
Picon
Favicon

Re: Changing already written text in console

Hi Antonio,

For very simple output, you can use \r.

For anything non-trivial, you should consider using ncurses.

Even though some folks think it is a can of worms -- and I can sympathize
with that opinion.

If you need anything beyond non-trivial, you'll end up recreating a good
chunk of the ncurses functionality.  Why re-invent that particular very
painful wheel?

http://www.gnu.org/software/ncurses/

HTH,
--Eljay
Permalink | Reply | 0 comments |
headers
Maldonado-Salgado, Jose (Space Technology | 1 Oct 2007 16:59
Picon
Favicon

getrusage... Configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES


When building the the gfortran compiler I get the following error:

Checking for getrusage... Configure: error: Link tests are not allowed
after GCC_NO_EXECUTABLES
Make[1]: *** [configure-target-libgfortran] Error 1

Any ideas of what could be the problem?

Thanks,
Jose
Permalink | Reply | 1 comment |
headers
Maldonado-Salgado, Jose (Space Technology | 1 Oct 2007 18:15
Picon
Favicon

Libgfortran compilation error


 When compiling file environ.c in the libgfortran/runtime
get following error:  
/home/jose1472/gnu/gcc-4.2.1/libgfortran/libgfortran.h:455: error:
expected identifier before '(' token

I looked at the file, but I don't see a problem in that area of the
file.

Any ideas?

Thanks,
Jose
Permalink | Reply | 0 comments |
headers
NightStrike | 1 Oct 2007 21:43
Picon

Re: Difficulties with creating a cross compiler

On 9/28/07, Brian Dessent <brian <at> dessent.net> wrote:
> Scott Moore wrote:
>
> > Why does gcc make create this batch file "as" on cross compilers?
>
> You did install a cross-binutils and put its $prefix/bin ahead of the
> native tools in the PATH, right?  Because it looks like the gcc
> configure wasn't able to find arm-elf-as and is doing the wrong thing.

Shouldn't gcc dump out an error if as is not found for the target
system instead of creating the aforementioned shell script?
Permalink | Reply | 0 comments |
headers
NightStrike | 2 Oct 2007 07:47
Picon

Building g++ fails

I can't build g++ anymore.  I get this during a make all:

../../../gcc/libgcc/../gcc/libgcov.c: In function '__gcov_execve':
../../../gcc/libgcc/../gcc/libgcov.c:948: warning: passing argument 2
of 'execve' from incompatible pointer type
../../../gcc/libgcc/../gcc/libgcov.c:948: warning: passing argument 3
of 'execve' from incompatible pointer type
configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1
make: *** [all] Error 2

Any ideas?
Permalink | Reply | 3 comments |
headers
Simon King | 2 Oct 2007 10:57
Picon
Picon
Favicon

Re: A problem related with installation of gcc 4.2.1?

Dear Brian,

On Mon, 1 Oct 2007, Brian Dessent wrote:
> When you configure gcc you give it a --prefix.  If you don't specify a
> prefix, the default is /usr/local.
<snip>
> The better solution is to just add $prefix/lib to LD_LIBRARY_PATH. 

I used the default prefix for building gcc. Indeed, 
/usr/local/lib/libstdc++.so.6 correctly points to libstdc++.so.6.0.9, 
similarly in /usr/local/lib64

Therefore, after removing the mess in /usr/lib, i did 
LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64
(before, i checked that LD_LIBRARY_PATH was empty)
and tried "make" (for the computer algebra thing) again.

However, this did not help, i had the same trouble as before. According to 
the messages of "make", it really used gcc 4.2.1 (which is located in 
/usr/local/bin), but apparently LD_LIBRARY_PATH did not allow to use 
/usr/local/lib/libstdc++.so.6
Permalink | Reply | 0 comments |

Gmane