missing symbols with bobcat C++ library on armel

[Frank B. Brokken]

Dear Ian Lance Taylor, you wrote:
> 
> "Frank B. Brokken" <f.b.brokken@rug.nl> writes:
> 
> > class MultiStreambuf: public std::streambuf
> > ...
> 
> > You won't see the implementations of the private virtual members here, as they
> > are provided in the following header file, which is included by
> > MultiStreambuf's sources: 
> >
> > -------------------------------------------------------
> > #include "multistreambuf"
> >
> > #include <algorithm>
> > #include <bobcat/fnwrap>
> >
> > using namespace FBB;
> >
> > inline std::streamsize MultiStreambuf::xsputn(char const *buffer, 
> >                                               std::streamsize n)
> > ...
> > -------------------------------------------------------
> 
> 
> This approach will only work if you guarantee that every piece of code
> that creates a new MultiStreambuf includes that header file.

I'm not sure if I follow you here. All MultiStreambuf sources include the
above header, and no other (external to MultiStreambuf) functions need/have
access to MultiStreambuf's private members. 

So I guess you do not mean by 'creates a new MultiStreambuf' constructions
like:
    void fun()
    {
        MultiStreambuf ms;
        MultiStreambuf *msp = new MultiStreambuf;
    }

Btw, this approach, which uses an 'internal header' to minimize the
requirements that need to be specified in class's header files is extensively
documented in section 7.9 (near the end) of my C++ Annotations
(cf. http://cppannotations.sourceforge.net/cppannotations/html/cplusplus07.html).
If you think the approach outlined there is somehow flawed, I would appreciate
receiving your thoughts.



> > Since it looks like armel's compiler skips the inline definitions of virtual
> > members when compiling for a shared library, we're in the process of removing
> > all inline definitions of virtual members, replacing them by non-inline
> > definitions in separate source files. From tests done so far by George Danchev
> > we get the impression that this might very well solve (or bypass?) the issue.
> 
> Yes, that should work.


The new library is already available, and I think George will test it out on
armel RSN. We'll see what he'll find.

But in any case: thanks for your help, so far!

Cheers,

-- 
    Frank B. Brokken
    Center for Information Technology, University of Groningen
    (+31) 50 363 9281 
    Public PGP key: http://pgp.surfnet.nl
    Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: Digital signature
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20110525/de8208d9/attachment.sig>