string class (almost there!)

[Jason Merrill]

>>>>> Jim Peterson <jspeter@roanoke.infi.net> writes:

>   This time, however (thanks to suggestions from Jason Merrill and Jeff Law),
>   I've noted that modifying the compilation as follows:

> g++ -o t t.cc /usr/lib/libstdc++.a

>   succeeds, and './t' yields the appropriate 'Hello, world!'.  This
>   prompts me to ask more questions, though:

Did you install egcs into /usr?

>     a.  How do I make linking with /usr/lib/libstdc++.a the default
>     action?

You shouldn't have to.

>     b.  What other version of libstdc++ was being used, if any?

Try 'ldd t' on the executable to see what shared libs it's using.

>     c.  Will linking with libstdc++.a make statically-linked executables which
>         are larger than those generated by gcc, and is there a way to get
>         dynamically-linked ones?

Yes, and link against libstdc++.so.

>     d.  If I generate a dynamically-linked executable with a non-standard
>         libstdc++, will it be portable?

No.

>     e.  How/Why are template functions and template class methods instantiated
>         and placed in a library instead of being in the appropriate
>         include files and instantiated upon demand?

With explicit instantiation directives, and to avoid putting all the code
in the include files.

>   I think only the first question really pertains to this mailing list.
>   The remaining questions really just demonstrate the borders of my
>   ignorance in this area.  I would truly appreciate anyone taking the
>   effort to help me push back these borders (and, for that matter, also
>   with the issue of why there's a libstdc++.so.27.2.8 _and_ a
>   libstdc++.so.2.7.2.8 on my system, what the difference is, and which,
>   if either, I could safely remove).

No libstdc++.so.2.8.0?  You should remove both of them.  You're probably
getting one of those, which would be why you're having problems.

Jason