I wish to build a local install of gcc 4.9.2. In order to make sure I do not clobber the native gcc install and the glibc and include files, I was thinking of doing it within a local bin directory within home then including that first in my PATH.

I believe there are flags to tell gcc to build a local install only with no attempt to install in the standard directories and when compiling using that local install of gcc to tell the linker where to look for the include files (will probably add it to my makefile to avoid having to repeatedly type it).

Since I am doing this on Slackware 14.1 I thought I should ask here first, but can conceivably move it to the programming forum if appropriate.

I think checking LFS documentation would help you a bit.
Maybe asking on #lfs-support (freenode), even knowing it is not a LFS question they might help (a lot).

or
use the compiler option from
"--program-suffix=492"

in among the tons of options for building gcc
( ./configure WILL NOT DO IT )

add the configure option to add 492 to the end of the program name

then use "alternatives " or a bash shell script to reset the default compiller nd the links in /uer/bin
gcc4.3 > gcc
cc4.3 > cc
g++4.3 > g++
-- and so on ---

---- the 4.9.2

gcc492 > gcc
cc492 > cc
g++492 > g++
-- and so on ---

It looks like you are trying to enable me to distinguish between my compiled version of gcc and the native one that came with Slackware. I am trying to avoid any conflicts and avoiding clobbering the native install of not just gcc but also the include files and glibc by essentially compiling it from source and placing the whole shebang of gcc, include files, glibc etc into a /home/user/bin/gcc directory (in other words install as user rather than root) and either include that bin directory as the first entry in my PATH env variable or else explicitely specify the compiler including it's path in my makefile, I also need to tell the linker where the include files are with each compilation. By researching a bit I believe invoking configure with --prefix=/home/user/bin/gcc should do the trick of installing into that directory rather than in the standard locations within the / root subdirectories. I am compiling as we speak. Will see how it goes. I will do make install as user so there is no chance of clobbering the main gcc install.

well if you do want to build gcc and EVERYTHING it needs is a alternet location
that is a lot of programs
including all the auto tools

have fun

The LFS documents will be best done for this. You might want to see about going about using /opt for this. /opt is good for adding custom extras and binary only distributions of packages not normally found. A directory like /opt/gcc might be what you're looking for.

The way I do that is to configure with a separate prefix, like --prefix=/usr/gcc492 and then create a small wrapper which sets up the environment to use it, instead of prefixing the normal PATH with the new path. Say, I name the wrapper GCC492 and whebn I want to use that compiler I simply give the command:
GCC492 make (or whatever command you wanted to use)
The contents of the wrapper would be:

this is what I have done to use a new gcc at a old RHEL (6.5) workstation

to use it, I source a file containing this

I have also a local cmake and use cmake for my projects, it works,

on Slackware I am happy with 4.8, so I did not test thits , but I assume it will work the same way

easiest is:

* remove /usr/local from /etc/ld.so.conf
* remove /usr/local from PATH

you can now build whatever your pre-requisites allow, installing to easy default: /usr/local

> tovalds likes sharks with lasers? yea but he gets paid - easy not to care that way. anybody makes money that way, anybody !

======================
you issue is: you start pumping options to gcc which does the right thing. but then all programs in the "tool chain" must also accept the options without failure.

some progs might not even have configure

a few, like say libattr (XFS) have only debian hacked version available and install to /usr/ even when the --prefix= option is given 2x

there's also such a thing as broken Make scripts, where it should use bins from /usr/local/bin by default, but hardcodes /usr/bin/foo. so you might find while some allow --prefix= that not all actually work when you do it

i've also found some are hacked or anicent like "ncurses" where --prefix= has an unusual default (not /usr/local)

========================
i'd bet whoever posted this never tried it:

--prefix=$HOME/local/opt/gcc-4.9.2 \
--libdir=$HOME/local/opt/gcc-4.9.2/lib \

i'm going to bet (tentatively) if i read gcc's configure that:

LIBDIR="${prefix}/${libdir}"

--exec-prefix=EPREFIX == [PREFIX]

gcc...glibc? i've sofar found hundreds obstructions, some suspicous clooges, other mistaken, no real guide to go by (ie, no trusted source that has all pkgs needed, no list of required easy to find, etc)

i had missing sources where only available source is "packaged to work only in fee's linux distro with fi pkg installer". libattr was one, even libtermcap (only old one is on gnu.org that doesn't make a .so at all! no filewatcher.org doesnt know either.)

so, after gcc ... glibc i made a chroot (after recompiling to put in what i'd mistakenly left out)

i got a login

there are many gotchas going from scratch, many mystery options (ie, due to new gcc --std and etc). in the end you'll end up without allot of support (a minus) but also be without allot you didn't need (a plus) - unless your really planning to do all the work submitted by all people on some distro like BSD or Debian all by yourself. so it's definitely not advised - i mean in BSD there's a way to build sources and keep OS compatible. you build it yourself: you don't know what may no longer work with what.

but once things are done correction: it all runs and installs with a breeze

i build X11R7 using older linux distro: it worked i didn't need upgrade. (required many patches i posted). for gtk (new firefox needs) i needed newer glibc. also works but many more obstructions than X11R7 build (meaning all 300 pkgs) - way more - just to build several pkgs to get glibc.

=======================
definitely go with a distro (one that likes building source) unless you dont mind having a 1/2 baked, non-recyclable, system that costed allot of time

You can install gcc with:

But if you want also custom glibc to be used with custom gcc then you should read glibc and toolchain HOWTO from http://www.tldp.org