g++4.4 - managed to compile but can't run g++

g++4.4 - managed to compile but can't run g++

[Simon Hill]

DISCLAIMER: I'm not sure if this is the right forum/place to post
this. If there is a more appropriate forum then sorry, but please
direct me to it. END.


I have been wanting to try out some of the features of c++0x that are
being implemented in g++. I'm trying to get g++ 4.4 installed and
going (I want to test/use "ctor() =delete" etc).

After a lot of messing around I finally got g++ to compile and:
"./g++ --version"
reports:
"g++ (GCC) 4.4.0 20080808 (experimental)"

However, when I run
"./g++ test.cpp" (eventually I want "./g++ test.cpp -std=c++0x").
I get:
"g++: error trying to exec 'cc1plus': execvp: No such file or directory"
cc1plus is in the same directory as g++, (.) or current.

Not sure if this is causing problems, but I have the default ubuntu
g++ installed elsewhere.
"which g++"
reports:
"/usr/bin/g++"
And
"g++ --version" (Note no ./)
reports:
g++ (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

If it's necessary/useful, I got and tested g++4.4 by:
Downloaded: "gcc-4.4-20080808.tar.bz2" from
"ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080808/" (I tried using the
svn but couldn't find version 4.4)
Unzipped to: "/make"
"cd /make/gcc-4.4-20080808"
"mkdir target"
"cd target"
"../configure --disable-multilib"
"make" (left overnight - takes many hours)
"cd gcc"
"g++ --version" reports 4.4 as above.
"g++ /make/test/test.cpp" reports the error posted above.

I'm running:
Ubuntu Release 8.04 (hardy) - x86-64 version.
Intel Core2 Duo.

Is there some g++ parameter I need to provide to specify the location
of "cc1plus"?

Thanks for all assistance.

Re: g++4.4 - managed to compile but can't run g++

[Brian Dessent]

Simon Hill wrote:

> DISCLAIMER: I'm not sure if this is the right forum/place to post
> this. If there is a more appropriate forum then sorry, but please
> direct me to it. END.

This is the proper mailing list.

> "cd /make/gcc-4.4-20080808"
> "mkdir target"
> "cd target"
> "../configure --disable-multilib"
> "make" (left overnight - takes many hours)
> "cd gcc"
> "g++ --version" reports 4.4 as above.
> "g++ /make/test/test.cpp" reports the error posted above.

You've built gcc but not installed it.  gcc is not meant to be used from
the build tree without being installed, except by the testsuite which
has specific infrastructure for doing this.

To install gcc, run "make install".  This will install gcc in the
--prefix that you configured with, which defaults to /usr/local since
you didn't supply a --prefix.  That's usually a fine default, as that is
the common place for non-distro-provided self-compiled things.  On most
distros normal users don't have write access to /usr/local so you'll
probably have to change to root first (or use sudo) or else configure
with a prefix where you do have write access.

After "make install" finishes you will need to add /usr/local/bin to
your PATH.  Most distros already add this to PATH by default in one of
the shell startup rc files, so you probably don't have to do anything. 
Note also that since you didn't use --program-prefix or --program-suffix
(or anything fancy like that) the new gcc will simply be named 'gcc',
'g++' etc.  Since you also have a system compiler of the same name in
/usr/bin, this means the order of PATH will determine which gets used
when you invoke 'gcc'.  You can change this by explicitly naming the
compiler, e.g. '/usr/local/bin/gcc', or reordering PATH, or you can
configure your gcc to have a different name.  For example if you used
--program-suffix=-4.4 then after "make install" you would have gcc-4.4,
g++-4.4 and so on.

Finally, there is the matter of notifying the dynamic linker of the new
shared libraries you just installed.  This is a more complicated subject
and there are multiple ways of solving it, some which require action at
run-time and some at link-time.

Firstly, you need to determine the location where the shared libraries
were installed.  This defaults to something resembling
$prefix/lib/gcc/$target, possibly with lib64 or lib32 instead of lib
(although not in your case since you disabled multilibbing.)  There
could be a version number in there on the end if you used
--enable-version-specific-runtime-libs which is useful if you want to
install multiple versions of gcc into the same prefix.  You can have gcc
tell you the name of the location with something like:

dirname $(gcc -print-libgcc-file-name)

This should be the directory that contains the shared libraries (*.so)
for libgcc_s, libstdc++, libgfortran, and so on.  Once you have this
directory (call it FOO) you need to decide how you want to tell the
dynamic linker to search there:

- add FOO to /etc/ld.so.conf and rerun ldconfig
- add FOO to the environment variable LD_LIBRARY_PATH at run-time (which
is a colon separated list like PATH)
- hard-code the path when linking your program, e.g. -Wl,-rpath,FOO
- hard-code a rpath, but by adding FOO to LD_RUN_PATH at link-time
instead of changing the link command

There are all sorts of various philosophies about the best way to handle
this topic.  Adding the path to the dynamic linker's global search list
(ld.so.conf) is probably the most direct and simple, but it requires
root.  Sometimes you don't have that, such as if you are a mere user of
the system and want to install gcc under your home directory.

Adding it to LD_LIBRARY_PATH is the next most simple, but the problem
here is that this environment variable must contain the location every
time the app is run, not just when it was linked.  This means adding it
to your shell startup scripts somewhere or otherwise having it always
set.  This can get complicated if you start to accumulate multiple paths
that need to be added, or if you have two dirs with similar but
incompatible SONAMEs and so requiring different settings of the variable
for the different apps.  Sometimes people write wrapper scripts that set
LD_LIBRARY_PATH and then invoke their app to simulate the need for it
not to be set.

Using an rpath -- either by giving it directly on the link command or
setting LD_RUN_PATH at link-time -- has the desirable quality that it
only need be set once, at link-time.  The value is hard coded into the
linked executable and that file forever knows where to search for its
shared libraries.  The problem is evident: if you need to later move or
upgrade those shared libraries you need to relink everything.

You don't have to worry about any of this with the system provided
compiler because the packages from your distro put shared libraries in
the standard locations that the dynamic linker already knows to search
for, such as /lib and /usr/lib.  If you really know what you are doing,
you can do this too.  However, this is extremely dangerous because your
package manager expects to be in control of those dirs and it might
overwrite your copies when you upgrade packages later.  This is in
addition to the very real problem of ABI versioning that can be rather
complex.  It's much safer and more direct to just to keep your
self-compiled things sequestered in their own place under /usr/local (or
whereever you prefer, such as under $HOME) away from the package
manager, and deal with telling the dynamic linker about them using one
of the above methods.

If you don't address the issue at all, i.e. do none of the above, then
your program *may* work or it *may* fail.  The problem is that there
will be a version difference between the shared libraries that the
program was linked with and what is found by the dynamic linker at
runtime -- keep in mind these are two different linkers!  At runtime the
dynamic linker will find the system copy in /lib or /usr/lib (because
you didn't tell it to search elsewhere), but at link time the version
used will correspond to the version associated with the gcc used to
link.  On GNU/Linux systems most important shared libraries like
libgcc_s and libstdc++ use symbol versioning, the purpose of which is to
gracefully allow such a difference.  However this concept can only work
in one direction -- a newer version found at runtime than at linktime. 
It can't work in the other direction.  This generally means that the
distro can upgrade the system copy to a newer version without breaking
backwards compatibility and having to relink everything, but if you
built a newer gcc than the system gcc you're in for trouble if the
dynamic linker finds the older version in the system location at
runtime.  But maybe you just get lucky and the interfaces you happened
to use were compatible between the versions.  It's kind of a version of
russian roulette though, so you can't in good faith ignore this issue
and hope everything will just work out.

Brian

Re: g++4.4 - managed to compile but can't run g++

[Tom Browder]

On Sat, Aug 23, 2008 at 12:42 AM, Brian Dessent <brian@dessent.net> wrote:
> Simon Hill wrote:
...
>> "cd /make/gcc-4.4-20080808"
>> "mkdir target"
>> "cd target"
>> "../configure --disable-multilib"

And don't forget about the possible consequences of a build in or
under the gcc source tree--possible the cause of your build problems
(failure to follow recommended configuration, see fifth para. on this
page http://gcc.gnu.org/install/configure.html ). [Note: I believe the
recommended procedure should be turned into a mandatory one, and the
build procedure prohibited from continuing if the rule is not
followed.]

> configure your gcc to have a different name.  For example if you used
> --program-suffix=-4.4 then after "make install" you would have gcc-4.4,
> g++-4.4 and so on.
...

I have used the --program-suffix=-X.Y.Z method for many years and many
versions and it has never failed me.  It obviates many of the concerns
Brian mentions.  I highly recommend it.

-Tom

Re: g++4.4 - managed to compile but can't run g++

[Tom Browder]

On Sat, Aug 23, 2008 at 6:32 AM, Tom Browder <tom.browder@gmail.com> wrote:
...
> (failure to follow recommended configuration, see fifth para. on this
> page http://gcc.gnu.org/install/configure.html ). [Note: I believe the
> recommended procedure should be turned into a mandatory one, and the
> build procedure prohibited from continuing if the rule is not
> followed.]

I have filed an enhancement proposal.  See bug # 37210:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37210

RE: g++4.4 - managed to compile but can't run g++

[Simon Hill]

Thanks heaps Brian, that explained it perfectly.
I now have it working and compiling c++0x code including ctor() =delete;

I did end up recompiling using "--program-suffix=-4.4 --prefix=/make/gcc-4.4"
And thanks Tom, I did end up compiling it inside a directory outside the source.
I'm specifying the library path during link (Option 3) cos I'm not
really a big fan of OS global stuff.


Just finished test suite.

        === gcc Summary ===

# of expected passes        52487
# of unexpected failures    6
# of unexpected successes    7
# of expected failures        193
# of unresolved testcases    2
# of unsupported tests        721

        === g++ Summary ===

# of expected passes        18222
# of unexpected failures    1
# of expected failures        81
# of unsupported tests        241