> It's not Windows only; it affects all platforms. Until it gets fixed, you
> can just compile your module directly into the server. The process for doing
> this is documented in the QTSS API docs.
Huh. Interesting. Well, FTR, I was able to debug it so that the
module loaded. To attempt to debug the problem (on Linux), I instrumented
the code so that in OSCodeFragment::OSCodeFragment, if the dlopen call
returned NULL, it would also fprintf(stderr, "%s\n", dlerror()).
I found that I was missing various symbols so I went and linked in
additional .o files from the source tree and then the module loaded
and my module was called in the Register_Role and Initialize_Role.
The other option was to change Makefile.POSIX in the top-level to
link DarwinStreamingServer with -rdynamic. This has roughly the
same effect as linking in additional object. From dlopen(3):
External references in the library are resolved using the
libraries in that library's dependency list and any other
libraries previously opened with the RTLD_GLOBAL flag. If
the executable was linked with the flag "-rdynamic", then
the global symbols in the executable will also be used to
resolve references in a dynamically loaded library.
So since the symbols I was missing happened to be defined in the
server, using -rdynamic also did the trick.
If this is an outstanding bug, it seems like these are
functional workarounds. The latter workaround is probably not
very portable (though in GNU ld, -export-dynamic seems to dtrt).
Also, I don't see anything on the publicsource bugs page which
seems to describe this bug. Is there a bug id which we can use to
track this bug?
--
Emil Sit / Cisco Systems, Inc.
