Re: how to combine gcc and binutils source into one tree

Re: how to combine gcc and binutils source into one tree

[steve]

the linux kernel docs say use gcc 2.95.3 and the latest binutils. However
some   packages like glibc won't build with 2.95.3 so you end up with 2
versions of gcc and 2 versions of binutils on the same system. While you
can manage this, should you get your wires crossed it could make for some
strange results. Perhaps I'm making the wrong approach, in the end I just
want two seperate toolchains. Since I will be putting both versions on
multiple machines I'm looking for a good way to package everything. I'll
post any success in doing this.

Re: how to combine gcc and binutils source into one tree

[David Kramer]

On Mon, 30 Aug 2004 steve@millersnet.net wrote:

> the linux kernel docs say use gcc 2.95.3 and the latest binutils. However
> some   packages like glibc won't build with 2.95.3 so you end up with 2
> versions of gcc and 2 versions of binutils on the same system. While you
> can manage this, should you get your wires crossed it could make for some
> strange results. Perhaps I'm making the wrong approach, in the end I just
> want two seperate toolchains. Since I will be putting both versions on
> multiple machines I'm looking for a good way to package everything. I'll
> post any success in doing this.

Ah! I see.  I'm going through similar issues now.  I think the solution to 
your problem is not to control how they are built, but how they are 
installed.  If you configure and make them with --with-prefix=, you can 
install them in different places, and have your $PATH set up one way or 
another to use one version or another.

In my login scripts I have:
$ORIGPATH- the path without any devel tools, so I can always get a clean 
path without duplcation.
$PATH- Set to $ORIGPATH
$GCC340PATH- Set to the bin directories for gcc 3.4.0 toolchain
$GCC333PATH- Set to the bin directories for gcc 3.3.3 toolchain
$XLCPATH- Set to the bin directories for the native xlC toolchain

To switch toolchains, I just issue a command like
export PATH=$GCC340PATH:$ORIGPATH
Or make scripts (remember to source them, not run them) or aliases to do 
the same thing.

If you decide to install them under opt, use --with_prefix=/opt/gcc3.3.3
or --with_prefix==/opt/gccc3.4.0 or whatever.  To package them all up,
install all the versions on one machine, and tar up the installed versions
like "cd /opt; tar cvf /tmp/gcc_all.tar gcc*".  Everything goes under the
prefix directory, so that should work.


----------------------------------------------------------------------------
DDDD   David Kramer         david@thekramers.net       http://thekramers.net
DK KD  
DKK D  You don't usually hear "hydraulics" and "simplicity" 
DK KD  in the same sentence.
DDDD                                             Cathy Rogers, Junkyard Wars

Re: how to combine gcc and binutils source into one tree

[steve]

ok that seems to be an easier way to handle things. I'm wondering which
will work better when configuring gcc use --with-prefix=/opt/gcc-2.95.3
and when configuring binutils use --with-prefix=/opt/binutils-2.15 this
would keep everything contained to their own directories or gcc use
--with-prefix=/opt/gnu and binutils use --with-prefix=/opt/gnu ..... would
the latter work as well seeing how both gcc and binutils have common
components?

Re: how to combine gcc and binutils source into one tree

[David Kramer]

On Mon, 30 Aug 2004 steve@millersnet.net wrote:

> ok that seems to be an easier way to handle things. I'm wondering which
> will work better when configuring gcc use --with-prefix=/opt/gcc-2.95.3
> and when configuring binutils use --with-prefix=/opt/binutils-2.15 this
> would keep everything contained to their own directories or gcc use
> --with-prefix=/opt/gnu and binutils use --with-prefix=/opt/gnu ..... would
> the latter work as well seeing how both gcc and binutils have common
> components?

Each package needs a different --with-prefix option.  That's the least 
risky way to do it.  You can settle any conflicts with your $PATH, and you 
can even try differernt gcc's with different binutil's that way.  Though 
doing
--with-prefix=/opt/gnu/gcc-2.95.3
--with-prefix=/opt/gnu/binutils-2.15
...
...

wouldn't be a bad idea, so you can just tar up /opt/gnu.


-- 
DDDD   
DK KD  
DKK D  Bush/Cheney '04: Putting the "Con" in Conservative
DK KD  
DDDD   

how to combine gcc and binutils source into one tree

[steve]

>they have common directories libiberty,include,texinfo,config, etc....
>what is the best way to merge them?
>
>
>thanks in advance
>Steven

I ask this question last week, is this not the right list for this question?

Re: how to combine gcc and binutils source into one tree

[Eljay Love-Jensen]

Hi Steve,

 >I ask this question last week, is this not the right list for this question?

This is the right list for your question.

This list is a user-community volunteer list.  Questions are posed by 
anyone, worldwide, and answers are provided by anyone, worldwide.

Those who regularly answer questions are, what I'd call, self-nominated 
"experts" on GCC.  There's only a few that are part of FSF or GCC 
developers per se.

So if you ask a question that no one on the "panel of experts" can answer, 
you end up with (in radio terms) dead air.

I know that this doesn't answer your initial question, but it does explain 
why no one volunteered an answer.

I, for one, do not know the answer to your initial question.  I'm more of a 
"C++ language lawyer" than a "nitty gritty internals of GCC guru".

--Eljay

Re: how to combine gcc and binutils source into one tree

[David Kramer]

On Mon, 30 Aug 2004 steve@millersnet.net wrote:

> >they have common directories libiberty,include,texinfo,config, etc....
> >what is the best way to merge them?
> >
> >
> >thanks in advance
> >Steven
> 
> I ask this question last week, is this not the right list for this question?

I will give it my best shot, but I am acutally new to compiling 
gcc/binutils myself.  Gaining Way Too Much experience in it in the last 
week or so though.

In combining projects like this in general, if those common directories 
have completely identical contents, then you can pull it off.  The way you 
integrate them is by changing the master Makefile to call the new 
directories too, and to make sure the install targets for the new 
directories get called too.

If I were a betting man (which I'm not), I would try something devious 
like:

- Untar package A into DIR1
- Untar package B into DIR2
- Copy the unique directories from package B to DIR1
- Copy the main Makefile of package B to $DIR1/Makefile.packageb
- cd $DIR1
- Configure and make package A
- Make package B using the makefile Makefile.packageb
 
One obstacle I fear is that their configure scripts will need different 
things.

I would be fascinated to hear whether this works or not.  Let me know.

I would also be interested in hearing why you want to do this though.  TO 
save 20 minutes of compile time?

----------------------------------------------------------------------------
DDDD   David Kramer         david@thekramers.net       http://thekramers.net
DK KD  
DKK D  You don't usually hear "hydraulics" and "simplicity" 
DK KD  in the same sentence.
DDDD                                             Cathy Rogers, Junkyard Wars

how to combine gcc and binutils source into one tree

[steve]

they have common directories libiberty,include,texinfo,config, etc....
what is the best way to merge them?


thanks in advance
Steven