Text 5599, 84 rader
Skriven 2006-04-01 19:55:00 av Paul Rogers (1:105/360.0)
     Kommentar till en text av Maurice Kinal
Ärende: Multiple GCC versions
=============================
I could be being betrayed by my previous experience with other
systems.  The way I'm thinking of it is similar to cross-
compiling, or even using two different languages.  But I've got
to make sure I understand how this works for Linux, that's why I
keep pounding on it.

In effect, GCC-3.2.1 defines/allows a slightly different syntax
than GCC-3.4.3.  Well, strike "slightly".  Consider it a totally
different language, "glorp", instead of a "dialect" of c++.  A
separate glorp compiler could compile programs that would use
the shared libraries, couldn't it?

 MK> Yes but the g++ version needed to successfully compile kde uses
 MK> libstdc++.so.5 and not libstdc++.so.6 so you're either
 MK> stuck with the older gcc as the default compiler or have a
 MK> backup one that builds and links to libstdc++.so.5.  I

How does it do that?

I expect the compiler to build an "external reference" for every
function call it doesn't have a subroutine for.  Then I expect
the linker to replace those with a call to ld-linux.so.2 with a
parameter list that identifies the required shared library,
routine, and destination parameter list.

The question is: where does it find ld-linux.so.2 (which already
knows where it is going to look for the libraries)?  LFS has a
couple steps where it "adjusts the tool chain".  It does that by
changing the compiler's spec file.

I figure, if I have it look at the system /lib rather than
/opt (where the 3.3.4 compiler built itself this afternoon) then
the compiled code would use the system ld-linux.so.2.  KDE-3.1's
configure and Makefile already refer to the system header files
and libraries.

 MK> I've never tried that but I suspect it isn't that 'easy'

Maybe I'm confused, but it seems to me LFS does that a couple
times as it builds the first "static libraries" on the host
system, and then uses those in a chroot environment to build the
final shared libraries.

 MK> and I can't for the life of me figure out why you'd want

I want to compile KDE written in it's old c++ "dialect" but run
it with the rest of the system with the same shared libraries.
Trying to run different programs that use different versions of
libstdc++ seems to be asking for trouble, to me.

 MK> Tell that to whoever is responsible for kde.  I doubt the
 MK> gcc people care if kde is keeping up with them.

Oh, I expect since KDE-3.1 they've corrected all the syntax
errors the new compilers insist on.  But those are in
KDE-3.[2-5], and drag in a lot of new dependencies I don't want.
Maybe if I knew there was something in KDE-3.[2-5] I knew I just
HAD to have...  ;-)

I'm not sure if I'm going to push on to OpenOffice, that would
enable me to quit using Windows/Office and still deal with its
files.  That remains to be seen.  The docs I saw suggest it
would take 4-5 DAYS to compile!  I think before that I'd build
SAMBA & Apache, etc., for my LFS-4.1 and replace my RHL-7.3 file
server.

 PR> compiler that accepts the syntax allowed by GCC-3.2.1 with the
 PR> headers for libstdc++.so.6, so the binaries would use the new
 PR> library.
 MK> Sounds like fun.  ;-)

Maybe it's because I'm building my systems with LFS, rather than
just using "commercial" distros.  I've learned a lot in the past
year!  Pascal helped a lot.  Say, has he gotten email fixed yet?

Paul Rogers, paulgrogers@yahoo.com                       -o)
http://www.angelfire.com/or/paulrogers                   /\\
Rogers' Second Law: Everything you do communicates.     _\_V

... Of course, I could be wrong ..... Naaah!
___ MultiMail/MS-DOS v0.35

---
 * Origin: The Bare Bones BBS (1:105/360)