Help needed desperately, inlining problem

[Robert Schweikert <rjschwei at mindspring dot com>]

Attached is a rather lengthy .i file which compiles just fine, but does
not link. The problem is that gcc-2.95.2 generates 4 unresolveable
symbols. 2 of the symbols appear to be compiler generated and 2 are
created as function calls to inline functions, i.e. the compiler does
not inline what should be in lined. On line 49866 a method named
"fieldOutputRequestRepositoryCmd" is defined as follows:

static omn_FixedString fieldOutputRequestRepositoryCmd() {
        static const omn_FixedString cmd = { "fieldOutputRequest" };
        return cmd;
    }

and on line 49880 a method named "historyOutputRequestRepositoryCmd" is
defined in the same way. Both methods are defined in "bas_NewModel.h"
and methods of the "bas_NewModel" class. The methods are called on lines

51819 and 51843, respectively. Instead of expanding this call g++
generates the symbols "fieldOutputRequestRepositoryCmd__12bas_NewModel"
and "historyOutputRequestRepositoryCmd__12bas_NewModel", respectively.
Since there is no real function these symbols are undefined and things
go wrong at link time.

To verify the problem:

> g++ -c inlinePrb.i
> nm -Bg inlinePrb.o | grep history
         U historyOutputRequestRepositoryCmd__12bas_NewModel
> nm -Bg inlinePrb.o | grep field
         U fieldOutputRequestRepositoryCmd__12bas_NewModel


The question now of course is how do I need to change the code to make
the compiler do the right thing and inline these methods?

I have tried loads of things, creating a local variables and using it in

the equivalence test, (failed),  creating temporaries at the point of
call (failed). I have tried moving the definition around in the class
(failed), I have tried not using the methods in other inline methods
(i.e. commented out code in lines 49877, 49873, 49887, 49891) (failed).
When I move the definition outside of the bas_NewModel class the
inlining worked, another problem persisted (see below); and when I
created a new class "bas_NewModel2" that contains only these two methods

it works as well. Is there as size problem?

Although I can work around whatever problem I am triggering with the
last to tricks mentioned above I would much prefer to find a proper
solution. Further, the work around still leave me with two compiler
internally generated symbols which are undefined at link time and I
can't appear to get rid off. Since I don't understand how and why these
are generated I am at a loss trying to figure out what to do to fix
them. The symbols are "__tf16dbm_P0AdoPtrBase" and
"__ti16dbm_P0AdoPtrBase".

I know the file is rather large, however, I didn't want to chop it up
since I do not know what parts of the file have no meaning when
analyzing this problem.

Any help is appreciated. Since I don't know where to look in the g++
code to try and understand what's going on and I don't understand why
the inlining works in some cases but not in others and I don't
understand why the internal symbols are generated I am more or less at a

stand still. All I can do is guess around and try stuff, which is
generally not very satisfying.

Is there an online server somewhere to test this code in the development

branch?

Thanks.
Robert

--
Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei@mindspring.com                         LINUX

inlinePrb.i.gz