Text 5601, 111 rader
Skriven 2006-04-02 13:00:04 av Maurice Kinal (1:140/13.1)
   Kommentar till text 5599 av Paul Rogers (1:105/360.0)
Ärende: Multiple GCC versions
=============================
Hey Paul!

Apr 01 19:55 06, Paul Rogers wrote to Maurice Kinal:

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

Yes but in this case glorp is building the shared library, as well as the
static, not simply using it.  Therefore the glorp source code would have to be
modified to build a different shared library for things that don't like the new
glorp shared library.

 PR> I expect the compiler to build an "external reference" for every
 PR> function call it doesn't have a subroutine for.

See above.  libglorp++.so.x is built by glorp and if something further on wants
libglorp++.so.y then it would be simpler to use the version of glorp that
builds libglorp++.so.y.  No?

 PR> The question is: where does it find ld-linux.so.2 (which already
 PR> knows where it is going to look for the libraries)?

gcc or g++ isn't responsible for ld-linux other then to compile it when
bootstrapping the system.  g++ owns libstdc++ and is directly responsible for
it, good or bad.

 PR> couple steps where it "adjusts the tool chain".  It does that by
 PR> changing the compiler's spec file.

Yes.  However that doesn't change whether it is compiling libstdc++.so.5 or
libstdc++.so.6 for further use by whatever apps use c++ code.  Other shared
libs don't directly belong to gcc despite being built by it.

 PR> I figure, if I have it look at the system /lib rather than
 PR> /opt (where the 3.3.4 compiler built itself this afternoon) then
 PR> the compiled code would use the system ld-linux.so.2.

Right, but the compiler version determines if libstdc++.so.5 or libstdc++.so.6
is linked in the case of c++ code.  If you use straight c code then this isn't
even an issue.

 PR> KDE-3.1's
 PR> configure and Makefile already refer to the system header files
 PR> and libraries.

Right again, but not which libstdc++ and if not to kde's liking then you're
stuck not being able to run kde nevermind compile it.

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

No only static but shared as well.  Bootstrapping is what it's called methinks.
 The first stage you'll still have some leakage from the system you are
building from and by the time you are chrooted and doing the final builds, you
should end up with an independent system, althought not quite since some source
will still have leakage in a chrooted enviroment.  I always build the kernel
twice, once while chrooted and again after finally booting the newly built
enviroment.  That way the new kernel is only dependant on the new enviroment.

 PR> I want to compile KDE written in it's old c++ "dialect" but run
 PR> it with the rest of the system with the same shared libraries.

Understood.

 PR> Trying to run different programs that use different versions of
 PR> libstdc++ seems to be asking for trouble, to me.

Not if you use the system's gcc since it'll be forced to use libstdc++.so.6
despite libstdc++.so.5 being present.  Unless you specify
CC=/opt/gcc-x.x/bin/gcc when building whatever c++ source then libstdc++.so.6
is the default c++ shared lib.

 PR> Oh, I expect since KDE-3.1 they've corrected all the syntax
 PR> errors the new compilers insist on.

Beats me.  I haven't bothered checking.

 PR> But those are in
 PR> KDE-3.[2-5], and drag in a lot of new dependencies I don't want.
 PR> Maybe if I knew there was something in KDE-3.[2-5] I knew I just
 PR> HAD to have...  ;-)

I see nothing.  Looks glitzy but nothing there worth the vastly too many bytes
it takes.  All the good stuff doesn't require kde.

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

Again, I don't know.  I haven't looked at OpenOffice as there is nothing there
that I would ever use or find useful.

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

Yes.  I haven't had any problems reaching him.  He has been busy as of late but
he eventually answers.  The address on the site should work.

Life is good,
Maurice

--- Msged/LNX 6.2.0
 * Origin: The Pointy Stick Society XIX - Simplify man! (1:140/13.1)