inline functions are the culprit?

[David O'Toole]

> OK .That's machine good for me too. Its pwgen ( in his own cvs subdir) the
> one that shows the problem

Yup, this is it:

--------------
octal: ./pwgen.so: dlopen() returned NULL.
octal: dlerror() gives <./pwgen.so: undefined symbol:
NextSamp__10Oscillator>
--------------

Which probably corresponds to NextSamp(void). Indeed, doing "nm
pwgen.cc" showed no NextSamp. On further snooping this looks like the
compiler is dropping your inline functions. 

NextSamp is declared inline in both the header file and the cc file. But
it is only defined in the cc file, and since pwgen.cc includes just the
header file, the definition of NextSamp isn't available when pwgen.cc is
compiled. So it can't be inlined anyway. But for some reason the
compilation of OSC.O makes the inline functions disappear. Sure enough,
'nm' reports that the .o file has no "out-lined" copies present, there
is no symbol for it in osc.o. They're getting optimized out, even though
-fno-implement-inlines does not seem to be set. So the pwgen.cc will
compile fine, but when it comes time to link it there will be no
existing definition of NextSamp. 

I removed "inline" from both the header and CC file and recompiled.
Suddenly osc.c contains a symbol for NextSamp (exactly the one that's
reported missing above.) So that would appear to fix the problem. 

You could:
    1. make the functions not inline, or
    2. move the definitions into the actual header file osc.h so that
    compilation of pwgen.cc will have access to the code at compile
    time.

By the way, I like your use of $(BASE)/octal and $(BASE)/octalmachines.
Perhaps we could use an environment variable for each user, called
OXBASE? (To build your makefiles I had to change the definition of BASE,
but if we all agree to make an environment variable, this will be
simpler.) 




-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal